エクストリーム・プログラミング
エクストリーム・プログラミングの初期の話題性と、ペアプログラミングや継続的設計(英語版)などの論争の的になっている教義は、 マクブリーン ベームとターナー、 マット・ステファンとダグ・ローゼンバーグ などからの批判を集めている。 しかし、批判の多くは、アジャイルの実践者によって、アジャイル開発への無理解であると信じられている 。
とりわけ、エクストリーム・プログラミングは、マット・ステファンとダグ・ローゼンバーグの書籍『Extreme Programming Refactored』で考察と批判がされている。
批判には次のようなものがある:
方法論が人によりけり、アジャイルはこれを解決していない
成果物を定義しないことで顧客からお金を垂れ流すための手段としてよく使用される
構造と必要な文書の欠如
上級レベルの開発者のみに作用する
不十分なソフトウェア設計を包含している
顧客は莫大な費用をかけて頻繁に会議をする必要がある
採用するにはあまりにも多くの文化的変化が必要
より困難な契約交渉につながる可能性がある
非常に非効率になる可能性がある: コードのある領域の要件が多くの反復によって変化する場合、同じプログラミングを数回繰り返す必要があるかもしれない。一方、計画にあってそれに従うのであれば、コードの1つの領域は1回しか記述されないことが期待される
プロジェクトの開始時には、誰も全体のスコープ/要件を知らないので、見積もりを出すのに必要な労力の現実的な見積もりを作ることは不可能
詳細な要件文書がないため、スコープ・クリープのリスクを増大させる可能性がある
アジャイルは機能駆動型である: 非機能的な品質属性をユーザーストーリーとして表現するのが困難
変化を受け入れるという原則は、変化に逆らうのではなく、変化を受け入れるということだ。 例えば、イテレーションでの会議の一つで顧客の要求が劇的に変化したことが判明したら、プログラマーはこれを受け入れ、次のイテレーションのために新しい要件の計画していく。
コーディング規約
ソースコードの共同所有
シンプル設計
システムメタファー