エクストリーム・プログラミング
XP のプラクティスは激しく議論されてきている。 エクストリーム・プログラミングの支持者は、オンサイト顧客に非公式に変更を要求することで、プロセスが柔軟になり、形式的なオーバーヘッドのコストを節約できると主張している。 XPの批判者は、これがコストのかかる手直しや、以前に合意や資金提供されていた範囲を超えたプロジェクトのスコープ・クリープにつながる可能性があると主張している。
変更管理委員会は、プロジェクトの目的と複数のユーザー間の制約に潜在的な矛盾があることを示している。 XPの迅速な手法は、プログラマーが妥協した目的や制約の文書化ではなくコーディングに集中できるようにするのに、統一されたクライアント視点をプログラマー達が想定できるかどうかにある程度依存している。 これは、複数のプログラミング組織、特にプロジェクトのシェアを競い合う組織にも当てはまる。
他にも、エクストリーム・プログラミングの潜在的な議論の余地のある側面としては、以下のようなものがある:
要件は、仕様書ではなく自動受け入れテストとして表現される。
持続可能なペース
これには、開発者のコードをテストするユニットテストを実行するだけでなく、単一のコマンドで起動される自動化されたプロセスを使用した、すべてのソフトウェアに対するすべての単体テストを実行することも含まれる。 このようにして、開発者の変更がシステムのその他の部分で開発者がほとんどまたはまったく知らない障害を引き起こした場合、 自動化された全ユニットテストスイートはすぐに障害を明らかにし、その変更がシステムの他の部分と非互換であること、そしてその変更を削除するか修正する必要があることを開発者に警告する。 伝統的な開発手法では、自動化された包括的なユニットテストスイートがないため、開発者は無害であると思っていたコード変更がそのまま残され、統合テスト中でしか現れず、さらに悪いことに、本番環境でしか現れなかった; また、統合テストの数週間前または数か月前からすべての開発者が行ったすべての変更の中から、どのコード修正が問題の原因となったのかを特定することは、大変な作業だった。
XPの支持者は、システム開発プロセスの唯一の真に重要な製品はコード、つまりコンピュータが解釈できるソフトウェア命令であると主張する。コードがなければ、動作する製品は存在しない。
コーディングは、最適な解決策を導き出すのに役立つ。コーディングはまた、プログラミングの問題についての考えを伝えるのにも役立つ。 複雑なプログラミングの問題を扱うプログラマーや、他のプログラマーに解決策を説明するのが難しいと感じるプログラマーは、シンプルな形でコード化し、そのコードを使って自分が何を言いたいのかを示すこともできる。 この立場の支持者らによると、コードは常に明確で簡潔であり、複数の方法で解釈することはできないと言う。 他のプログラマーも、自身の考えをコード化することで、コードに対してフィードバックすることができる。