Iteration Planning

自分の決めたことに執着せよ。しかし、アプローチは柔軟であれ。

– トム ロビンズ

反復計画の概要

チームベースの反復計画は制御を分散し、迅速でローカルな意思決定に権限を委譲するために重要なメカニズムである。スクラムでは、プロダクトバックログからいくつかのストーリーを選択し、それを次の反復で実行すると確約することによって、チーム計画を行う。この基本的なプロセスはSAFeの基礎でもあるが、SAFeのチームは「アジャイルリリース列車」(ART)の一部であるため、こちらの方が背景が広い。そのため、チームのバックログは、PI計画策定ミーティング時に種がまかれ、部分的に事前に計画されている。さらに、チームは前の反復からだけではなく、システムデモや他のチームからもフィードバックをもらう。
そのことや、物事の自然な成り行きと事実パターンの変更によって、反復計画の背景はさらに広くなる。しかしながら、各アジャイルチームは時間枠が固定された反復計画ミーティングにて次の反復を計画するため、この計画プロセスはスクラムのと大体同じである。このミーティングのアウトプットは以下である。

  1. 反復バックログ:反復で実行すると確約したストーリー、及び必要であれば受け入れ基準からなる
  2. 反復ゴールに関する文言:反復のビジネス目標。通常1、2文である
  3. ゴールを達成するために必要な作業に関するチームの確約

詳細

反復計画の目的は、作業を整理し、反復のために現実的なスコープを定義することである。各アジャイルチームは次の反復のためのいくつかのストーリー(反復バックログ)に合意し、これらのストーリーをまとめ、反復ゴールを作成する。反復のバックログやゴールはチームの容量に基づく。さらに、個々のストーリーの複雑さ、規模、他のストーリーやチームとの依存関係を考慮するようにする。計画の最後に、チームは反復ゴールに確約し、より大きな目的を達成するために必要に応じてストーリーを調整する。その代わりに、チームがゴールに集中し続けられるように、上役は反復のスコープに干渉したり、調整したりしない。

反復計画のインプット

SAFeでは、反復計画はアジャイルリリース列車PI計画策定で作成した初期の反復計画に対する調整と詳細レベルでの手入れである。

チームは事前に推敲されたチームバックログを用いて反復計画を行う。通常、チームバックログは今回対象となる反復の前に別のバックログ手入れのセッションで推敲される。計画ミーティングのインプットは以下である。

  • チームプログラムPI目標:PI計画策定時に確立されたもの
  • チームPI計画バックログ:PI計画時に計画されたストーリー からなる
  • ローカルコンテキストによる追加されたストーリー:計画セッション後に見つかった欠陥、リファクタリング作業、ストーリーを含む
  • 前の反復からのフィードバック:反復内でうまく完成できなかった(完了の定義を満たさなかった)優先順位の高いストーリーを含む(完了の定義はリリースページをご参照)
  • システムデモからのフィードバック:前の反復のどこかの時点で発生するもの

反復計画を行う

ミーティングの前に、プロダクトオーナープログラムインクリメント (PI)におけるチームの進捗に基づいて、予備的な反復ゴールをいくつか準備しておく。
通常、プロダクトオーナーは、ミーティングの最初に、提案された反復ゴール及びチームバックログにある優先順位が最も高いストーリーに対するレビューを行う。ミーティング中、アジャイルチームは実装の選択肢、技術課題、非機能要求 (NFR)、依存関係について議論し、反復を計画する。プロダクトオーナーは「何をするか」(What)を定義し、チームは「どのようにするか」(How)、「どれだけするか」(How much)を定義する。

ミーティングを通じ、チームは受け入れ基準を推敲し、各ストーリーを完了するためにかかる労力を見積もる。チームはチームのベロシティーに基づいて、候補のストーリーを選択する。ほとんどのチームは個々のストーリーをタスクに分解し、時間単位でタスクの見積もりを行う。このように、チームは各ストーリーを完了するためのキャパシティとスキルがあるかを確認する。確認が済んだら、チームは作業を行うと確約する。また、ストーリーボードやツールを利用し、反復バックログを見える場所へ記録する。ミーティングは4時間以下の時間枠(タイムボックス)で行う。

