チームバックログ

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

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

チームバックログの概要

チームバックログは、システムの担当部分を進歩させるためにチームが行わなければならない、すべてのことを集めたものである。ユーザーストーリーやイネイブラーストーリーが含まれる。その多くはプログラムバックログから来たストーリーだが、チームの個別のコンテキストで発生したローカルのものもある。チームバックログの所有者はプロダクトオーナー(PO)だが、バックログを「所有する」といっても、POしかバックログに追加できないという意味ではなく、どの作業を実施するかの優先順位をPOが付けるという意味である。

イネイブラーストーリーとユーザーストーリーの両方がバックログに含まれるため、処理能力の割り当てを行って、競合するニーズの間で投資のバランスを取れるようにすることが大切である。これは、アジャイルリリース列車全体の処理能力の割り当てと、チームのニーズとに基づいて行う。

詳細

「バックログ」は単純な概念のように見えるが、このシンプルな構造の裏に力を生み出すいくつかの知恵がある。

  • 本当にすべてのものが含まれる。そこに含まれているものは、実施されるかもしれない。含まれていなければ、実施されるチャンスはない
  • 「やりたい」項目のリストであり、確約ではない。リストの各項目は、見積もりされる場合(こちらの方が望ましい)もされない場合もあるが、いずれにしても、いつ実施されるかについて具体的な時間を確約するものではない。
  • 所有者はチームのプロダクトオーナーただ1人である。これによって、何が重要かについて複数の利害関係者の見解がそれぞれ異なるという問題からチームが守られる。
  • チームメンバーの誰でも、自分が重要だと思うストーリーをバックログに追加することができる。
  • ユーザーストーリーイネイブラーストーリー、「改善ストーリー」(チームの反復の振り返りの結果を反映したストーリー)が含まれる。

チームバックログはシンプルで統一化された構造であり、大規模なアジャイルの複雑な部分がうまく隠される。図1は、チームバックログと3つの主な情報源を示した図である。

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

プログラムバックログには、アジャイルリリース列車(ART)によって納品される予定の、これからのフィーチャーが含まれている。PI計画策定時に、そのプログラムインクリメント(PI)の計画に含まれるフィーチャーはストーリーに分割され、チームバックログ内で今後の個々の反復に暫定的に割り当てられる。さらに、将来の作業の一部がこのあとの期間の計画に含められる。その場合、まだストーリーに分割されていない将来のフィーチャーもチームバックログに入れられることがある。また、フィーチャーを納品するのに複数のチームが協力しなければならない場合には、作業のうちそのチームの担当する部分(と見積った規模)が、チームのバックログにプレースホルダーとして入れられ、保守される。

チームには独自のコンテキストもある。チームのバックログには、通常、フィーチャーを実現するのに必要なストーリーだけでなく、新機能、リファクタリング、不具合、調査スパイクや、その他の技術的負債を表すローカルのストーリーも含まれる。後者も同じように、識別し、イネイブラーストーリーとして記述し、見積もり、優先順位を付けなければならない。

リリース列車に乗っているチームは孤立した島ではないため、チームのバックログには他のチームや利害関係者の目標をサポートするためのストーリーが反映されている。たとえば、フィーチャーやシステム能力や場合によってはエピックのための調査・見積もりのスパイクであったり、チームの依存関係や外部への確約を反映したストーリーなどである。

処理能力の割り当てにより価値の納品とシステムの健全性を最適化する

ART自体と同様に、どのチームも1つの課題に直面する。保守、リファクタリング、技術的負債といった内部の作業と、もっと直接的な価値を納品する新規ユーザーストーリーとの間で、どうバックログのバランスを保つかという課題である。「常にすべての新機能」という考えは、しばらくの間はうまくいって、市場に当面の満足をもたらすことができるかもしれないが、それが続くのは短期間であり、技術的負債の負荷に押しつぶされて、いずれは納品のベロシティーが低下してしまう。ベロシティーの低下を回避し、技術が古くなってシステムの大規模リプレースが必要になる時期を延ばすために、ソリューションの技術的な土台を強化し、同時に不具合修正やシステム強化によって既存顧客の満足度を維持するための、継続的な投資を行う。

その結果、作業の優先順位付けという課題が複雑になる。プロダクトオーナーは常に、1)不具合、2)リファクタリング/再設計/技術のアップグレード、3)新しいユーザーストーリーという、3つの異なるものの価値を比較しようとしているからである。そしてどの需要も天井知らずなのだ。プログラムバックログの場合と同じように、チームは処理能力の割り当てを行って、それぞれの種類の作業に対し、ある期間の全工数のうちどれだけを投入できるかの方針を決定する。その様子を図2に示す。

図2.  チームバックログの処理能力の割り当て

 

それが決まったらさらに、それぞれの種類について、各反復で実装する最も優先順位の高いバックログ項目を選択しなければならない。プログラムに対して確約されているストーリーの場合は、PI計画の確約で既に順位が決まっているだろう。しかし、ローカルのストーリーの場合には、価値を工数で割った値を使って、または手間をかける価値のある場合には完全なWSJFを適用して、プロダクトオーナーが優先順位を付けることができる。さらに、長期的なプロダクトの健全性と価値の納品とのバランスを保てるよう、時間が経てば(たとえばPIごとに)それぞれの種類への割り当て率を変更することができる。

バックログの手入れ

ここまでの部分で、バックログには、高度に成熟した、大きなリスクも驚きもなく実装できるよう基本的に準備の整った、いくつかのストーリーが含まれていることを述べた。チーム全体がこのプロセスに関与するため、ほとんどのチームはこのプロセスにもフローベースの方法を適用する。典型的には、反復ごとに(場合によっては毎週)少なくとも1回のチームワークショップを開催し、今後のストーリー(必要であればフィーチャーも)のレビュー、議論、見積もり、受け入れ基準の初期理解だけに焦点を絞って実施する。このミーティングを指す標準的な名前はないが、SAFeではバックログの手入れという名前でこのミーティングを呼んでいる。ただし、バックログの手入れという活動は継続的に行うものであり、1回きりの固定時間のミーティングだけで行えないことは認識されている。また、受け入れテスト駆動開発を導入しているチームは、具体的な受け入れテストを開発するために、先行して多くの時間を投入することが多い。場合によって、仕様ワークショップという特別なセッションを設けることもある。さらに、複数のチームがバックログの手入れを行うことによって、新たな課題や依存関係やストーリーが見つかる可能性もある。このように、バックログの手入れというプロセスは、現行の計画の中に潜む問題を明るみに出すのに役立つ(その問題についてはART同期ミーティングで議論する)。


さらに知りたい場合

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

Last update:15 October 2015