エクストリーム・プログラミングの計画とフィードバックのループ エクストリーム・プログラミング 、XP （英 : extreme programming ）は、 ソフトウェア品質 を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセス である。アジャイルソフトウェア開発 の一つとして[ 1] [ 2] [ 3]
エクストリーム・プログラミングの他の要素には、ペアでの プログラミングや広範なコードレビュー の実施、すべてのコードのユニットテスト 、機能は実際に必要となるまでは追加しない 、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある[ 2] [ 3] [ 4] コードレビュー は有益なプラクティスと考えられており、これを極端にすれば、コードを「継続的」にレビューする、つまり、ペアプログラミング のプラクティスとなる。
ケント・ベック は、クライスラー総合報酬システム （英語版 ） プロジェクト での業務の中で、エクストリーム・プログラミングを開発した[ 5] プロジェクトリーダー になった。彼はプロジェクトで使用された開発方法論を改良し始め、その方法論に関する本を書いた (エクストリームプログラミング , 1999年10月出版)[ 5] クライスラー は7年後の2000年2月、ダイムラー・ベンツ が同社を買収した際にC3プロジェクトをキャンセルした[ 6]
エクストリーム・プログラミングの多くのプラクティスは以前から存在していた。この方法論は、「ベストプラクティス 」を極端なレベルに引き上げる。 たとえば、「テストファースト開発のプラクティス、各マイクロインクリメントの前にテストを計画して書く」は、1960年代初頭のNASAのマーキュリー計画 で早くも使われていた。総開発時間を短縮するために、一部の正式なテストドキュメント(受け入れテスト のためのものなど)は、ソフトウェアのテストの準備がされるのと並行して(あるいは少し前から)開発されてきた。NASAの独立テストグループは、プログラマーがソフトウェアを書いてハードウェアと統合する前に、公式な要件と論理的限界に基づいてテスト手順を書くことができた。XPは、この概念を極限のレベルにまで引き上げて、機能という大きなテストしかしないのではなく、ソフトウェアコーディングの小さなセクションでさえも動作を検証する自動テスト（時にはソフトウェアモジュールの内部）を記述する。
2つの大きな影響が1990年代のソフトウェア開発を形作った:
急速に変化する要件は、製品のライフサイクル の短縮を要求し、しばしばソフトウェア開発の伝統的な方法と衝突した。
クライスラー総合報酬システム（C3）は、クライスラーの給与計算システムを研究対象とし、言語としてSmalltalk 、データアクセス層 （英語版 ） Gemstone を用いて、オブジェクト技術の最善の利用方法を見極めるために始まった。
クライスラーは、システムのパフォーマンスチューニング （英語版 ） ケント・ベック を招き入れた[ 5] ウォード・カニンガム との業績に基づいたもの- を提案および実施した。
ケント・ベックは、手法の初期のコンセプトの説明を残している[ 8]
初めてチームのリーダーを任された時に、テストやレビューなど、私が理にかなっていると思ったことを少しだけやってもらいました。2回目はもっとたくさんのことをやってもらいました。私は、「機雷にかまうな、少なくともこれは良いシステムになるぞ」と考え、[そして]チームに、私が必要不可欠だと思うこと全てのツマミを10に上げ、それ以外はすべて省いてくれと求めました。
ケント・ベックは、これらの方法の開発と改良の支援のために、ロン・ジェフリーズ （英語版 ）
XPの背後にある原則とプラクティスに関する情報は、オリジナルのウィキ であるカニンガムのWikiWikiWeb での議論を通じて、より広い世界に広まった。
さまざまな寄稿者がアイデアを議論し、拡張し、いくつかのスピンオフの方法論が生まれた(アジャイルソフトウェア開発 を参照)。
また、XPのコンセプトは、1999年頃のXPのWebサイト http://www.extremeprogramming.org でのハイパーテキスト システムによって、数年前から説明されている[誰によって? 。
ケント・ベックは、彼自身の書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』 (原書初版1999年、ISBN 978-4894712751 )を皮切りに、XPに関する一連の書籍を編集し、彼の考えをより多くの人に広めていった。
このシリーズの著者たちは、XPとそのプラクティスについて、様々な側面から考察をしている。一連の書籍には、プラクティスに批判的な本も含まれている。
XPは、1990年代後半から2000年代初頭にかけてソフトウェアコミュニティの間で大きな関心を集め、その起源とは根本的に異なる多くの環境で採用された。
元のプラクティスに求められていた高い規律はしばしば道端に捨て置かれ、厳しすぎると思われていたプラクティスの中には、銘々のサイトで非推奨になったり、縮小されたり、あるいは未完成のままにされるものもあった。
たとえば、各プロジェクトにおける一日の終わりの統合テスト の実施を、週の終わりのスケジュールに変更したり、単に相互に合意した日でのテストに減らしたりする。
そのような弛んだスケジュールでは、一日の終わりのテストに合格するためだけに人為的なスタブを生成しなければならないという焦りを感じることはない。厳格でないスケジュールでは、代わりに、数日間も費やして複雑な機能を開発してしまう。
一方、他のアジャイル開発プラクティスは立ち止まっておらず、XPも、2019年の時点で、他のプラクティスを利用するために、現場での経験による多くの教訓を取り入れて進化し続けている。
初版から5年後の第2版の書籍『エクストリームプログラミング』（2004年11月原著発行）では、ケント・ベックはより多くの価値 とプラクティスを追加し、基礎プラクティスと周辺プラクティスを区別した。
持続可能なソフトウェア開発の理論は、エクストリーム・プログラミングチームがチームの混乱にもかかわらず成長できる理由が説明されている
[ 9] [要非一次資料
。
書籍『エクストリームプログラミング』では、エクストリーム・プログラミングは、より高品質なソフトウェアをより生産的に生産するために人々を組織化するソフトウェア開発の規律として説明されている。
XPは、長い開発サイクルではなく、複数の短い開発サイクルにより、要件変更のコストを下げようとする。
この教義では、変更はソフトウェア開発プロジェクトの自然で避けられない望ましい側面であり、変わることがない要件定義をしようとするのではなく、計画すべしとしている。
エクストリーム・プログラミングでは、アジャイルプログラミングのフレームワークに加えて、いくつかの基本的な価値、原則、およびプラクティスを取り入れている。
XPでは、ソフトウェア開発プロセス内で実行される4つの基本的なアクティビティ（コーディング、テスト、傾聴、設計）を描き出す。これら各アクティビティを次に説明する。
XPの支持者は、システム開発プロセスの唯一の真に重要な製品はコード、つまりコンピュータが解釈できるソフトウェア命令であると主張する。コードがなければ、動作する製品は存在しない。
コーディングは、最適な解決策を導き出すのに役立つ。コーディングはまた、プログラミングの問題についての考えを伝えるのにも役立つ。
複雑なプログラミングの問題を扱うプログラマーや、他のプログラマーに解決策を説明するのが難しいと感じるプログラマーは、シンプルな形でコード化し、そのコードを使って自分が何を言いたいのかを示すこともできる。
この立場の支持者らによると、コードは常に明確で簡潔であり、複数の方法で解釈することはできないと言う。
他のプログラマーも、自身の考えをコード化することで、コードに対してフィードバックすることができる。
テストはエクストリーム・プログラミングの中心である[ 10]
ユニットテスト は、特定の機能が意図した通りに動作するかどうかを判断する。プログラマは、コードを「壊す」可能性のある自動テストを思いつく限り多く書く; すべてのテストが成功したら、コーディングは完了である。書かれたすべてのコードは、次の機能の作成に進む前にテストされる。受け入れテスト では、プログラマーが理解した要件が顧客の実際の要件を満たしているかどうかを検証する。システム全体の統合テスト は、最初は、互換性のないインターフェースを早期に発見し、各セクションが首尾一貫した機能から大きく乖離する前に再接続するために、毎日の終業時に実施することが推奨されていた。しかし、システム全体の統合テストは、システムの全体的なインターフェースの安定性に応じて、週1回、またはそれ以下の頻度にまで減少した[要出典 。
プログラマーは、顧客がシステムに何を必要としているのか、どのような「ビジネスロジック 」が必要なのかに耳を傾けなければならない。
プログラマーはこれらのニーズを十分に理解して、問題がどのように解決されるか、あるいは解決されないのかの技術的な側面について顧客にフィードバックしなければならない。
顧客とプログラマーの間のコミュニケーションは、計画ゲーム
単純さの観点で言うと、当然のことながら、システム開発にはコーディング、テスト、傾聴以上のものは必要ないと言える。
これらのアクティビティが適切に行われていれば、その結果は常に動作するシステムになるはずだ。しかし、実際にはそうはならない。
設計せずに長い道のりを歩むことはできるが、いつかは行き詰まる。
システムが複雑になりすぎて、システム内の依存関係が明確でなくなる。
システム内のロジックを整理する設計構造を作成することで、これを回避できる。
優れた設計は、システム内の多くの依存関係を回避する; つまり、システムのある部分を変更しても、システムの他の部分に影響を与えない[要出典 。
1999年の最初のエクストリーム・プログラミングでは、コミュニケーション、シンプルさ、フィードバック、勇気という4つの価値観に着目した。第2版の書籍『エクストリームプログラミング』では、新たに「リスペクト」という価値観が追加された。これら5つの価値観を以下で説明する。
ソフトウェアシステムを構築するには、システムの要件をシステムの開発者に伝える必要がある。
格式ばったソフトウェア開発方法論では、このタスクは文書化によって行われる。
エクストリーム・プログラミング技法は、開発チームのメンバー間における組織化された知識を迅速に構築し、普及させるための方法と見なせる。
目標は、システムの利用者が持つ見解と一致するシステムの共有見解をすべての開発者に与えることです。
この目的を達成するために、エクストリーム・プログラミングは、シンプルな設計、共通のメタファー、ユーザーとプログラマーのコラボレーション、頻繁な口頭でのコミュニケーション、フィードバックを重視している。
エクストリーム・プログラミングでは、最もシンプルな解説策から始めることを推奨している。機能は、後から追加できる。
このアプローチと従来のシステム開発手法との違いは、明日、来週、または来月のニーズではなく、今日のニーズに合わせた設計とコーディングに焦点を当てていることだ。
これは、「実際に必要となるまでは追加しない 」(YAGNI)アプローチとして要約されることがある[ 11]
エクストリーム・プログラミングでは、フィードバックはシステム開発のさまざまな側面に関連している:
システムからのフィードバック: ユニットテスト を書いたり[ 5]
顧客からのフィードバック: 機能テスト（別名：(受け入れテスト ）は、顧客とテスターが作成する。彼らは、システムの現状について具体的なフィードバックを得られる。このレビューを2～3週間に1回のペースで計画することで、顧客は容易に開発の舵取りができる。
チームからのフィードバック: 顧客が計画ゲームで新しい要求を出すと、チームは直接、実装にかかる時間を見積もる。 フィードバックは、コミュニケーションとシンプルさに密接に関係している。
システムの欠陥は、特定のコードが壊れることを証明するユニットテストを書くことで簡単に伝達される。
システムからの直接のフィードバックは、プログラマーにこの部分を再コーディングするように伝える。
顧客は、ユーザーストーリー [ 5] ケント・ベック を引用すると、「楽観主義はプログラミングの職業上の危険である。フィードバックが治療法である。」[ 12]
いくつかのプラクティスは勇気を体現している。
1つは、明日のためではなく、常に今日のために設計とコーディングをするという戒めである。
これは、設計の行き詰まりを避け、余計なものを実装するために費やす多くの労力を回避するための取り組みである。
勇気により、開発者は必要に応じてコードのリファクタリング を快適に行える[ 5]
リスペクトの価値には、自尊心だけでなく、他者への尊敬も含まれる。
プログラマは、コンパイルを中断させたり、既存のユニットテストを失敗させたり、仲間の作業を遅らせたりするような変更をコミットしてはならない。
チームメンバーは、常に高品質を目指し、リファクタリングを通して目の前の解決策に対して最善の設計を追求することで、自分の仕事を尊重する。
先に述べた4つの価値観を採用することは、チーム内の他のメンバーからの尊敬を得ることにつながる。
チームの誰かが、感謝されていないと感じたり、無視されていると感じたりするのはいけない。
これにより、高いモチベーションが確保され、チームとプロジェクトの目標に対する忠誠心が高まる。
この価値は他の価値に依存しており、チームワークを重視している。
XPのルールの最初のバージョンは、1999年にドン・ウェルズ[ 13]
XPのルールの別バージョンは、ケン・アウアー[ 14]
以下、ルールの一部を示す（不完全）:
コーディング
テスト
全てのコードは、ユニットテスト を持つ
全てのコードは、リリース前にすべてのユニットテスト を通す
バグ があれば、バグを調べる前にテストを書く(バグとは、ロジック内の誤りではない; 書かれていないテストである)受け入れテスト は頻繁に実行され、結果は公開される
XPの基礎となる原則は、先ほど説明した価値観に基づいており、システム開発プロジェクトにおける意思決定を促進することを目的としている。
原則は、価値よりも具体的で、より実践的な状況でのガイドラインに変換しやすいことを目指している。
エクストリーム・プログラミングでは、フィードバックが頻繁かつ迅速に行われることが最も有用であると考えられている。
また、あるアクションとそのフィードバックの間の遅延を最小限に抑えることが、学習や変化をする上で非常に重要であると強調している。
伝統的なシステム開発手法とは異なり、顧客との接触がより頻繁に繰り返される。
顧客は開発中のシステムを明確に理解しており、必要に応じてフィードバックを与え、開発の舵取りをすることができる。
顧客からの頻繁なフィードバックがあれば、開発者が誤った設計決定をした場合でも、開発者がそれを実装するのに多くの時間を費やす前に、迅速に気付き、修正することができる。
ユニットテストは迅速なフィードバックの原則に貢献している。
コードを書くとき、ユニットテストを実行することで、システムに加えられた変更に対してどのように反応するかの直接的なフィードバックが得られる。
これには、開発者のコードをテストするユニットテストを実行するだけでなく、単一のコマンドで起動される自動化されたプロセスを使用した、すべてのソフトウェアに対するすべての単体テストを実行することも含まれる。
このようにして、開発者の変更がシステムのその他の部分で開発者がほとんどまたはまったく知らない障害を引き起こした場合、
自動化された全ユニットテストスイートはすぐに障害を明らかにし、その変更がシステムの他の部分と非互換であること、そしてその変更を削除するか修正する必要があることを開発者に警告する。
伝統的な開発手法では、自動化された包括的なユニットテストスイートがないため、開発者は無害であると思っていたコード変更がそのまま残され、統合テスト中でしか現れず、さらに悪いことに、本番環境でしか現れなかった;
また、統合テストの数週間前または数か月前からすべての開発者が行ったすべての変更の中から、どのコード修正が問題の原因となったのかを特定することは、大変な作業だった。
これは、すべての問題を、あたかもその解決策が「非常にシンプルである」かのように扱うことだ。
伝統的なシステム開発手法では、将来を見据えた計画を立て、再利用性を考慮したコーディングを行うように言われてきたが、エクストリーム・プログラミングはこれらの考え方を否定する。
エクストリーム・プログラミングの支持者は、一度に大きな変更を加えてもうまくいかないと言う。
エクストリーム・プログラミングでは、漸進的な変更を適用する:
例えば、システムは3週間ごとに小さなリリースを行うかもしれない。
多くの小さな段階が作られると、顧客は開発プロセスと開発中のシステムをより詳細に制御できるようになる。
変化を受け入れるという原則は、変化に逆らうのではなく、変化を受け入れるということだ。
例えば、イテレーションでの会議の一つで顧客の要求が劇的に変化したことが判明したら、プログラマーはこれを受け入れ、次のイテレーションのために新しい要件の計画していく。
エクストリームプログラミングには、4つの領域にグループ化された12のプラクティスがあると説明されている:
XP のプラクティスは激しく議論されてきている[ 5] [ 5] スコープ・クリープ につながる可能性があると主張している[要出典 。
変更管理委員会は、プロジェクトの目的と複数のユーザー間の制約に潜在的な矛盾があることを示している。
XPの迅速な手法は、プログラマーが妥協した目的や制約の文書化ではなくコーディングに集中できるようにするのに、統一されたクライアント視点をプログラマー達が想定できるかどうかにある程度依存している[ 15] [要出典 。
他にも、エクストリーム・プログラミングの潜在的な議論の余地のある側面としては、以下のようなものがある:
要件は、仕様書ではなく自動受け入れテストとして表現される。
要件は、すべてを事前に取得しようとするのではなく、漸進的に定義される。
ソフトウェア開発者は通常、二人一組で作業することが求められる。
事前の大規模設計 （英語版 ） デバッグ する」ことと比較し、要件が変更されたときだけ再設計するよりも、再設計の労力が増えることを危惧している。プロジェクトに顧客担当者 （英語版 ） マイクロマネジメント の危険もある。 批評家は、不安定な要件の問題、ユーザーの衝突の妥協点が文書化されていないこと、全体的な設計仕様書や文書の欠如など、いくつかの潜在的な欠点を指摘している[ 5]
ThoughtWorks （英語版 ） [要出典 。
2004年に、XPの進化形として産業用エクストリーム・プログラミング（IXP）[ 16]
2003年に、マット・ステファン （英語版 ） [ 6]
XPのある側面は『Extreme Programming Refactored』の出版以降、変化している;
特に、XPは現在、必要な目標が満たされているのであれば、プラクティスの変更を受け入れている。
XPはまた、プロセスに一般的な用語を使うようになってきている。
これらの変更により以前の批判は無効であると主張する人もいれば、これは単にプロセスを骨抜きにしているだけだという意見もある。
他の著者は、統一された方法論を形成するために、古い方法論とXPを調和させることを試みた。
これらのXPのいくつかは、 ウォーターフォール・モデル のような、置き換えを求めていた:
例: プロジェクトのライフサイクル: ウォーターフォール、高速アプリケーション開発 (RAD)、およびそのすべて。
JPモルガン・チェース は、能力成熟度モデル統合 (CMMI)およびシックス・シグマ のコンピュータプログラミングの方法とXPを組み合わせてみた。
彼らは、3つのシステムが互いをよく補強し、よりよい開発をもたらし、相互に矛盾しなかったことを見つけた[ 17]
エクストリーム・プログラミングの初期の話題性と、ペアプログラミング や継続的設計 （英語版 ） [ 18] [ 19] [ 20] [ 21]
とりわけ、エクストリーム・プログラミングは、マット・ステファンとダグ・ローゼンバーグの書籍『Extreme Programming Refactored』で考察と批判がされている[ 6]
批判には次のようなものがある:
方法論が人によりけり、アジャイルはこれを解決していない[要出典
成果物を定義しないことで顧客からお金を垂れ流すための手段としてよく使用される [要出典
構造と必要な文書の欠如 [要出典
上級レベルの開発者のみに作用する[要出典
不十分なソフトウェア設計を包含している[要出典
顧客は莫大な費用をかけて頻繁に会議をする必要がある[要出典
採用するにはあまりにも多くの文化的変化が必要[要出典
より困難な契約交渉につながる可能性がある[要出典
非常に非効率になる可能性がある: コードのある領域の要件が多くの反復によって変化する場合、同じプログラミングを数回繰り返す必要があるかもしれない。一方、計画にあってそれに従うのであれば、コードの1つの領域は1回しか記述されないことが期待される[要出典
プロジェクトの開始時には、誰も全体のスコープ/要件を知らないので、見積もりを出すのに必要な労力の現実的な見積もりを作ることは不可能[要出典
詳細な要件文書がないため、スコープ・クリープ のリスクを増大させる可能性がある[要出典 アジャイルは機能駆動型である: 非機能的な品質属性をユーザーストーリー として表現するのが困難[要出典
^ "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006
^ a b UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003 .
^ a b USFCA-edu-601-lecture Extreme Programming .
^ “Manifesto for Agile Software Development ”. Agilemanifesto.org (2001年). 2019年3月26日 閲覧。 ^ a b c d e f g h i j k l m Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001
^ a b c Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP ISBN 978-1-59059-096-6 . https://archive.org/details/extremeprogrammi00matt
^ Interview with Kent Beck and Martin Fowler . http://www.informit.com/articles/article.aspx?p=20972 ^
Sedano, Todd; Ralph, Paul; Péraire, Cécile (2016). Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement - ESEM '16 doi :10.1145/2961111.2962590 . ISBN 9781450344272 . https://www.researchgate.net/publication/304014117
^ Lisa Crispin; Tip House (2003). Testing Extreme Programming . ISBN 9780321113559 ^ "Everyone's a Programmer" by Clair Tristram. Technology Review , November 2003. p. 39.
^ Beck, K. (1999). Extreme Programming Explained: Embrace Change . Addison-Wesley. ISBN 978-0-321-27865-4 ^ “Extreme Programming Rules ”. extremeprogramming.org . 2019年3月26日 閲覧。 ^ Ken Auer Archived September 20, 2008, at the Wayback Machine .^ John Carroll; David Morris (July 29, 2015). Agile Project Management in easy steps, 2nd edition ISBN 978-1-84078-703-0 . https://books.google.com/books?id=oqFKCgAAQBAJ&pg=PT162 ^ Cutter Consortium. “Industrial XP: Making XP Work in Large Organizations - Cutter Consortium ”. cutter.com . 2019年3月26日 閲覧。 ^ Extreme Programming (XP) Six Sigma CMMI .^ McBreen, P. (2003). Questioning Extreme Programming . Boston, MA: Addison-Wesley. ISBN 978-0-201-84457-3 ^ Boehm, B. ; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed . Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6 ^ Stephens, Matt ; Doug Rosenberg (2004). The irony of extreme programming . http://www.drdobbs.com/the-irony-of-extreme-programming/184405651 ^ sdmagazine Archived March 16, 2006, at the Wayback Machine .
Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win , Addison–Wesley.ケン アウアー (著), ロイ ミラー (著), Ken Auer (原著), Roy Miller (原著), 平鍋 健児 (翻訳), 遠藤 真奈美 (翻訳), 高嶋 優子 (翻訳), 山田 禎一 (翻訳) 『XPエクストリーム・プログラミング適用編―ビジネスで勝つためのXP』ピアソン・エデュケーション、2002。ISBN 978-4894715554
Ken Auer; Ron Jeffries ; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). “Are Testers eXtinct? How Can Testers Contribute to XP Teams?”. Extreme Programming and Agile Methods — XP/Agile Universe 2002 . Lecture Notes in Computer Science. 2418 . Springer-Verlag. pp. 287. doi :10.1007/3-540-45672-4_50 . ISBN 978-3-540-44024-6 Kent Beck : Extreme Programming Explained: Embrace Change , Addison–Wesley.ケント・ベック(著)、長瀬嘉秀(監訳)、永田渉、飯塚麻理香(訳)『XPエクストリーム・プログラミング入門：ソフトウェア開発の究極の手法』ピアソン・エデュケーション、2000。ISBN 489471275X
Kent Beck and Martin Fowler : Planning Extreme Programming , Addison–Wesley.ケント ベック (著), マーチン ファウラー (著), Kent Beck (原著), Martin Fowler (原著), 長瀬 嘉秀 (翻訳), 飯塚 麻理香 (翻訳)『XPエクストリーム・プログラミング実行計画』ピアソン・エデュケーション、2001。ISBN 978-4894713413
Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change, Second Edition , Addison–Wesley.KentBeck、CynthiaAndres(著)、角征典 (訳)『エクストリームプログラミング』オーム社、2015。ISBN 978-4-274-21762-3
Alistair Cockburn : Agile Software Development , Addison–Wesley.Martin Fowler : Refactoring: Improving the Design of Existing Code , Addison–Wesley.Martin Fowler (著), 児玉 公信 (翻訳), 友野 晶夫 (翻訳), 平澤 章 (翻訳), 梅澤 真史 (翻訳)『リファクタリング(第2版): 既存のコードを安全に改善する』オーム社、2019。ISBN 978-4274224546
Harvey Herela (2005). Case Study: The Chrysler Comprehensive Compensation System . Galen Lab, U.C. Irvine.Jim Highsmith . Agile Software Development Ecosystems , Addison–Wesley.Ron Jeffries , Ann Anderson and Chet Hendrickson (2000), Extreme Programming Installed , Addison–Wesley.ロン・ジェフリーズ (著), アン・アンダーソン (著), チェット・ヘンドリクソン (著), 平鍋 健児 (翻訳), 高嶋 優子 (翻訳), 藤本 聖 (翻訳)『XPエクストリーム・プログラミング導入編 ― XP実践の手引き』ピアソン・エデュケーション、2001。ISBN 978-4894714915
Craig Larman & V. Basili (2003). "Iterative and Incremental Development: A Brief History", Computer (IEEE Computer Society) 36 (6): 47–56.Matt Stephens and Doug Rosenberg (2003). Extreme Programming Refactored: The Case Against XP , Apress.Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225–256.
