アジャイルプログラムの実行
(冷静さを失わずに)

アジャイルへ移行すると全体像が見えなくなると考える人々がいます。これにはまったく同意できません。 

アジャイル開発の早期導入者は、小規模な、自己完結型のプロジェクトで作業する小規模な、自己完結型のチームでした。これらの人々によって、アジャイルモデルが実用的で、世界中のソフトウェアメーカーに喜びと改善をもたらすことが証明されました。最近では、大規模な組織が単一のチームやプロジェクトを越えてアジャイルを拡大しており、全プログラムに適用する方法を探しています。 

これには課題がないわけではありません。ただし、それは行うことができないという意味ではありません。しかし、まず、オンライン ファッション小売業者の Gilt がアジャイルを使用してビジネスをどのように変えたか聞いてみましょう。

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

アジャイルの特長など、基本的なところから始めましょう。 

従来のプロジェクトマネジメントのスタイルは、ウォーターフォール型のようにフェーズで構成されています。以下は、標準的なウォーターフォール型プロジェクトの図です。この製品開発のスタイルは、あらゆるものを同時に一括して単一の製品に盛り込む「ビッグバン」アプローチで、リスクの高いリリースとなります。プロジェクトが1つのフェーズを終えると、チームは必ず次のステージに押しやられるため、戻るには手間がかかります。

標準的なウォーターフォール型プロジェクトはフェーズで構成されており、これがアジャイル プログラムマネジメントと異なる点です。

従来のプロジェクトマネジメントのスタイルでは、「クリティカルパス」を作成することがよくあります。この場合、プロジェクトは進行を妨げている問題が解決するまで先に進めません。さらに言えば、エンドカスタマーは製品が完全に完成してからでないと製品に触れることができません。このため、製品の設計上の重要な問題とコードは、リリースされるまで明らかになりません。

では、アジャイル型のパターンを比較してみましょう。アジャイル型の開発は反復アプローチを取り、一定の間隔でフィードバックが行われます。こうした反復により、チームは進行を妨げている問題を解決しながら、プロジェクトの別の領域に (生産的な意味で) 迂回することができます。

アジャイルプログラムマネジメントは、反復アプローチで開発を進め、一定の間隔でフィードバックを行います。

イテレーションによりクリティカルパスを取り除き、開発中の製品に触れることができる。

その結果、チームは持続的にビルド、デリバリー、学習、調整を行う機会を得ます。市場の変化に足をすくわれることなく、チームは新しい要件に迅速に適応できます。

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

優れたアジャイルプログラムを作成する方法

プログラムを従来のプロジェクトマネジメントからアジャイルへ移行する場合、チームとその関係者は 2 つの重要な概念を受け入れる必要があります。

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

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

ロードマップ

ロードマップは、製品またはソリューションの開発スケジュールの概要です。ロードマップはイニシアチブで構成されています。イニシアチブは機能の大部分に相当し、フィーチャーが利用可能になる時期を伝える予定表が含まれています。プログラム開発の進行に伴い、ロードマップの変更が受け入れられます。変更は、わずかな場合もあれば、大幅に行われる場合もあります。目標は、ロードマップの焦点を現行の市場の状況と長期的な目標に置くことです。 

製品要件

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

バックログ

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

アジャイルのデリバリー原動力

アジャイルは様々なフレームワーク (スクラムカンバンなど) を使用して実装でき、ソフトウェアをデリバリーします。 スクラム チームは開発の指針としてスプリントを使用し、カンバン チームは、多くの場合、固定された作業間隔なしに作業を行います。しかし、いずれのフレームワークでも、エピックやバージョンなどの大規模なデリバリー原動力を利用して、同期化されたリリース期間で本番に移行するために開発をスケジュール化します。 

アジャイルの指標

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

これらの各トピックに関する詳細は、「プログラムのためのアジャイル」セクションをお読みください。

信頼で進行するアジャイル

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

In summary, agile development is a structured and iterative approach to making software. It gives you the ability to respond to change without going off the rails. And that's good news for any program.