アジャイルとウォーターフォール型プロジェクト管理

アジャイル開発を早期に導入したのは、たいていは小規模な自己完結型のプロジェクトで作業する、小規模な自己完結型のチームでした。これらの人々によって、アジャイル モデルが実用的で、世界中のソフトウェア メーカーに喜びと改善をもたらすことが証明されました。ウォーターフォール開発モデルは、ほとんどのチームにとってアジャイル プロジェクト管理ほどソフトウェア管理には効果的ではないことが判明しました。

アジャイル プロジェクト管理の人気が高まるにつれて、多くの組織が単一のチームやプロジェクトを越えてアジャイルを拡大し、全プログラムに適用するようになってきています。アジャイルは開発チームを越えて、IT、マーケティング、ビジネス開発にまでも普及しています。

アジャイル型のプロジェクト管理は、反復的な方法でプロジェクトを実施して、顧客のフィードバックを取り込む継続的なリリースに重点を置いています。イテレーションごとに調整できる機能によって、ベロシティと適応性が高まります。このアプローチは、限られた偏差で設定されたパスに従う、線形のウォーターフォール型プロジェクト管理アプローチとは異なるものです。

今日、顧客やビジネスに対しては迅速な対応と変更が求められますが、アジャイルは開発プロセス中に調整と反復を可能にする柔軟性を提供します。アジャイル型のプロジェクト管理は、開発チームと運用チームが連携する DevOps の実践の基盤でもあります。

ウォーターフォール型プロジェクト管理アプローチでは、プロジェクト フェーズの連続する実行を明確に定義する必要がありますが、ここでは 1 つのフェーズが最終承認を得るまで次に進みません。フェーズの完了後は、前のステージに戻ることが困難になってコストがかかります。アジャイル チームがたどる順序も同様のものですが、定期的なフィードバック ループにより、その増分は小さくなります。

ウォーターフォール型プロジェクト管理アプローチでは、線形で連続する方法を採ります。予測可能で反復的なプロセスがある作業には便利ですが、開発チームにはそれほど効果がなく、競合他社の調整速度を上回れません。

A single missed deadline or scope change during a waterfall project can cause outsized impacts on subsequent releases. Additionally, when a team is fully focused on the next phase of work, resolving technical debt or fixing bugs can be painful if the team is fully allocated to new feature work and always pressing forward to the next stage.

以下は、時間ブロックを厳密にセグメント化した標準的なウォーターフォール型プロジェクトの図です。これは将来的に繰り返す可能性がほとんどないため、開発者、プロダクト所有者、関係者に、それぞれの期間にできるだけ多くの時間をリクエストすることを推奨する「使わないと駄目になる」という意識が生じます。通常、ウォーターフォール型を使用するチームは「変更管理」によるスコープ クリープをコントロールしようとして、ここでは元の契約は変更されないことに同意しています。

ウォーターフォール モデルは製品の構築に関する既知の問題を大きくする場合があります。

• ブロッカーと依存関係の管理: 従来のプロジェクト管理のスタイルでは、「クリティカル パス」を作成することがよくあります。この場合、プロジェクトは進行を妨げている問題が解決するまで先に進めません。
• ユーザー フィードバックや製品検証の入手の困難さ: さらに言えば、最終顧客は製品が完全に完成してからでないと製品に触れられません。このため、製品の設計上の重要な問題とコードは、リリースされるまで明らかになりません。

ウォーターフォール型のメリット

• フェーズの順次プロセスが明確に定義されており、調整の必要性が少なくなっています。
• 明確なプロジェクト フェーズは、作業の依存関係を明確に定義するのに役立ちます。
• プロジェクトのコストは要件定義後に見積もることができます。
• 設計と要件の文書化により重点を置いています。
• ソフトウェアのコーディング以前の設計フェーズがより系統的になっており、かつ構造化されています。

ウォーターフォール型のデメリット

• フェーズ シーケンスが厳しくなり、チームがより専門的になるため、分割による作業の共有が難しくなります。
• フェーズ移行中の遅延や後退により時間の無駄が発生するリスクがあります。
• アジャイルが部門横断的なチーム構成を促進するのに比べて、各フェーズに特化されたチームの要件を満たすための追加の雇用要件が発生します。
• フェーズ間移行のハンドオフで追加の通信オーバーヘッドが発生します。
• 現在のフェーズに焦点を合わせるため、製品の所有権とエンゲージメントは、アジャイルと比較するとそれほど強力ではない可能性があります。

アジャイルは最初にソフトウェア チームに取り入れられました。このチームは、従来の連続したウォーターフォール型アプローチから、開発ライフサイクルを通して一貫したフィードバックと調整を収集するメソッドに移行していました。

アジャイル型のプロジェクト管理は、定期的なフィードバック間隔を含む複数の増分ステップを作成して、反復アプローチによって開発する方法を採ります。これによって、チームが線形パスに限定されるのではなく、製品開発プロセス全体を通して調整できる適応性が高まります。また、定期的に影響の大きいリリースが可能になるため、チームは時間の経過とともに続けて成果を上げられます。

反復リリースによって、チームにとって次の多数の可能性が広がります。

• 新たに検出された要件からブロックされている作業まで、状況の変化に対応できる。
• プロセスの途中で関係者からフィードバックを収集して、最終納品期限を意識せずにすぐに繰り返せる。
• ロール全体で関係を構築して連携し、人とのつながりや効果的なコミュニケーションを容易にする。

アジャイルでは、プロジェクトの途中で避けて通れない変更に対して弾力的に対応できます。

さらに優れている点は、ソフトウェア チーム内で一連のスキルが共有されることです。チームの一連のスキルがオーバーラップすることで、チームのコード ベースのすべての部分で作業に柔軟性が加わります。このため、プロジェクトの方向性が変わっても、作業と時間が無駄になりません (詳細については優れたアジャイル チームを構築する方法に関する記事をご参照ください)。

