情報を伝えるもっとも効率的で効果的な方法はフェース・ツー・フェースで話をすることである。
- アジャイル宣言 原則6

 

 

リリース計画策定の概要

リリース計画策定は、アジャイルリリース列車の将来に影響を与える、リズムに基づく同期点である。リリース計画策定は、ビジョンの説明、チームに分かれての計画策定、PIや次のPIの時間枠に関するリリース目標への確約を含む標準化されたアジェンダを持つ、定期的な、プログラム規模のフェース・ツー・フェースのイベントである。通常リリース列車エンジニアにより主催され、参加者にはプログラムのすべてのメンバーが含まれる。各PIの区切りで1.5~2日をかけて実施される。地理的に分散したプログラムでは、場所から場所へ絶えずコミュニケーションを取ることによって、このイベントを同時に複数の場所で開催する可能性がある。

計画策定プロセスの成果物には次のものがある。各チームのチームPI目標。チーム目標を集めて合成したプログラムのPI目標。これには、リリース確約、期間内のマイルストーンを示すプログラムボード(計画)、プログラム全体からこれらの目標への信任投票/確約が含まれる。計画策定後に、ロードマップを更新し、計画策定の結果と将来のPIへの予測を反映する。

詳細

リリース計画策定は、アジャイルリリース列車の「心臓の鼓動」となる、将来に影響を与える、リズムに基づくイベントである。SAFeにとっては、このイベントは重要で、不可欠である(これを実施しなければ、SAFeを行っていないのと同じである)。リリース計画策定は以下のようなビジネス上の恩恵をもたらす。

  • フェース・ツー・フェースの計画策定により、広い帯域幅のコミュニケーションと関係構築が可能になる
  • チームやプログラム目標、ビジネス責任者とのやり取りにより、ビジネスと開発の足並みが揃う
  • 依存関係を特定でき、チーム間、プログラム間の連携が促進される?
  • 「ちょうど適当な量」のアーキテクチャーやUXに関するガイダンスを実施する機会となる
  • ニーズと処理能力が一致し、WIPの超過が低減する

リリース計画の1つの主要な目的は、次のPI時間枠に対する共通の確約されたプログラムPI目標チームPI目標について(その期間の具体的なリリース確約を識別することも含む)、ビジネス責任者とプログラムチームの足踏みを揃えることである。計画策定プロセスのもう1つの利点は、プログラム全体のチーム育成である。これは、プログラムの高いパフォーマンスを達成するために必要な社会組織を作り上げるのに役立つ。このプロセスの概要を図1に示す。

Figure 1. Release Planning Flow

図1. リリース計画策定フロー。プログラムバックログを基に計画策定を進める。チームはチームの目標を確約する。チーム目標を集約してプログラム目標を作成する。

また、計画策定は既知のベロシティに基づいて行われるため、リリース計画策定は継続的にWIPを評価し、必要に応じて余分なWIPを削減するための重要なステップとなる。

このイベントへのインプットは、ビジョンロードマッププログラムバックログの上位10位までのフィーチャー、他のビジネス背景などである。参加者は、ビジネス責任者を含むすべてのプログラム利害関係者とチームメンバーである。主な成果物には以下の4つがある。

  1. 各チームの「SMART」チームPI目標。チームが作成し、ビジネス責任者がビジネス価値を割り当てる。
  2. 集約され、まとめられたプログラムPI目標。
  3. PI計画。チーム目標から集められる。これによって、新しいフィーチャーや、予定納品日、その他の関連マイルストーンを示す。
  4. プログラム全体からこれらの目標への信任投票/確約。

繰り返し行うこの「ローリングウェーブ計画策定」プロセスによって、プログラムは、避けられない技術障害や市場の紆余曲折を乗り切ることができる。

イベント

リリース計画策定ミーティングは主要なイベントである。このため、準備、連携とコミュニケーションが必要である。また、第1回目の計画策定ミーティングは、企業が大規模開発に初めてアジャイルを導入している可能性があるため、事前に集中的に準備作業を行う必要があるかもしれない。

イベントを作成させるには、以下の主な3つの面で準備が必要である。
  • 組織の準備 - 戦略的な歩調統一と組織の準備
  • 内容の準備 - 管理と開発の準備
  • 設備の準備 - イベントのための実際の場所と物流

以下は、参考文献[1]の付録Cにある「リリース計画準備チェックリスト」の概要である。他の詳細については参考文献[1]の第15章を参照してほしい。

組織の準備

計画の前に、以下を保証することが重要である:プログラムは、参加者、利害関係者、ビジネス責任者の間で適度な戦略的整合が取れている。チームは価値のストリームに同調できる。重要な役割が割り当てられる。これに対処するために、準備状況を以下で確認する。

  • 計画策定のスコープと背景 - 計画策定プロセスのスコープ(プロダクト、システム、技術分野)は理解されているか。計画を立てるためにどのチームが集まる必要があるかを把握しているか。
  • ビジネスの調整 - ビジネス責任者間で優先順位について適度な合意が取れているか。
  • アジャイルチーム - アジャイルチームは本当に存在するか。チームには専用の開発者とテストリソースがあるか、またスクラムマスタープロダクトオーナーが特定されているか。

内容の準備

ビジョンとコンテキストが明確になっていること、適切な利害関係者が参加できることが同様に重要である。

設備の準備

多くの出席者をサポートするために必要な物理空間と技術インフラを確保することは簡単なことではない。特にリモート参加者がいる場合は困難である。主に以下の点を考慮する。

  • 設備 - 出席者全員がゆったり入ることができ、必要であれば別の小会議室が備わっていること。
  • 設備/技術サポート - 設備/技術サポート人員を特定し、設定、テスト、およびイベント時に連絡がつくようにしておくこと。
  • 通信チャネル - 分散した計画策定ミーティングの場合、プライマリとセカンダリのオーディオ、ビデオ、プレゼンテーションのチャネルが使用可能でなければならない。

