None of my inventions came by accident. I see a worthwhile need to be met, and I make trial after trial until it comes.
—Thomas Edison
イテレーション
注: SAFeスクラムについて詳しくは、スクラム関連の追加のフレームワーク記事をご覧ください。これには、SAFeスクラム、SAFeスクラムマスター / チームコーチ、イテレーションプランニング、イテレーションゴール、イテレーションレビュー、そしてイテレーションレトロスペクティブが含まれます。
イテレーションは固定期間の標準的なタイムボックスです、このタイムボックスの中で、アジャイルチームとARTは個別に、また集団で、PIオブジェクティブの達成に向けて仕事をしながらインクリメンタルなバリューを顧客に提供します。
各プランニングインターバル (PI) には通常、4つの2週間の開発イテレーション(この記事の内容)に続いて、1つのイノベーション&プランニング (IP) イテレーションがあります。 これらのイテレーションの間、アジャイルチームは継続的に探索、定義、構築、テストし、顧客にバリューを提供します。IPイテレーションはPIオブジェクティブを達成するための見積りバッファーであり、イノベーション、教育の継続、PIプランニング、およびインスペクト&アダプト (I&A) イベントのための専用の時間を提供します。
アジャイルリリーストレイン (ART) 上のアジャイルチームは、PI内で協力し、チームおよびART PIオブジェクティブに向けてソリューションを進めます。 ART上のすべてのチームは、同一のイテレーションとPIケイデンスで同期します。
これらのチームは共に計画を立て、デモを行い、学習します。これにより、チームはローカルな懸念とトレインのより大きな目標の両方に集中することができます。 このベクトル合わせにより、チームは共に、そして独立してバリューを探求、統合、デプロイ、リリースすることができます。
詳細
アジャイルチームとARTは、一連のイテレーションで仕事をすることで、それぞれの責任を果たします。 各イテレーションはARTのPDCAサイクルです。 イテレーションは継続的に順を追って実行され、新しいイテレーションは前のイテレーションの直後に開始されます。
PDCAサイクルには次の4つのステップがあります。
- Plan (計画): タイムボックスのゴールを決定し、必要な仕事を特定する
- Do (実行): ソリューションの小さなインクリメントを迅速に提供する
- Check (確認): 結果と学びをレビュー、実証、および分析する
- Adjust (調整): 調整して新しいサイクルを開始する
原則 #7 – ケイデンスを適用する。分野横断のプランニングで同期するは、アジャイルチームが同一のリズムに従うことで、他のグループとより良く同期し、依存関係を管理する方法を説明しています。 しかし、そのリズム内でのプランニングと実行の実践は、チームがSAFeスクラムまたはSAFeチームカンバン、またはそれらの手法のハイブリッドで仕事するかどうかに基づいて異なる場合があります。 スクラムチームは、標準的で特定のイテレーションイベント(SAFeスクラムの記事を参照)を使用して、仕事を計画および管理します。 カンバンチームは通常、継続的なフローモデルで仕事をしますが、イテレーションイベントを使用することもあります。
図1は、PI、ART、およびアジャイルチームのネストされたPDCAサイクルを示しています。
以下のセクションでは、これらのPDCAサイクルの各要素について説明します。
PIのPDCAサイクル
PIプランニングはPIのPDCAサイクルを開始し、そこでチームは、ソリューションビジョンを達成するため部分的にバックログを埋めます。 その後、ARTとそのチームはPI内で個別および共同のイテレーションPDCAサイクルを実行します。 ARTは定期的な一連のシステムデモで進捗状況を客観的に測定します。 タイムボックスは、インスペクト&アダプト (I&A) イベントの最初の部分であるPIシステムデモで終了します。 このデモでは、ARTがPIにおいて開発したすべてのフィーチャーを示します。 I&Aにおいて、ビジネスオーナーはPIオブジェクティブを評価し、プロダクト / ソリューションのパフォーマンスをアセスします。 さらに、ARTの全員が協力して、I&Aの問題解決ワークショップでシステムに関連する問題を特定し、対応します。
以下のセクションでは、PI内の各イテレーションにおけるARTとアジャイルチームのアクティビティについて説明します。
アジャイルリリーストレインのアクティビティ
ARTの高い開発ベロシティを維持するためには、フィードバックを得ることが重要です。 スピードは、迅速な学習、頻繁な統合ポイント、およびARTイテレーションのPDCAサイクル内での適応から生まれます。
図1は、各イテレーションが短いPDCAサイクルであり、その中でARTがPIオブジェクティブの大部分を開発することを示しています(詳細については、SAFe原則#4、迅速で統合された学習サイクルでインクリメンタルに構築するを参照してください)。
以下のセクションでは、ARTのイテレーションにPDCAサイクルを適用するためのアクティビティについて説明します。これは、すべてのチームの共同作業です。
Plan (計画)
- システムデモのプランニング – チームとARTステークホルダーは、システムデモで何を発表するか、誰がファシリテートしデモを行うかを計画します。 システムコンテキスト、ロジスティクス、インフラストラクチャ、およびステージング環境はデモの前に確立されなければなりません。 プロダクトマネジメントは、システムデモのアジェンダと内容を、特に新機能においてビジネスおよび顧客の利益に関わる内容をステークホルダーに伝えます。
- リリースのプランニング – 次回のイテレーション中に、チームはソリューションのベースラインに新機能を継続的に統合し、リリースオンデマンドを行います。 ARTはこれらのリリースを計画し、コンプライアンスと品質基準、ビジネスおよび顧客への影響をアセスする準備ができている必要があります。
Do (実行)
- バリューの提供 – 完了したフィーチャーは、意図した成果を達成するために顧客にリリースされます。 ARTは多くのリリース要素を継続的デリバリーパイプラインを通じて自動化できますが、ARTステークホルダーとのコミュニケーションやデリバリープロセスへの関与など、手動の監視が必要な場合もあります。
- 阻害要因の除去およびリスクへの対処 – ARTステークホルダー、特にリリーストレインエンジニア (RTE)、プロダクトマネジメント、およびシステムアーキテクトは、イテレーションを通じてチームと協力して障害に対処します。 時として、重大な問題を解決するためにビジネスオーナーや他のステークホルダーへのエスカレーションが必要になる場合があります。
- システムデモの実行 – システムデモは、各イテレーションの終わりにARTの複合インクリメントを検査し、進捗状況をアセスし、フィードバックを得て、プロダクトと開発プロセスの両方を改善する機会を提供します。
Check (確認)
- シンクイベントの実施 – ARTは同期ミーティング(例えば、POシンクやコーチシンク)を開催して進捗状況を確認し、チーム間およびARTの依存関係の解決を促し、その他の問題を解決します。
- 進捗状況の測定と監視 – PIオブジェクティブに向けた進捗状況は測定および監視されます。 PIプランニング中に作成されたROAMボードは、通常、POシンクまたはコーチシンク中にレビューされ、リスクを所有または軽減する責任を持つ人が必要なアクションを取ることを確認します。
- 前回のI&Aからの改善事項の進捗状況のレビュー – RTEとスクラムマスター / チームコーチは協力して、PIにおいて特定されたI&Aの改善事項を達成するために必要な関連する仕事をARTが完了することを確実にします。
- 成果とフローメトリクスのレビュー – SAFeの3つの測定分野である、「成果」、「フロー」、および「コンピテンシー」は、進捗状況をアセスし、より良い意思決定をサポートし、ARTの人々、プロダクト、およびプロセスの改善機会を特定するのをサポートするため、定期的にレビューされます。 (詳細については、メジャー&グローの記事をご覧ください。)
Adjust (調整)
- 継続的なARTバックログのリファインメント – ARTバックログは、PIオブジェクティブに対する進捗状況を追跡し、開発中のソリューションから顧客がベネフィットを得られるように、常に優先順位をつけて調整されます。
- ARTのプロセスの改善 – 進捗状況を測定し、迅速なフィードバックを得ることで、ARTが開発プロセスを改善するために必要なデータを提供します。
- フィードバックへの対応 – 顧客、ビジネスオーナー、および他のステークホルダーから迅速なフィードバックを得ることは、ARTが実現可能で経済的に妥当であり、魅力的で持続可能なソリューションを構築していることを確認するために不可欠です(デザイン思考を参照してください)。
チームアクティビティ
アジャイルチームは、各イテレーションごとに完全なPDCAサイクルを実行することで、顧客に対して迅速かつ信頼性の高いバリューフローを達成します。 アクティビティには以下が含まれます。
Plan (計画)
- チームバックログのリファインメント – チーム、顧客、および他のステークホルダーとの協力的な対話の中で、チームはバックログをリファインします。 このリファインメントはビジネスと開発チームの間の障壁を取り除き、依存関係を特定して対処し、ムダ、引き継ぎ、遅延を排除します。 ストーリーの受け入れ基準は、要件の明確さを高め、チームの集合知識と創造性を活用し、理解、関与、およびオーナーシップを生み出します。
- チームのイテレーションプランニング – SAFeスクラムチームは各イテレーションの開始時にイテレーションプランニングイベントで協力します。 チームは、次のタイムボックス中にどれだけのチームバックログを提供できるかを決定し、その仕事をイテレーションバックログに記録します。 チームは計画を一連のイテレーションゴールにまとめます。 SAFeカンバンチームは、必要に応じて(多くの場合週1回)プランニングを行って仕事を調整し、バックログ内のストーリーを補充し、イテレーションにおける依存関係や期日のあるコミットメントに対応します。 チームは、しばしばイテレーションゴールを作成することが役立つと感じています。これにより、ステークホルダーとマネジメントがPI実行中にベクトル合わせを維持し、進捗状況を伝え、依存関係を管理し、必要な調整を行うための共通言語が提供されます。
- チームとシステムデモのプランニング – チームは、フィーチャーを実装してPIオブジェクティブを達成するために、PIプランニング中およびその後に定義したストーリーをどのようにデモするかを計画します。 終わりを念頭に置いて始めることで、プランニングとベクトル合わせが促進され、イテレーション実行前に、必要な機能について理解を深めることができます。
Do (実行)
- ストーリーと高品質バリューのインクリメントのデリバリー – チームはARTの開発ケイデンスと同期の要件内でバリューを創造し、ビジネスのニーズに応じてオンデマンドでリリースします。 チームは継続的デリバリーパイプライン (CDP) を構築、活用して、継続的な探索、継続的な統合、および継続的なデプロイメントのアクティビティが可能な限り継続的に行われることを保証します。
- チームシンクとデモの実施 – チームは継続的に仕事を調整して同期し、進捗状況を確認し、現在および今後の仕事を調整するためのアクションプランを作成します。 チームは完了した仕事のデモをすぐに実施して、迅速なフィードバックを得ます。
- ストーリーの進捗状況の監視 – チームはカンバンボードを使用して、すべてのアクティブおよび保留中の仕事、ワークフロー状態、WIP制限、リスク、および阻害要因を視覚化します。
Check (確認)
- レトロスペクティブの実施 – チームはイテレーションを振り返り、インクリメントとプロセスを改善するための新しいアイデアを導き出します。 方法によっては、チームはこの振り返りをイテレーションレトロスペクティブで行うか、必要に応じて定期的に行うことがあります。 レトロスペクティブは継続的な改善が行われ、得られた知識がI&Aでの問題解決に役立つことを確実にします。
- 以前のイテレーションからの改善ストーリーのレビュー – チームは以前の改善ストーリーの結果をレビューし、特定された問題とその根本原因に十分に対処したかどうかを確認します。
- チームのステークホルダーとのデモのレビュー – チームは完了した仕事のデモをできるだけ早く実施して、顧客とステークホルダーの迅速なフィードバックを得ます。 スクラムチームは通常、進捗状況をよりよく理解するために、より正式なイテレーションレビューを実施します。
Adjust (調整)
- チームバックログのリファインメント – チームは常にバックログをリファインし、実装の準備が整ったストーリーが常に含まれるようにします。 リファインメントの間、チームは今後のユーザーストーリーやフィーチャーをレビューし、予備的な受け入れ基準を議論し、見積り、確立します。
- チームのプロセスの改善 – 結果、フロー、およびコンピテンシーのメトリクスに基づいて、チームはプロセスの改善点を特定し、バリューフローを妨げる阻害要因や遅延に対処します。
詳しく学ぶ
[1] Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled, Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020 [2] Cockburn, Alistair. Using Both Incremental and Iterative Development. STSC CrossTalk 21, 2008.
最終更新: 2022年12月20日