• アジャイル型のプロジェクトは、定期的なフィードバック間隔を含むいくつかの増分ステップに分割されます。
• プロジェクト要件はさらに細分化されて、その重要性に応じて優先順位が付けられます。
• 特に顧客とのコラボレーションを促進します。
• 顧客のニーズを満たすように、定期的に調整します。
• 計画と実施を統合して、チームが常に変化する要件に効率的に対処できるようにします。

アジャイル プロジェクト管理のメリット

• フィードバック サイクルが短縮されます
• 問題を早期に特定できます
• より高い顧客満足度をもたらす潜在能力があります
• 市場投入までの時間が劇的に短縮されます
• 可視性/説明責任が向上します
• 専任チームを置くことにより、時間の経過とともに生産性が向上します
• 価値デリバリーに重点を置いた柔軟な優先順位付けが可能です

アジャイルのデメリット

• クリティカル パスとプロジェクト間の依存関係は、ウォーターフォールのように明確に定義されていない可能性があります
• 組織的な学習曲線のコストが発生します
• 継続的デプロイのパイプラインによる真のアジャイル実行には、確立に必要な多くの技術的依存関係とエンジニアリング コストがかかります

アジャイルへの移行は、特にチームや組織が比較的、従来のプロジェクト管理アプローチを基盤としている場合には困難が伴います。アジャイル プラクティスに移行するにあたり、特に DevOps アプローチの採用時などは、開発チームと運用チームが連携してソフトウェアの開発と保守に取り組んでいるため、さまざまなプロセス変更が必要になる場合があります。アジャイル原則を採用する際は、チームと関係者は次の 2 つのコンセプトを受け入れる必要があります。

• プロダクト所有者は、チームの成果の価値を最適化することに集中します。チームは、最も重要な作業を最優先に位置付けるプロダクト所有者を信頼します。
• 開発チームは余裕がある場合にのみ作業を受け入れられます。プロダクト所有者がチームに作業を強いたり、独断的な締め切りを課したりしません。開発チームは、新しい作業の受け入れが可能になったときに、プログラムのバックログから作業を取り出します。

アジャイルプログラムが反復して作業の編成、実行、構成を行う仕組みを調べてみましょう。

製品ロードマップは、製品またはソリューションの開発スケジュールの概要です。アジャイル開発のロードマップでは、チームが増分目標とプロジェクト全体の目標を達成できるように強化する重要なコンテキストを示しています。ロードマップはイニシアチブで構成されています。イニシアチブは機能の大部分に相当し、機能が利用可能になる時期を伝える予定表が含まれています。作業が進んでチームの知識が増えると、新たな情報を反映するためのロードマップの変更が受け入れられていきます。変更はわずかな場合もあれば、大量に行われる場合もあります。この目標は、プロジェクトと長期目標に影響を及ぼす現在の条件にロードマップの焦点を置いて関係者と効率的に連携し、競合環境に迅速に対応することです。

以下に、イニシアチブをボックスで、タイムラインを赤のマイルストーン マーカーで示した製品チーム向けの単純なロードマップを次に示します。

ロードマップ内の各イニシアチブは要件セットに細分化されます。アジャイル要件は、従来のプロジェクトのように 100 ページにも及ぶドキュメントではなく、必要な機能に関する軽量な記述書です。開発が進むにつれて発展し、顧客や理想的な製品についてチームで共有された理解を十分に活用します。アジャイル要件はリーンのまま、継続的な会話やコラボレーションを通して共有された理解をチーム メンバー全員で発展させます。実装が始まるときになって初めて全詳細が具体化されます。

バックログはアジャイル プログラムの優先順位を設定します。チームはバックログ内のすべての作業項目を取り込みます。これらには、新機能、バグ、機能強化、技術的なタスクまたは構造上のタスクなどがあります。プロダクト所有者は技術チームのバックログでの作業について優先順位を決めます。一方、開発チームは優先順位付けされたバックログを、完了する必要のある作業内容に関する唯一の正しい情報源として使用します。

アジャイル チームは指標を糧にしています。進行中の作業 (WIP) 制限によって、チームとビジネス部門は最優先の作業を遂行することに集中し続けられます。バーンダウン チャートや管理図のようなグラフは、チームがデリバリー間隔を予測するのに、連続フロー図はボトルネックを特定するのに役立ちます。これらの指標とアーティファクトによって、チームの全員が大きな目標に集中し続けて、チームの能力に自信を深めて今後の作業を遂行できます。

アジャイル プロセスは、チーム メンバー間に高いレベルの信頼がなければ機能せず、信頼を確立できません。特定のプログラムと製品にとって何が適切なのかという難しい話し合いをするには、率直さが必要です。会話は一定の間隔で生じるので、アイデアと懸念は定期的に示されます。つまり、こうした会話の間に行われた意思決定を実行するためには、チーム メンバーがお互いの能力 (と意欲) を信頼している必要があります。

アジャイル型のプロジェクト管理は、ソフトウェア プロジェクトだけではなく、あらゆる種類のプロジェクトに向けた革新的なアプローチです。アジャイルが開発ライフサイクル中の変化に対応する柔軟性をもたらすため、チームは顧客のニーズを満たす、高品質の製品を提供できます。アジャイルはチームの強化、説明責任の構築、イノベーションの促進と同時に、継続的な改善を促します。アジャイルによって、脱線することなく変化に対応できるようになります。そして、これはどのプログラムにとっても重要なポイントです。

Learn more about agile project management and check out our free jira project management template. Plus, dive into agile adoption with agile tools for software teams, and learn how to communicate the progress of work across teams.