「バックログ」の定義
1. 炉の奥に入れておく大きなまき
2. たまった未実施のタスク、あるいは未処理の材料

1番目はゆっくり、2番目は早く燃やそう。

 

チームバックログの概要

チームバックログはソリューションを進歩させるためにチームが行わなければならない、すべてのことを集めたものである。チームバックログはユーザーストーリー、将来のフィーチャー、技術ストーリー、欠陥、インフラ作業、スパイク、リファクタリング作業など、チームが行わなければならないことを含むことができる。ストーリーの大部分がリリース計画策定時に識別されたが、一部はチームの特定のコンテキスト下で発見される。単純な概念であるように見えるが、このシンプルの構造の裏に本当の力をつくるいくつかの知恵がある。

  • 本当にやることが「すべて」含まれている。そこに書かれた場合には、完了されるかもしれない。そこに書かれていなかった場合、完了されるチャンスはない。
  • 「やりたい」ことのリストであるが、確約ではない。リストの各項目に関して、見積もりされることが望ましいが、必須ではない。いつ完了させるかに関する特定の時間の確約を意味しない。
  • チームのプロダクトオーナーは唯一の管理者である。複数の利害関係者は、何が重要なことかに関して、潜在的に異なる見解をもっているので、プロダクトオーナーの役割はこの問題からチームを守る。

プログラムバックログ、チームのローカルのコンテキスト、チーム外の利害関係者のニーズ、このようなバックログの内容に貢献する源はいくつがある。バックログは常に見積もりされた状態に維持することはチームの責務である。こうすることによって、チームやプログラムの経済性を促進する。

詳細

チームバックログ概要

チームバックログはシンプルで統一化された構造である一方、アジャイル、大規模アジャイルに関する複雑さを都合よく隠している。図1は、チームバックログと3つの主要な源を示した図である。

図1. チームバックログを展開した図

源1. プログラムバックログ

プログラムバックログはこれから実装するフィーチャーからなる。これらのフィーチャーはアジャイルリリース列車によって納品されることが計画されている。リリース計画策定時に、プログラムインクリメントのために計画されたフィーチャーはストーリーに分解され、暫定的にチームバックログに入れられ、これから実施する1つのスプリントに割り当てる。また、将来の作業はもしこれからの期間内で計画される場合、チームバックログに将来のフィーチャーも入れられる。プログラムレベルのフィーチャーが複数のチームによって納品されなければならない場合、各チームのバックログに「フィーチャーの某チームの部分」がプレースホルダとして入れられ、その規模の見積もりも維持される。

源2. チームコンテキスト

チームは自分のコンテキストがある。プロラムフィーチャーを実現するために必要なストーリーはもちろん、チームバックログにローカルストーリー(プログラムバックログから落ちってくるものではなく、顧客によって促進した新しいストーリー)、リファクタリング作業、欠陥、調査スパイクやほかの技術負債も含まれている。これらも識別され、見積もられ、優先順位付けられなければならない。

源3. その他の利害関係者

リリース列車にある各チームが決して孤立な島ではない。彼らのチームのバックログにほかのチームや利害関係者の目標をサポートするための特定のストーリーがあるでしょう。これらのストーリーは調査や見積もりスパイクであり、チームの依存関係や外部の確約を反映するものである。

バックログは見積もりされるものである

継続的、相対的な見積もりは効果的なアジャイルエンタプライズチームの印である。チームバックログでは、ストーリーや将来のフィーチャー、ほとんどのバックログ項目が見積もりされる。あるフィーチャーはチーム単独で実装できる場合、フィーチャーの見積もりはこのフィーチャーに対するすべての見積もりである。この場合、見積もりはプロダクト管理に利用され、WSJF優先順位モデルの中で分母(作業の規模)を決定する。チームが1つのフィーチャーに関し、一部しか実装できない場合、プログラムにおけるこのフィーチャーの見積もりは、フィーチャーの実装に関与する各チームからの見積もりの積み重ねとなる。このように、企業は、チームとプログラムのベロシティー(容量)に基づき、プログラムやポートフォリオと「こうしたらどうなるか(What if)」ゲームを行うことができる。また、将来のフィーチャー(あるいはフィーチャーに分解されたエピック)の規模の見積もりも行うことができる。

