エクストリームプログラミング

エクストリーム・プログラミング（XP）は、ソフトウェアの品質と変化する顧客要件への対応力を向上させることを目的としたソフトウェア開発手法です。アジャイル・ソフトウェア開発の一種として^[1]^[2]^[3]、短い開発サイクルで頻繁なリリースを推奨し、生産性の向上と、新たな顧客要件に対応できるチェックポイントの導入を目指しています。

エクストリームプログラミングのその他の要素には、ペアプログラミングや徹底的なコードレビュー、全コードのユニットテスト、実際に必要になるまで機能のプログラミングを行わないこと、フラットな管理構造、コードの簡潔性と明瞭性、時間の経過とともに問題がより深く理解されるにつれて顧客の要件が変化することを想定すること、顧客およびプログラマー間の頻繁なコミュニケーションなどがある。^[2]^[3]^[4]この方法論の名前は、従来のソフトウェアエンジニアリング手法の有益な要素を「極端な」レベルにまで引き上げたという考え方に由来する。例えば、コードレビューは有益な手法と考えられているが、これを極限まで推し進めると、コードを継続的にレビューすることができる（つまり、ペアプログラミングの手法）。

歴史

ケント・ベックはクライスラーの包括的報酬システム（C3）給与計算プロジェクトに携わっていた時にエクストリームプログラミングを開発しました。^[5]ベックは1996年3月にC3プロジェクトのリーダーになりました。彼はプロジェクトで使用された開発方法論を改良し始め、その方法論に関する本（エクストリームプログラミングの説明、1999年10月出版）を執筆しました。^[5] クライスラーは7年後の2000年2月、ダイムラー・ベンツに買収されたためC3プロジェクトを中止しました。^[6] ワード・カニンガムもXPに大きな影響を与えました。

エクストリームプログラミングの実践は古くから存在しており、その方法論は「ベストプラクティス」を極限レベルにまで押し進めたものである。例えば、「テストファースト開発、すなわちマイクロインクリメントごとにテストを計画・作成する実践」は、1960年代初頭のNASAのマーキュリー計画で既に実践されていた。 ^[7]開発期間全体を短縮するために、ソフトウェアのテスト準備と並行して（あるいはその直前に）正式なテスト文書（受け入れテスト用など）が開発されてきた。NASAの独立したテストグループは、プログラマがソフトウェアを記述し、ハードウェアに統合する前に、正式な要件と論理的限界に基づいてテスト手順を作成することができる。XPはこの概念を極限レベルまで押し進め、大規模な機能のテストだけでなく、ソフトウェアコーディングの小さなセクションの動作さえも検証する自動テスト（場合によってはソフトウェアモジュール内部）を作成する。

起源

1990 年代のソフトウェア開発に影響を与えた主な要因は 2 つあります。

内部的には、一部の開発者が好むプログラミングパラダイムとして、手続き型プログラミングに代わってオブジェクト指向プログラミングが採用されました。
外部的には、インターネットの台頭とドットコムブームにより、市場投入までのスピードと企業の成長がビジネス競争の要因として重視されるようになりました。

急速に変化する要件により、製品のライフサイクルを短縮する必要が生じ、従来のソフトウェア開発手法と衝突することが多かった。

クライスラー包括的報酬システム（C3）は、クライスラーの給与システムを研究対象とし、Smalltalkを言語、GemStoneをデータアクセス層として、オブジェクト技術の最適な利用方法を決定するために開始されました。クライスラーは、 Smalltalkの著名な実践者であるケント・ベック氏[ ^{5]をシステムの}パフォーマンスチューニングに起用しましたが、開発プロセスにいくつかの問題があることに気づいたため、彼の役割は拡大しました。彼はこの機会に、長年の共同研究者であるウォード・カニンガム氏との研究に基づき、開発手法にいくつかの変更を提案し、実装しました。ベック氏は、この手法の初期の構想について次のように述べています。^[8]

初めてチームを率いるよう頼まれた時は、テストやレビューなど、自分が合理的だと思ったことを少しだけやらせました。2回目は、もっと多くのことをやらなければなりませんでした。「魚雷なんてどうでもいい、少なくともこれは良い記事になる」と思い、私が不可欠だと思ったことだけを全力でやり、それ以外は省いてほしいとチームに頼みました。

