While building trust gives teams the ability to reconfigure and “do the right thing,” it is also necessary to make sure that team members know what the right thing is. Team members must all work toward the same goal, and in volatile, complex environments that goal is changeable.
—General Stanley McChrystal, Team of Teams
チームバックログ
Definition: The Team Backlog is a Kanban system that is used to capture and manage the user stories and enablers intended to enhance the solution.
これには、ARTバックログのフィーチャーから作成されるストーリーや、チームのローカルコンテキストから発生するストーリーが含まれます。詳細
チームバックログには、ソリューションの強化のためにチームが実施する可能性のあるすべての仕事が含まれます。例えば、ユーザーストーリーやイネーブラーに加え、チームのレトロスペクティブやARTのインスペクト＆アダプトで話し合った是正措置のための改善ストーリーなどの作業項目が含まれます。
概念そのものは複雑ではありませんが、チームバックログには、それをアジャイル開発に欠かせないものにしている重要な側面がいくつかあります。以下に例を挙げます。
- ソリューションの発展に向けたアジャイルチームの仕事がすべて含まれ、共通の目標に向かってすべてのチームメンバーのベクトルを合わせます。
- コミットメントではなく、要望のリストです。項目の見積りを行う場合も (こちらが望ましい)、行わない場合もありますが、チームバックログは単なる順序付きリストであり、特定の時点までに完了させるコミットメントを伴いません。つまり、バックログは時間に依存しないため、何をいつ実装するかについては、通常、チームが柔軟に判断できます。
- チームメンバーは誰でも、バックログにストーリーを入力できます。
- オーナーはプロダクトオーナー (PO) で、何が必要不可欠なのかという点に関してそれぞれ意見が異なる複数のステークホルダーがいる難しい状況に対応できるよう、チームをサポートします。
チームやその他のステークホルダーからのインプットをもとに、チームバックログを作成し、メンテナンスする責任を担うのは主にPOです。ただし、チームメンバーなら誰でも、検討すべき項目をバックログに入力できます。POはステークホルダーのニーズのバランスを取りながら、バックログに優先順位をつけます。図1に示すように、チームバックログへの主なインプットは3つあります。
- ARTバックログ – ARTバックログは、トレインが今後提供を計画しているフィーチャーで構成されます。PIプランニング期間中に、チームは候補となるフィーチャーをストーリーに分割し、以降のイテレーションに仮に配置します。こうした新しいストーリーは、チームバックログで管理します。
- チームのローカルコンテキスト – チーム単位のローカルな懸念事項 (他の新機能、不具合、リファクタリング、技術的負債、メンテナンス) もバックログに含まれます。PIプランニングは概要レベルなので、PI期間中に調整が行われると考えられます。おそらく、スクラムを使用しているチームはイテレーションプランニングの際に、一方、カンバンを適用しているチームはバックログの補充の際に調整を行う可能性が高いでしょう。
- その他のステークホルダー – ARTに属するアジャイルチームはそれぞれが隔絶されているのではなく、バックログには他のチームの依存関係や、ARTのPIオブジェクティブを含むその他のコミットメントをサポートするストーリーが一部含まれます。こうしたストーリーには、フィーチャー、ケイパビリティ、場合によってはエピックの見積りに必要な調査のためのスパイクが含まれる場合があります。
さらに、チームは以前のインクリメント、システムデモ、他のグループからフィードバックを受けるため、それがバックログに影響を与える可能性もあります。
非機能要件 (NFR) は、ソリューションのデザイン、パフォーマンス、または品質に影響を与える可能性のある持続性のある品質です。チームのあらゆる項目に対する制約 (または制限) となりうるため、図1のビッグピクチャーでは、バックログの一番下に示されています。その重要性から、チームがNFRの受け入れテストを自動化し、それを完了の定義 (DoD) に含めることも珍しくありません。
バックログの作成とリファインメント
アジャイルチームは、継続的なフローベースのアプローチを採用して、バックログの準備状況を整えます。バックログに、重大なリスクや予期せぬ事態を生じさせることなくすぐに実装できるストーリーが常にいくつか含まれるようにするのです。庭の手入れを怠って放置すると荒れ果ててしまうように、チームバックログも手入れをしないと手に負えない状態になります。チームバックログのリファインメントには、以下のアクティビティが含まれます。
- ストーリーの精度を高め、受け入れ基準を確立する
- POは、チームおよびステークホルダーと協力して、定期的にチームバックログの優先順位をつける
- イネーブラーを含む新しいストーリーを見出し、記述し、既存のストーリーを変更または削除する
- 受け入れ基準を定義し、短期間のタイムボックスに収まるように規模を調整することで、優先順位の高い項目の準備を整える
- バックログにあまりに長い期間残っているストーリー、または重要性が失われたストーリーを削除する
チームバックログを管理するのはPOですが、リファインメントは協力して行うプロセスです。リファインメントによって、チーム、顧客、そしてその他のステークホルダーとの間に対話が生まれます。ビジネスと開発チームの間の障壁を取り除いて、ムダ、引き継ぎ、遅延をなくします。ストーリーの受け入れ基準を策定することで、要件がより明確になり、チームの集合知と集団的創造性を活用でき、賛同と共同オーナーシップが生まれます。
バックログリファインメントについては、規定されたミーティングパターンはありません。チームシンクの後に少し時間を取って、バックログリファインメントを行うチームもあります。1週間に1回リファインメントセッションや要件仕様ワークショップを行い、ビヘイビア駆動開発 (BDD) テクニックを実践してストーリーを明確にするチームもあります。フィーチャー開発は複数のチームが協力して進めることが多いため、得てして新たな問題、依存関係、ストーリーが発生しがちです。バックログリファインメントはまた、現在の計画における問題を明らかにするのにも有効で、その場合にはチームシンク、POシンク、またはコーチシンクでのディスカッションが必要となることがあります。
カンバンを使ったバックログの管理
SAFeでは、アジャイルチームはカンバンシステムを使用してバックログを管理します。バックログカンバンシステムによって、ベクトル合わせ、可視化、そして依存関係管理を円滑に進められます。例として、あるチームの初期のカンバンシステムを図2に示します。
このカンバンは、アクティブおよび保留中の仕事、ワークフローの状態、仕掛かり中の仕事 (WIP) の制限をすべて可視化します。システムにはWIP制限が設けられていて、作業項目の数がWIP制限を下回っている場合のみ、項目を次のステップに進められます。カンバン内のアクティビティの一部 (通常は、最初と最後) が、WIP制限の対象外となる場合もあります。チームはWIP制限を定義し調整することで、複雑なシステム開発バリエーションのフローに迅速に適応できるようにします。
チームカンバンシステムの確立に関して詳しくは、「SAFeでカンバンを適用する」および「SAFeチームカンバン」の記事を参照してください。
キャパシティ配分によってバリューのデリバリーとシステムの健全性のバランスを取る
ARTと同様に、各々のアジャイルチームも、内部の仕事 (メンテナンス、リファクタリング、技術的負債) と、より即時性の高いビジネスバリューを提供する新たなユーザーストーリーとの間のバランスを取るという課題に直面しています。ビジネス機能のみに重点的に取り組むアプローチは、しばらくの間はうまくいくかもしれませんが、技術的負債が増加するにつれて短期間で行き詰まり、結局は開発ベロシティを遅らせることになります。このリスクを回避するには、ソリューションのアーキテクチャランウェイの発展に継続的に投資すると同時に、機能強化、新機能、バグ修正を通じて顧客の満足度を高める必要があります。うまくこのバランスを取ることで、システムの寿命を延ばし、技術的な陳腐化を遅らせることができます。
しかし、不具合、リファクタリング、再設計、テクノロジーアップグレード、新しいユーザーストーリーなど、異なるもののバリューを比較しようとするPOにとって、種類の違う仕事に優先順位をつけるのは難しいものです。そして、これらのどの要素のデマンドにも際限はありません。
チームと協力して、POはそれぞれの項目の種類に対し、キャパシティ配分 (図3) を行います。続いてPO、チーム、システムアーキテクトは、プランニングにおいて、キャパシティ配分の各スライスに対する最優先のバックログ項目を選択します。多くのストーリーがフィーチャーをもとに作成されているため、ストーリーの中には、PIプランニングでのコミットメントによって優先順位があらかじめ決まっているものもあります。ただし、POはバリュー、サイズ、論理的順序を比較することによって、チームのローカルコンテキストに沿って仕事に優先順位をつけることができます。また、POはそれぞれの種類の作業項目への配分割合を調整できます。チームは必要に応じて、キャパシティ配分のカテゴリを変更すべきです。ただし、カテゴリは、同じARTに属するすべてのチームで一貫したものにする必要があります。
詳しく学ぶ
[1] Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled, Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020. [2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
最終更新: 2023年3月14日