従来のプロジェクト管理とアジャイルプロジェクト管理 (Classical Project Management vs Agile Project Management) : warren

(アジル、スクラム、アジャイル開発: Classical Project Management vs Agile Project Management)
)

あなたがスクラムマスター、プロジェクトマネージャ、プロダクトオーナー、チームメンバー、あるいは単に「現実の世界でアジャイルスクラムプロジェクトを運営するにはどうすればいいですか」という質問に対する答えを望む人であれ、この記事は間違いなくあなたに答えを提供できます。

従来のプロジェクト管理

従来のプロジェクト管理（ウォーターフォール）アプローチは、プロセスのすべてのフェーズが順番に行われる場合は線形です。アプローチは予測可能なツールと予測可能な経験に依存します。すべてのプロジェクトは、下の図に示すように、実現可能性、計画、設計、構築、テスト、生産、サポートなどの段階を含む同じライフサイクルに従います。

滝vsアジャイルソフトウェア開発

Waterfall、PMIのPMBOK、PRINCE2などの要件を変更する余地はなく、プロジェクト全体が事前に計画されているため、すべて厳格で管理されています。これらは、プロジェクト計画の最初から最後までの明確な段階を概説しており、必要な要件と情報がすべて揃っていることを前提としています。

このアプローチでは、時間とコストが変動し、要件が固定されていると想定しています。これが、従来のプロジェクト管理が予算とタイムラインの問題に直面している理由です。

アジャイルプロジェクト管理

コスト、範囲、時間などの要素を重視した従来のシステムが前もって計画を立てる場合、アジャイル管理はチームワーク、顧客とのコラボレーション、そして柔軟性を際立たせます。

アジャイルは、これらの伝統的なプロジェクト管理方法論を厄介で制限的であり、スピードの新時代には不適切であるとして拒否します。アジャイルプロジェクト管理は反復的で、上の図に示すように、ソフトウェア開発プロジェクトの反復ごとにユーザーフィードバックと継続的リリースを常に取り入れることを目的としています。すべてのタスク出力は、あなたが関係者に販売している製品です。チームおよび作業構造は、顧客またはクライアントにとって直接役立つものを作成することを中心に設計されています。

トラディショナルまたはアジャイル - 選択方法

Standish Groupによる2011年のCHAOS宣言によると、アジャイルプロジェクトはWaterfallプロジェクトよりも3倍成功しています。下のグラフは、2002年から2012年までに実施されたプロジェクトに基づいて実施された調査から報告された具体的な結果を示しています。

滝とアジャイルプロジェクトの成功率

伝統とアジャイルの違い

次の表は、スクラムと従来のプロジェクト管理モデルの違いの多くをまとめたものです。

カテゴリー	トラディショナル	アジャイル
開発モデル	トラディショナル	繰り返し
フォーカス	プロセス	人
管理	管理する	促進する
顧客の関与	要件収集と配信のフェーズ	オンサイトで常に関与している
開発者	チーム内で個別に作業する	共同またはペアで
技術	どれか	主にオブジェクト指向
製品の特徴	全部含めて	最も重要な最初の
テスト	開発サイクルの終わり	反復コードおよび/またはドライブコード
ドキュメンテーション	スルー	必要なときだけ

アジャイルソフトウェア開発は変更が避けられないことと詳細な計画への投資が現実的でないことを理解している間、伝統的に変更はゲームの後半で高い知覚コストのためにソフトウェアプロジェクトで避けるべきです。これは、アジャイルマニフェストの4つの値のいずれかで明確に表現されています。

「計画をたどることへの対応」

アジャイルはこの概念に異議を唱え、下の図に示すように、変更コストは比較的横ばいになる可能性があると考えています。

トラディショナルとアジャイルの変更コスト

プロジェクト管理におけるアジャイル対伝統的な鉄の三角形

下の図に示すように、プロジェクト管理の成功は、範囲、時間、コスト、品質の面でプロジェクトの制約パラメータが「アイアントライアングル」と呼ばれる能力に関連してきました。プロジェクトマネージャがこれらの制約の間で合理的なトレードオフを達成するよう求められていることを指摘するのは一般的な比喩です。

プロジェクト管理におけるアジャイル対伝統的な鉄の三角形

伝統的な鉄の三角形の問題は何ですか？

たとえば、予算を増やしたりスコープを削減したりすることで、プロジェクトをより早く完了させることができます。同様に、範囲を拡大するには、予算とスケジュールを同等に増やす必要があります。スケジュールや範囲を調整せずに予算を削減すると、品質が低下します。しかし実際には、制約間の取引は必ずしも可能ではありません。たとえば、十分にスタッフが配置されたプロジェクトにお金（および人）を投入すると、処理が遅くなる可能性があります。さらに、実行が不十分なプロジェクトでは、品質に悪影響を及ぼさずに予算、スケジュール、または範囲を改善することが不可能な場合があります。

従来の意味では、プロジェクト管理におけるIron Triangleは、利害関係者への影響、学習、およびユーザー満足度を含む成功の重要な側面を省略しているため、プロジェクト成功のモデルとして明らかに不十分です。

アジャイル感覚のアイアントライアングル - パラダイムシフト

従来のアプローチでは、三角形は通常、下の図に示すように左側のもののように見えます。ご覧のとおり、製品要件には一定の範囲があります。そのため、製品が必要な機能をすべて完了できるようにするためには、リソース（および予算）、およびスケジュール（期限）について少し柔軟に対応する必要があります。製品に最先端の要求仕様書に記載されている機能のリストが絶対に必要な場合は、おそらく実際にはリリース日を数か月以上遅らせる必要があります。

アジャイルの意味では、固定スケジュールがあります（スクラムでは、時間枠付きスプリントと固定リソースを通してこれを行います。したがって、計画通りに動作しない場合は、範囲を縮小する必要があります）。ただし、範囲を妥協しなければならない場合でも、プロジェクトによってもたらされる価値を最大化するために、製品バックログで最も優先順位の高い項目を提供しています。

機敏な意味の鉄の三角形

視覚的パラダイムについて

ビジュアルパラダイムは、変化の激しい今日の環境において、組織が競争力を維持しながら変化に迅速に対応できるように支援します。当社の受賞歴のある製品は、中小企業、コンサルタント、世界中の優良企業、大学、政府機関など、32万人以上のユーザーから信頼されています。2018年にアジャイル機能をさらに強化したVisual Paradigmは、スクラムチームがソフトウェアアプリケーションを作成、管理、展開する方法を自動化するためのスクラムプロセスキャンバスを導入しました。これまでにないスピードと規模でチームのパフォーマンスを継続的に向上させることができます。