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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

エクストリームプログラミングにおける計画とフィードバックのループ

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

エクストリームプログラミングの他の要素には、ペアプログラミングまたは広範なコードレビューの実行、すべてのコードの単体テスト、実際に必要になるまでプログラミング機能ではない、フラットな管理構造、コードの単純さと明確さ、時間の経過とともに顧客の要件の変化を期待することが含まれますそして問題はよりよく理解され、顧客やプログラマーの間で頻繁にコミュニケーションを取ります。[2] [3] [4]この方法論は、従来のソフトウェアエンジニアリング手法の有益な要素が「極端な」レベルにあるという考えにちなんで名付けられました。例として、コードレビュー有益な実践と見なされます。極端に言えば、コードは継続的にレビューできます(つまり、ペアプログラミングの実践)。

歴史

ケントベックは、クライスラー総合報酬システム(C3)の給与プロジェクトでの作業中にエクストリームプログラミングを開発しました[5]ベックは1996年3月にC3プロジェクトリーダーになりました。彼はプロジェクトで使用される開発方法論を改良し始め、方法論に関する本を書きました( Extreme Programming Explained、1999年10月発行)。[5] クライスラーは、ダイムラーベンツが会社を買収した7年後の2000年2月にC3プロジェクトをキャンセルした[6] ウォード・カニンガムは、XPに対するもう1つの大きな影響でした。

多くのエクストリームプログラミング手法がしばらく前から存在しています。この方法論では、「ベストプラクティス」を極端なレベルに引き上げます。たとえば、「各マイクロインクリメントの前にテストを最初に開発し、計画し、テストを作成する方法」は、1960年代初頭にNASAのプロジェクトマーキュリーで使用されました。[7]総開発時間を短縮するために、いくつかの正式なテスト文書(検収試験など))ソフトウェアがテストの準備ができているのと並行して(またはその少し前に)開発されました。NASAの独立したテストグループは、プログラマーがソフトウェアを作成してハードウェアと統合する前に、正式な要件と論理的な制限に基づいてテスト手順を作成できます。XPはこの概念を極限まで高め、より大きな機能をテストするだけでなく、ソフトウェアコーディングの小さなセクションの動作を検証する自動テスト(ソフトウェアモジュール内の場合もある)を作成します。

起源

1990年代のソフトウェア開発を形作った2つの主要な影響:

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

要件が急速に変化するため、製品のライフサイクルを短縮する必要があり、ソフトウェア開発の従来の方法と衝突することがよくありました。

Chrysler Comprehensive Compensation System(C3)は、Chryslerの給与システムを研究対象として、 Smalltalkを言語として、GemStoneデータアクセス層として使用して、オブジェクトテクノロジを使用する最良の方法を決定するために開始されましたChryslerは著名なSmalltalkプラクティショナーであるKent Beck [5]を招き、システムのパフォーマンスチューニングを行いましたが、開発プロセスに関するいくつかの問題に気付いたため、彼の役割は拡大しました。彼はこの機会を利用して、頻繁に協力しているウォード・カニンガムとの仕事に基づいて、開発慣行のいくつかの変更を提案し、実装しましたベックは、メソッドの初期の概念について説明しています。[8]

初めてチームを率いるように頼まれたとき、私は彼らに、テストやレビューなど、私が賢明だと思うことを少しするように頼みました。2回目は、さらに多くの回線がありました。「魚雷を酷評しなさい、少なくともこれは良い記事になるだろう」と私は思った[そして]私が不可欠だと思ったものについてすべてのノブを10に上げて、他のすべてを省くようにチームに頼んだ。

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

