Kent Beckらによって提唱されているソフトウェア開発プロセス(工程)です． 正式には eXtreme Programming ，略してエックスピー(XP)と呼ばれます．

開発リスクを早期に軽減することを主眼におき，繰り返し型 (iterative)の開発を取り入れている点は，RUP(Rational Unified Process) な どのオブジェクト指向プロセスと同じです．ただし，次の点が XP の大きな特徴です．

• 開発の中でコーディングおよびテストという工程に特に重点を置いている
• 初期設計よりもリファクタリングによる再設計を重視している
• すぐにでも始められるライトウェイトな方法論である
• 明確な言葉で XP を行うための「12のプラクティス」が示されている

そして何より，「プログラマは人間である」という温かな視点による思想 が全体を通して流れていること，これがエクストリームプログラミングの人気 の秘密だと私は思っています．

XP は 12のプラクティスを示しています．プラクティス(practice)とは， 経験に基づいて有用性が立証された実践項目のことです．以下が，その 12のプラクティスです(要約 by 上手)．

• 計画ゲーム(The Planning Game)
  ビジネス優先度と技術的見積により次回リリースの範囲を早急に決 める。現実が計画と変わったら、計画を更新する。
  
• 小規模リリース(Small Releases)
  シンプルなシステムを早急に生産に投入する、それから新バージョン を非常に短いサイクルでリリースしていく。
  
• 比喩(Metaphor)
  どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)を メンバーが共有することで全ての開発を導く（ガイドする）。
  
• シンプルデザイン(Simple Design)
  いつでもシステムは出来る限りシンプルに設計されるべきだ。余分 な複雑さは見つけ次第取り除かれる。
  
• テスティング(Testing)
  プログラマは継続的にユニットテストを書く、それは開発を続けるために 完全に動かなければならない。顧客は、機能の開発が終わったことを 示す機能テストを書く。
  
• リファクタリング(Refactoring)
  ２重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性 を加えるために、プログラマは、システムの動作を換えることなくシステ ムを再構成する。
  
• ペアプログラミング(Pair Programming)
  全てのコードは２人のプログラマにより一台のマシンで書かれる。
  
• 共同所有権(Collective Ownership)
  誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修 正できる。
  
• 継続的インテグレーション(Continuous Integration)
  システムを一日に何回もインテグレードしビルドし、テスト を 100% パスさせる．
  
• 週40時間(40-Hour Week)
  週４０時間以上仕事をしてはいけないのがルール。
  
• オンサイト顧客(On-Site Customer)
  現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。
  
• コーディング標準(Coding Standards)
  プログラマは、コーディング標準に従って全てのコードを書く。

1つのイメージを思い浮かべてください．グラフィックエコライザーのように， たくさんの調節用のスライドバーが着いたパネルがあります．1つ1つのバーには， ソフトウェアプロジェクトに必要な実践項目が書かれています． 例えば，伝統的な項目としては「設計レビュー」や「単体テスト」 のようなものを思い浮かべるとよいでしょう．

XP では，いくつものバーの中で12のプラクティスのバーだけを ボリューム10にまで上げた状態をイメージしています．

Kent Beck は，この状態で行われるプロジェクトが安定していてかつ 生産性の高いものだということを発見し，この名前を付けました．

XP の父と呼ばれる資格がある人が3人います． Ward Cunningham, Kent Beck, Ron Jeffries です．彼らは Three Extremos とも呼ばれる ことがあります．

WardとKentの2人は，ソフトウェアパターンの開祖となる 一派でもあります．Kent は 1987年にSmalltalkでユーザインター フェイスの設計を行った時に，建築家 C.Alexanderの 「パターン言語」 のアイディアをはじめてソフトウェアに取り入れ， OOPSLA'87で "Using Pattern Languages for Object-Oriented Programs" として発表しています．また，Ward は PLoP(Pattern Language of Programming) の父とも呼ばれ， PLoP'94の議長を務めています．2人は，Hillside Group を生み出しました． Ward が書いたパターン言語である "EPISODES: A Pattern Language of Competitive Development には，XP 的な考え方の萌芽がみられます． Ward と Kent の2人はパターンコミュニティで大きな役割を果たしています．

Ron は，Kent に招かれて最初の XP プロジェクトである伝説の C3プロジェクト(Crysler payroll project)に参加しました． このプロジェクトには， Martin Fowler も参加しています． そのプロジェクトで Kent は Smalltalk, パターンの経験を 活かしながら，初めて12のプラクティスバーを10にまで上げることを試しました． Ron の実践を通して XP は形あるものへとなったのです．

Kent は'99に "Extreme Programming Explained - Embrace Change" という最初のXPの本を書き，12のプラクティスを示しました．この本を， 以下"EC本"と呼びます．

