将来の製品開発タスクを事前に決定することはできません。 最終結果を理解し、対応できる人に計画と管理を配布します。
-マイケル-ケネディ、リーン企業のための製品開発
SAFeに魔法はありません。 . . 多分PI計画のためを除いて。
PI計画の紹介: 簡単な概要
プログラムインクリメント（PI）計画は、アジャイルリリーストレイン（ART）のハートビートとして機能するケイデンスベースのイベントであり、ART上のすべてのチームを共通のミッションとビジョンに合わせて整列させます。
PI計画はSAFeにとって不可欠です。
コースを探す:
アジャイルマニフェストでは、”開発チームとの間で情報を伝える最も効率的で効果的な方法は、対面の会話です。”SAFeは、PI計画でこれを次のレベルに引き上げます。
可能であれば、これは物理的なコロケーションを含み、これらの大規模なPI計画イベントは現在、世界中の多くの企業内で行われています。 彼らは明らかにアジャイルチームのチームが個人的かつ集合的にやりがいのある社会的構造を作成するときに発生する無形資産はもちろんのこと、
しかし、アート全体が併置することは必ずしも実用的ではないかもしれませんが、現在のCOVID-19ではこれが選択肢ではない状況を作り出しています。 物理的な顔の計画には利点がありますが、書かれていない安全な”ルール”は、”作業を行う人々が作業を計画することです。”物理的な存在が不可能な場合、リアルタイム、並行、仮想、対面計画が効果的であることが証明されました。 実際、多くの芸術は、図1に示すように、いくつかのチームがリモートで参加するハイブリッド状況を作成することに成功しています。
高度なトピックの記事”Distributed PI Planning with SAFe”では、これらのシナリオを正常に管理するための追加のガイダンスと考慮事項が提供されています。
PI Planningには、ビジネスコンテキストとビジョンのプレゼンテーションを含む標準的な議題があり、その後にチーム計画ブレークアウトがあります。 リリーストレインエンジニア（RTE）によって促進され、このイベントは、芸術のすべてのメンバーが含まれており、革新と計画（IP）の反復内で発生します。 IP反復中にイベントを保持すると、PI内の他の反復のスケジューリングや容量に影響を与えることはありません。 PIの計画は2日間にわたって行われますが、これは多くの場合、複数のタイムゾーンにわたる計画に対応するために拡張されます。
PI Planningのビジネス上の利点
PI planningは、以下を含む多くのビジネス上の利点を提供します:
- すべてのチームメンバーと利害関係者間の対面コミュニケーションの確立
- ソーシャルネットワークの構築アートが依存する
- ビジネスコンテキスト、ビジョ’アーキテクチャとリーンユーザーエクスペリエンス(ux)ガイダンス
- 需要を容量にマッチングし、過剰な仕掛品(wip)を排除する
- 高速 意思決定
PI計画の入力と出力
PI計画への入力には次のものが含まれます:
- ビジネスコンテキスト(下記の”コンテンツ準備”を参照)
- ロードマップとビジョン
- プログラムバックログのトップ10機能
PI計画イベントが成功:
- コミットされたPI目標–ビジネスオーナーによって割り当てられたビジネス価値を持つ各チームによって作成されるスマートな目標のセッ
- プログラムボード–新しい機能の配信日、チーム間の機能の依存関係、および関連するマイルストーンを強調表示します。
準備
PI計画は、準備、調整、コミュニケーションを必要とする重要なイベントです。 それはRTEによって促進され、イベントの参加者には、ビジネスオーナー、製品管理、アジャイルチーム、システムとソリューションアーキテクト/エンジニアリング、シ このイベントでのビジネスオーナーの積極的な参加は、予算支出に重要なガードレールを提供します。
イベントを成功させるためには、三つの主要な分野での準備が必要です:
- 組織の準備-戦略的アライメントとチームと列車の設定
- コンテンツの準備–管理と開発の準備
- 物流の準備–成功したイベントを実行するための考慮事項
(完全なチェックリストは、SPCsで利用可能なSAFe PI Planning Toolkitに記載されています)。
組織の準備
PI計画の前に、参加者、利害関係者、およびビジネスオーナーの間で戦略の調整が必要です。 重要な役割が割り当てられます。 ただし、事前にこれに対処するには、イベント主催者は次の点を考慮する必要があります:
- 計画範囲とコンテキスト-計画プロセスの範囲（製品、システム、技術ドメイン）は理解されていますか？ どのチームが一緒に計画する必要があるか知っていますか？
- ビジネスアライメント-ビジネスオーナーの間で優先順位について合理的な合意がありますか？
- アジャイルチーム–アジャイルチームはありますか？ 各チームに専用のチームメンバーと識別されたスクラムマスターと製品所有者がいますか？
コンテンツの準備
明確なビジョンと文脈があり、適切な利害関係者が参加できることを確認することも同様に重要です。 したがって、PI計画には以下を含める必要があります:
- Executive briefing–現在のビジネスコンテキストを定義するブリーフィング
- Product vision briefing(s)–プログラムバックログのトップ10機能を含む製品管理によって作成されたブリーフィング
- Architecture vision briefing–CTO、エンタープライズアーキテクト、またはシステムアーキテクトによって作成されたプレゼンテーションで、新しいイネーブラー、機能、および機能しない要件(NFRs)を伝えるためのプレゼンテーション。)
物流準備
多数の参加者をサポートするためのイベントの準備は簡単ではありません。 物理的に配列された計画のためにこれは物理的なスペースをしっかり止め、準備することを含むことができる。 リモート参加者の場合、または完全に分散されたPI計画の場合、これには必要な技術インフラストラクチャへの投資も含まれます。 考慮事項は次のとおりです:
- 場所–各計画の場所は事前に準備する必要があります
- 技術とツール–分散計画やリモート出席者をサポートするための情報とツールへのリアルタイムアクセス
- ….. 各項目の説明は以下のとおりです。 複数のタイムゾーンにわたる計画をサポートするためにこのアジェンダを適応させるためのガイダンスについては、高度なトピックの記事”Distributed PI Planning with SAFe”を参照してください。
図2. Standard two-day PI planning agenda Day1Agenda
- ビジネスコンテキスト–ビジネスオーナーまたは上級幹部は、ビジネスの現在の状態を説明し、ポートフォリオビジョンを共有し、既存のソリ
- 製品/ソリューションビジョン–製品管理は、現在のビジョン（通常は次のトップ10の今後の機能によって表されます）を提示し、以前のPI planningイベントからの変
- アーキテクチャビジョンと開発プラクティス–システムアーキテクト/エンジニアリングは、アーキテクチャビジョンを提示します。 また、上級開発マネージャーは、テストの自動化、DevOps、継続的統合、継続的な展開など、今後のPIで進められている開発プラクティスにアジャイル支援の変更を
- 計画の文脈と昼食–RTEは、イベントの計画プロセスと期待される成果を提示します。
- Team breakout#1–breakoutでは、チームは各イテレーションの容量を推定し、機能を実現するために必要となる可能性のあるバックログ項目を特定します。 各チームは、反復ごとにすべての人に表示されるドラフト計画を作成します。
このプロセスの間、チームはリスクと依存関係を特定し、最初のチームPI目標を策定します。 PI目標には、通常、計画に組み込まれた目標（例えば、これらの目標のために定義され、含まれているストーリー）であるが、あまりにも多くの未知数やリスクのた コミットされていない目標は、時間がある場合に行う余分なものではありません。 代わりに、彼らは計画の信頼性を高め、経営陣に芸術が提供できないかもしれない目標の早期警告を与えます。 また、図3に示すように、チームは機能と関連する依存関係をプログラムボードに追加します。
図3. 機能と依存関係を示すプログラムボード - ドラフト計画のレビュー-厳密にタイムボックス化されたドラフト計画のレビュー中に、チームは能力と負荷、ドラフトPIの目標、潜在的なリスク、および依存 ビジネス所有者、製品管理、および他のチームおよび係争物受寄者は確認し、入力を提供する。
- 管理レビューと問題解決-計画案は、範囲、人と資源の制約、依存関係などの課題を提示する可能性があります。 問題解決イベントの間、経営陣は範囲の変更を交渉し、さまざまな計画調整に同意することによって他の問題を解決することができます。 RTEは、達成可能な目標を達成するために必要な意思決定を行うために必要な限り、主要な利害関係者を容易にし、一緒に保ちます。
マルチアートソリューショントレインでは、出てきたクロスアートの問題を解決するための計画の最初の日の後に同様のイベントが開催されることがあ あるいは、関係する列車のRteは、各ARTの特定の管理レビューおよび問題解決イベントで解決される問題を提起するために互いに話すことができます。 ソリューショントレインエンジニア（STE）は、芸術全体の問題を容易にし、解決するのに役立ちます。
2日目の議題
- 計画調整–次の日、イベントは経営陣が計画範囲、人、リソースへの変更を提示することから始まります。
- Team breakouts#2–チームは前日からの議題に基づいて計画を継続し、適切な調整を行います。 図4に示すように、ビジネスオーナーがビジネス価値を割り当てるPIの目標を確定します。
図4。 ビジネス価値が割り当てられたチームのPI目標シート - 最終計画のレビューと昼食–このセッションでは、すべてのチームがグループに計画を提示します。 各チームのタイムスロットの終わりに、チームはリスクと障害を述べ、ローミング演習の後半で使用するためにrteにリスクを提供します。 チームは計画が受諾可能であるかどうかそれからビジネス所有者に尋ねる。 計画が承認された場合、チームはチームPI目標シートを部屋の前に持ってきて、誰もが集計目標がリアルタイムで展開するのを見ることができます。 ビジネスオーナーに懸念がある場合、チームには、特定された問題に対処するために必要に応じて計画を調整する機会が与えられます。 チームはその後、彼らの改訂された計画を提示します。
- プログラムのリスク–計画中に、チームは目標を達成する能力に影響を与える可能性のあるプログラムのリスクと障害を特定しました。 これらは、全体の列車の前でより広範な管理コンテキストで解決されます。 一つ一つ、リスクについて議論し、誠実さと透明性をもって対処し、次のいずれかのカテゴリに分類されます:
- 解決済み–チームは、リスクはもはや懸念事項ではないことに同意する。
- Owned–列車の誰かがPI計画中に解決できないため、リスクの所有権を取得します。
- Accepted–いくつかのリスクは、理解され受け入れられなければならない事実または潜在的な問題です。
- 緩和–チームはリスクの影響を軽減するための計画を特定する。
- 信頼投票–プログラムのリスクに対処すると、チームはチームPIの目標を達成するための信頼に投票します。
各チームは”五人の拳”投票を行います。 平均が3本指以上の場合、経営陣はコミットメントを受け入れる必要があります。 それが3未満の場合、チームは計画を再調整します。 二本指以下に投票する人は、彼らの懸念を表明する機会を与えられるべきである。 これは、リスクのリストに追加するか、いくつかの再計画を必要とするか、単に有益である可能性があります。 各チームが投票したら、図5に示すように、すべての人が集合計画に自信を持って表現して、アート全体についてプロセスが繰り返されます。
図5. アートのための自信の投票 - 計画のリワーク-必要に応じて、チームは高い信頼レベルに達するまで計画をリワークします。 これは、アライメントとコミットメントがタイムボックスに付着するよりも高く評価されている一つの機会です。
- レトロスペクティブの計画と前進–最後に、Rteは、図6に示すように、PI planningイベントの簡単なレトロスペクティブをリードして、うまくいったこと、できなかったこと、次回より良いことをキャプチャします。
図6. PI企画回顧 - 通常、チームへの最終的な指示とともに、次のステップについての議論が続きます。 これには、
- 計画に使用される部屋の清掃が含まれます。
- アジャイルなプロジェクト管理ツールでチームPIの目標とストーリーをキャプチャします。
- イテレーション計画と毎日のスタンドアップ(DSU)の場所とタイミングを決定します。
計画イベントが完了した後、RTEおよびその他のART利害関係者は、個々のチームPI目標を一連のプログラムPI目標に要約し（図7）、これを使用して外部と通信し、目標に向かって進捗状況を追跡します。
製品管理は、プログラムPI目標を使用してロードマップを更新し、学んだことに基づいて、次の二つのPiの予測を改善します。
プログラムボードは、依存関係を追跡するためにスクラムのスクラム中によく使用されます。 これは、計画が完了した後に（手動で）更新される場合も、更新されない場合もあります。 これは、適切なアジャイルプロジェクト管理ツールと芸術のニーズに依存します。
チームは、今後のPIのために事前に入力されたイテレーションバックログでPI計画イベントを終了します。 彼らは、チームのPI目標、イテレーション計画、およびリスクを通常の作業領域に戻します。 プログラムのリスクはRTEに残り、リスクを所有または軽減する責任者が情報を取得し、リスクを積極的に管理していることを保証します。
最も重要なのは、芸術はPIを実行し、進行状況を追跡し、新しい知識が出現するにつれて起こる変化に必要に応じて調整することに進むことです。 PIの実行は、すべてのチームが最初のイテレーションの計画を実行し、PI計画を開始点として使用して開始します。 これは、その後のイテレーション計画プロセスのための新鮮な入力です。 PI計画中に作成されたイテレーション計画では、詳細なストーリーレベルの受け入れ基準が考慮されていないため、最初以降のイテレーション計画に調整
図7. プログラムPIの目的 ソリューションTrain PI Planning
この記事では、単一の芸術の計画活動に焦点を当てています。 しかし、大きな価値の流れには、複数の芸術とサプライヤーが含まれている可能性があります。 この場合、ソリューション列車は、コンテキストを設定し、個々のART PI計画イベントの入力を提供するPI前計画イベントを使用して調整を提供します。 POST-PI PlanningイベントはART PI planningに続き、解決策に貢献する芸術の計画結果を統合するために使用されます。
図8. PRE and Post-PI Planning Innovation and Planning Iterationの記事では、PRE-Post-PI planningのイベントに対応するためのカレンダーの例を提供しています。
詳細はこちら
レフィングウェル、ディーン。 アジャイルソフトウェア要件：チーム、プログラム、および企業のためのリーン要件の実践。 アディソン-ウェスリー、2011年。 ケネディマイケル リーン企業のための製品開発。 2003年、オークレア-プレス。
最終更新日:12月2020
このページの情報は©2010-2021Scaled Agile,Inc.です。 そして、米国および国際著作権法によって保護されています。 画像やテキストは、著作権者の書面による明示的な許可なしに、このサイトからコピーすることはできません。 Scaled Agile FrameworkおよびSAFeは、Scaled Agile,Inc.の登録商標です。 アクセス許可のFaqを訪問し、アクセス許可のための私達に連絡してくださ著者
- ディーン-レフィングウェル-
