「アジャイルな見積もりと計画づくり」を読みました

名著と言われながら、今まであまり興味がなくて読んでなかった分野。もっと早く読んでおけばよかったなと思う反面、おそらく以前の自分では消化できなかった＆活かせなかっただろうなと思ってはいます。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

1章：計画の目的

1. なぜ見積もりや計画づくりが必要なのか？

しょっぱなにあるこの問いかけ、最初からすごいためになる文章です。この本を読むまでは、見積もりや計画って、やりたくないけどやらざるを得ないといった、どちらかというと消極的な理由しか思い浮かびませんでした。でも、それだけでないよという話。具体的には、以下の5つが挙げられています。

• リスクを軽減する
• 不確実性を減らす
• 意思決定を支援する
• 信頼を確立する
• 情報を伝達する

この中で太字にしたものが、消極的な理由ではなく、計画作りをしていくことによってもっと前に進めるための理由かなと感じました。開発者・チームにおいても、いやいや計画づくりをやっていくのではなく、チームが計画づくりをやっていくことによって、ビジネス面での意思決定を支援したり他チームとの信頼を確立していくことを意識する。それが結果的に、開発チームだけでなく全体のサービス・プロダクトにいい影響をもたらしていくというのは、自他共に意識づけていきたいなと強く思いました。

あとは、これかな。

3. アジャイルな計画づくりとは？

本書で扱うのはアジャイルな「計画づくり（planning）」だ。アジャイルな「計画（plan）」ではない。
...
アジャイルな計画づくりで重視するのは、計画よりも、計画を作る過程そのものなのだ。

プロジェクト初期のみ「計画」を作成するだけじゃだめで、ちゃんと日々の活動の中で計画を更新していく「計画づくり」が大事だよということ。これって、プロセス改善の文脈でのメトリクスとかでも同様だよなーというのを思い描きながら読んでました。

11章：「望ましさ」による優先順位づけ

狩野モデルについての説明。このモデルについてはどっかで見たことがある気がするけど、本の中で出たので改めて見なおしてみました。守備範囲的にはプロダクトオーナーの領域っぽいけど、スクラムマスターとしてもさらっとでも知っておいて損はない領域だし、参考になりました。

モデルの説明については、先人のブログを参考に。
d.hatena.ne.jp

16章：ベロシティの見積もり

ベロシティは常に固定になるわけではなく当然幅があるけど、その幅をどう扱うかの話。3イテレーション（スプリント）以上取れる場合、以下の方法が挙げられていました。

• イテレーション毎のベロシティをそのまま幅として扱う
• 不確実性コーンを活用する

前者は単純。3回のイテレーションのベロシティが (12, 15, 16) ポイントだった場合、見積もり幅は 12~16 ポイントと扱います。

後者は、不確実性コーンと呼ばれる、プロジェクトの状況に応じて不確実性の幅が変わる図を流用しています。ここで、3回イテレーションこなした後の平均ベロシティが20ならば、下限が20*0.85=17, 上限が20*1.15=23 で、17~23 の幅に収まるだろうと推測する感じ。

実施したイテレーション数	下限の係数	上限の係数
1	0.60	1.60
2	0.80	1.25
3	0.85	1.15
4以上	0.90	1.10

ちょっと計算式は複雑になるけど、不確実性コーンをもとにした方が、今のうちのチームにとってはいいかなと思いました。理由としては、ベロシティの平均が基準となってるから。

うちのやり方として、1イテレーション内できれいに終わりきらないことがあるのですが、その場合各イテレーションのベロシティは変動しやすくなるんですよね。ただ、各イテレーション毎の変動はともかく、移動平均をとっていくと中長期的には問題とならないことが多い*1。なので、平均を考慮した方がより精度が高いものが出せるかなと思っています。

22章：なぜアジャイルな計画づくりがうまくいくのか

11. ゆとりを残す

チームメンバー全員の時間を100%使い切るような計画を立てないこと。特にイテレーション計画では気をつけること。高速道路の限界100%まで車を詰め込むと、誰も身動きの取れない渋滞になってしまう。開発チームもこれと同じだ。メンバー個々の時間を限界まで使ってしまうと、プロジェクトの進みは遅くなってしまう。

はい、やってしまってました。イテレーション計画ミーティング時は作業時間見積もりをしてるのですが、このとき全時間を詰め込もうとして結局計画したものが全部終わりきらない。終わらないものを計画時に話すのムダだし、終わらなかったという事実はチームメンバーのモチベーション的にもいい影響を与えない。

なので、最近ではベロシティ（実績）ベースで考えるようにしようとしてます。普段大体これぐらいポイント消化できてるのだから、（作業時間はもうちょい余裕あるけど）計画するのはここまでにしておこう。で、おかわりできるならばそのとき考えよう、という方針にしてます。

チームがもっと成熟して毎回安定して計画したものを終わらせられるようになってきたならば、その次はいかにベロシティを上げていくかを考えていく感じ。もしかしたらその中で、作業時間のムダに着目していって、より効率的にタスクに取り掛かれるようになるかもしれないなーとは考えています。

---

いつもより長くなった。それだけためになる内容が多かったです。特に1章の「1. なぜ見積もりや計画づくりが必要なのか？」は常に意識しておきたいです。

あと、タイムリーなことに、先月の WEB+DB PRESS でちょうど見積もりの話がでてました。こちらも参考に。

WEB+DB PRESS Vol.93

*1:この辺は「7章：再見積もり」の「4. 部分的に完了したストーリーの再見積もり」も参考に。