ベックは、これらの手法の開発と改良を支援するため、ロン・ジェフリーズをプロジェクトに招聘しました。ジェフリーズはその後、コーチとしてC3チームにこれらの実践を習慣として浸透させました。

XPの背後にある原則と実践に関する情報は、カニンガムのWikiWikiWeb（原典となるWiki）における議論を通じて、より広く世界に広まりました。様々な貢献者がそのアイデアを議論・発展させ、いくつかの派生的な方法論が生まれました（アジャイルソフトウェア開発を参照）。また、XPの概念は、 1999年頃からXPウェブサイト（http://www.extremeprogramming.org）上でハイパーテキストシステムマップを用いて長年にわたり解説されてきました。

ベックはXPに関する一連の書籍を編集しており、その最初の書籍は彼自身の『エクストリームプログラミング解説』（1999年、ISBN 0-201-61641-6）によって、彼の考えはより広い読者層に広まりました。このシリーズの著者たちは、XPとその実践に関わる様々な側面を考察しました。このシリーズには、XPの実践を批判する書籍も含まれています。

現在の状態

XPは1990年代後半から2000年代初頭にかけてソフトウェアコミュニティの間で大きな関心を集め、その起源とはまったく異なる多くの環境で採用されました。^[9]

従来のプラクティスに求められていた高度な規律はしばしば見過ごされ、一部のプラクティス、特に厳格すぎると判断されたものは、個々のサイトで非推奨になったり、縮小されたり、あるいは未完成のまま放置されたりしました。例えば、あるプロジェクトで1日の終わりに統合テストを実施していたプラクティスを、週末のスケジュールに変更したり、あるいは双方が合意した日にテストを実施するだけに縮小したりすることも可能です。このようなより緩やかなスケジュールであれば、1日の終わりのテストに合格するためだけに人為的なスタブを急いで作成しなければならないという焦りを避けることができます。より緩やかなスケジュールであれば、複雑な機能を数日かけて開発することが可能になります。

一方、他のアジャイル開発プラクティスも停滞することなく、2019年現在も^[update]XPは進化を続け、現場での経験から得た教訓を吸収し、他のプラクティスを活用しています。初版から5年後の『エクストリームプログラミング解説』第2版（2004年11月）では、ベックはより多くの価値とプラクティスを追加し、主要なプラクティスと付随的なプラクティスを区別しました。

コンセプト

目標

『エクストリームプログラミングの説明』では、エクストリームプログラミングを、より生産的に高品質のソフトウェアを作成するために人々を組織するソフトウェア開発の規律として説明しています。

XPは、長い開発サイクルではなく、複数の短い開発サイクルを設けることで、要件変更にかかるコストを削減しようとします。この原則では、変更はソフトウェア開発プロジェクトにおける自然で避けられない、そして望ましい側面であり、安定した要件セットを定義しようとするのではなく、事前に計画しておくべきであるとされています。

エクストリームプログラミングでは、アジャイル方法論に加えて、いくつかの基本的な価値観、原則、実践も導入されます。

活動

XPは、ソフトウェア開発プロセスにおいて実行される4つの基本的なアクティビティ、すなわちコーディング、テスト、リスニング、設計について説明しています。それぞれのアクティビティについて、以下で説明します。

コーディング

XPの支持者は、システム開発プロセスにおいて真に重要な成果物はコード、つまりコンピュータが解釈できるソフトウェア命令だけであると主張します。コードがなければ、実際に機能する製品は存在しません。

コーディングは、最適な解決策を見つけるために活用できます。また、コーディングはプログラミングの問題に関する考えを伝えるのにも役立ちます。複雑なプログラミング問題に取り組んでいるプログラマー、あるいは他のプログラマーに解決策を説明するのが難しいと感じているプログラマーは、問題を簡略化した形でコーディングし、そのコードを使って自分の考えを示すことができます。この立場を支持する人々によると、コードは常に明確かつ簡潔であり、複数の解釈は不可能です。他のプログラマーは、自分の考えをコーディングすることで、このコードに対するフィードバックを与えることができます。

テスト

テストはエクストリームプログラミングの中心です。^[10]エクストリームプログラミングのアプローチは、少しのテストでいくつかの欠陥を排除できるのであれば、多くのテストを行えばさらに多くの欠陥を排除できるというものです。

