アジャイルとウォーターフォール

• 詳細な製品要件とドキュメンテーションにより、新しいプログラマーは迅速かつ簡単にオンボーディングすることができます。
• ドキュメンテーションはプロジェクトの範囲を明確にし、プロジェクト・マネージャーは予算、スケジュール、主要なマイルストーンを関係者に伝えることができます。

• プロジェクトの開始時にすべての要件の概要を説明することが困難であり、ドキュメンテーションの欠落が生じる可能性があります。
• 開発プロセス中に顧客とのコラボレーションが最小限であると、製品が期待を満たさない場合、コストのかかる変更につながる可能性があります。
• テスト担当者はプロセスの後半で問題やバグを報告し、代替のプログラム・アーキテクチャーに影響を与えていた可能性があります。

ウォーターフォール型開発とは対照的に、アジャイルはプロジェクト管理に対する反復的なアプローチによって定義されます。アジャイルなチームは、開始時に長いプロジェクト要件を作成するのではなく、製品を具体的な機能に分割し、スプリントと呼ばれる特定の時間制約の下でそれぞれのことに取り組みます。

アジャイルなプロジェクト管理では、通常5～9人のメンバーで構成される、部門横断的かつ自己組織化されたチームが必要です。彼らは協力して、各スプリント中に、以前のイテレーションの他の機能コードと組み合わせた実行可能なソフトウェアを開発します。スプリントの期間が終了するまでに、チームは作業の進め方を利害関係者に向けてデモを行い、フィードバックを求めます。これにより、利害関係者はソフトウェア開発に対して柔軟にアプローチできるようになります。チームは頻繁にフィードバックにアクセスできるため、開発ライフサイクル中に製品ロードマップを適応させ、機能がユーザーの期待に真に応えられるようになります。ウォーターフォール・アプローチでは通常、顧客の関与は最終製品の納品と同時に行われます。要件が誤って解釈されたり、誤って文書化されたりした場合、多大なコストがかかる可能性があります。

ウォーターフォール型プロジェクト管理システムが非常に効果が低いと考えた17人が、2001年にソフトウェア開発プロセスに関する彼らのアイデアをまとめた『アジャイルソフトウェア開発宣言』と呼ばれる文書を完成させました。この文書では、ソフトウェア開発ワークストリーム内で優先すべき具体的な価値観と原則を強調し、スクラム、カンバン、ユーザー機能駆動開発（FDD）、エクストリーム・プログラミングなど、多数の一般的なアジャイル・フレームワークを生み出しました。それ以来、アジャイル・ソフトウェア開発の人気が、特にウォーターフォール・モデルと比較して高まっています。

ラグビーのゲームにインスパイアされたアジャイル・スクラムは、ラグビー・ボールを手にするためにフォワードたちがスクラムで協力する必要があるのと似た、成果物を達成するためのチームワークを重視します。アジャイル・スクラム・チームのスキルセットはさまざまですが、通常は次の役割が含まれます。

• プロダクトオーナー：このチーム・メンバーは、顧客とビジネス双方のニーズを表現します。ユーザー・ストーリーを作成することで、チームは機能リクエストが特定の問題の解決にどのように役立つかを理解し、そのストーリーでチームが取り組むべきタスクのバック・ログを策定します。この人物はまた、顧客にとっての価値によってストーリーを優先し、理論的にはビジネスの価値に結びつくはずです。プロダクト・オーナーはこのようにチームを率いますが、期限を設定したり、仕事の納品方法を指示したりすることはありません。
• スクラム・マスター：このチーム・メンバーは、アジャイル開発プロセス全体を促進します。プロジェクト・マネージャーと同様に、この人物はチームをタスクに集中させ、プロジェクト中もチームが集中し続けられるようにします。また、チームメンバー間の意見の不一致を仲介する中立的な当事者として機能することもあります。たとえば、特定のスプリントでどれだけの負荷を引き受けるかについてチームメンバーの意見が異なる場合があります。特にプロダクト・オーナーは、所定の時間枠内で提供できる以上のことをコミットするようチームにプレッシャーを与える場合があります。このような場合、スクラム・マスターはチーム・メンバーにチームでの役割の範囲を思い出させることができます。

アジャイル・チームの他のチーム・メンバーはさまざまですが、通常は、設計、分析、QA、開発など、さまざまな分野のユーザーが含まれます。これらの個人が協力して、引き受ける作業の量と完了方法を決定します。

アジャイル方法論は、チームが団結する方法によっても定義されます。チーム全体のワークフローを促進するための特定のミーティングがあります。たとえば次のようなミーティングを開きます。

• スプリントプランニング：このミーティングでは、現在のスプリントにどのストーリーを含めるかを決定します。プロダクト・オーナーはユーザー・ストーリーに優先順位を付けますが、残りのチームは、その期間内にどのユーザー・ストーリーを何件まで完了できるかについて合意する必要があります。
• デイリー・スタンドアップ：これらの短いミーティングは、デイリー・スクラムとも呼ばれます。これらのチェックイン中に、各チームメンバーは、完了したタスク、今後のタスク、遅延につながる可能性のあるブロッカーや依存関係など、個々の進捗状況を伝えます。
• デモ：このミーティングでは、チームがスプリントの過程（2週間から4週間ごと）に完成させた実用的なソフトウェアをプレゼンします。プロダクト・オーナーは、ユーザー・ストーリーが「完了」の定義を満たしているかどうかを判断します。そうでない場合、製品バック・ログは、欠落している要素を考慮して調整されることがあります。これは、チームがフィードバックを求めて利害関係者にプレゼンテーションを行う機会でもあります。
• 振り返り：この時間はチームの自己分析のために予約されており、チームは将来的により良い成果を達成するためにワークフローを改善する方法を特定します

• チーム・デザインは、より多くのコラボレーションを促進します。
• 製品開発では、適応型設計アプローチを採用しています。
• コードは開発段階で反復ごとにテストされるため、コードの欠陥は将来のソフトウェア設計に影響を与える可能性があります。
• フィードバックが頻繁にある場合、顧客ニーズの優先順位付けが進むため、顧客満足度が高くなる傾向があります。
• 各機能が独自の実用的なソフトウェアであるため、継続的な統合が可能になります。
• このリーン型のソフトウェア開発は、顧客と製品の調整ミスのリスクが少ないため、コスト削減につながります。

• アジャイルなアプローチでは、包括的なドキュメンテーションが欠如している場合があります。このため、新しい開発者のオンボーディング、利害関係者へのスケジュールの予測、正確なコスト見積もりの提供が困難になります。
• 拡張が困難な場合があります。

いずれのプロジェクト管理アプローチでも開発チームは成功を収めてきましたが、アジャイル・プロセスを中心とした勢いは確かに高まっています。今日の企業にもたらすメリットを見ると、その理由が簡単にわかります。チームが進捗状況を把握するのに役立つプロジェクト管理ツールは数多くありますが、IBMは、開発者がよりアジャイルな方法でコーディングできるようにするシステムも提供しています。