アジャイルな計画と実践
2年ほどアジャイル開発（XP）を行なって来た上での学びを一度整理しようと思います。
主に観点は以下の3つです。
- ストーリーの分割粒度について
- 計画時のコツ
- クォーターにリリースするフィーチャー決め、リリースプランニング、イテレーションプランニング
- ベロシティを安定化させる方法
前提として僕が所属する組織は、大まかに対象クォーターでリリースしたいフィーチャー決め→リリースプランニング（プランニングゲーム）→イテレーションプランニングの順に計画を行っています。
またストーリーとフィーチャーを厳密に使い分けて書いてないです。（ストーリーの塊や大きめのストーリーをフィーチャーと捉えています）
ストーリーの分割粒度について
ストーリーの分割粒度は、タイミングによって異なります。僕が所属する組織では主に3段階の計画が存在します。
- 大まかに一定の期間のうちにリリースしたいフィーチャーのを決めたいとき→大
- 機能の中でもさらに粒度細かくストーリーを出し、プランニングゲームをしてバーンダウンチャートを作成したいとき（リリース計画）→小
- 該当ストーリーを実際に着手するイテレーションのプランニングのタイミング〜実際に実装するタイミング（イテレーション計画）→極小
そしてそれぞれ、1が大、2が小、3が極小の粒度でストーリーを出します。以下例です。
フィーチャー決め：大
- 例. ユーザーは企業情報ページを見れる
- ページ単位とか、その中の数個の機能ぐらい粒度
リリースプランニング：小
- 例. ユーザーは企業情報ページで企業名を見れる
- ここではINVESTをできるだけ保つ
イテレーションプランニング：極小
- 例. ユーザーは企業情報ページで企業名欄を見れる・ユーザーは企業情報ページで企業名を見れる
- 長くても1日でリリースできるぐらいの大きさで、理想は1時間程度でリリース可能な大きさ
なぜこのように分割流動が違うかというと、それぞれでストーリーに求める目的が違うからです。
フィーチャー決め時の目的
- 主に経営に関わる意思決定に主に使われる。事業計画とかリソース配分とか
リリース計画の目的
MVP、対象期間（1四半期とか）のスコープを定める
大体いつどの機能が出るのかを把握する
マーケティングとか、お客さんと接するビジネスサイドのコミュケーションに使える
開発チーム内での仕様の認識の確認
開発とPDMで仕様の認識の確認
イテレーション計画の目的
- 頻繁にリリースを行う為のストーリーの分割
- より詳細に仕様、実装イメージをすり合わせる
実際着手してわかったことの反映
- ここは場合分けがあるので、ストーリーも分割しましょうとか
補足なのでうがストーリーの粒度がなぜ、「大中小」ではなく「大小極小」にしたかというと、僕の中での規模の感覚が「大小極小」だからです。2のタイミングで一定細かい方が仕様の漏れがなくなり、後々計画と実際のズレが少なくなります。
計画時のコツにやることとコツ
フィーチャー決め
やること
ざっくりクォーターで何ポイントぐらい消化できそうか
- クォーターで大体どんぐいらいポイント増加するかも考慮しといた方がいい
大きな単位の機能の見積りをする
実現可能性の調査
- 技術的、法的、既存で所持している資産 (リリース済みが) etc…
コツ
- 仕様を細かく把握しようとしすぎない
- 見積もりの粒度は3段階ぐらいでいい
- 今まで出してきた機能からの大体の相対値で決める
- このページは合計何ポイントぐらいだからこのページも何ポイントぐらいみたいな
イテレーションプランニング
やること
- 細かい単位のストーリーを出し、見積もり
- 予測消化を求める
- プランニングゲームをする
- バーンダウンチャートを引く
- 細かい単位のストーリーを出し、見積もり
コツ
思ったより細かく出す
- 参考: https://www.slideshare.net/kentjmcdonald/21-story-splitting-patterns-49940134
- PdMがわかりづらくなりすぎないことに注意する
見積もりは相対見積もりがコスパがいい（精度と早さ）
できるだけINVESTを保つ
- 例えばストーリー間に依存があるとプランニングゲーム時にストーリーの入れ替えがしづらくなるから
- ただし一方独立性は、場合によっては破ってもOKだとも思おう。その方が使用の漏れがなくなる、見積もり的にあきらかに不自然になる場合。（基盤部分を作るストーリーと、それぞれの対応みたいなもの。ユーザーはVISAカードで支払いができる、Masterカードで支払いができるをそれぞれ独立したもの前提でポイントをふることに違和感があるときはユーザーはクレジットカードで支払いができるという基盤のストーリーを作るとか）
予測増加を盛り込む
- 過去の実績を参考にする
- アートオブアジャイルデベロップメント2いわく、安定したチームにおいて、40%バーファーを設けると50%の確率で全てのストーリーが終わると書かれている
- 過去の実績を参考にする
既存の実装はない前提でポイントをふる
- ポイントにはテスト、実装、リファクタの分の大きさが含まれる。テストを書く必要があったり、リファクタの対象になる可能性があるなら、既存の実装があってもない基本ない前提で振るべき。結果開発が早くなるときはあるがベロシティが上がるだけでポイントが変わるわけではない。実体験として基本そうした方がうまくいく。
対象のコンテキスにおける予測消化を考える
- 関わるドメイン、技術が変わると同じチームでも全然違ったベロシティとなる。
- 過去似たような状況のプロジェクトでどうだったかを自分達で振り返ったり、周りに聞いたりする
- 次の期間でそのチームが触るコンテキストが異なる場合はできれば1つストーリーをやってみる。無理なら過去そのようにコンテキストがスイッチしたタイミングでどのぐらいのベロシティになったかを参考にする
- 関わるドメイン、技術が変わると同じチームでも全然違ったベロシティとなる。
イテレーションプランニング
やること
- 今週やるべきストーリーのコミットメントを決める
- ストーリーを分割する
- 場合によってはストーリーの実現方法を詳しく共有する（僕の組織ではあえて細かくやってなかったりする）
コツ
今までストーリーをやってみて、これからやるストーリーに反映させるべき点はないかを考える
ストーリーの分割
TDDのプロセスと同じ感覚で分割する。 参考： https://www.slideshare.net/kentjmcdonald/21-story-splitting-patterns-49940134
固定文字をまずは出す
- 空のページを出す
- ループの場合は0->1->ループに分解
ユーザーがやる処理を徐々に自動化しようという目線を持つ
このタイミングではストーリー間での独立性がなくても問題にならないことが多いので、そこまで気にしない。ただしVertical Sliceは意識する。そこを無視して分割すると、どっかにボトルネックが発生する可能性がでてきてしまう
ベロシティの安定化のコツ
ほぼ計画でベロシティが安定するかは決まってしまう一面がある一方で、実際に行う上でのコツもある。
一番大事なのはストーリーを滞留させず、頻繁にリリースすることである。
そのためには、1ストーリーでやることをシンプルにする（ストーリーのサイズを小さくする）ことが必要である。
そのためには以下のことに気を付ける。
- ストーリーでやるべきことをシンプルにする。TDDと同じ思考
- プロジェクトの作成だけ、テストのライブラリ入れるだけ、とかlinterを入れる、CICDを整えるとかを少しずつやっていく
- それぞれストーリーをわけてもいいぐらい
- これを通常のユーザストーリーの1つめに全部やろうすると時間がかかり滞留する
- イテレーションのコミットしたポイントが達成できそうかを日々考えて改善の量、コードの質の調整をする
- 1周目のストーリーは薄くやって、横展開モードの時にしっかり目にリファクタする
- ストーリーが小さいと上記の行動がとりやすくなる
- 頻繁にリリースできるようにする
- フィーチャートグルを使う。下位互換性を持ったコードを書く。（一部しかできていなからデグレするリリースになることを防げる）
頻繁にリリースすることはベロシティ安定以外にいも細かくFBが得られる、トランクベース開発をしている時、リモートとローカルの差分が小さくなるなどのメリットもある。
