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

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

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

感想・レビュー・書評

[wisyさんの感想 · 2020年3月7日]

Project is continuous development of creating values and knowledge. We all only have a vague picture of the goal. Given that, it is obvious having an abstract plan. Yet, static plan is as dangerous as no plan. The plan may be static, but planning is activity. See the difference. There is nothing to be shame of changing the plan. Modifying the plan merely implies updating the plan towards the goal. It is encouraged to approach to the goal.

[hirocsさんの感想 · 2019年8月15日]

”PMBOKの計画づくりを本格的に学ぼうとしていた矢先なので、タイトルが気になり購入
---
T:
P:
O:
---
＜読書メモ＞”

[takuma510さんの感想 · 2019年2月6日]

具体的なやり方をなぜそうするのか含めて説明してくれているのでとても参考になった。

本に書いてあったからこうするのではなく、現場のフォースを見極めた上で適宜学んだ知識を適用していくよう心がけたい。

[takashiiwasakiさんの感想 · 2019年1月28日]

従来の計画は作業完了を基準にしているが、顧客からすると価値の単位はフィーチャーである
（バリューストリームマッピングは意味がある）

作業基準の計画はパーキンソンの法則により、フルで使うようになってしまう。（という暗黙の了解を得る）
計画は確率であってコミットメントではない

ユーザーストーリー→プロダクトバックログ→スプリントバックログ

リリースプランニング→つぎのリリースのテーマやユーザーストーリーを検討
イテレーションプランニング→スプリント計画

プランニングポーカーのゴールは精緻な見積りを出すことではなく、低コストで価値のある見積りを出すこと（労力、正確性曲線の左上）
プランニングポーカーの議論を長引かせすぎると曲線の右に追いやられ、労力に見合った正確性がでなくなる

ベロシティは補正装置である
再見積りすべきときは相対サイズが変わったときのみ

ベロシティを計測するときのポイントの乗せ方はオールオアナッシングが原則

チームが熟練してストーリーポイントが変わることはない（サイズが変化するのは例えばフレームワークを導入したとか）

目標の不確実性（なにを作るか）はいきなりなくせないことは前提にありながらも、早めに（優先的に）減らしていくべき

スプリントレビューは誰でも参加可能

優先順位づけ（スプリント始まる前）
スプリントレビュー（1つ前）
スプリントプランニング（レビューと同日）
スプリント（次のやつ）


開発はヨットで海を航海するようなもの
（風向きや波によって進むべき進路が変わる）

個人のベロシティは測るべきでない

[Cognosce te ipsumさんの感想 · 2019年1月20日]

アジャイルプロセスでの見積に必要な方法論が書かれている。2011年現在では、これが最も合理的で詳細なやり方に見える。

[beakmarkさんの感想 · 2019年1月20日]

年初に購入してあったのにやっといま読み終わり。なんとか年内に読めた:-)

会社でこの本の読書会をやるというので読み始めたんだけど、前評判どおりのいい本でした。特に第一部はグッとくる。

読了したけど、読書会は年明けからが佳境になりそうで、それもふくめてまだまだ楽しめそうな一冊。

[kigumaさんの感想 · 2019年1月17日]

定評のある書籍だけど未読だった。

Agile開発の本でよくある「肝心なところがぼかしてあり、Agileであればなんでもバラ色」的な居心地悪さがない。
Agile開発は「アバウト」なのではなく、基準点として開発者の経験値を重んじ、数値を重要視するのが良く分かる。

総量としての見積もり数の制度を上げるのではなく、精度を高めていくという事がよく分かる。

実際には、経営資料や投資効率指数を駆使して、優先度を決定するなど、かなりハードコアな内容だ。

実際、びっしり文字なので、読んでいて、細部に入りすぎると感じすぎていたが、最初のチャプタのケーススタディーで、それまでの細部の情報がなぜ必要だったか分かる。

開発プロセスの本のケーススタディーも、読んでいていまいち居心地悪い感覚があったが、これはケーススタディーが秀悦だ。


システム開発の現場だけでなく、デザイン、設計、いろんな環境の職場に応用できる。

評判が高いだけあって素晴らしい内容だった。

[boscono19さんの感想 · 2019年1月3日]

アジャイルサムライ参考資料

[ichiro.marinersさんの感想 · 2018年10月23日]

ウォーターフォールは、ほぼ死んだ。そもそも、建築プロセスを見本にしたこのやり方がここまで命を永らえたのは、ソフトウエアに対する人類の知見がいかに未熟かを示す良い例だろう。　そのアンチテーゼとして、アジャイルが存在する。アジャイル・マニフェストから垣間見るその精神は高く評価されるも、ＨｏｗＴｏの決定打と思える本が無いのも事実だったのだが、この本は決定打だと確信できる。この本が２年も前に出版されていたのだから、浅学を恥じるのみである。

[kiyochanさんの感想 · 2018年10月22日]

図書館
アジャイル
ソフトウェア開発
プログラミング
見積り
プロジェクトマネジメント
コンピュータ
マネジメント
IT
開発