スクラムでチーム開発する上でのプロダクトゴールに向けたスケジュールの立て方がわからなく、書籍でそれらしきタイトルを見つけたので学習しました。
著者mike cohn 氏について
- Agile AllianceやScrum Allianceでの活動
- 有名書籍
リリース計画づくりの基本
概要
- リリース計画とは、期間内に、チームのベロシティの範囲内でできるタスクを選択して、一覧にしたもの
- 期間が3~6ヶ月（12週〜24週）
- イテレーションは3~12回（1週間/1回〜2ヶ月/1回）
必要な理由
- プロダクトオーナーとチームで何をどれくらいの期間で開発するかを決断できる
- 何をいつ開発できるかをステークホルダーに伝えられる
- ただイテレーションを繰り返すのではなく、最終的な目標へ向かう道標となる
リリース計画手順
- 作業量の計算
- 作業量の合計 = 予定しているイテレーションの回数 × チームのベロシティ
- 例: 6ヶ月後に新しいプロダクトをリリースしたい。1イテレーションの長さが2週間。リリースまでに13回のイテレーションを繰り返せる。チームのベロシティを20ポイントと想定する
- 13回のイテレーション × 20ポイント = 260ストーリーポイント
- 260ストーリーポイントがプロジェクトでこなせる作業量となる
- 260ポイントを超えないように選んで、それぞれに優先順位を付ける
- 作業量に見合う分だけのストーリーを選ぶ
- 260ポイントを超えない範囲でストーリーを選び、優先順位を決定
注意
- この時点では、担当者を割り当てず作業する順番も決めない
- 結局は、これをタスクへと分解することになる。しかし、そのタイミングは開発するイテレーションの開始時点にする
リリース計画を始める前準備
- プロジェクトの成功と失敗を決める評価条件の把握
- スケジュール・スコープ・リソースの3つの要素それぞれの理想的な目標を提示する
- 例「4つのテーマ（合計200ストーリーポイント）を3ヶ月で、増員することなく開発したい」
- 特に重要なのは大抵1つ
- 多くの場合、日付か機能のいずれか
- 日付の場合、フィーチャーは調整できる
- フィーチャーの場合、できることが重要
- 両方重要な場合は不明
- 多くの場合、日付か機能のいずれか
見積もりについて
前提、各チケットごとに見積もらなければならない。
- しかし、見積もりが必要なのは、新しいフィーチャーのうち、次のリリースに含まれそうなものだけ
- 数リリース先のような遠い将来のことまで見積もる必要はない
リリース日を決める
- フィーチャー手動の場合
- リリースに必要なすべてのフィーチャーの見積もりを合計し、その値に期待されるベロシティで割る
- 日付手動の場合
- イテレーション数に期待されるベロシティをかければ、ストーリーポイントの合計がわかる
- フィーチャーも日付も両方重要な場合
- 本書での記載はなし
リリース計画をどれだけ詳細にするか
リリースプランニングでどこまで詳細にするかは、あらかじめチームで話し合う必要がある
ケース
- リリース計画にあらかじめ全てのイテレーションでの開発内容を含める
- イテレーションごとの詳細は後回しにする=>こっちが一般的
メリデメ
リリース計画にあらかじめ全てのイテレーションでの開発内容を含める
- メリット: 具体的な詳細がわかる
- デメリット: 計画変更に対応しづらく、工数がかかる
イテレーションごとの詳細は後回しにする=>こっちが一般的
- メリット: 工数少なく、不確実性の多い（計画が変化しやすい）場合、柔軟性を持たせられる
- デメリット: 詳細がわからない
筆者の落とし所
- 最初の3回程度のイテレーションまではどのイテレーションにどのフィーチャーを割り振るのかを決めておく。残りはひとまとまりにしておく。付箋を使って入れ替え可能にする
リリース計画を更新する
- リリース計画には定期的な見直しと更新が必須。イテレーション終了時点でリリース計画を見直すようにルールを定めているチームが成果を上げている