ベロシティーの確立

まず、チームはその反復において作業を実施するためのチームのキャパシティを定量化する。各チームメンバーはそれぞれの休み、他の潜在的な作業に使う時間を除く、反復に提供できる作業時間を決める。決める時に、メンテナンス作業のような新しいストーリー開発とは区別して行われる定常的な他の確約(チームバックログページの「キャパシティの割り当て」を参照)も考慮に入れる。

反復ゴール

反復ゴールはPI計画セッションで作成したチーム及びプログラムのPI目標に基づいたものである。チームメンバーのキャパシティが確立された後、チームは1つあるいは複数の反復ゴールに関する理解と合意に注意を向ける。PI計画セッションに近い反復ほど、プログラム目標もそのままとなる可能性が高い。

ストーリーの分析と見積もり

提示された反復ゴールを基準点として用い、チームバックログに対するレビューを実施する。チームはストーリーの相対的な難しさ、規模、複雑さ、技術的な課題、受け入れ基準などを討議する。最後に、チームはストーリーの規模の見積もりに合意する。チームバックログには、通常、インフラ作業、リファクタリング作業、調査スパイク、アーキテクチャーの改善と欠陥など、その他の種類のストーリーも含まれる。これらのストーリーはイネイブラーと呼ぶ。

タスク

大部分のチームは各ストーリーをタスクに分解する。タスクを識別したあと、タスクを完了させるために誰が一番適切な人か、タスクはおおよそどのくらい(通常時間単位)をかかるか、タスクが他のタスクやストーリーに依存するかに関して、チームメンバーは議論を行う。理解したら、チームメンバーがそれぞれタスクに関する責任を負う。チームメンバーがタスクに対して確約すると、そのメンバーのこの反復におけるキャパシティが徐々に少なくなり、最後には0になる。セッションの終わりごろには、あるチームメンバーは多く確約しすぎ、別のメンバーはキャパシティに余裕があるというようなことがしばしば生じる。このような状況を受けて、作業をより均等に分散できるようにチームメンバー間でさらなる議論を行う。

確約

確約されたストーリーでチームの総キャパシティがいっぱいになると、チームバックログからのストーリーの取り出しを中止する。この時点で、反復バックログに移動したストーリーの一覧に関してプロダクトオーナーとチームは合意し、同時に反復ゴールの再レビューと再確認を行う。チーム全体は反復ゴールに確約し、反復期間内の作業スコープを固定する。

参加者

反復計画ミーティングの参加者は以下を含む。

  • プロダクトオーナー
  • スクラムマスター(このミーティングのファシリテータとしても勤める)
  • ほかのチームメンバー
  • 他の利害関係者。他のアジャイルチームやARTの代表、ビジネス分野の専門家を含む

アジェンダ

以下は反復計画ミーティングのアジェンダのサンプルである。

  • チームは反復で提供できるベロシティーを決める
  • プロダクトオーナーは反復ゴールを説明し、チームはゴールを検討し、合意する
  • チームは順位の高い順(順序付け、あるいは優先順位付け)に各ストーリーを検討する。各ストーリーに対し、チームは以下のことを行う
    • ストーリーポイントを用いて規模の見積もり/再見積りをする。必要に応じ、ストーリーの分割を行う
    • 会話を通じ、受け入れ標準を推敲する
    • 規模、価値/時間/リスクに基づいて、必要であればPOがストーリーの順位を再調整する
    • オプション:順位の高い順に、チームが各ストーリーをタスクに分解し(時間単位で見積もる)、担当者を決める
    • 時間を使い切ったら計画を停止する
    • チームとPOは選択されたストーリーについて交渉し、最終決定をする
    • 全員が反復ゴールに対し確約する

ガイドライン

以下は反復計画ミーティングを成功させるためのポイントである。

  • ミーティングは4時間以内の時間枠で行う
  • チーム自身がチームのためにミーティングを開催する
  • チームが確約時に、今までのベロシティーや調整されたキャパシティーを超えないようにする

