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

著者 : Mike Cohn マイク・コーン 安井力 角谷信太郎

• 毎日コミュニケーションズ (2009年1月29日発売)

感想・レビュー・書評

[yysakiさんの感想 · 2018年10月20日]

アジャイルに対して曖昧な理解しかなかったので、イテレーションをこなす見積りと計画づくりについてためになった。
アジャイル系で次読む本はテスト駆動開発入門かアート・オブ・アジャイル デベロップメントかな？

[yoshihasegawaさんの感想 · 2018年10月13日]

コストの考え方が参考になりました。

[isopさんの感想 · 2018年10月7日]

プロジェクトの見積りと計画をアジャイルに進めるにはどのようにしたらよいかが纏められた本。 「不確実な現状」と如何に向き合い、プロジェクトのゴールに向かって走り続けるか。この本にはそのための比較的普遍的なテクニックが書かれています。 アジャイルに物事を進めるには、変化を受け入れ変わり続ける必要があり、それは見積りや計画においても同じことが言えます。 この本にあることを如何にして自分たちのプロジェクトに落とし込めることができるか、が重要だと思います。

[masterkaさんの感想 · 2018年10月7日]

感想は以下
https://blog.masterka.net/archives/688

[nyankoteacherさんの感想 · 2017年5月27日]

170528 中央図書館
プロのシステム屋からすれば、本書などは内容やテーマが１周（いや１０周くらい？）回って古い、と切り捨てるのかもしれない。今更「アジャイル」を冠して技術論を講じる人はいない、というところか。
しかし、プロジェクトのプランニングとマネジメントの重要性は、別にシステム開発だけの専売特許ではない。およそ「仕事」と呼ばれるものの全てに関係する。
たとえば、計画は、その個別内容の重みを考慮して、（構造を把握して、といえるかもしれない）シンセシスしてまとめる。また、不確定要素に応じるバッファを確保する。適時な進捗把握（マイルストーン）を設けて、チームの進度ムラを把握、管理する・・・などなど。
それぞれは、整理すれば当たり前のことに過ぎるが、「仕事」の現場では、時間に追われ、いまだにKKDで、指標や納期やコストを管理表に記入していることも多いだろう。ごちゃごちゃと管理のための精度を上げる作業をしするよりは、「とっととやってしまえ！」という知恵でもある。
そういったことを、継続的に考えるきっかけとなる読書。

[norikoniさんの感想 · 2016年9月2日]

図書館で借りた。なかなかうまくいかないんだな

[warumetさんの感想 · 2016年8月11日]

THE GOAL以上の良書と思った。同書同様、プロマネを向上させたい汎ゆる職業の人間に薦める。

[yusabanaさんの感想 · 2016年6月6日]

ストーリーやベロシティの考え方など継続的に見積りを続けていくための参考になった。精度を上げるには継続して行くことが大事。

[pauls92さんの感想 · 2015年12月29日]

リスク軽減
最初にリスクを知っていれば、そのリスクを勘案してスケジュールが立てられる

不確実性を減らす
新しい知識を取り入れながら、計画が洗練される。更に新たなフィーチャーも追加される

意思決定を支援
計画をもとにリリース日の決定やフィーチャーの追加を決定できる

信頼を確立
計画通り進捗している証明

情報伝達
計画の根拠を示す。計画に従って、他部門も営業や取説が作られる

計画は常に更新すべき。計画ではなく、計画づくりが大切。

最初の作業で予定通りに行かなくて、次で挽回するとよく言うけれど、学ぶべきは次の作業も最初同様に予定通りにいかないということ。

従来型の計画づくりの問題点は見積もりがコミットメントになっている。それは日付で表される。そして、それは作業完了の確率が100%に満たない日。

ユーザーのフィードバックによって、フィーチャーの優先度が変わることを受け入れる必要あり。それで、プロジェクトへの投資から最大のリターンが得られるのであれば協力すべき。変化を受け入れる。

理想時間と現実時間。アメフトの試合、理想時間は60分、現実時間は3時間。

収益逓減の法則。見積もりへの労力と正確さは比例しない。見積もりは完璧にやっても、100%になりえない。

顧客満足度の狩野モデル。顧客満足度とフィーチャーの量の関係図。

満足条件を決める。日付もフィーチャーも主導なプロジェクトもありますね。

20章。個人のベロシティを測定するのは危険極まりない。それの結果が公表されるのであれば、個人のベロシティを上げることに終始し、チームに貢献する事を辞めるため。

計画は随時見直し続けられる必要がある。おしりのスケジュールだけ決めて、あとはよろしくじゃ何もマネージメントできてない！

仕掛かり作業を次のイテレーションに持ち越すと、サイクルタイム（着手からユーザーに提供さるまでの時間）を延ばすことに繋がるため、避けるべき。残してはいけない。

[penxeraさんの感想 · 2015年1月5日]

ストーリー仕立ての最終章がわかりやすかった。リリースまでのスケジュールを図式化しまバーンダウンチャートの工夫や、チームメンバーの抱える仕事の見積もり方と調整など役に立つものが多い。