＊こちらはオプトテクノロジーズの社内勉強会資料になります
自己紹介
株式会社オプト シニアエンジニア @sisisin
突然ですが、計画立ててますか？
スプリントプランニング、事業計画、etc...
アジャイル開発の文脈でよく用いられる「リリース計画」というものを簡単に紹介しようと思います
どんなもの？
開発チームの実力に照らし合わせて作成した、どの機能がどのぐらいの時期にリリースできそうかという計画
「プロジェクトのゴール」、「優先順位付けされ、可能な範囲で見積もられたユーザーストーリー」、「イテレーションの長さ」、「ベロシティ」があればリリース計画を立てることが可能であるといえる
アウトプットイメージ
なんのためのもの？
- 事業責任者目線：プロダクトの事業計画を敷くため
- 開発チーム目線：事業の目標に対して自分たちがどこまで行ける見込みなのか？また、途中経過で今どこにいるのか？を見える化し、適応するため
大事なポイント
- リリース計画は常に流動的であり、プロダクトの状況に合わせて継続的にメンテナンスしていかないと意味がなくなってしまう
- 計画はあくまでも「見込み」であり、これを約束するためのものではない
- 出来なさそうという「見込み」がわかったときにQCDSをどう調整するか？を考えるために利用する
- この計画は「変化への対応」のための道具である、という認識を持つ
どうやって作るか
- リリース計画を作成する
- プロジェクトのゴールを決める
- イテレーションの長さを決める
- ベロシティを算出する
- ユーザーストーリーを見積もり、優先順位をつける
- 用意した情報を元に、どの機能がいつごろに出せそうか？を書き出す
- リリース計画を更新する
リリース計画を作成する
プロジェクトのゴールを決める
- 「いつまでに」、「どんな機能を」、「どのぐらいのコストで」などを決定する
- 日付主導か、機能主導かが決まっていると良い
- 計画に変更があったときに、「この日までにはリリースをしたいのでこの機能は諦めよう」というような判断を下せるようにするため
イテレーションの長さを決める
ベロシティを算出する
ここで、「期間」と「実力」を数値化して、1イテレーションでどれだけのモノを提供できるのかを算出するための準備をします
スクラムを実施しているのであれば、簡単に出せますね。
ユーザーストーリーを見積もり、優先順位をつける
積み上がっているユーザーストーリーを見積もり、優先順位に並び替えます
日付主導のプロジェクトの場合、ここでどこまでいけそうか？を元に優先順位が変わってくるかと思います
用意した情報を元に、どの機能がいつごろに出せそうか？を書き出す
ここまでくれば書き出すだけです。簡単！
リリース計画を更新する
チームの状況が変わったら都度更新をします
例えばイテレーションの終了時や、新しいユーザーストーリーが発生したときに見直すのが定番です
やってみてどうなったか
- 次何をやるのかがわからない、ということがなくなり、将来への不安が減った
- 締切のある作業に対して、現時点でヤバいかどうかが即座に分かるようになった
- 向こう半年でやりたいことベースに、ユーザーストーリーの優先度を議論できるようになった
- 例えば、「こっちやってたらこの半年であっちのストーリー終わらせきれないかもしれないから優先度下げよう」というような会話
まとめ
アジャイルな開発プロセスでの中長期的計画方法であるリリース計画について紹介しました。
大事なのは、「自分たちのために活用する」という前提と、そのための継続的なメンテナンスかなと思います。
是非活用していきましょう
参考資料：アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~