第18章 リリースプランニング(長期計画)
一つのフィーチャーができるたびにリリースすることを継続デプロイメントと呼ばれる
この場合でも、ある程度長期間に合わたる概要レベルの計画を作っておくと便利
リリースプランニングはスプリントごとに行うアクティビティ
参加者はステークホルダーとスクラムチーム全体
実行するアクティビティは2つ
- これまでの流れやこれまでにわかってきたことを鑑みて、いずれかの制約を変更する必要があるか見直す
- プロダクトバックログのグルーミング
- 概要レベルのプロダクトバックログをもとにして、より詳細なPBIを作ったり、見積もりや優先順位をつける
制約内容の内容は以下の3つ
- スコープ
- 期日
- 予算
基本的にトレードオフの関係になる
スコープの制約を固定にすると、期日や予算の制約が可変になるなど
上記3つの制約を厳しくしすぎると、品質が犠牲になる
リリースまでに必要なスプリント数と計算するには、ベロシティの最小値と最大値でそれぞれ、ストーリーポイントを割ればわかる
ここまでの感想や実際の現場との差異
- うちの開発体制だと、スコープ固定が一番違い(たまに期日も固定される場合もある)
- しかし、複数のプロダクトをまとめて、一つのプロダクトバックログに入れているので見積もりが立てづらい
- なので現状ではリリースプランニングをやっても意味がないかも?
- 期日固定の場合だけ開催するでもいいかもしれない
- なので現状ではリリースプランニングをやっても意味がないかも?
- しかし、複数のプロダクトをまとめて、一つのプロダクトバックログに入れているので見積もりが立てづらい