エクストリーム・プログラミング
要件は、すべてを事前に取得しようとするのではなく、漸進的に定義される。
ソフトウェア開発者は通常、二人一組で作業することが求められる。
事前の大規模設計(英語版)がない。ほとんどの設計作業は、「可能で最も単純なもの」から始まり、テストの失敗によって必要になった場合にのみ複雑さを追加することで、その場で漸進的に行われる。批評家はこれを「システムの外観をデバッグする」ことと比較し、要件が変更されたときだけ再設計するよりも、再設計の労力が増えることを危惧している。
プロジェクトに顧客担当者(英語版)が付き添う。この役割はプロジェクトの単一障害点になる可能性があり、それがストレスの原因になると気づいた者もいる。また、技術的なソフトウェアの機能やアーキテクチャの使用を指示しようとする非技術的な担当者によるマイクロマネジメントの危険もある。
批評家は、不安定な要件の問題、ユーザーの衝突の妥協点が文書化されていないこと、全体的な設計仕様書や文書の欠如など、いくつかの潜在的な欠点を指摘している。
ソフトウェアシステムを構築するには、システムの要件をシステムの開発者に伝える必要がある。 格式ばったソフトウェア開発方法論では、このタスクは文書化によって行われる。 エクストリーム・プログラミング技法は、開発チームのメンバー間における組織化された知識を迅速に構築し、普及させるための方法と見なせる。 目標は、システムの利用者が持つ見解と一致するシステムの共有見解をすべての開発者に与えることです。 この目的を達成するために、エクストリーム・プログラミングは、シンプルな設計、共通のメタファー、ユーザーとプログラマーのコラボレーション、頻繁な口頭でのコミュニケーション、フィードバックを重視している。
リスペクトの価値には、自尊心だけでなく、他者への尊敬も含まれる。 プログラマは、コンパイルを中断させたり、既存のユニットテストを失敗させたり、仲間の作業を遅らせたりするような変更をコミットしてはならない。 チームメンバーは、常に高品質を目指し、リファクタリングを通して目の前の解決策に対して最善の設計を追求することで、自分の仕事を尊重する。
先に述べた4つの価値観を採用することは、チーム内の他のメンバーからの尊敬を得ることにつながる。 チームの誰かが、感謝されていないと感じたり、無視されていると感じたりするのはいけない。 これにより、高いモチベーションが確保され、チームとプロジェクトの目標に対する忠誠心が高まる。 この価値は他の価値に依存しており、チームワークを重視している。
エクストリーム・プログラミングでは、フィードバックが頻繁かつ迅速に行われることが最も有用であると考えられている。 また、あるアクションとそのフィードバックの間の遅延を最小限に抑えることが、学習や変化をする上で非常に重要であると強調している。 伝統的なシステム開発手法とは異なり、顧客との接触がより頻繁に繰り返される。 顧客は開発中のシステムを明確に理解しており、必要に応じてフィードバックを与え、開発の舵取りをすることができる。 顧客からの頻繁なフィードバックがあれば、開発者が誤った設計決定をした場合でも、開発者がそれを実装するのに多くの時間を費やす前に、迅速に気付き、修正することができる。
ユニットテストは迅速なフィードバックの原則に貢献している。 コードを書くとき、ユニットテストを実行することで、システムに加えられた変更に対してどのように反応するかの直接的なフィードバックが得られる。