ユニットテストは、特定の機能が意図したとおりに動作するかどうかを判断します。プログラマーは、コードを「壊す」可能性のある自動テストを思いつく限り多く記述します。すべてのテストが正常に実行されれば、コーディングは完了です。記述されたすべてのコードは、次の機能に進む前にテストされます。
受け入れテストでは、プログラマーが理解した要件が顧客の実際の要件を満たしているかどうかを確認します。

システム全体の統合テストは、当初は毎日の業務終了時に実施することが推奨されていました。これは、互換性のないインターフェースを早期に検出し、個々のセクションが一貫性のある機能から大きく逸脱する前に再接続できるようにするためです。しかし、システム全体の統合テストは、システム全体のインターフェースの安定性に応じて、週1回、あるいはそれ以下の頻度にまで縮小されました。^[要出典]

リスニング

プログラマーは、顧客がシステムに何を求めているのか、どのような「ビジネスロジック」が必要なのかを傾聴しなければなりません。プログラマーはこれらのニーズを十分に理解し、問題がどのように解決されるか、あるいは解決できないかについての技術的な側面について顧客にフィードバックする必要があります。顧客とプログラマーの間のコミュニケーションは、プランニングゲームの中でさらに深く掘り下げられます。

設計

もちろん、シンプルさの観点から言えば、システム開発にはコーディング、テスト、そしてリスニング以上のものは必要ないと言えるでしょう。これらの活動が適切に行われれば、結果として必ず機能するシステムが完成するはずです。しかし、実際にはそうはいきません。設計をせずに長い道のりを歩むことはできますが、ある時点で行き詰まりに陥ることがあります。システムが複雑になりすぎて、システム内の依存関係が明確でなくなるのです。これを回避するには、システム内のロジックを整理する設計構造を構築します。優れた設計は、システム内の多くの依存関係を回避します。つまり、システムの一部を変更しても、システムの他の部分に影響が及ばないということです。^[要出典]

価値観

エクストリームプログラミングは1999年に、コミュニケーション、シンプルさ、フィードバック、そして勇気という4つの価値を初めて認識しました。『エクストリームプログラミング解説』第2版では、「尊重」という新たな価値が追加されました。これら5つの価値について、以下に説明します。

コミュニケーション

ソフトウェアシステムを構築するには、システム要件をシステム開発者に伝える必要があります。正式なソフトウェア開発方法論では、この作業はドキュメント作成を通して行われます。エクストリームプログラミングの手法は、開発チームのメンバー間で組織的な知識を迅速に構築し、普及させるための手法と捉えることができます。その目標は、すべての開発者に、システムのユーザーが持つシステム観と一致する共通のシステム観を与えることです。この目的を達成するために、エクストリームプログラミングでは、シンプルな設計、共通のメタファー、ユーザーとプログラマーのコラボレーション、頻繁な口頭でのコミュニケーション、そしてフィードバックが重視されます。

シンプルさ

エクストリームプログラミングでは、最もシンプルなソリューションから始めることを推奨します。追加の機能は後から追加できます。このアプローチと従来のシステム開発手法との違いは、明日、来週、来月のニーズではなく、今日のニーズに合わせた設計とコーディングに重点を置くことです。これは時に「You aren't gonna need it」（YAGNI）アプローチと要約されます。^[11] XPの支持者は、このアプローチにはシステム変更のために明日より多くの労力が必要になる可能性があるという欠点を認めています。しかし、将来変更される可能性のある要件が重要になる前に投資する必要がないという利点によって、この欠点は十分に補えると主張しています。不確実な将来の要件に合わせてコーディングと設計を行うことは、必要のないものにリソースを費やし、重要な機能の実現を遅らせるリスクを伴います。「コミュニケーション」の価値に関連して、設計とコーディングのシンプルさはコミュニケーションの質を向上させるはずです。非常にシンプルなコードで書かれたシンプルな設計は、チーム内のほとんどのプログラマーが容易に理解できるでしょう。

フィードバック

エクストリームプログラミングでは、フィードバックはシステム開発のさまざまな側面に関連します。

システムからのフィードバック：ユニットテスト^[5]を書いたり、定期的に統合テストを実行したりすることで、プログラマーは変更を実装した後のシステムの状態から直接フィードバックを得ることができます。
顧客からのフィードバック：機能テスト（受け入れテストとも呼ばれます）は、顧客とテスターによって作成されます。システムの現状に関する具体的なフィードバックが得られます。このレビューは2～3週間に1回実施されるため、顧客は開発をスムーズに進めることができます。
チームからのフィードバック: 計画段階で顧客が新しい要件を提示すると、チームは実装にかかる時間の見積もりを直接提供します。