XPの背後にある原則と実践に関する情報は、元のwikiであるCunninghamのWikiWikiWebでの議論を通じて、より広い世界に広められましたさまざまな貢献者がアイデアについて話し合い、拡張し、いくつかのスピンオフ方法論が生まれました(アジャイルソフトウェア開発を参照)。また、XPの概念は[誰によって?]、数年間、1999年頃 のXP Webサイト(http://www.extremeprogramming.org )でハイパーテキストシステムマップを使用していました。

ベックは、彼自身のExtreme Programming Explained(1999、ISBN  0-201-61641-6)から始めて、XPに関する一連の本を編集し、彼のアイデアをはるかに多くの聴衆に広めました。シリーズの著者は、XPとその実践に参加するさまざまな側面を経験しました。シリーズには、実践に批判的な本が含まれていました。

現在の状態

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

元の慣行に必要な高い規律はしばしば道に迷い、硬すぎると考えられていたものなど、これらの慣行の一部は、個々のサイトで非推奨または削減されたり、未完成のままにされたりしました。たとえば、特定のプロジェクトの1日の終わりの統合テストの実施を週末のスケジュールに変更したり、単に相互に合意した日付のテストに減らしたりすることができます。このようなよりリラックスしたスケジュールは、一日の終わりのテストに合格するためだけに人工スタブを生成するために急いでいると感じる人々を避けることができます。厳密性の低いスケジュールでは、代わりに、数日間にわたって複雑な機能を開発できます。

一方、他のアジャイル開発プラクティスはまだ定着しておらず、2019年の時点で、XPは進化を続けており、フィールドでの経験からより多くの教訓を取り入れて、他のプラクティスを使用しています。エクストリームプログラミングの説明の第2版(2004年11月)では、第1版から5年後、ベックはより多くの価値と実践を追加し、主要な実践と当然の実践を区別しました。

コンセプト

目標

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

XPは、長い開発サイクルではなく、複数の短い開発サイクルを使用することで、要件の変更のコストを削減しようとします。この教義では、変更はソフトウェア開発プロジェクトの自然で避けられない望ましい側面であり、安定した一連の要件を定義しようとするのではなく、計画する必要があります。

エクストリームプログラミングはまた、アジャイルプログラミングフレームワークに加えて、いくつかの基本的な価値観、原則、実践を紹介します。

アクティビティ

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

コーディング

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

コーディングを使用して、最適なソリューションを見つけることができます。コーディングは、プログラミングの問題についての考えを伝えるのにも役立ちます。複雑なプログラミングの問題を扱っているプログラマー、または他のプログラマーに解決策を説明するのが難しいと感じているプログラマーは、単純化された方法でそれをコーディングし、そのコードを使用してそれらの意味を示すことができます。この立場の支持者によると、コードは常に明確で簡潔であり、複数の方法で解釈することはできません。他のプログラマーは、自分の考えをコーディングすることで、このコードに関するフィードバックを提供できます。

テスト

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

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

システム全体の統合テストは、最初は、互換性のないインターフェイスを早期に検出するための毎日の終わりのアクティビティとして、個別のセクションがコヒーレント機能から大きく逸脱する前に再接続することが推奨されていました。ただし、システム全体の統合テストは、システム内のインターフェイス全体の安定性に応じて、毎週、またはそれより少ない頻度に削減されています。[要出典]

聞く

プログラマーは、顧客がシステムに何をする必要があるのか​​、どのような「ビジネスロジック」が必要なのかを聞く必要があります。問題を解決する方法、または解決できない方法の技術的側面について顧客にフィードバックを提供するために、これらのニーズを十分に理解する必要があります。顧客とプログラマーの間のコミュニケーションは、計画ゲームでさらに取り上げられます。

デザイン

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

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

コミュニケーション

ソフトウェアシステムを構築するには、システムの開発者にシステム要件を伝える必要があります。正式なソフトウェア開発方法論では、このタスクはドキュメントを通じて実行されます。エクストリームプログラミング技術は、開発チームのメンバー間で制度的知識を迅速に構築および普及するための方法と見なすことができます。目標は、すべての開発者に、システムのユーザーが保持するビューと一致するシステムの共有ビューを提供することです。この目的のために、エクストリームプログラミングは、単純な設計、一般的な比喩、ユーザーとプログラマーのコラボレーション、頻繁な口頭でのコミュニケーション、およびフィードバックを支持します。

シンプルさ

エクストリームプログラミングは、最も単純なソリューションから始めることをお勧めします。その後、追加機能を追加できます。このアプローチと従来のシステム開発方法との違いは、明日、来週、または来月のニーズではなく、今日のニーズに合わせた設計とコーディングに重点を置いていることです。これは、「あなたはそれを必要としない」(YAGNI)アプローチとして要約されることがあります。[10]XPの支持者は、これにより、システムを変更するために明日より多くの労力が必要になる場合があるという欠点を認識しています。彼らの主張は、これは、関連する前に変更される可能性のある将来の要件に投資しないという利点によって十分に補われるというものです。不確実な将来の要件に対応するためのコーディングと設計は、重要な機能を遅らせる一方で、必要とされない可能性のあるものにリソースを費やすリスクを意味します。「コミュニケーション」の価値に関連して、設計とコーディングの単純さはコミュニケーションの質を改善するはずです。非常に単純なコードを使用した単純な設計は、チーム内のほとんどのプログラマーが簡単に理解できます。

フィードバック

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

  • システムからのフィードバック:単体テスト[5]を作成するか、定期的な統合テストを実行することにより、プログラマーは変更を実装した後、システムの状態から直接フィードバックを得ることができます。
  • 顧客からのフィードバック:機能テスト(別名受け入れテスト)は、顧客とテスターに​​よって作成されます。彼らは彼らのシステムの現在の状態について具体的なフィードバックを得るでしょう。このレビューは2、3週間に1回計画されているため、お客様は開発を簡単に進めることができます。
  • チームからのフィードバック:顧客が計画ゲームで新しい要件を考え出すと、チームは実装にかかる時間の見積もりを直接提供します。

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

勇気

いくつかの実践は勇気を体現しています。1つは、明日ではなく、今日のために常に設計とコーディングを行うという戒めです。これは、設計に行き詰まり、他の何かを実装するために多くの労力を必要としないようにするための取り組みです。勇気により、開発者は必要に応じてコードをリファクタリングすることに慣れることができます。[5]これは、既存のシステムをレビューし、将来の変更をより簡単に実装できるように変更することを意味します。勇気のもう1つの例は、コードをいつ破棄するかを知ることです。つまり、ソースコードの作成にどれだけの労力が費やされたとしても、廃止されたソースコードを削除する勇気です。また、勇気は永続性を意味します。プログラマーは、複雑な問題に1日中立ち往生し、翌日、問題を迅速に解決する可能性がありますが、それは永続的である場合に限られます。

尊重

尊敬の価値には、他者への敬意と自尊心が含まれます。プログラマーは、コンパイルを中断したり、既存の単体テストを失敗させたり、ピアの作業を遅らせたりするような変更をコミットしてはなりません。メンバーは、常に高品質を追求し、リファクタリングを通じて手元のソリューションに最適な設計を探すことで、自分の仕事を尊重します。

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

ルール

XPのルールの最初のバージョンは、1999年にDon Wells [12]によってXPWebサイトで公開されました。計画、管理、設計、コーディング、およびテストのカテゴリに29のルールがあります。XPがこれらのアクティビティをサポートしていないという主張に対抗するために、計画、管理、および設計が明示的に呼び出されます。

XPルールの別のバージョンがXP / Agile Universe2003でKenAuer [13]によって提案されました。彼は、XPはその慣行ではなく、そのルールによって定義されていると感じました(より多くのバリエーションとあいまいさの影響を受けます)。彼は2つのカテゴリを定義しました。ソフトウェア開発を効果的に行うことができる環境を規定する「エンゲージメントのルール」と、エンゲージメントのルールのフレームワーク内で分ごとのアクティビティとルールを定義する「プレイのルール」です。

いくつかのルール(不完全)は次のとおりです。

コーディング

  • お客様はいつでもご利用いただけます
  • 最初に単体テストをコーディングします
  • 一度に1つのペアのみがコードを統合します
  • 最後まで最適化を残す
  • 残業なし

テスト

原則

XPの基礎を形成する原則は、今説明した値に基づいており、システム開発プロジェクトでの意思決定を促進することを目的としています。原則は、値よりも具体的であり、実際の状況でガイダンスに簡単に変換されることを目的としています。

フィードバック

エクストリームプログラミングは、フィードバックが頻繁かつ迅速に行われる場合に最も役立つと考えています。アクションとそのフィードバックの間の最小限の遅延が、学習と変更を行うために重要であることを強調しています。従来のシステム開発方法とは異なり、顧客との接触はより頻繁に繰り返されます。お客様は、開発中のシステムについて明確な洞察を持っており、必要に応じてフィードバックを提供し、開発を進めることができます。顧客からの頻繁なフィードバックにより、開発者が実装に多くの時間を費やす前に、開発者が行った誤った設計決定にすぐに気づき、修正されます。

ユニットテストは、迅速なフィードバックの原則に貢献します。コードを書くとき、単体テストを実行すると、システムが加えられた変更にどのように反応するかについて直接フィードバックが提供されます。これには、開発者のコ​​ードをテストする単体テストの実行だけでなく、単一のコマンドで開始できる自動化されたプロセスを使用して、すべてのソフトウェアに対してすべての単体テストを実行することも含まれます。そうすれば、開発者の変更により、開発者がほとんどまたはまったく知らないシステムの他の部分で障害が発生した場合、自動化された全ユニットテストスイートはすぐに障害を明らかにし、開発者に変更の非互換性を警告します。システムの他の部分、およびそれらの変更を削除または変更する必要性。従来の開発慣行では、自動化された、包括的なユニットテストスイートは、開発者が無害であると想定したこのようなコード変更がそのまま残され、統合テスト中にのみ、さらに悪いことに、本番環境でのみ表示されることを意味しました。統合テストの数週間前または数か月前にすべての開発者が行ったすべての変更の中で、どのコード変更が問題を引き起こしたかを判断することは、手ごわい作業でした。

単純さを仮定して

これは、すべての問題をその解決策が「非常に単純」であるかのように扱うことです。従来のシステム開発方法では、将来の計画を立て、再利用性をコード化するように言われています。エクストリームプログラミングはこれらのアイデアを拒否します。

エクストリームプログラミングの支持者は、一度に大きな変更を加えることは機能しないと言います。エクストリームプログラミングは段階的な変更を適用します。たとえば、システムには3週間ごとに小さなリリースがある場合があります。多くの小さなステップが行われると、顧客は開発プロセスと開発中のシステムをより細かく制御できます。

変化を受け入れる

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

練習

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

細かいフィードバック

連続処理

理解の共有

プログラマー福祉

物議を醸す側面

XPでの実践は、激しく議論されてきました。[5]エクストリームプログラミングの支持者は、オンサイトの顧客[5]に非公式に変更を要求させることにより、プロセスが柔軟になり、正式なオーバーヘッドのコストを節約できると主張しています。XPの批評家は、これがコストのかかるやり直しにつながる可能性があり、プロジェクトの範囲が以前に合意または資金提供されたものを超えてクリープする可能性があると主張しています。[要出典]

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

エクストリームプログラミングの他の潜在的に物議を醸す側面は次のとおりです。

  • 要件は、仕様書ではなく、自動化された受け入れテストとして表されます。
  • 要件は、すべてを事前に取得しようとするのではなく、段階的に定義されます。
  • ソフトウェア開発者は通常、ペアで作業する必要があります。
  • 事前の大きな設計はありません設計作業のほとんどは、その場で段階的に行われ、「おそらく機能する可能性のある最も単純なもの」であり、テストに失敗して必要な場合にのみ複雑さを追加します。批評家はこれを「システムを外観にデバッグする」と比較し、要件が変更された場合にのみ再設計するよりも多くの再設計作業が発生することを恐れています。
  • 顧客担当者プロジェクトに所属しています。この役割は、プロジェクトの単一障害点になる可能性があり、一部の人々はそれがストレスの原因であることに気づきました。また、技術的なソフトウェア機能とアーキテクチャの使用を指示しようとする非技術的な代表者によるマイクロ管理の危険性があります。

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

スケーラビリティ

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

2004年に、XPの進化形として産業用エクストリームプログラミング(IXP) [15]が導入されました。これは、大規模で分散したチームで作業できるようにすることを目的としています。現在、23のプラクティスと柔軟な価値があります。

可分性と応答

2003年、MattStephensとDougRosenbergは、 Extreme Programming Refactored:The Case Against XPを公開しました。これは、XPプロセスの価値に疑問を投げかけ、それを改善する方法を提案しました。[6]これは、記事、インターネットニュースグループ、およびWebサイトのチャットエリアで長い議論を引き起こしました。この本の核となる議論は、XPの慣行は相互に依存しているが、すべての慣行を採用する意思がある/できる組織はほとんどないということです。したがって、プロセス全体が失敗します。この本は他の批判も行っており、XPの「集団所有権」モデルを社会主義に否定的に似せています。

エクストリームプログラミングリファクタリングの公開以降、XPの特定の側面が変更されました特に、XPは、必要な目的がまだ満たされている限り、プラクティスの変更に対応するようになりました。XPはまた、プロセスに対してますます一般的な用語を使用しています。これらの変更は以前の批判を無効にするという主張もあります。他の人は、これは単にプロセスを弱体化させていると主張しています。

他の著者は、統一された方法論を形成するために、XPを古い方法論と調和させようとしました。ウォーターフォール手法など、これらのXPの一部は置き換えようとしました例:プロジェクトのライフサイクル:ウォーターフォール、Rapid Application Development(RAD)など。JPMorgan Chase&Co。は、XPを能力成熟度モデル統合(CMMI)のコンピュータープログラミング手法およびシックスシグマと組み合わせてみました。彼らは、3つのシステムがお互いをうまく強化し、より良い開発につながり、相互に矛盾しないことを発見しました。[16]

批評

ペアプログラミング継続的設計などのエクストリームプログラミングの初期の話題と物議を醸す信条は、McBreen [17]やBoehmand Turner [18] MattStephensやDougRosenbergなどからの批判を集めています。[19]しかしながら、批判の多くは、アジャイル実践者によってアジャイル開発の誤解であると信じられています。[20]

特に、エクストリームプログラミングは、MattStephensとDougRosenbergのExtremeProgramming Refactoredによってレビューされ、批評されています。[6]

も参照してください

参考文献

  1. ^ 「人間中心の技術ワークショップ2006」、2006年、PDF、人間中心の技術ワークショップ2006
  2. ^ a b UPenn-Lectures-design-patterns "Design Patterns and Refactoring"、ペンシルベニア大学、2003年
  3. ^ a bUSFCA -edu-601-講義エクストリームプログラミング
  4. ^ 「アジャイルソフトウェア開発のためのマニフェスト」Agilemanifesto.org。2001 2019年3月26日取得
  5. ^ a b c d e f g h i j k l m Computerworld-appdev-92 "Extreme Programming"、Computerworld(online)、2001年12月
  6. ^ a b c Rosenberg、Doug; スティーブンス、マット(2003)。リファクタリングされたエクストリームプログラミング:XPに対するケース押してください。ISBN 978-1-59059-096-6
  7. ^ ラーマン2003
  8. ^ ケントベックとマーティンファウラーへのインタビューinformit.com2001年3月23日。
  9. ^ リサクリスピン; チップハウス(2003)。エクストリームプログラミングのテストISBN 9780321113559
  10. ^ ClairTristram による「Everyone'saProgrammer」。 テクノロジーレビュー、2003年11月。p。39。
  11. ^ ベック、K。(1999)。極端なプログラミングの説明:変化を受け入れる。アディソン-ウェスリー。ISBN 978-0-321-27865-4
  12. ^ 「エクストリームプログラミングルール」Extremeprogramming.org
  13. ^ Ken Auer は、2008年9月20日、 WaybackMachineでアーカイブされました
  14. ^ ジョンキャロル; デビッドモリス(2015年7月29日)。簡単なステップでのアジャイルプロジェクト管理、第2版簡単な手順で。p。162. ISBN 978-1-84078-703-0
  15. ^ カッターコンソーシアム。「インダストリアルXP:大規模な組織でXPを機能させる-カッターコンソーシアム」カッター.com
  16. ^ エクストリームプログラミング(XP)シックスシグマCMMI
  17. ^ McBreen、P。(2003)。エクストリームプログラミングに疑問を投げかける。マサチューセッツ州ボストン:アディソン-ウェスリー。ISBN 978-0-201-84457-3
  18. ^ ベーム、B。; R.ターナー(2004)。敏捷性と規律のバランスをとる:困惑した人のためのガイドマサチューセッツ州ボストン:アディソン-ウェスリー。ISBN 978-0-321-18612-6
  19. ^ スティーブンス、マット; ダグ・ローゼンバーグ(2004)。エクストリームプログラミングの皮肉MA:ドブス博士のジャーナル。
  20. ^ sdmagazine 2006年3月16日、 WaybackMachineでアーカイブ

さらに読む

  • ケンアウアーとロイミラー。エクストリームプログラミングの適用:Playing To Win、Addison–Wesley。
  • ケンアウアー; ロン・ジェフリーズ; ジェフ・カンナ; グレンB.アレマン; リサクリスピン; ジャネットグレゴリー(2002)。「テスターは絶滅していますか?テスターはどのようにXPチームに貢献できますか?」エクストリームプログラミングとアジャイル手法— XP /アジャイルユニバース2002コンピュータサイエンスの講義ノート。2418.Springer-Verlag。p。287. doi10.1007 / 3-540-45672-4_50
  • Kent BeckExtreme Programming Explained:Embrace Change、Addison–Wesley。初版、1999年。第2版、シンシア・アンドレス、2004年。
  • ケントベックマーティンファウラーエクストリームプログラミングの計画、アディソン-ウェスリー。
  • Alistair Cockburnアジャイルソフトウェア開発、Addison–Wesley。
  • Martin Fowlerリファクタリング:既存のコードの設計の改善。KentBeck、John Brant、William Opdyke、およびDon Roberts(1999)とともに。アディソン-ウェスリー。
  • ハーベイヘレラ(2005)。ケーススタディ:クライスラー総合報酬システムガレンラボ、カリフォルニア大学アーバイン校。
  • ジムハイスミスアジャイルソフトウェア開発エコシステム、Addison–Wesley。
  • Ron Jeffries、Ann Anderson and Chet Hendrickson(2000)、Extreme Programming Installed、Addison–Wesley。
  • Craig Larman&V。Basili(2003)「反復型およびインクリメンタル開発:簡単な歴史」、Computer(IEEE Computer Society)36(6):47–56。
  • マットスティーブンスとダグローゼンバーグ(2003)。エクストリームプログラミングのリファクタリング:XPに対するケース、Apress。
  • Waldner、JB。(2008)。「ナノコンピューターと群知能」。In:ISTE、225〜256。

外部リンク