あなたがスクラムマスター、プロジェクトマネージャー、プロダクトオーナー、チームメンバー、あるいは「現実世界でアジャイルなプロジェクトをどのように運営するか？」という問いに答えるために努力している人にとって—この記事はあなたが求める答えを必ず提供します。アジャイル スクラム現実世界でのプロジェクトをどう運営するか？」—この記事はあなたが求める答えを必ず提供します。
伝統的プロジェクトマネジメント
伝統的プロジェクトマネジメント（ウォーターフォール）アプローチは線形であり、プロセスのすべての段階が順次進行します。この方法は予測可能なツールと予測可能な経験に依存しています。各プロジェクトは、下図に示すように、実現可能性、計画、設計、構築、テスト、本番運用、サポートの各段階を含む同じライフサイクルを経ます。
ウォーターフォール対アジャイルソフトウェア開発
プロジェクト全体が事前に計画されており、要件の変更の余地がありません—ウォーターフォールやPMIのPMBOK、PRINCE2のように、厳格で高度に管理されたものであり、開始から終了まで明確な段階を示し、すでにすべての要件や必要な情報を持っていると仮定しています。
このアプローチは時間とコストを変数とし、要件は固定と仮定しています—これが伝統的プロジェクトマネジメントが予算やスケジュールの問題に直面しやすい理由です。
アジャイルプロジェクトマネジメント
伝統的なシステムは前もっての計画に大きく注力する一方で、コスト、範囲、時間といった要因が重要です。一方、アジャイルはチームワーク、顧客との協働、柔軟性を重視します。
アジャイルは伝統的プロジェクトマネジメントを退屈で制限的、そして急速に変化する現代社会に不適切だと拒否します。アジャイルプロジェクトマネジメントは反復的であり、開発の各反復においてユーザーのフィードバックを継続的に統合し、継続的なリリースを実現することを目指しています（上図参照）。各タスクの出力は、ステークホルダーに販売する製品です。チームとワークフローは顧客にとって直接的に役立つものを作り出すことに基づいて構成されています。
伝統的かアジャイルか—どう選ぶべきか？
スタンドィッシュグループによる2011年のCHAOSレポートによると、アジャイルプロジェクトはウォーターフォールプロジェクトの3倍の成功を収めています。以下の図は、2002年から2012年の間に実施された調査の具体的な結果を示しています。
ウォーターフォール対アジャイルプロジェクトの成功確率
伝統的とアジャイルの違い
以下の表は、スクラムと伝統的プロジェクトマネジメントモデルの多くの主要な違いを要約しています。
| カテゴリ | 伝統的 | アジャイル |
| 開発モデル | 順次的（ウォーターフォール） | 反復的 |
| 焦点 | プロセス | 人 |
| マネジメントスタイル | コントロール | ファシリテーション |
| 顧客の関与 | 要件定義および納品フェーズに限定される | 継続的かつ現場での関与 |
| 開発者の作業スタイル | チーム内で個別に作業する | 協働またはペアプログラミング |
| 技術 | 任意 | 主にオブジェクト指向 |
| 製品の機能 | すべての機能を含む | 最も重要な機能を最初に |
| テスト | 開発サイクルの終盤 | 反復的および／またはテスト駆動 |
| ドキュメント | 詳細 | 必要に応じて |
変更コスト
従来、ソフトウェア開発プロジェクトにおける変更は、プロジェクトの後半でコストが著しく増加するため避けられる傾向がある。アジャイルソフトウェア開発は、変更は避けがたいものであり、初期段階での過剰な計画投資は現実的でないと認識している。これはアジャイル宣言の4つの価値の一つに明確に表れている：
「固定された計画を優先するよりも、変化する要件に応じる。」
アジャイルはこの考え方に挑戦し、変更コストは図に示すように相対的に平坦であると主張している。
従来型とアジャイルにおける変更コスト
プロジェクトマネジメントにおけるアジャイルと従来型の鉄三角
プロジェクトマネジメントの成功は、従来、範囲、時間、コスト、品質の制約を管理する能力と関連づけられてきた。図に示すように、これはプロジェクトマネージャーがこれらの制約を適切にバランスさせることが期待されているという一般的な比喩である。
アジャイルと従来型プロジェクトマネジメントにおける鉄三角
伝統的な鉄三角の問題点は何ですか？
例えば、予算を増やすか範囲を減らすことで、プロジェクトをより早く完了できます。同様に、範囲を拡大するには、通常、予算とスケジュールの対応する増加が必要です。スケジュールや範囲を調整せずに予算を削減すると、品質が低下します。しかし実際には、制約間のトレードオフが常に可能であるとは限りません。たとえば、十分なリソースを持つプロジェクトにさらに資金（および人材）を投資しても、実際には進捗が遅くなることがあります。さらに、パフォーマンスが低いプロジェクトでは、品質に悪影響を与えることなく予算、スケジュール、範囲を改善することはしばしば不可能です。
したがって、伝統的な鉄三角は、ステークホルダーへの影響、学び、ユーザー満足度といった成功の重要な側面を無視しているため、プロジェクト成功のモデルとして明らかに不十分です。
アジャイル・鉄三角 – パラダイムシフト
伝統的なアプローチでは、三角形は以下の左側の図のようになります。ご覧の通り、製品要件は固定された範囲を持っています。したがって、製品がすべての必要な機能を提供できるようにするには、リソース（および予算）とスケジュール（納期）の柔軟性が必要です。初期の要件仕様に記載されたすべての機能を含む製品を絶対に必要とする場合、リリース日を数か月以上遅らせる必要があるかもしれません。
アジャイルの観点では、タイムラインが固定されています（スクラムでは、タイムボックス スプリントおよび固定されたリソースによって達成されます）。したがって、予定通りに進まない場合、範囲を縮小しなければなりません。しかしアジャイルでは、範囲を犠牲にしても、プロダクトバックログから最も優先度の高い項目を提供することを確保することで、プロジェクトが生み出す価値を最大化します。
アジャイル文脈における鉄三角
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish