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

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

2012/08/05

そもそも作る前からシステムで実現したい内容がくまなくわかって、スケジュールもたてられるなんて無理に決まってるよね、しかも手段が目的化してて要らないもの作っちゃってるかもしれないよね、だったら前提が無理なのに無理に頑張って無理やりやるよりも、その前提をとっぱらって、「できる限りがんばってよしとしよう」、その代わり、できたとこから実装されてるから、顧客にとってもイメージしやすくちょうどいいところで止められて無駄にならないからいいじゃない、というのがアジャイルの思想と解釈した。
日本への適用という観点でいうと、「一度頼んだからにはとことんやらせないと損」というお客さん側の意識をどう変えていくかが課題か。

2012/06/25

アジャイル開発がどのようなもので、それを実現するには何から始めればよいのか（=つまり計画）というのがとてもよくわかる。見積もり手法を学ぶために手に取った本で、将来的にPJを運営するときに参考にしたい本である。

アジャイル開発というと、開発期間（イテレーション）を短く区切って、機能を部分的に納品＆レビューしてもらう開発手法ということは知っていた。

開発者としてではなく、PJ運営者として知るべきことを少しメモ。
①アジャイル開発は「チーム全員参加型」
②ストーリー（＝満たすべき機能）を挙げる。
③優先順位を決める（MoSCoWルール）
④ストーリーポイントや理想日といった手法で見積もりを行う。その際、期日は幅を持たせてコミットすること（×60%～160%）
⑤１イテレーションで何を行うか決める。※その後のイテレーションで何をやるかは、速さ（＝ベロシティ）・重要度などで変わってくるので、優先順位だけにとどめておくほうがベター？

・・・PJのリリース期日に間に合わなそうな場合、優先順位の低い機能を取りやめる。余裕があるなら追加機能を開発する。
全体計画の70％程度をMust haveにし、きつきつのスケジュールを立てないこと。

まとめ
・規模を見積もること。
・期間を算出すること。

2012/06/17

良書。自分で読む間にも同僚、他部署の上長など薦められる事しばしば。その推薦に足る本だと思う。
アジャイル開発の計画、見積もり、実測そしてフィードバックのやり方とその背景にある考え方がとても緻密に説明されている。恐らく、これ一冊だけで計画とその進め方について十分な知識が得られると思う。
ただもちろん題にあるように、スコープにしていないプロジェクトの多くの要素があるので、これだけでアジャイル開発ができるわけでない。アジャイルではチームビルディングからTDDなどのような下流のテクニカルプラクティスまでがこの計画の実行を支える大切な要素になっているので、それらについては別途学ぶ必要があるだろうと思う。

2012/03/29

アジャイル界で、必読と言われている一冊だけあって、非常に良い内容でした。現プロジェクトでは、フォーターフォール開発なので、自分はリーダーでもないこともあり、実践できることは限られますが、得られた気づきを現場で有効に活用できればと思います。

2012/03/21

表紙がキレイで好き。読まなきゃもぐりコーナーでよく見かけていたけどなかなか厚さに負けて勇気がでなかった本。意外とすんなり読めた。

優先順位付けの辺りは普段考えない内容ばかりで、今の私には退屈だったけど、最後のシナリオがおもしろく全体としてはお気に入りなので、コーヒーこぼしたのは多目にみてほしい…

2012/03/16

しばらくチーム開発から離れていたのでとても為になりました。（PivotalTrackerを導入する前にその方法論を学ばねばと慌てて読みました。）

規模の見積りと期間の見積りを明確に分けるのは目から鱗。

ただ、受託開発の時にどういった契約書（請求書）出すのかがイメージ出来なかった。他にも参考になりそうな書籍を当たってみたい。

2012/02/26

アジャイルな見積。計画→見直を行いながら、詳細化していく。
ゴールドラット氏のクリティカルチェーン的な内容が含まれています。
開発を行う方法としては、理想的です。

一方で、顧客は「要件」に匹敵する、「予算」を用意して（もしくは、確保して）いるが、発注されるためには、「要件」をクリアにする必要があり、また、「予算」は枠で確保されるのが現実である。
また、会社の内部に対しても、ソフト開発＝会社からカネを持ち出すということであるから、開発を開始するとき（＝お金を借りるとき）、「総額は1000万～2000万の間になると思いますが、ボンヤリとしたこういう機能を実現するのにお金を使いますので貸してください。段々詳細化していきますから」とは行かないであろう。
お金がからむと急にシビアになり、その予算に見合う機能としてもっと具体的に表現せよ・・・、といった羽目になる。

つまり、開発を進めるやり方の理想型と、事業を行うやり方の理想型にはギャップがあるということであり、このあたりのギャップに日々苦しめられています。

2012/01/09

・アジャイルでPJを進めるための実ノウハウ
・サンプル通りにPJが推進できれば大変素晴らしい完成物ができあがる
・ステークホルダーから最初から完璧な計画立案を求められる実環境の中で、どうやって活用していくか・・・

必要なタイミングがくれば、もう一回読み返す。

2011/11/25

素晴らしい。わかりやすい。
第７部ケーススタディだけでも読んでおくべき本。
１０章はわかりにくかったが、EVMをやるよりは実現可能性が高そう。
実際にここをやることはないだろうけど。

2011/06/19

ストーリーなどの見積もりについての考えを学習することができる。
見積もりについての経験と知識がない新人エンジニアは読んでいおいたほうがいい。もちろんベテランエンジニアの方も

エンジニアやプロマネ以外の人も読んでおいたほうがいいと思う。