Marin Fowler が'99に "Refactoring" を著しましたが，これはXP の12のプラクティスの1つとしてXPを支える中核であると同時に，XPの 実プロジェクトの中で実践され，収集されて初めて効果が 立証されたと言えます．

また，Ron は 2000に "Extreme Programming Installed" を著し，実践的なXP 導入法を書いています．

Kent Beck が EC本 を書く以前に，Ron Jeffries が C3 プロジェクトでの XP の経験を 'XPractices'と してまとめています．そこでは多くのプラクティスが，いきいきとした文章で まとめられています．エクスプラクティスは，ここで参照可能です．

• 英語オリジナル

時間を横軸に，ソフトウェアの変更にかかるコストを縦軸にプロットします． この「時間-変更コスト」曲線は極端な右上がりになると信じられています．

現在までのソフトウェア開発プロセスは，この仮定上の議論が多数でした． XP はこの問題に立ち向かう1つの回答を示して行こうとしています． この曲線を平坦にできるのではないか， またそうできたら全く違った方針でプロジェクトに 立ち向かえるのではないか，と考えています．

「変化ヲ抱擁セヨ(Embrace Change)」とは，変化を嫌うのではなく 変化が起こることを自然なこととして受け入れよう， という XP の基本姿勢を表明しています．

Kent は，"Extream Programming Explained - Embrace Change" の中で，はじめて"EC"という言葉を"Embrace Change"として使いました．

Kent は，はじめて自動車を運転する練習をした日のことを例にしています．

母を横に乗せ，ハンドルを握り... 最初はうまく行きました．でも， ちょっと油断した瞬間，車は車道を外れて砂利に突っ込んでしまいました． 母は車を道に戻すと，初めて運転とは何かを教えてくれました．

「運転で大切なのは，車を正しい方向に進めることじゃないのよ．大切 なのは，常に注意を払って細かく左右に方向修正していくことなの．」

XP の開発プロセスを以下に示します．

まず，「計画ゲーム」では，ユーザが書いたストーリーカードを 基にプランニングが行われます．そこでは， システムを表現する比喩(メタファー)が投入され， ユーザーストーリーは，プログラマが見積り可能なタスクに分割されます． これらから，リリース計画が決定されることになります． 「イテレーション」によって 実装，ユニットテストが行われ，継続的インテグレーションによって 最新バージョンが作成されます．最新バージョンに対して機能テストが行われ， それを 100% パスすることで，小さなリリースにたどり着きます． 全過程で，フィードバックが行われること， また，サイクルが非常に短いことが，XP の特徴です． 1イテレーションは1～4週間．継続的インテグレーションと機能テスト は少くとも日に1度です．XP ではこのリズムを大切にしています．

Addison-Wesley から，「XP Series」が刊行されています． 日本では，ピアソンエデュケーションから翻訳が出ています． 以下のリンクは，amazon.co.jp へのアソシエイトリンクです．

XP では，リファクタリング(Refactoring)による再設計や 複数人によるコードの変更(Collective Ownership)をプラクティスの中に含 んでいます．これを支えているのは，ユニットテストを非常に 短いサイクルで行うことができる環境です． Eric Gamma と Kent Beck とは，このテスト環境を「テスティングフレームワーク」 呼び，JavaReport 1999 May に解説しています．

現在，さまざまな言語に対してこのユニットテストをサポートする ツールが発表されています．JUnit, CppUnit, VBUnit, RubyUnit, PalmUnit などです．

• テスティングフレームワーク論文 by Kent Beck
  http://www.xprogramming.com/testfram.htm
• テスティングフレームワークの日本語解説 by 石井勝
  http://homepage3.nifty.com/masarl/
• 各言語のテスティングフレームワーク
  http://www.xprogramming.com/software.htm
• Ruby のテスティングフレームワーク by 助田 雅紀
  http://homepage1.nifty.com/markey/ruby/rubyunit/rubyunit_j.html
• PythonUnitの紹介記事
  http://www.jp.ibm.com/developerworks/linux/pythonunit.html
• C++Builder 用テスティングフレームワーク by 中口
  http://www.kcat.zaq.ne.jp/takao/download/CppUnitCB_15.lzh
• VC++, Borland C++, Cygwin, Tornado 用 CppUnit by 伊東
  http://member.nifty.ne.jp/glad/cpp/test/ http://www.kcat.zaq.ne.jp/takao/download/CppUnitCB_15.lzh
• Palm 用テスティングフレームワーク by catoo
  http://www.geocities.co.jp/SiliconValley-SanJose/7344/PalmUnit/README.html
• C 言語用テスティングフレームワーク by おおむら
  http://www.ki.rim.or.jp/~omura/pub/