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

- トム ロビンズ

反復計画の概要

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

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

詳細

目的

反復計画はスクラムで定められた1つの儀式(ミーティング)であるので、図1に示すようにSAFeのチームレベルで行う。

図1.SAFeの反復計画

反復計画の目的は、作業を整理し、反復のために現実的なスコープを定義することである。このスコープはチームによって受け入れられる。このスクラムの儀式を行うことで、アジャイルチームスプリントゴールへの合意や、チームの容量に基づく合理的な確約が促進される。これはさらに、ストーリーの複雑さ、規模、他のストーリーやチームとの依存関係を考慮するのにも役立つ。

反復計画のインプット

SAFeでは、反復計画はPI 計画策定セッションで作成した初期のスプリント計画に対する調整と詳細レベルでの手入れである。チームは事前に推敲された チームバックログを用いて反復計画を行う。通常、チームバックログは今回対象となるスプリントの前に別のバックログ手入れのセッションで推敲される。計画ミーティングのインプットは以下である。

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

概要

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

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

儀式の詳細

ベロシティーの確立

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

スプリントゴール

スプリントゴールはチーム及びPI計画セッションで作成した プログラムの目標に基づいたものである。チームメンバーの処理能力が確立された後、チームは1つあるいは複数のスプリントゴールに関する理解と合意に注意を向ける。PI計画セッションに近いスプリントほど、プログラム目標もそのままとなる可能性が高い。図2にあるプロジェクトのスプリントゴールの例を示す。

図2. スプリントゴールの例

ストーリーの理解と見積もり

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

タスク

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

確約

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

参加者

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

  • プロダクトオーナー
  • スクラムマスター(ファシリテータとしても活動する)
  • 開発者やテスト担当者、及びその他反復に関わる全てのチームメンバー。QA、ドキュメント作成者、ビジネス分析者、技術リーダー、アーキテクトを含む
  • 他の利害関係者。他のアジャイルチームやプログラムの代表、ビジネス分野の専門家を含む

アジェンダ

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

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

ガイドライン

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

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

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

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

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

標準スクラムでは、チームのストーリーポイント見積もり、すなわち結果としてのベロシティーは、ローカルの、独立した関心事である。実際、小さなチームが自分たちのベロシティーを50と見積もり、一方より大きなチームが自分たちのベロシティーを12と見積もったとしても、誰かの知ったことではない。しかし、SAFeでは、ストーリーポイントベロシティーは正規化されたポイントでなければならない。正規化されたポイントによって、複数のチームが一緒にサポートしなければならないフィーチャーやエピックに関する見積もりは合理的経済性に基づいたものになる。こうするため、SAFeでは、あるチームの1ストーリーポイントが他のチームの1ストーリーポイントと同じになるよう近付いてくる。そして、場所(アメリカ、ヨーロッパ、インド、中国など)の経済面を考慮して調整すると、ストーリーポイントをコストに変換することによって、作業を経済性に基づいて見積もり、優先順位付けすることができる。結局のところ、投資とは何かを知らなければ、ROIの見込みを判断できない。チームごとの差異をなくしてスタート地点となる共通のストーリーポイントとベロシティーのベースラインを定めるために我々が利用しているアルゴリズムは以下である。

  • チームのすべての開発者とテスト担当者に対して、チームに8ポイントずつ与える (兼務者は調整する)
  • チームメンバーの休暇や休日すべてに対して各々1ポイント減らす
  • コーディングに半日、テストと検証に半日要するような小さなストーリーを探す。 そのストーリーを1とする
  • 他のすべてのストーリーをそのストーリーに対して相対的に見積もる

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

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

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

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


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley, 2011. 第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 14 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.