今のチームで、どうやってリリースプランニングをしているか簡単にまとめておく。
はじめに
リリースプランニングにはチームによっては様々な定義があるようだ。 自分のチームでは、エッセンシャル スクラムにある、
ある程度の長期間にわたる概要レベルの計画を作っておくと便利だ。私は、この種のプランニングのことをリリースプランニングと呼んでいる。
が近いと感じている。常に2~3ヶ月くらい先までのリリース計画を立てている。
タイミング
次のスプリントの準備をするときに実施をしている。 その時点で計画しているリリース計画の次の準備を始めていく。
参加者
プロダクトオーナー(PO)、プロジェクトマネージャー(PM)、開発リーダー(自分)。 このメンバーで、エッセンシャル スクラムにある以下を検討する事が可能なため。
- ビジネスと技術のトレードオフ
- 価値と品質の最適なバランス
プロセス
POが、中長期のビジョンや概要レベルの要件を準備してくる。 それを元にざっくりとしたスコープの確認と、大体のリリース期日を話す。
その話し合いを経て、POが後日より詳細なプロダクトバックログを準備してくる。 それを元にまた話し合ってスコープ・期日を決定していく。
大体2~3回くらいのMTGで、次のリリース計画を立てている。
リリース制約
今回のリリースにあたっての制約事項(主に機能のスコープと期日)を確認しておく。
といった、いずれの制約が重要なのかを確認しておく。 スプリントで計画どおりに開発が進捗しない場合に、スコープを変更するのか期日を遅らせるのかを、この段階で認識を揃えておく。
バックロググルーミング(リファインメント)
メンバーがバックログの確認をする。
- 開発リーダー(自分)が、POの要件から、バックログアイテムを作る
- 開発メンバーが、チケットは見積もり可能なタスクとなっているかを確認する
- メンバーの質問・指摘を受けてチケットの粒度を調整していく
上記のステップを踏んだ上で、後日スプリントプランニングをする。
最後に
細かいやり方は変化しているが、1年くらいはこの方法で実施している。
リリース制約に関しては、ほぼスコープを固定する方が多いので、どうしても間に合わない場合はリリース日を変更することが多い。
安定してリリースは出来ている。ただ、この方法がベストとは考えていない。
リファインメントについてはチケット粒度の調整がイマイチなことがあるので、これからも改善をしてより良いスクラムにしていきたい。
