http://martinfowler.com/bliki/FivePoundBag.html

10ポンドのクソを5ポンドの鞄に入れることはできない——実際にやってみた人

Kentと一緒に『XPエクストリーム・プログラミング実行計画』を書いたとき、計画がどんなものなのか端的に示すために、この一風変わった文章を引用をした。 ソフトウェア開発の大きな問題点は、限られた時間内にどれだけのことを成し遂げられるか、きちんと認識している人がほとんどいないという点である。 どれだけの量が入るか分からないまま、多くの機能を鞄に無理やり詰め込もうとしている。 すべての機能を入れたいのだろうが、たいていその鞄は小さすぎる。 Kentの計画手法が本当に素晴らしいのは、シンプルなメカニズムを使ってこのことにうまく対応している点だ。

その原則は極めてシンプルである。 プロジェクトを複数のイテレーションに区切る。 要求された機能をフィーチャに分ける（または、XPで言うストーリーに分ける）。 各フィーチャにどれだけ作業量がかかるかを見積もる。 イテレーションごとの作業量を記録し、許容量以上のフィーチャを詰め込まないようにする。 XPのリリース計画とは、どの機能をどのイテレーションに入れるかというものである。

これは、他の事と同様、人間のプロセスなのである。 最近あったカンファレンスで同僚のTim Mackinnonが次のように述べた。 「数名のトレーダーを開発チームと一緒にしておくと、 現場の感覚を得ながら開発をすることができ、大きな違いがでた」 トレーダーはフルタイムでトレーディングを行っていたが、 「一緒にいる」ことで生じたインフォーマルコミュニケーションによって、 その違いがでたのだ。

アジャイル手法を「アンチ計画手法」だと思っている人もいる。 しかし、私が最初にXPに出会った頃、幼虫期のXPがもっとも特徴的だったのは「計画の質」だった。 計画がシンプルであるが故に、 フィーチャを追加するとすぐにその結果が分かってしまう。 これがアジャイル手法の適応型計画のエッセンスだ——計画は変わりやすいが、一定の”儀式”に包括されている。 もしフィーチャを追加したければ、「スペースを空けるために、どれを外しましょうか？」と聞かなければならないのだ。 つまり、もしスペースを空けることを考えずにフィーチャを追加しようとしているなら、 計画自体が悪いと結論付けてよいだろう。

comment

  • 2005-11-02 (水) 14:38:21 kdmsnr : これも、実際にやった人がいたほうが面白いかなーと。
  • 2005-11-02 (水) 11:06:03 holic : ちょっとコメント遅れなのだけれど、「実際にやってみた人」というよりは、「やってみりゃわかるさ」という感覚じゃないのかなぁと思います。「クソ」はそのままのほうがいいですね ;)
  • 2005-10-14 (金) 23:37:37 kdmsnr : 『XPエクストリーム・プログラミング実行計画』だと「10ポンドのがらくた」になってる。でも面白いので「クソ」のままにしてみよう。