リリース計画策定イベント

このミーティングは、通常、図2に示すような標準的なアジェンダで開催する。以下は各アジェンダの項目に関する説明である。

図2. 標準的な2日間のリリース計画アジェンダ

1日目

ビジネス背景。シニア経営者/ビジネスラインの責任者が、役員からの概要説明を行う。

プロダクト/ソリューションのビジョン。計画領域に責任を持つプロダクト管理者が現在のプロダクト/ソリューションビジョンを説明する。

アーキテクチャービジョンと開発プラクティス。CTO、エンタープライズアーキテクトやシステムアーキテクトがアーキテクチャービジョンを説明する。さらに、シニア開発管理者が、標準的なプラクティス、テスト自動化、および継続的なインテグレーションなど、アジャイルを支えるための変化を説明する場合もある。

計画策定の要求リリース列車エンジニア/ファシリテータが計画策定のプロセスと計画受け入れ基準を説明する。

チームに分かれての検討1。グループはいくつかのチームに分かれ、各チームで計画草案を作成する。チームに分かれての検討1では、チームは処理能力(各スプリントのベロシティー)を見積もり、フィーチャーを実現するために必要なストーリーを作成および詳細化し、リスクと依存関係を識別し、チームPI目標の草案を作成する。

計画の草案に対するレビュー。時間が厳密に決められたこの計画草案レビュー中に、チームは目標の草案、潜在的なリスクと妨害事項、依存関係を含む主要な計画のアウトプットを説明する。このレビュー中に、ビジネス責任者、レビュー者と利害関係者は、計画調整ミーティングおよびチームに分かれての検討2で利用するインプットを用意する。

管理層のレビューと問題解決。計画草案には、スコープ、リソース制限、依存関係などの課題が含まれている可能性がある。このレビューと問題解決ミーティングの間に、管理層とスコープを交渉し、必要な変更を行い、これらの課題を解決していく。RTEは、達成可能な目標を達成するために必要な意思決定を行えるよう、必要なだけ主要な利害関係者を引きとめておく。

2日目

計画調整。計画調整会議中に、管理チームメンバーはスコープとリソースに関する必要な変更を説明する。

チームに分かれての検討2。チームは前日の計画に基づいて、適切な調整を行い、計画策定の続きを行う。チームはPI目標を完成させ、ビジネス責任者はPIにビジネス価値を割り当てる。

最終計画レビュー。最終計画レビュー中に、すべてのチームはそれぞれ自分の計画をグループに発表する。各チームは与えられた時間の終盤に、リスクと妨害事項を述べる。ただし、この短い時間内では、それらを解決しようとはしない。計画がビジネス責任者にとって受け入れ可能であれば、チームはPI目標シートとプログラムリスクシートを部屋の前方に持ってきて、集約した目標が姿を表すのを全員がリアルタイムに見られるようにする。

プログラムリスクへの対処。計画策定中に、チームは自分の目標達成能力に影響を与える可能性のある重大なリスクと妨害事項を識別した。これらに対して、グループ全員の前でより広い管理のコンテキストで対処する。リスクを1つずつ次のグループのいずれかに分類し、明確、公正、かつ目に見える方式で対処する。

  • 解決済み(Resolved) - その問題に対する懸念がなくなったことにチームが合意する
  • 引き受け済み(Owned) - ミーティングでは解決できないので、誰かが責任を持つ/li>
  • 受容済み(Accepted) - いくつかのリスクは事実であるか発生する可能性があるものなので、理解し受け入れるしかない
  • 軽減済み(Mitigated) - チームはリスクの影響を軽減するための計画を特定することができる

確信度投票。プログラムのリスクに対処した後に、チームはリリース目標を達成することに関する確信度を投票する。各チームは、「手を上げて指の数で投票」する。もし、平均が指3~4本の場合、管理層はこの確約を受け入れる必要がある。平均が指3本より少ない場合、計画の調整を行い、計画をやり直す。

必要に応じ計画をやり直す。必要であれば、チームは確約に到達するまで計画をやり直す。これは、歩調の統一と確約が時間枠の遵守より高く評価される場合の1つである。

計画の振り返りと前進。最後に、RTEは短い振り返りミーティングを主催し、何がうまくいったか、何がうまくいかなかったか、次回は何を改善できるかについて話し合う。その後、アジャイルプロジェクト管理ツールへの目標とストーリーの取り込み、今後の主要な作業とイベントの日程など、次のステップについて話し合う。最後は部屋をきれいにする。

成功したイベントの成果物

イベントが成功した場合には、以下の3種類の主要成果物が作成される。

1.チームが作成し、ビジネス責任者によってビジネス価値が割り当てられた各チームのための「SMART」目標。ここには、計画にゴールとして組み込まれているけれどもチームが確約していないストレッチ目標が含まれる場合がある。ストレッチ目標は、プログラムの実施に関する信頼性と品質を向上させるために必要な、処理能力とスコープを柔軟に管理するための選択肢となる。図3にチームのリリース計画策定の成果物のサンプルを示す。

図3. チームのリリース計画策定成果物

 

2.「プログラムボード(計画)」。ここには、チームの目標から集約した、新しいフィーチャー、予想納品日、関連するマイルストーンを明示する。例を図4に示す。

図4. プログラムボードの例

3.プログラム全体によるこれらの目標に対する確信度の投票/確約。

その後、プロダクト管理は計画されたPI目標に基づいて、プログラムのロードマップを更新できる。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011。第16章。(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)
Last update 20 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.