フィードバックはコミュニケーションとシンプルさと密接に関連しています。システムの欠陥は、特定のコードが動作しないことを証明するユニットテストを作成することで簡単に伝わります。システムからの直接的なフィードバックは、プログラマーにその部分を再コーディングするように指示します。顧客は、ユーザーストーリーと呼ばれる機能要件に従って、定期的にシステムをテストすることができます。^[5]ケント・ベックの言葉を引用すると、「楽観主義はプログラミングの職業病である。フィードバックは治療である。」^[12]

勇気

勇気を体現する実践はいくつかある。そのひとつは、常に明日のためではなく今日のために設計し、コードを書くという戒律である。これは、設計に行き詰まり、他の実装に多大な労力を要することを避けるための努力である。勇気があれば、開発者は必要に応じて安心してコードをリファクタリングすることができる。 ^[5]これは、既存のシステムを見直し、将来の変更をより容易に実装できるように修正することを意味する。勇気のもうひとつの例は、コードをいつ捨てるべきかを知ることである。つまり、どれだけの労力をかけて作成されたソースコードであっても、古くなったソースコードを削除する勇気である。また、勇気は粘り強さを意味する。プログラマーは複雑な問題に丸一日悩まされ、翌日にはその問題を素早く解決するかもしれないが、それは粘り強さがある場合に限る。

尊敬

尊重の価値には、自尊心だけでなく、他者への尊重も含まれます。プログラマーは、コンパイルを失敗させたり、既存のユニットテストを失敗させたり、あるいは同僚の作業を遅らせたりするような変更をコミットしてはいけません。メンバーは常に高品質を目指し、リファクタリングを通じて目の前のソリューションに最適な設計を模索することで、自身の仕事を尊重します。

前述の4つの価値観を体現することで、チームメンバーからの尊敬を得ることができます。チームの誰もが、評価されていないと感じたり、無視されていると感じたりしてはいけません。これにより、高いモチベーションが確保され、チームとプロジェクトの目標に対する忠誠心が促進されます。この価値観は他の価値観に依存しており、チームワークを重視しています。

ルール

XPルールの最初のバージョンは、1999年にドン・ウェルズ^[13]によってXPウェブサイトで公開されました。計画、管理、設計、コーディング、テストのカテゴリーに分類された29のルールが提示されています。計画、管理、設計は、XPがこれらの活動をサポートしていないという主張に反論するために、明示的に言及されています。

XPルールの別のバージョンは、ケン・アウアー^[14]によってXP/Agile Universe 2003で提案されました。彼は、XPはプラクティスではなくルールによって定義されると考えました（プラクティスはより多様性と曖昧さを伴います）。彼は2つのカテゴリーを定義しました。「エンゲージメントルール」はソフトウェア開発が効果的に行われるための環境を規定し、「プレイルール」はエンゲージメントルールの枠組みの中で分単位の活動とルールを定義します。

以下にいくつかのルールを示します (不完全)。

コーディング

顧客はいつでも対応可能
まずユニットテストをコーディングする
一度にコードを統合できるのは 1 組のみ
最適化は最後に残す
残業なし

テスト

すべてのコードにはユニットテストが必要です
すべてのコードは、リリースされる前にすべてのユニットテストに合格する必要があります。
バグが見つかった場合、バグに対処する前にテストが作成されます（バグはロジックのエラーではなく、作成されていないテストです）
受け入れテストは頻繁に実行され、その結果が公開される

原則

XPの基盤となる原則は、今述べた価値観に基づいており、システム開発プロジェクトにおける意思決定を促進することを目的としています。原則は価値観よりも具体的であり、実際の状況におけるガイダンスとしてより容易に解釈できるよう意図されています。

フィードバック

エクストリームプログラミングでは、フィードバックは頻繁かつ迅速に行われることが最も効果的であると考えられています。アクションとフィードバックの間の遅延を最小限に抑えることが、学習と変更の実現に不可欠であることを強調しています。従来のシステム開発手法とは異なり、顧客とのコンタクトはより頻繁な反復で行われます。顧客は開発中のシステムを明確に理解しており、必要に応じてフィードバックを提供し、開発を方向付けることができます。顧客からの頻繁なフィードバックがあれば、開発者が誤った設計決定を下しても、実装に多くの時間を費やす前に、迅速に発見され、修正されます。

