概要
リリース計画は、リリースまでにどれだけ作業できて、どんなユーザーストーリーを実現できるかを判断すること
- 単純なケースなら、ベロシティ×予定しているイテレーション数に収まるようにストーリーを選択する。
リリース計画作りの進め方
- 満足条件を決める
- プロジェクトの成功と失敗を決める評価条件
- 例えば、「4つのテーマを3ヶ月で、増員することなく開発したい」
- ユーザーストーリーを見積もる
- イテレーションの長さを決める
- ベロシティを見積もる
- ユーザーストーリーに優先順位をつける
- ストーリーを選択し、リリース日を決める
- リリース計画をどれだけ詳細にするかを決める
- イテレーションにフィーチャを振り分けるか、直前でやるフィーチャを決めるか
- リリース計画をどれだけ詳細にするかを決める
- 各イテレーションの開始時点でリリース計画を見直して、更新する。
- イテレーション中のイベントのイテレーション計画ミーティングでやるのがいい
アジャイルサムライ――達人開発者への道 - Jonathan Rasmussonではアジャイルな初回の計画づくりとして紹介されていたが、同じことを指しているはず
不確実性に備えるバッファの計画
- フィーチャバッファ
- まず必須のフィーチャを選び、そこから25~40%のフィーチャを選ぶ。
- これらすべてを実現することを前提にプロジェクトの計画を立てる。
- スケジュールバッファ
- 各ユーザーストーリーの50%自信のある見積もりと90%自信のある見積もりの差の平方を求め、その値の合計の平方根から算出される。
- 機能面での不確実性から守るためにはフィーチャバッファを使い、スケジュール面での不確実性から守るにはスケジュールバッファを使う。
- 両方組み合わせて使うこともできる。
複数チーム編成プロジェクトの計画づくり
- 複数のチームが関わってくる場合に役立つテクニック4つ
- チーム間で共有できる見積もり基準の確率
- すべてのチームで同じ見積もり単位を採用する(理想日orストーリーポイント)
- 早い段階でのユーザーストーリーの詳細化
- プロダクトオーナーの満足条件を明確にしておく
- 先を見越した計画づくり
- 「移動する先読み範囲」
- 今後予定されているイテレーションのいくつか(2~3ite)までの先を見越して計画を立てる
- 近いうちに各チーム間でどういった連携が必要になるかを調整できる
- 「移動する先読み範囲」
- 合流バッファを取り入れた計画
- あるチームの作業の遅れがほかチームの作業開始に影響が及ばないようにプロジェクトに時間的な余裕を設ける
- チーム間で共有できる見積もり基準の確率