不良の極めて少ないプロジェクト

人々がエクストリーム・プログラミングについて語るとき、しばしばアダプティブ・プランニング・スタイルや進化的なアプローチ設計のようなことに焦点を当てます。私が特に興味を持っている、小さなながらも増えつつある傾向は、1か月あたりの本番バグが1件未満という非常に不良率の低いXPプロジェクトのわずかながらも増えつつある数です。

私が最初にこれに出くわしたのは、食品仕分け機を製造する会社の、ケントによる説明でした。この食品仕分け機には、カメラやその他のセンサーが設置されたコンベアベルトがあり、それによって果物や野菜がさまざまなカテゴリに仕分けられます（これらすべてがSmalltalkによって制御されています）。チームはある時期に100ほど未解決のバグを抱えていましたが、XPを採用してからバグ発生率は低下し、2か月に1バグ程度の発生頻度になりました。

次に遭遇した2番目の事例に遭遇できたことを非常に嬉しく思っています。これはC3の私の旧友数名がかかわっていた事例だからです。彼らは現在、クライスラーで一部のポータルソフトウェアを構築しています。最初は1か月に1件という衝撃的な不良率でしたが、2002年にはシステムに対して正確に1件のバグが記録されました。この間、彼らは週に1、2回の頻度でソフトウェアの新バージョンをリリースしていました。

あるソフトウェア会社がXPに大きくシフトしました。その仕事の多くは、課題となる大規模なレガシーシステムに関係しています。しかし、一部の新規の開発では、不良率が非常に低くなっています。そのようなプロジェクトは2つあり、月あたりのバグが1件未満で実行されています。そのうちの1つは、インストール前の政府認定が数週間から数日に短縮されたことが判明しています。

Thoughtworksでも、これらの一部が見られます。候補となる非常に不良率の低いプロジェクトのリリースからまだ日は浅いですが、一部では同様に低いバグ率が見られます。

これらの低い率はプロジェクトのごく一部によってのみ達成されていますが、XPを真剣に取り入れたチームは、バグ率が大幅に低下するという共通の成果を得ているようです。不良率が大幅に低下したという話を数多く聞いていますが、たとえサブバグ月レベルまでには至らなかったとしてもです。

これまでのところ、非常に低いバグ率を実現しているのは数少ないXPチームであることを強調する必要があります。これまでに出会ったのはごくわずかです。チームは非常に規律正しく、XPを1、2年経験した人々が率いているようです。

これはまだプロジェクトのごく一部であるため、XPを採用するだけで非常に低いバグ率を得られると想定しないでください。また、他のプロセスでもこのようなバグ率を得られないわけではないことに注意してください。

しかし、ソフトウェア開発においてはこのようなバグ率を実現できるという結論に達することができます。また、到達した一部のチームは、XPをそれを行う上で非常に重要なツールであると考えています。