project-management - スクラムだけでアジャイルか?

Question

多くの企業がアジャイルのように振る舞っていると聞いていますが、彼らが行っているアジャイルはスクラム プロセスだけです。これはアジャイルと見なすのに十分でしょうか? スクラムを単独で使用することは、悪いマネージャーがより頻繁に会議を行うための完璧な言い訳のように思えます。私はそのような会社にうんざりすべきですか？

Answer 1

アジャイルは大きくて漠然とした概念です。多くのことがアジャイルです。

スクラムは、スプリントとリリースを行うための特定の一連のテクニックです。アジャイル マニフェストに適合するため、アジャイルです。

他にも多くの特定のアジャイル手法があります (たとえば、xDD のすべて)。

疑問がある場合は、企業の実際のプラクティスをアジャイル マニフェストと比較してください。

Answer 2

「アジャイルのように振る舞う多くの企業について聞いていますが、アジャイルなのはスクラム プロセスだけです。これでアジャイルと見なすのに十分ですか?」

簡単な答え - はい。とにかく私の意見では:-)

もちろん、名前を壁に貼り付けるだけではなく、実際にスクラムを実行する必要があります。スクラムには、毎日のスタンドアップ以上のことがたくさんあります...そして、それがすべてである場合、彼らはそれを正しく行っていません。

スクラムは、企業が組織の運営方法のボトルネックを特定することを強制します。定期的なタイムボックス スプリントを設定し、適切なフィードバック ループを取得し、責任をプロダクト オーナーとチーム間で適切に分割することで、プロセスを改善する方法に関する有用なベースライン情報を実際に得ることができます。

組織はそのフィードバックに耳を傾け、それに基づいて行動する必要があります。

アジャイルを行う唯一の方法ではないことは確かです。アジャイルを組織に導入する最良の方法ではないかもしれません。私自身、どちらかというと XP のファンです。追加のプラクティスは、これらのプロセスの改善を開始するための有用なフレームワークを提供することがわかっています。

とはいえ、多くの組織にとって最大の問題は、責任の不適切な分割と、健全で迅速なフィードバック ループの完全な欠如です。スクラムはそれをすぐに修正します。

会議はそのごく一部です:-)

Answer 3

悪いマネージャーは、スクラムが促進する透明性によって追い出されます。スクラムを真に取り入れている企業は一見の価値があります。

Answer 4

SCRUM を単独で使用することは、必ずしもより多くの会議を開催する言い訳にはなりません。毎日行われる作業を追跡し、スプリントの残りの作業を (作業を削減または再調整することによって) 変更する方法を決定できることは、それ自体が非常に便利であり、私には機敏に聞こえます。:-)

もちろん、アジャイル プロセスの他のコンポーネントがなければ、作業の成功を測定するのに時間がかかります。そのため、スプリントで順調に進んでいると考えているかもしれませんが、実際にはその点にはほど遠い状態です。高品質の製品をスケジュールどおりに納品する必要があります。

更新：その前提だけでそのような会社を却下するべきではありません。ただし、インタビュー中に、なぜ彼らが SCRUM のみを使用しているのかを理解する機会を利用する必要があります。TDD や CI のようなものを擁護する人がいないことが問題である場合は、テクニカル リーダーになりたいと考えている場合に適している可能性があります。これらのプロセスを「オーバーヘッド」、「愚か」、または「不必要」として却下していることが原因である場合は、その会社に注意する必要があります。

Answer 5

アジャイル！=スクラム。

アジャイルとは、変化への準備です。

アジャイルは、変化をサポートする環境で機能するための包括的な、さまざまな手法、方法のセットとして何度も提示されます。スクラムはプロジェクト管理用であり、開発技術用にはxpがあり、より良い要件プロセスのためにBDDを使用し、TDDをテストするために使用できます。

スクラムから始めることは、敏捷性の方法の最初のステップです。他の手法も検討してください。時間はかかりますが、本当のメリットがあります。そして、共通の理解と優れたチームスピリットに勝るものはありません。最初にそれを達成します。

Answer 6

