Release 締め切りは、多くの場合、トレードショー、会計上のプレッシャー、契約上の義務など、外部から課せられる固定されたものです。しかし、できるだけ早く動作するソフトウェアをユーザーの手に届け、できるだけ早く「軌道修正」を行うことが目標であるため、リリース ソフトウェア開発サイクルをできるだけ短く保つためにあらゆる努力が払われます。アジャイル リリース サイクルは 1 年よりも短く抑えるべきであり、多くの場合 6 か月や 3 か月と短くなります。リリースは、反復で構成されます。特定のプロジェクトでは、反復の長さは通常 1 週間から 1 か月の間の長さに固定されます。リリースが 6 か月後にあり、反復がそれぞれ 2 週間の場合、リリースは 13 の反復で構成されます。
環境によっては、ソフトウェアは各イテレーションの終了時、あるいは数回のイテレーションごとに、ユーザー、あるいは少なくとも一部のユーザーに段階的に提供される場合があります。初期の機能リストが特定され、優先順位が付けられ、場合によっては見積もりが出された後、チームはリリース計画会議を開催し、全体的なリリーススケジュールを策定し、どの機能が提供可能かを判断します。優先順位付けされた機能に関する全体的なリリース計画は、個々のイテレーション計画に直接反映されます。
一部のアジャイル手法では、プログラマーと顧客の間で明確な責任分担が重視されます。計画段階では、ビジネス上の意思決定と優先順位付けは顧客のみが責任を負い、タスクの見積もりと開発の実行はプログラマーのみが責任を負います。 アジャイル手法 また、経営陣が開発グループに技術の選択を恣意的に押し付けることを強く控え、開発者がシステムとプロジェクトに最適なツールを選択できるように可能な限りの自由度を与えるようにしてください。
予備的なリリース計画
初期リリース計画の目的は、リリース期限までにどの機能が提供されるかを大まかに見積もること（期限が決まっている場合）、または特定の機能セットのおおよその納品日を決定すること（スコープが決まっている場合）です。この情報に基づき、プロジェクトが少なくとも投資回収できるほどのROIを生み出すかどうか、そしてプロジェクトを続行するかどうかを判断します。
初期リリース計画会議は、1日以上続くことは稀です。丸一日会議に出席するのが難しい場合は、半日を2回に分けて行うこともあります。まず、顧客は提供すべき機能の優先順位を提示します。理想的には、開発者は各機能の実装に必要な作業量の大まかな見積もりを既に作成しておく必要があります。
開発者の見積もりと顧客の機能優先度に基づき、チームはリリース計画を作成し、機能を最初の数回のイテレーションに大まかにマッピングします。開発者は、優先度の低い機能が設計上またはアーキテクチャ上のリスクをもたらす可能性があると判断した場合、プロジェクトのできるだけ早い段階で潜在的なリスクに対処するため、顧客にそれらの機能を初期のイテレーションに割り当てることを検討してもらうことがあります。
開発チームの前回リリースにおけるベロシティが既に分かっている場合は、非常に役立ちます。その場合、スコープが固定されているのであれば、必要なすべての機能の合計見積りをチームのベロシティで割ることで、機能を提供するために必要なイテレーションの概算数、ひいては期限を算出できます。期限が固定されている場合（通常はそうなります）、ベロシティにイテレーション数を掛けることで、提供可能な機能数の大まかな目安が得られます。開発チームのベロシティが不明な場合は、ベロシティの見積りを提出する必要があります。また、信頼できるベロシティの数値が得られるまで、最初の数回のイテレーションではリリース計画の精度が低くなることを理解しておく必要があります。
暫定リリース計画
初期のリリース計画が関係者全員の満足を得ることは稀です。十分な機能が提供されないか、あるいは必要な機能を提供するのに時間がかかりすぎると感じられるからです。しかし、アジャイルの世界では、チームはこうした厳しい現実を直視し、それに基づいてソフトウェア開発計画を策定します。誰もが満足できるスコープの奇跡など信じていません。集団で否定するのではなく、チームは現実的な指標と交渉を用いて、プロジェクト開始のできるだけ早い段階で難しい決断を下します。
アジャイルの思想家たちは、 可能 特定のプロジェクトのスコープ、期限、リソース、品質を調整する場合、調整によく対応する変数は期限とスコープだけです。広範な調査により、大規模なチームは低品質のシステムを遅く納品する傾向があり、小規模なチームは高品質のシステムを早く納品する傾向があることがわかっています。確かにチームにプログラマーを追加する必要があるかもしれませんが、それはチームのスピードを上げるのではなく、少なくともしばらくは遅らせる可能性があります。これらの調査結果を受け入れたら、リリース計画では、スコープまたは期限を調整して、スポンサー、顧客、開発者、マネージャー、その他の利害関係者が実行可能と合意できるリリース計画を作成する必要があることを受け入れます。チームがこれらの難しい選択を事前に行うという事実は、プロジェクトの全体的なリスクを軽減します。チームが期限までに利害関係者の投資に十分以上の見返りをもたらす機能セットを作成できる可能性が高まります。
リリースを継続的に計画する
初期リリース計画は大まかなものであると理解されています。プロジェクトが投資回収率（ROI）を十分に達成し、投資額を上回ると予測することで、プロジェクトを開始するために必要な程度の詳細さが必要です。（初期リリース計画で予測されたROIがプロジェクトを正当化するほど低くない場合は、多額の費用を無駄にする前にプロジェクトを中止できます。）アジャイルプロジェクトでは、継続的に計画を立て、進捗に合わせて軌道修正を行います。軌道修正の主なメカニズムの一つは、あらゆる種類のフィードバックに応じてリリース計画を進化させることです。チームの速度が落ち着くまでには、少なくとも数回のイテレーションが必要です。イテレーションでは、当初の計画よりも機能が少なくなる場合もあれば、多くなる場合もあります。機能、アーキテクチャの選択、設計の選択、フレームワークやテクノロジーの選択が、リスクが高すぎる、あるいは単に機能しないことが判明するかもしれません。ユーザーインターフェースの修正が必要になるかもしれません。スタッフの解雇や追加が必要になるかもしれません。機能の優先順位が変更される可能性もあります。これらのすべての要素が、リリース計画を継続的に見直し、洗練していく上で役立ちます。新しいイテレーション計画が公開されるたびに、新しい現実を反映した改訂版リリース計画も公開する必要があります。
スタートアップとまとめ
多くのアジャイルチームは、最初のイテレーション（多くの場合「イテレーション0」と呼ばれる）では、初期の技術的およびロジスティックス上の問題を明確に解決し、場合によってはアーキテクチャをエンドツーエンドでテストするために、ごくわずかな機能のみを提供する計画を立てています。これは、アジャイル開発の経験がほとんど、あるいは全くないチームにとって非常に重要になる可能性があります。適切なベロシティ指標を持たないチームの場合、これは、ベロシティが安定し、信頼できる状態になるのは2回目または3回目のイテレーションの終わりになってからになる可能性があることを意味します。
一部のチームでは、プロジェクトの終了時に、安定化、システム全体の統合とテスト、バグ修正、ユーザードキュメントの完成のために、最大2回のイテレーションをスケジュールします。理想的なアジャイルプロジェクトではこれは必須ではありませんが、現実には、チームが採用する具体的なアジャイルプラクティス、組織構造、システム全体の複雑さ、チームに期待される非コード成果物、システム展開の複雑さなど、さまざまな要因によって異なります。
くある質問（FAQ）
リリースとリリース プランを本当に使用する必要がありますか?
一部のチームは アジャイルプランニング リリースレベルでは、例えばASPはソフトウェアをイテレーションごとに（つまり数週間ごとに）本番環境にリリースするだけなので、各イテレーションは実質的にリリースであり、イテレーションごとのシンプルなアジャイル計画で十分でしょう。一方、ソフトウェア開発において経営陣がある程度レベルの可視性を求める場合、 リリース管理 レベル (つまり、進捗状況、ステータス、初期のソフトウェア開発計画からの変更など) が不明瞭な場合は、リリース レベルの計画と管理が非常に重要になります。
リリースの規模はどのくらいですか?
Releaseリリース期間は通常2ヶ月から12ヶ月です。より長いリリースの場合は、複数のサブリリースに分割する方が合理的です。
リリースには何回の反復がありますか?
リリース内のイテレーションの回数は通常、スケジュールによって決まります。リリース期間が6か月で、イテレーションが2週間の場合、リリースには13回のイテレーションをスケジュールする必要があります。
リリース計画には誰が参加しますか?
小規模なチームであれば、クロスファンクショナルチーム全体が意見表明と説明責任の両方の目的で参加することが合理的かもしれません。大規模なチームや組織では、チームの一部のメンバーを選出または選抜し、チームを代表することもあります。
リリース計画会議はどのくらい続きますか?
Release 計画会議は通常 4 ～ 8 時間続きます。
リリース計画会議の準備としてどれくらいの作業が行われますか?
通常、リリース計画会議の前には、プロジェクトの承認、予算編成、ビジョン、チームの特定など、かなりの作業が行われています。機能面では、顧客は開発部門と協力して初期機能を特定し、それらを細分化して初期の高レベルの見積りを提供することに時間を費やしている可能性があります。
リリース中にリリース計画は変更されますか?
より多くの情報が明らかになり、機能が提供され、システムに関する理解が深まり、ビジネスニーズが進化し、優先順位が変化するにつれて、リリース全体の構成はほぼ確実に変化します。ソフトウェアリリース管理の進化は予想されていましたが、時間の経過とともに変化していくため、関係者全員に伝える必要があります。
