SAFeのPI計画

Scaled Agile Framework、SAFeは、Scaled Agile Inc.が開発したアジャイル開発フレームワークであり、基本的に無駄のないエンタープライズレベルのアジャイル開発を実装するための知識ベースです。 以下は、元のPI Planning-Scaled Agile Frameworkの記事の無料の改定です。





190名のPI計画セッション

製品開発タスクを事前に予測することはできません。 最終結果を評価し、結果に影響を与えることができる人に計画と追跡を渡します。

-マイケルケネディ、リーンエンタープライズ向け製品開発

SAFeには魔法はありません...ただPIの計画がない限り。

-著者SAFe

アジャイルマニフェストの原則の 1つは、「直接コミュニケーションは、チーム自体およびチーム内で情報を交換するための最も実用的で効果的な方法です」と述べています。 これは、小さなチームが1人いる場合は簡単です。 しかし、多くのチームがあり、それらの同期作業が必要な場合、大企業の規模はどうでしょうか？ これを行うには、PIアジャイルフレームワーク（SAFe）でPI計画ツールを使用します。これは、すべてのチーム、ビジネス担当者、その他の利害関係者の直接コミュニケーションの実践です。



コミュニケーションは、標準的なアジェンダを使用した定期的な会議で行われます。最初に、チームがプログラム内で作成された製品の増分を実装するための計画を作成するときに、現在の状況、戦略、タスク、および計画セッションに関するストーリーを含むビジネス代表者のプレゼンテーションがあります-プログラム増分（PI）。 すぐに予約します。SAFeの用語では、「プログラム」という用語は、相互に接続された多数のチームを指すために使用されますが、将来的にはこれに固執します。 このセッションには、可能な限りすべてのARTメンバーが参加します。 そのような会議を容易にするために、特別な役割が割り当てられています-リリーストレインエンジニア（RTE）。 また、ブロッカーのエスカレーションを担当し、リスク管理、価値提供、継続的な改善を支援しています。



このような計画、研究、およびトレーニングイベントには、PI内の他の反復でチームの時間がかからないように、特別なIP反復（イノベーションと計画の反復）が提供されます。 セッションは1.5から2日間続きます。 その結果、次のPIのプログラム目標の一貫したセットが得られます。



地理的に分散したARTは、この会議を別の場所で同時に開催しますが、相互の継続的なコミュニケーションを維持します。

復習

PI計画を定期的に実行することが重要です。これは、ART全体のリズムを設定するからです。 これはSAFeの不可欠な部分です。PI計画を実行しない場合、SAFeは使用しません。





250人の参加者向けのPI計画セッション



PIプランニングは、ビジネスに多くの利点をもたらします。

• ARTの内部では、共同プロジェクトを行う必要のある人の多くが初めて知り合うため、ビジネスコミュニケーションが確立されています。
• すべてのチームメンバーと利害関係者間のコミュニケーションの高い効率が確保されます。 簡単に言えば、たくさんの人を集めて彼らに目標を与えれば、これは並外れたエネルギーコミュニケーションにつながります。 私たちの経験でテストしました！ （コメント翻訳者）
• ビジネスの顧客と開発者は、最終的にお互いの意見を聞き、ビジネスの目標に従って協調して行動し始めます。
• チームは「全体像」を見るようになり、依存関係が明らかになります。これにより、チーム同士や他のART間の調整が促進されます。
• チームは、アーキテクチャとユーザーインターフェイスに必要な最小要件のみを選択します。 これにより、過剰な機能を「ロールアップ」せずに、予定された期限を守ることができます。
• チームの能力を考慮して作業範囲を計画します。これにより、過剰な不完全な作業が排除されます。
• 意思決定が加速されます。

セッションでは、ロードマップ、コンセプト、プログラムのバックログの上位10項目、およびビジネスコンテキストを伝えるためのその他の成果物の資料を準備中です。



PI計画の主な結果は次のとおりです。

1. 各チームが独自に定義するPIチームのSMART目標のセット。 各目標は、ビジネスの関連性の観点から評価されます。 すべてのチームの目標は、PIプログラム全体の目標のセットに結合されます。
2. 新しい機能、実装の予定日、およびチームの目標が関連付けられているその他のマイルストーンを示すプログラムボード。
3. これらの目標の達成に責任を負うというリアリズムと意欲との一般的な合意。

準備する