スクラムは、何よりもまずプロジェクト管理の方法論です。はい、スクラムを行っている場合は、アジャイルであること、および顧客に価値を提供することについて、おそらくもっと考え始めているでしょう。しかし、必ずしも機敏になるとは限りません。まず第一に、スクラムはソフトウェア開発の方法については語っていません。ここで、XP のようなものが登場します。より効率的かつ効果的になるために、作業慣行を見直して変更することを強制する他の方法論やアイデアです。

ですから、「スクラムや XP などをやっていますか」と尋ねるのではなく、これらの企業に全体的なプロセスについて尋ね、全体論的な見方をします。企業は最大のビジネス価値を提供することに重点を置いており、継続的な改善の精神によって推進されていますか? もしそうなら、彼らはおそらくスクラムを行うと言っている人よりもはるかに機敏です.

Answer 7

誰かがスクラムをやっていると言ったからといって、チームがアジャイルかどうかを判断することはできません。

スクラムの実装には良い点と悪い点がありますが、アジャイルの重要な点は次のとおりです。

• プロジェクトとチームが柔軟に考える能力
• チームがどの程度自己組織化されているか (彼らにはコントロールフリークの「アーキテクト」またはマネージャーがいますか? または、かなりの量のコンセンサスによる意思決定が行われていますか?)

真にアジャイルでなくても、チームがスクラムを実行するために必要なことの最小要件に準拠するのは、あまりにも簡単です。これらの最低限の要件は、特定の態度と働き方を実現するためにのみ存在します。

プロジェクトの意思決定は、非常に柔軟性がなく、トップダウンで管理されていても、スクラムの最小要件に準拠している可能性があります。悲しいことに、契約契約を探すと、スクラム名のみの実装が実際のものよりもかなりの数であることがわかります。

個人的には、極端なプログラミングをスクラム内に実装することを選択します。(実際、Jeff Sutherland は、XP プラクティスを行わない最高の生産性スクラム チームを見たことがないと言います。) しかし、人々が XP を非常にうまく実装できないと確信しています... ;-)チームの姿勢に。

Answer 8

スクラム ミーティングだけを使用するだけで、会社がアジャイルの概念を正しく実装していないことを示す非常に明確な兆候であることに気付きました。

スクラム ミーティングがどれほど簡単かを考えてみてください。Outlook を起動して、全員に毎日 15 分間のミーティングを行うだけです。しかし、すべてを迅速なイテレーションに分割し、新しい機能がエンド ユーザーによって迅速にテストされるようにするには、さらに多くの作業が必要です。

ほとんどのマネージャーは、スクラムの部分の直後に読むのをやめて、興味を失っていると思います。しかし、彼らの毎日の会議出席依頼は永遠に生き続けます。

Answer 9

スクラムは、開発プロセスを修正/改善するためのフレームワークを提供します。これは、「ゼリー状のチーム」およびより生産的なチームへの出発点と見なされるべきです。ほとんどの場合、すぐに標準のスクラム プラクティスを超えることになりますが、開始点として、スクラムにはいくつかの魅力的な特性があります。

1. とても分かりやすいです
2. ほぼすべてのプロジェクトとチームに適用できます
3. お金を稼ぎ、スクラムの採用で企業を支援する人はかなり多い

また、スクラム = アジャイルかどうかを知ることはそれほど重要ではありません。生産性の向上に集中し、そのような質問に悩まされない方がよいでしょう。

Answer 10

ええ、私はここでの感情のいくつかに同意します. Be Agile とは、マニフェストに従い、優先順位が正しく調整されていることを保証することです。SCRUM は、特定の部分が書き留められた単なる別のバリ​​アントです。どちらかといえば、管理の「ツール」です。

そうは言っても、ツールは二次的なものであり、従業員が優先されることを忘れないでください。管理スタイルに過度に焦点を当てないでください。人と製品の代わりに焦点を当ててください。

Answer 11

スクラムのみを実践している組織は、ソフトウェア管理とプロジェクトの可視性が向上する可能性が最も高いでしょう。ただし、ユニットテスト、継続的インテグレーション、ペアプログラミングなどの XP の原則を取り入れないことで、より高いエンジニアリング品質とスループットの可能性を達成することはほとんどなく、Sprint の最終製品は「潜在的に出荷可能」ではありません。