さらに、フィーチャーの一部が実装された場合、この部分が計画されないように、またユーザーストーリーに分解されないように、チームバックログにあるフィーチャーのプレースホルダに対し、更新しなければならない。更新によって、残作業のみの見積もりが反映される。このように、そのフィーチャーにどれくらいの作業が残っているかを確認するため、ツールのクエリが用いられる。これは仕掛作業や残作業の透明化と可視化に貢献する。また、サンク・コストを無視する能力も提供する。すなわち、もし残労力に対し、残作業の価値が釣り合わない場合、チームやプログラムが残作業を放置し、もっと重要な作業を取り込むことができる。このように、もっと高価値の作業のために容量を解放する。

容量の割り当てにより、価値の提供とシステムの健全性を最適化にする

すべてのチームが1つの挑戦に直面する。それはメンテナンス作業、リファクタリング作業、技術的負債といった内部に面する仕事と、より即時の価値を提供する新規ユーザーストーリーの間でのバランスを保つことである。「常に新規ユーザーストーリー」という考えは市場の満足をすぐにもたらせるかもしれないが、技術的負債の破壊的な重みによるベロシティーの低下とともに短命である。ベロシティーの低下を回避するため、そして技術の退化によるシステムの大規模リプレースの必要性を延期するため、アジャイルチームはソリューションの技術的な土台を強化するために投資しつつあり、同時に欠陥修正やシステム強化によって、既存顧客の満足を維持する。

これは優先順位付きの作業への挑戦を繁雑にしている。というのは、プロダクトオーナーは常に1.欠陥、2.コードのリファクタリング、再設計、技術の更新、3.新規ユーザーストーリーという三種類の異なるものの価値を比較しようとしている。しかもこれらのものに関する要望にきりがない!幸い、私たちはリーンとアジャイルツールキットに、この問題を解決できる他のツールを持っている。図2に示したように、容量の割り当てを利用し、チームは各種類の活動に対し、どのくらいの工数を投入できるかというシンプルなポリシーを決定する。

図2. チームバックログの容量割り当て

一旦決定した後に、チームは各部分に対し、それぞれ優先順位の高いバックログ項目を選択し、スプリントで実装する。プログラムにコミットされたユーザーストーリーは、リリース計画策定の確約によって事前に順位がすでに決められたかもしれない。ローカルのストーリーやリファクタリング作業、欠陥など、チームが「価値を工数で割る」(もし有益の場合、フルのWSJF)を利用しこれらの優先順位をつけることができる。さらに、長期的なプロダクトの健全性と価値の提供をバランス保つため、時間と共に、各種類の活動への割り当て率を変更することができる。(例えば、各プログラムインクリメント(PI))。

バックログの手入れ

ここまでの部分で、バックログには高度に成熟しており、大きなリスクや驚きもなく基本的に実装できるようなストーリーが含まれていることを述べた。チーム全体がこのプロセスに関与するため、ほとんどのチームはこのプロセスを利用する時、リズム感のあるアプローチを採用する。典型的に、各スプリント(あるいは毎週)ではチームワークショップを1回実施し、将来のストーリー(フィーチャーやエピック)のレビュー、議論、見積もり、初期の受け入れテスト基準に対する理解の確立などに注力する。このミーティングに関する標準用語がないが、SAFeでは「バックログの手入れ」を利用し、このミーティングを説明する。バックログの手入れは1回きりの固定時間のミーティングではなく、継続的な活動である。また、受け入れテスト駆動開発を導入するチームにとって、特定の受け入れテストを開発するため、先行して多くの時間を投入する必要がある。場合によって、「仕様ワークショップ」と呼ばれる特別なセッションを設ける。さらに、複数のチームがバックログの手入れを行うことによって、新たな課題、依存性とストーリーは生まれる可能性がある。このように、バックログ手入れプロセスは、現行の計画に関する根底的な問題を表面化することに役に立つ。


さらに知りたい場合

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

 

Last update: 2 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.