5ポンドの袋

5ポンドの袋に10ポンドの糞は詰められない

--挑戦した人

ケントと私は『エクストリームプログラミングのプランニング』を執筆した際、プランニングの基本を理解しやすくするためにこの風変わりな引用を掲載しました。

ソフトウェア開発における大きな問題の1つは、人々が限られた時間内に実際に何を達成できるかについてほとんど認識していないことです。機能が詰め込まれすぎて、収まるかどうかを考慮せずに袋に詰め込まれている場面を頻繁に見かけます。人間の欲求は尽きず、通常は袋が小さすぎます。ケントのプランニングアプローチで私が本当に気に入ったことの1つは、この問題に対処しようとするシンプルなメカニズムです。

その原理は非常にシンプルです。プロジェクトの時間を反復作業に分割します。要求された機能をフィーチャ（またはXPではストーリーと呼ばれます）に分割します。各フィーチャの作業量を見積もります。各反復作業でどれだけの作業が完了したかを追跡し、収まらない量のフィーチャを1つの反復作業に詰め込みません。XPのリリースプランニングは、どのフィーチャをどの反復作業に入れるかを決めることです。

多くのものと同様に、これは人間のプロセスです。最近のカンファレンス講演で、私の同僚であるティム・マッキノンは、少数のトレーダーを開発チームと配置することで、開発可能なものに対する現実的な感覚を得る上で大きな違いがあったと説明しました。トレーダーは依然としてフルタイムで取引を行っていましたが、配置を共有することで行われた非公式のコミュニケーションが大きな違いを生み出しました。

人々はしばしば、アジャイル手法をアンチプランニングであると特徴付けます。それでも、エクストリームプログラミングで最初に遭遇したとき、最も印象的だったのはプランニングの品質でした。特に、プランの単純さにより、その結果に直面せずに計画に余分な機能を忍び込ませることが困難になりました。これが、アジャイル手法の適応的プランニングの本質です。プランは頻繁に変更されますが、制御された方法で行われます。機能を追加したい場合は、常に「スペースを作るために何を削除するか」を考慮する必要があります。したがって、アジャイルプロジェクトに機能が追加され、そのスペースが確保されないと見られる場合、プランニングが適切に行われていないと安全に結論付けることができます。