PIプランニングは、準備、調整、コミュニケーションを必要とする重要なイベントです。 イベントの参加者：プロダクトマネージャー、アジャイルチーム、アーキテクトとエンジニア、システムチーム、利害関係者-すべて事前に通知し、十分に準備されたイベントに来てください。



次の分野で成功するイベントが準備されています。

• 組織：戦略に基づくビジネスと開発の一貫性、チームおよびART全体の準備。
• 内容：管理者と開発者の準備。
• インフラストラクチャ：会場およびイベントのロジスティクス。

以下は、各エリアでのトレーニングの説明です。

組織

プログラムには、ビジネスの利害関係者や代表者を含むイベントの参加者が理解できる戦略があり、チームがこの戦略に従って機能すること、ARTのすべての主要な役割に人がいることを確認することが重要です。



この準備を判断するのに役立つ質問の例を以下に示します。

• 作業範囲と計画コンテキスト：「計画フレームワークは明確ですか？製品、システム、技術分野ですか？ 共同計画にどのチームが必要かを知っていますか？」
• ビジネスの一貫性：「ビジネス代表者間で優先順位は一致していますか？」
• アジャイルチーム：「アジャイルチームはありますか？ すべてのチームに開発者とテスターが配置されていますか？ スクラムマスターとプロダクトオーナーはどこでも定義されていますか？」

内容

コンセプトとビジネスコンテキストを正しく伝えることも同様に重要です。したがって、必要なすべての利害関係者がセッションに出席する必要があります。 このため、PI計画には次のアクティビティが含まれます。

• 経営陣からの現在のビジネスコンテキストの概要。
• プログラムのバックログの上位10の優先機能に基づいて、製品マネージャーが作成した製品コンセプトの概要。
• アーキテクチャコンセプトの概要は、通常、機能の要件だけでなく機能の実装をサポートするための技術革新について話すために、テクニカルディレクターまたはアーキテクトによって提供されます。

インフラ

特に遠隔地の参加者がいる場合、多数の参加者でイベントの会場と技術インフラストラクチャを準備するのはそれほど簡単ではありません。



考慮すべき点は次のとおりです。

• スペース：必要に応じて休憩のためのスペースを含め、部屋はすべての参加者に十分な大きさでなければなりません。
• 技術サポート：イベントでの技術インフラストラクチャの問題の設定、テスト、解決を支援する人を事前に特定します。
• 通信チャネル：分散スケジューリングセッションには、オーディオ、ビデオ、およびプレゼンテーションをブロードキャストするためのプライマリチャネルとバックアップチャネルが必要です。

議題

一般に、イベントは以下に示す標準のアジェンダに従います。 次に、イベントの各ブロックを詳細に検討します。





2日間のPI計画セッションの標準アジェンダ

1日目

ビジネスコンテキスト

トップマネージャーまたはビジネスオーナーは、ビジネスの現在の状態と、現在のソリューションが長期的に顧客のニーズをどれだけ満たしているかを説明します。

製品コンセプト

プロダクトマネージャーは、プログラムの現在のコンセプトを提示し、通常、実装のために登場する最も重要な10の機能、以前のPI計画からの変更、および将来のマイルストーンについて話します。

アーキテクチャと開発プラクティス

システム設計者は、アーキテクチャの概念を提示します。 さらに、上級開発マネージャーは、テストの自動化や継続的統合など、次のPIで考慮する必要があるアジャイル開発プラクティスの変更について話すことができます。

計画のコンテキスト

ファシリテーターのRTEは、イベントの計画プロセスと期待される結果について説明します。





ファシリテーターは、100人のPI計画セッションの目標と計画を説明します

チームワーク-1

各反復のチームは、実行可能な作業量（容量）を推定し、機能の実装に必要と思われるバックログ要素を決定します。 各チームは、他のすべての参加者に見える計画案を繰り返し作成します。 現時点では、リスクと依存関係を特定し、PIのチームの目標の草案を決定します。 チームはまた、プログラムボードに機能を追加します。





チームは、100人ごとにPI計画セッションの相互依存関係を特定します。

計画案のレビュー

計画のレビューは、各チームのパフォーマンスに対して厳しい時間制限で実行されます。 この時点で、チームは主な計画結果、つまり目標案、潜在的なリスク、依存関係を提示します。 ビジネスの代表者、製品マネージャー、他のチーム、および利害関係者が質問し、フィードバックを提供します。