ユニットテストは、迅速なフィードバックの原則に貢献します。コードを作成する際にユニットテストを実行すると、システムが変更にどのように反応するかについての直接的なフィードバックが得られます。これには、開発者のコードをテストするユニットテストだけでなく、単一のコマンドで開始できる自動化プロセスを使用して、すべてのソフトウェアに対してすべてのユニットテストを実行することも含まれます。これにより、開発者の変更が、開発者がほとんど、あるいは全く知らないシステムの他の部分で障害を引き起こした場合、自動化された全ユニットテストスイートがその障害を即座に検出し、開発者に変更がシステムの他の部分と互換性がないこと、そして変更を削除または修正する必要があることを警告します。従来の開発手法では、自動化された包括的なユニットテストスイートが存在しなかったため、開発者が無害と想定していたこのようなコード変更はそのまま残され、統合テスト中のみ、あるいはさらに悪いことに本番環境でのみ確認されていました。そして、統合テストの数週間、あるいは数か月前にすべての開発者が行ったすべての変更の中から、どのコード変更が問題を引き起こしたのかを特定することは、非常に困難な作業でした。

シンプルさを前提とする

これは、あらゆる問題を、その解決策が「極めて単純」であるかのように扱うことです。従来のシステム開発手法では、将来を見据えた計画を立て、再利用性を重視してコーディングすることが推奨されます。エクストリームプログラミングは、こうした考え方を否定します。

エクストリームプログラミングの支持者は、一度に大きな変更を加えることはうまくいかないと主張します。エクストリームプログラミングでは、段階的な変更が行われます。例えば、システムでは3週間ごとに小さなリリースが行われることがあります。小さなステップを積み重ねることで、顧客は開発プロセスと開発中のシステムに対するコントロールをより強固にすることができます。

変化を受け入れる

変化を受け入れるという原則は、変化に逆らうのではなく、変化を受け入れることです。例えば、ある反復的な会議で顧客の要件が劇的に変化したことが明らかになった場合、プログラマーはこれを受け入れ、次の反復に向けた新しい要件を計画する必要があります。

実践

エクストリームプログラミングには、次の 4 つの領域にグループ化された 12 のプラクティスがあると言われています。

微細スケールのフィードバック

連続プロセス

共通の理解

プログラマーの福利厚生

持続可能なペース

物議を醸す側面

XPの実践については激しい議論が交わされてきた。^[5]エクストリームプログラミングの支持者は、現場の顧客^[5]が非公式に変更を依頼することで、プロセスが柔軟になり、正式なオーバーヘッドにかかるコストを削減できると主張する。一方、XP批判者は、これがコストのかかるやり直しや、事前に合意された範囲や予算を超えたプロジェクトスコープの拡大につながる可能性があると主張する。 ^[要出典]

変更管理ボードは、プロジェクトの目的と制約に関して複数のユーザー間で潜在的な衝突が生じている兆候です。XPの迅速な手法は、プログラマーが統一されたクライアントの視点を想定できることにある程度依存しており、プログラマーは妥協案の目的と制約の文書化ではなくコーディングに集中することができます。^[15]これは、複数のプログラミング組織、特にプロジェクトのシェアを競い合う組織が関与する場合にも当てはまります。^[要出典]

エクストリームプログラミングに関して他に議論の余地があると思われる側面としては、以下のものがあります。

要件は、仕様書ではなく、自動受け入れテストとして表現されます。
要件は、すべてを事前に取得しようとするのではなく、段階的に定義されます。
ソフトウェア開発者は通常、2 人 1 組で作業する必要があります。
事前に大規模な設計を行う必要はありません。設計作業の大部分は、その場で段階的に行われ、「可能な限り最も単純なもの」から始め、テストの失敗によって必要になった場合にのみ複雑さを追加します。批評家はこれを「システムを見た目だけでデバッグする」と表現し、要件の変更時にのみ再設計するよりも多くの再設計作業が必要になることを懸念しています。
プロジェクトには顧客担当者が担当します。この役割はプロジェクトの単一障害点となる可能性があり、ストレスの原因となる人もいます。また、技術系ではない担当者が技術的なソフトウェア機能やアーキテクチャの使用を指示しようとするマイクロマネジメントの危険性もあります。

