estimationhttp://martinfowler.com/bliki/FivePoundBag.html10ポンドのクソを5ポンドの鞄に入れることはできない——実際にやってみた人Kentと一緒に『XPエクストリーム・プログラミング実行計画』を書いたとき、計画がどんなものなのか端的に示すために、この一風変わった文章を引用をした。ソフトウェア開発の大きな問題点は、限られた時間内にどれだけのことを成し遂げられるか、きちんと認識している人がほとんどいないという点である。どれだけの量が入るか分からないまま、多くの機能を鞄に無理やり詰め込もうとしている。すべての機能を入れたいのだろうが、たいていその鞄は小さすぎる。Kentの計画手法が本当に素晴らしいのは、シンプルなメカニズムを使ってこのことにうまく対応している点だ。その原則は極めてシンプルである。プロジェクトを複数のイテレーションに区切る。要求された機能をフィーチャに分ける(または、XPで言うストーリーに分ける)。各フィーチャにどれだけ作業量がかかるかを見積もる。イテレーションごとの作業量を記録し、許容量以上のフィーチャを詰め込まないようにする。XPのリリース計画とは、どの機能をどのイテレーションに入れるかというものである。これは、他の事と同様、人間のプロセスなのである。Mackinnonが次のように述べた。アジャイル手法を「アンチ計画手法」だと思っている人もいる。私が最初にXPに出会った頃、幼虫期のXPがもっとも特徴的だったのは「計画の質」だった。フィーチャを追加するとすぐにその結果が分かってしまう。これがアジャイル手法の適応型計画のエッセンスだ——計画は変わりやすいが、一定の”儀式”に包括されている。フィーチャを追加したければ、「スペースを空けるために、どれを外しましょうか?」と聞かなければならないのだ。計画自体が悪いと結論付けてよいだろう。これも、実際にやった人がいたほうが面白いかなーと。コメント遅れなのだけれど、「実際にやってみた人」というよりは、「やってみりゃわかるさ」という感覚じゃないのかなぁと思います。『XPエクストリーム・プログラミング実行計画』だと「10ポンドのがらくた」になってる。面白いので「クソ」のままにしてみよう。gmail.combliki-ja。