著名なアジャイリストであるJ.B. Rainsberger氏は(リンク)XP Yahoo Groupで興味深い議論を始め(リンク)、アジャイルソフトウェアプロジェクトで見積もりを行うという考えに意義を唱えている。J.B.氏は、2008年のGordon Pask Awardの受賞者の一人であるArlo Belshee氏との、この話題に関する会話について順を追って話している。
Mike Hill氏が(リンク)議論に加わり、Industrial Logic社の人たちがAgile eLearning製品開発のために、どのようにして内部的にこの方向に向かったかについて言及した。［Arlo 氏は］彼がコストの見積もり－特に、作ってはいません－に関して仕上げた、ある調査とプラクティスについて教えてくれました。彼が主張したか、あるいは私が何とか気づいたのですが、コストの見積もりを行い管理するのに費やされるエネルギーは、それらをもつ価値を上回ります。
私たち自身の仕事のためには、純粋な「プル」モデルが上手くいくことに気づいていました。私達は顧客がソートしたスタックの先頭のストーリーを「プル」し、実装します。計画ミーティングは小さくなり、今では最も重要なものにフォーカスしています。
Agile 2008での講演「見積もりは無駄とみなされている(リンク)」の中で、Industrial Logic社(リンク)の創業者であるJosh Kerievsky氏は、これについてさらに詳しく述べている。彼は、より小さくもっと頻繁な「小さなリリース」を行い、「ポイントと速度」について彼らが以前持っていたのと同じくらいの「直感」を効果的に利用して活動できるようにし、しかし、カードに番号を付けて計算をすることに時間をかける必要なしに、どのようにして彼らが成功に結び付けたのかを説明した。
つい最近まで、Amit Rathore氏は同じような考えに言及していた。Rathore氏は、次に最も重要なストーリーを全てほぼ同じサイズ（２～３日）にブレークダウンし、優先順位に従って次のイテレーションでプルするプロセスを説明している(リンク)。
秘訣はここにあります－それぞれのストーリーを実装するのに、１～３日以上かかってはなりません。２週間の予定がいっぱいになるまで、次の要件を取り出して同じ事をし続けるのです。Rathore氏は、このアプローチが「ムダ」（無駄）を削減するだけではなく、さらに様々な方法で価値を高めることを説明している。
これにより時間が節約されること、努力が実際に良い副作用であることは事実です。本当に開発プロセスを把握しておけるようになることで、真の価値がもたらされます。小さなストーリーによって、必要な場合に変更したり、必要に応じてバックログからプルしたり、あるいはビジネスの要求に応じて新しいものを追加することが可能になります。また、小さくインクリメンタルな塊でコードを書くのは簡単ですし、テストもより簡単で、ユーザに小さなリリースを出していくのは簡単なので、速く進むようにもなります。
そして最後に、それぞれのストーリーを小さくするという規律を課すことによって、みなさんがコーディングを始める前に、その要件について徹底的に考えられるようになります。チームも要件をインクリメンタルな大きさにブレークダウンすることを強いられ、ごく一部が完了せずに残っている終わりのないストーリーは完全に避けられます。
David Anderson氏は、かなり以前に同様の発言をしており (リンク) 、それ以来「ソフトウェアかんばん(参考記事・英語)」の活動に積極的に携わっているが、これはBelshee氏、 Kerievsky氏、Rathore氏によって議論されているアイデアと非常に強固な関係をもつイニシアチブである。
それぞれの視点を見て、J.B.氏が考えたように「本当に‘見積もらない’のですか？」と尋ねる人がいるかもしれない。Kerievsky氏と Anderson氏はどちらも「直感」に似たものと言っているし、Rathore氏は「同じサイズ」であると言っている。おそらくそうではないが、良いことなのだろうか？悪いことなのだろうか？本当に「見積もらないのですか？」と聞くべきなのか、あるいは「数字はないのですか？」と聞くべきなのか、何か他のものがあるのだろうか？
他に誰かアジャイルプロジェクトを見積もりなしに進めた経験のある人はいるだろうか？あなたがそれをやっていてもいなくても、少し時間を取ってInfoQやXP Yahoo Groupで(リンク)議論に参加して欲しい。
原文はこちらです：http://www.infoq.com/news/2008/08/estimates-wasteful