読者です 読者をやめる 読者になる 読者になる

月曜日までに考えておきます

ITネタとゲームネタ中心に興味のあること色々書きます。

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

アジャイルサムライ」読んでなんとなくアジャイル分かった気になってたんですが、名著と名高い「アジャイルな見積りと計画づくり」ようやく読みました。

感想

結論から言うと、アジャイルやるなら絶対に読むべき。アジャイルサムライの倍ぐらい分厚い(適当な見積り)けれど、とても良い内容です。 「アジャイルサムライ」の方はそんなに分厚くなく、読みやすい内容で"アジャイル開発とは"ということを良い感じに紹介してくれてる、こちらもとてもいい本です。その一方で、「アジャイルな見積りと計画づくり」の方は、実際にアジャイルプロセスで見積りを行うには具体的にどのようにやればいいのか、というところがとても詳しく書かれています。 また、最終章にあるケーススタディも「そんなうまくいくわけねーよ」というとそれまでですが、アジャイルがうまく回るとどのように進むのか、ということが具体的に書かれていて読みやすかったです。 少し前までアジャイルプロセスによる開発でプロダクトオーナー的な立場で関わっていたので、もう少し早く読んでおきたかったな、という思いがすごく強いです。でもほむほむのように過去に戻ったりはできないので、今このタイミングで読んだことに感謝しつつ、これからの仕事に活かしていきたいと思います。 最近の思いとして、プロダクトオーナーよりもスクラムマスターの立場をやっていきたいというのもありますし。このタイミングで読めたのはきっと良かったのだろうと思います。 ここ最近は一人でスケジュール立てて開発してるような感じなのですが、その作業見積りをするのにも考え方として参考になってとても良いです。さっそく実践投入してます。 というわけで、もう一度繰り返すとアジャイルやるなら絶対に読むべき、なのですが、取っ掛かりとして「アジャイルサムライ」読んでから読むと、戦士経由してからバトルマスターになる感じでいいんじゃないでしょうか。

良かった点とか

見積りがコミットメントになっている(P.43)

そもそも見積りというものは、見積もった時間内に作業が完了する確率のことである。(中略)従来の計画づくりの問題点は、プロジェクトのチームやステークホルダーが見積りをコミットメントと捉えてしまうことだ。 見積りが確率、というのははじめて知りました。というときっともっともな事を言ってるんだろうけど、コミットメントではありません、ということを言うとぶち○される確率が高いのよなぁ、と思いました。 とはいえ、アジャイルプロセスにおいて見積りはコミットメントではないので、例えばエライ人が「アジャイルってのが流行なのでやろうぜ」とか唐突に言い出した時にコミットメントではない見積りを出して「ぶち殺すぞこのやろう」みたいな話になったらその人に見切りをつけるいいリトマスなのかもしれません。

犬種による見積りの例え(p.63)

犬好きなのでわかりやすかったです。

理想時間、理想日(p.69)

5日(今週中)でできますって思ってても、請求書の処理とかeラーニングとか避難訓練とかISMSとかありますよね(;´Д`)

プランニングポーカー(p.79)

みんなで見積もり出して、ずれてたら納得できるまで話す。大きく(小さく)見積もってしまった理由を話す。 一人見積りだと、

  • 自分の出した見積りに、「え!?こんな掛かるの?おかしいでしょ!」と言われる → ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああぁぁぁ
  • 自分の出した見積りに、「は、そんな期間じゃ無理でしょ!」ってデキる同僚に言われる。そして指摘されたとおりに間に合わない。 → ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああぁぁぁ みたいになりがちな小心者の私には救いのメソッドなのですがまだ実践する機会がありません。

見積りの一貫性(p.87)

見積りが正確でも、やや不正確でも、著しく不正確であっても構わないのである。見積りに一貫性があることが大切なのだ。不正確ならば一貫して同じくらい不正確であればよい。 不正確な見積りだったのであとで直すと、そこからは正しくなってストーリーポイントとベロシティが狂うという話。ストーリーポイント3で見積もったものの消化に5かかったのであれば、他のも3も5掛かるのであるが、再見積もりするのではなくベロシティ(速度)で調整するのがよい。

リスクと価値のマトリクス(p.106)

  • 高リスク/高価値 => 最優先でやる
  • 低リスク/高価値 => 次にやる
  • 低リスク/低価値 => 最後にやる
  • 高リスク/低価値 => やらない 下2つの達成がコミットになるので日本の家電メーカーから不思議プロダクトが出るのかな、とオモタ。

狩野モデル(p.131)

フィーチャのある/なしを

  1. 気に入る
  2. 当然である
  3. 何とも感じない
  4. しかたない
  5. 気に入らない に分けて考えて統計を取るという手法。

リリースバーンダウンチャート(p.230)

イテレーションごとの残ストーリーポイントの表。 線グラフではなく棒グラフのパターンもあるのが参考になった。

個人のベロシティ(p.243)

個人のベロシティを計測してはならない

個人のベロシティ(作業速度)を計測すると、個々人が自分の作業を終わらせることを最優先にしてしまい、対立意識的なものが生まれるのだな、と解釈。 達成しなければいけないのは、個々人の作業の完了ではなく、チームとしてのスループットの向上であるという考え方。

仕掛り作業の考え方(p.260)

アジャイルプロセスにおいて仕掛り作業というものを次のイテレーションに持ち越さない。 ウォーターフォールプロセスで、進捗報告樹にほとんどが仕掛中で進んでいるように見せかけて等しく課題にぶつかっていて結局何も進んでいない、というのはありがちなので、「仕掛中」というステータスは計測せずに、「未着手」か「完了」に絞るべきという考え方というふうに解釈。(ちょっと言いすぎかも) 1イテレーション内で完了させることが難しいフィーチャというのはそもそももっと細分化すべきなんだろうな。

ということで、自分なりにまとめてみましたがいい本でしたのでアジャイルやるならぜひ読んでみてください。

 

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

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