アジャイルな見積りと計画づくり の商品レビュー

MikeCohn【著】,安井力,角谷信太郎【訳】

2019/01/20

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

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

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

2019/01/17

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

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

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

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

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

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

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

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

2018/10/23

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

2018/10/22

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

2018/10/20

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

2018/10/07

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

2018/10/20

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

2016/06/06

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

2016/01/10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2015/01/05

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