製品所有者は、100人のPI計画セッションでチームが組み立てた計画を提示します。

マネジメントレビューと問題解決

予想される作業量、限られたリソース、特定された依存関係を考慮して、計画を完成させる必要がある可能性があります。 この会議中、経営陣は作業範囲を承認し、計画の不備を修正します。 RTEは、達成可能な目標を特定するまで、すべての主要な利害関係者との会議を開催します。

2日目

計画を変更する

翌日、イベントは、マニュアルに計画された作業量とリソースのすべての変更が記載されているという事実から始まります。

チームワーク-2

チームは前日の結果に基づいて計画を継続し、必要な変更を加えます。 PIで目標を確定し、ビジネスの代表者がこれらの目標のビジネス価値を評価します。





100人のPI計画セッションでの1つのチームの計画結果

最終計画の提示

すべてのチームが計画を簡単に提示します。 各チームのパフォーマンスの終わりに、リスクとブロッカーが表明されますが、チームはこの短期間で解決策について議論したり求めたりすることはできません。 計画が顧客に受け入れられた場合、チームはPIの目標とリスクのあるフリップチャートを最も目に見える場所に掲示し、誰もがプログラムの全体的な目標の形成をリアルタイムで確認できるようにします。

プログラムのリスク

計画中、チームはプログラムレベルで重大なリスクとブロッカーを発見します。これは、チームが問題を解決する能力に影響を与える可能性があります。 これらの問題は、すべての参加者によって対処されています。 すべてのリスクは、次のグループに明確に、正直に、そして公然と分類されます。

• 解決済み-チームは、問題がもはや関連していないことに同意しました。
• 所有-イベントで問題を解決できませんが、誰かがこの問題をさらに解決することに同意しました。
• 受け入れられた-いくつかのリスクは、将来の作業で単に理解され考慮されるべき事実または潜在的なイベントです。
• 軽減-チームは、このリスクまたはブロッカーの結果を排除する計画を決定できます。

100人のPI計画セッションでのプログラムのリスク

投票

プログラムのリスクが考慮された後、チームはPIでこれらのプログラムの目標を達成するための責任をとる現実主義と意欲に投票します。 チームメンバー全員が手を上げて、1本から5本の指を見せます。





100人ごとのPI計画セッションの投票ルール



すべてのチームで平均で3本または4本の指が挙がっている場合、経営者はそのような義務を受け入れることができます。 平均して指が3本未満の場合、必要な変更が計画に加えられ、すべての計画が処理されます。 2本以下の指を上げる人は、懸念を表明する必要があります。 これにより、再計画が必要な新しいリスクを特定するか、重要な情報を全員に伝えることができます。





100人のPI計画セッションの前に、スクラムマスターとチームのプロダクトオーナーとのリハーサルで投票

必要に応じて計画の変更

必要に応じて、チームは信頼レベルが十分になるまで計画を修正します。 これはPI計画セッション全体の最初の瞬間であり、時間の制約が通り過ぎるときです。より重要なのは、計画の一貫性と実装の責任を取るチームの意欲です。

回顧

最後に、RTEは短い回顧セッションを実施して、何がうまくいったのか、何が良くなかったのか、そして次のPI計画セッションで何が改善できるのかを判断します。



その後、次のステップについて議論し、アジャイルプロジェクト管理ITツールに目標とユーザーストーリーを入力し、今後の主要なアクティビティとイベントを計画し、さらに部屋を片付けることもできます！

結果

PIプランニングの成功は、3つの重要な成果物をもたらします。

1. 各チームが独自に定義するPIチームのSMART目標のセット。 各目標について、ビジネスの代表者がビジネス価値の評価を決定しました。
2. プログラムボード。新機能の配信日、チーム間の依存関係、他のARTへの依存関係、および重要なマイルストーンを表示します。
   
   
   
   
   
   ART Oneプログラム委員会
   
   
   
   
3. すべてのARTチームが、PIの目標の現実性と、これらの目標を達成する責任を負う意志を持つことの合意。

練習する

このビデオでは、私たちのPIプランニングのプラクティス：





PS 大企業のプロセスの変革に関する資料に興味がある場合は、FacebookのEnterprise Agile Russiaグループをお勧めします。 SAFeやLeSSなどのスケーリングアプローチについて説明します。