プログラマーはこれらのニーズを十分に理解して、問題がどのように解決されるか、あるいは解決されないのかの技術的な側面について顧客にフィードバックしなければならない。
設計.
単純さの観点で言うと、当然のことながら、システム開発にはコーディング、テスト、傾聴以上のものは必要ないと言える。
これらのアクティビティが適切に行われていれば、その結果は常に動作するシステムになるはずだ。しかし、実際にはそうはならない。
設計せずに長い道のりを歩むことはできるが、いつかは行き詰まる。
システムが複雑になりすぎて、システム内の依存関係が明確でなくなる。
システム内のロジックを整理する設計構造を作成することで、これを回避できる。
優れた設計は、システム内の多くの依存関係を回避する; つまり、システムのある部分を変更しても、システムの他の部分に影響を与えない。
価値.
コミュニケーション.
ソフトウェアシステムを構築するには、システムの要件をシステムの開発者に伝える必要がある。
格式ばったソフトウェア開発方法論では、このタスクは文書化によって行われる。
エクストリーム・プログラミング技法は、開発チームのメンバー間における組織化された知識を迅速に構築し、普及させるための方法と見なせる。
目標は、システムの利用者が持つ見解と一致するシステムの共有見解をすべての開発者に与えることです。
この目的を達成するために、エクストリーム・プログラミングは、シンプルな設計、共通のメタファー、ユーザーとプログラマーのコラボレーション、頻繁な口頭でのコミュニケーション、フィードバックを重視している。
シンプリシティ.
エクストリーム・プログラミングでは、最もシンプルな解説策から始めることを推奨している。機能は、後から追加できる。
このアプローチと従来のシステム開発手法との違いは、明日、来週、または来月のニーズではなく、今日のニーズに合わせた設計とコーディングに焦点を当てていることだ。
これは、「実際に必要となるまでは追加しない」(YAGNI)アプローチとして要約されることがある。
XPの支持者は、これが、システムの変更に明日より多くの努力を必要とすることがあるという欠点を認めている;