相対的見積もり、ベロシティー、正規化されたストーリーポイント見積もり

アジャイルチームは、ストーリーポイント[参考文献2と3]でストーリーの規模を相対的に見積もる。 相対的見積もりでは、各ストーリーの規模(労力)を、他のストーリーの規模(労力)と比較し、相対的に見積もる。ある反復に関するチームのベロシティーは、反復中で完成したすべてのストーリーの規模の合計となる。チームのベロシティーを知っておくことは、計画策定に役立つし、WIP(仕掛かり作業)を制限する(チームはそれまでのベロシティーを超えるストーリーを取り入れない)ための主要な要素にもなる。ベロシティーは、より大きなフィーチャーエピックを納品するために掛かる時間を見積もるのにも使われる(これらはストーリーポイントでも見積もられる)。

正規化されたストーリーポイントによる見積もり

標準スクラムでは、チームのストーリーポイント見積もり、すなわち結果としてのベロシティーは、ローカルの、独立した関心事である。実際、小さなチームが自分たちのベロシティーを50と見積もり、一方より大きなチームが自分たちのベロシティーを12と見積もったとしても、誰かの知ったことではない。しかし、SAFeでは、ストーリーポイントベロシティーは正規化されたポイントでなければならない。正規化されたポイントによって、複数のチームが一緒にサポートしなければならないフィーチャーやエピックに関する見積もりは合理的経済性に基づいたものになる。結局のところ、投資とは何かを知らなければ、ROIの見込みを判断できない。

こうするため、SAFeでは、あるチームの1ストーリーポイントが他のチームの1ストーリーポイントと同じになるよう近付いてくる。そして、場所(アメリカ、ヨーロッパ、インド、中国など)の経済面を考慮して調整すると、ストーリーポイントをコストに変換することによって、作業を経済性に基づいて見積もり、優先順位付けすることができる。このやり方は最初のPI計画で特に役に立つ。なぜならば、多くのチームがアジャイルの初心者である場合、最初のPIで作業範囲を見積もる方法が必要だろう。スタートするためのアルゴリズムは以下である。

  • プロダクトオーナーを除く、すべてのチームメンバーに対して、1人8ポイントを与える (兼務者は調整する)
  • チームメンバーの1日の休暇や休日に対して1ポイントを減らす
  • 開発に半日、テストと検証に半日要するような小さなストーリーを探す。 そのストーリーを1ポイントとする
  • 他のすべてのストーリーをそのストーリーに対して相対的に見積もる

例:3名の開発者、2名のテスト担当者、1名のPOからなる6名のチームで休暇等が無い場合、見積もられた初期ベロシティー = 5 * 8 ポイント= 40 ポイント/反復。(注意:開発者やテスト担当者がスクラムマスターを兼務する場合は、少し低く調整する必要がある)

このように、すべてのチームは共通の方法で作業の規模を見積もる。その結果、上役は特定の地域のチームの1ストーリーポイントにかかるコストを迅速に見積もることができる。そして、今後のフィーチャーやエピックに関するコスト見積もりを意味のある方法で算出できる。

注意: チームの見積もりやベロシティーを再構成する必要はない。これは単なる1つの共通スタート地点である。

チームのベロシティーは時間とともに向上していくという傾向がある。これは素晴らしいことで、実際に、数値はかなり安定していく。また、生産性の変化より、チームサイズや技術的背景の変化の方がチームのベロシティーに大きな影響を与える。必要に応じ、ファイナンシャル・プランナーにより1ストーリーポイントのコストを調整できる。正規化されていない場合、チームの規模が同じであっても、ベロシティーが大きくかけ離れているため、これは、正規化されていない状況と比べ、大きな問題ではない。


さらに知りたい場合

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

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. 第10章。(邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

[3] Cohn, Mike. Agile Estimating and Planning. Robert C. Martin Series. Prentice Hall, 2005.(邦訳:アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~、毎日コミュニケーションズ 、2009)

Last modified 23 October 2015