批評家は、不安定な要件の問題、ユーザー間の衝突に関する文書化された妥協点がない、全体的な設計仕様や文書が欠如しているなど、いくつかの潜在的な欠点を指摘して^いる[5]。

スケーラビリティ

Thoughtworks は、最大 60 名の分散 XP プロジェクトでかなりの成功を収めたと主張しています。^[要出典]

2004年には、XPの進化形としてインダストリアル・エクストリーム・プログラミング（IXP）^[16]が導入されました。IXPは、大規模かつ分散したチームでの作業を可能にすることを目的としています。現在、IXPには23のプラクティスと柔軟な価値観が組み込まれています。

分離可能性と対応

2003年、マット・スティーブンスとダグ・ローゼンバーグは『エクストリーム・プログラミング・リファクタリング：XPへの反論』を出版しました。この本は、XPプロセスの価値に疑問を投げかけ、改善策を提案しました。^[6]これは、記事、インターネットのニュースグループ、ウェブサイトのチャットエリアで長きにわたる議論を引き起こしました。本書の核心的な主張は、XPのプラクティスは相互に依存しているものの、実践的な組織ですべてのプラクティスを採用する意思と能力を持つ組織は少なく、したがってプロセス全体が失敗しているというものです。本書は他にも批判を展開しており、XPの「共同所有」モデルと社会主義の類似性を否定的に指摘しています。

『エクストリーム・プログラミング・リファクタリング』の出版以来、XPにはいくつかの側面が変化しました。特に、XPでは、必要な目標が達成される限り、プラクティスの修正が許容されるようになりました。また、XPではプロセスを表す用語がますます一般化しています。これらの変更は以前の批判を覆すものだと主張する人もいますが、単にプロセスを弱体化させているだけだと主張する人もいます。

他の研究者たちは、XPと従来の方法論を調和させ、統一された方法論を形成しようと試みてきました。XPが置き換えようとした方法論の中には、ウォーターフォール法（プロジェクトライフサイクル：ウォーターフォール、ラピッドアプリケーション開発（RAD）など）などがあります。JPモルガン・チェースは、 XPをコンピュータプログラミング手法である能力成熟度モデル統合（CMMI）やシックスシグマと組み合わせようと試みました。彼らは、3つのシステムが互いに補完し合い、より良い開発につながり、矛盾が生じないことを発見しました。^[17]

批判

エクストリームプログラミングの初期の話題性や、ペアプログラミングや継続的設計といった物議を醸した教義は、マクブリーン^[18] 、ボームとターナー^{[19] 、マット・スティーブンス、ダグ・ローゼンバーグ}^[20]などからの批判を集めた。しかし、アジャイル実践者からは、これらの批判の多くはアジャイル開発の誤解であると考えられている。^[21]

特にエクストリームプログラミングは、マット・スティーブンスとダグ・ローゼンバーグの『エクストリームプログラミング・リファクタリング』でレビューと批評が行われている。^[6]

参照

参考文献

^ 「ヒューマンセンタードテクノロジーワークショップ2006」、2006年、PDF、ヒューマンセンタードテクノロジーワークショップ2006
^ ab UPenn-Lectures-design-patterns「デザインパターンとリファクタリング」、ペンシルバニア大学、2003年 Archived August 2, 2010, at the Wayback Machine。
^ ab USFCA-edu-601-lecture エクストリームプログラミング。
^ 「アジャイルソフトウェア開発宣言」 Agilemanifesto.org. 2001年. 2019年3月26日閲覧。
^ abcdefghijklm Computerworld-appdev-92「エクストリームプログラミング」、Computerworld (オンライン)、2001 年 12 月。
^ abc Rosenberg, Doug; Stephens, Matt (2003). 『エクストリーム・プログラミング・リファクタリング：XPに反対するケース』Apress. ISBN 978-1-59059-096-6。
^ ラーマン＆バシリ 2003.
^ ケント・ベックとマーティン・ファウラーへのインタビュー。2001年3月23日。 {{cite book}}:|work=無視されました (ヘルプ)
^ セダノ、トッド、ラルフ、ポール（2025年）『持続可能なデュアルトラック開発』テイラー＆フランシス、ISBN 978-1-032-98310-3。
^ Lisa Crispin; Tip House (2003). 『エクストリームプログラミングのテスト』 Addison-Wesley Professional. ISBN 9780321113559。
^ 「誰もがプログラマーだ」クレア・トリストラム著、 テクノロジーレビュー、2003年11月、39ページ。
^ Beck, K. (1999). 『エクストリームプログラミング入門：変化を受け入れる』Addison-Wesley. ISBN 978-0-321-27865-4。
^ 「エクストリームプログラミングのルール」extremeprogramming.org。
^ Ken Auer アーカイブ済み 2008年9月20日、Wayback Machine
^ ジョン・キャロル、デイビッド・モリス（2015年7月29日）『アジャイル・プロジェクトマネジメント in easy steps』第2版、In Easy Steps、162ページ。ISBN 978-1-84078-703-0。
^ カッターコンソーシアム. 「インダストリアルXP：大規模組織におけるXPの活用 - カッターコンソーシアム」. cutter.com .
^ エクストリームプログラミング (XP) シックスシグマ CMMI。
^ McBreen, P. (2003). 『エクストリームプログラミングへの問いかけ』ボストン、マサチューセッツ州: Addison-Wesley. ISBN 978-0-201-84457-3。
^ ボーム、B.、R.ターナー（2004年）『アジリティとディシプリンのバランス：困惑した人のためのガイド』ボストン、マサチューセッツ州：アディソン・ウェズリー、ISBN 978-0-321-18612-6。
^ マット・スティーブンス、ダグ・ローゼンバーグ (2004). エクストリームプログラミングの皮肉. MA: Dr Dobbs journal. {{cite book}}:|work=無視されました (ヘルプ)
^ sdmagazine 2006年3月16日アーカイブ、Wayback Machine

さらに読む

ケン・アウアー、ロイ・ミラー著『エクストリームプログラミング応用：勝利へのプレイング』アディソン・ウェズリー社。
ケン・アウアー、ロン・ジェフリーズ、ジェフ・カンナ、グレン・B・アレマン、リサ・クリスピン、ジャネット・グレゴリー (2002)。「テスターは絶滅したのか？テスターはXPチームにどのように貢献できるのか？」エクストリームプログラミングとアジャイル手法 — XP/Agile Universe 2002。コンピュータサイエンス講義ノート。第2418巻。シュプリンガー出版社。p. 287。doi : 10.1007/3-540-45672-4_50。ISBN 978-3-540-44024-6。
ケント・ベック著『エクストリーム・プログラミング入門：変化を受け入れる』アディソン・ウェズレー社。初版1999年。シンシア・アンドレス共著、第2版2004年。
Kent BeckとMartin Fowler : 『エクストリームプログラミングの計画』、Addison–Wesley。
Alistair Cockburn : Agile Software Development、Addison–Wesley。
Martin Fowler著『リファクタリング：既存コードの設計改善』Kent Beck、John Brant、William Opdyke、Don Roberts共著（1999年）。Addison-Wesley。
ハーヴェイ・ヘレラ (2005). ケーススタディ：クライスラーの包括的報酬制度. カリフォルニア大学アーバイン校ガレン研究所.
ジム・ハイスミス著『アジャイルソフトウェア開発エコシステム』アディソン・ウェズリー出版。
Ron Jeffries、Ann Anderson、Chet Hendrickson (2000)、『Extreme Programming Installed』、Addison–Wesley。
Larman, C. ; Basili, VR (2003年6月). 「反復的かつ漸進的な開発：その歴史」(PDF) . Computer . 36 (6): 47– 56. doi :10.1109/MC.2003.1204375.
Matt Stephens、Doug Rosenberg (2003). 『エクストリームプログラミングのリファクタリング：XPに反対するケース』、Apress.
ウォルドナー、JB. （2008年）。「ナノコンピューターと群知能」。掲載:ISTE、225–256。

外部リンク

ウィキメディアコモンズには、エクストリームプログラミングに関連するメディアがあります。

Wikiquote にはエクストリームプログラミングに関連する引用があります。

優しい紹介
産業用エクストリームプログラミング
XP導入における問題と解決策
オフショア開発におけるアジャイルソフトウェアプロセスの活用 - ThoughtWorksによる大規模分散プロジェクトにおけるXP実装の経験