コンテンツにスキップ

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

出典: フリー百科事典『ウィキペディア（Wikipedia）』
エクストリーム・プログラミングの計画とフィードバックのループ
ソフトウェア開発工程
中心となる活動
パラダイムとモデル
ソフトウェア開発方法論とフレームワーク
開発支援
プラクティス
プログラミングツール
標準と機関
用語集

エクストリーム・プログラミング、XP（英: extreme programming）は、 ソフトウェア品質 を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。アジャイルソフトウェア開発の一つとして[1][2][3]、短い開発サイクルで頻繁に「リリース」することを推奨することで、生産性を向上させ、新しい顧客の要求を採用するためのチェックポイントを導入することを意図している。

エクストリーム・プログラミングの他の要素には、ペアでのプログラミングや広範なコードレビューの実施、すべてのコードのユニットテスト、機能は実際に必要となるまでは追加しない、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある[2][3][4]。この方法論は、伝統的なソフトウェアエンジニアリングのプラクティスの有益な要素を「極端な（エクストリームな）」レベルに持っていくという考えからその名前を取っている。例えば、コードレビューは有益なプラクティスと考えられており、これを極端にすれば、コードを「継続的」にレビューする、つまり、ペアプログラミングのプラクティスとなる。

歴史

[編集]

ケント・ベックは、クライスラー総合報酬システム（英語版）（C3）給与計算プロジェクトでの業務の中で、エクストリーム・プログラミングを開発した[5]。ケント・ベックは1996年3月にC3プロジェクトリーダーになった。彼はプロジェクトで使用された開発方法論を改良し始め、その方法論に関する本を書いた (エクストリームプログラミング, 1999年10月出版)[5]。クライスラーは7年後の2000年2月、ダイムラー・ベンツが同社を買収した際にC3プロジェクトをキャンセルした[6]。

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

起源

[編集]

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

急速に変化する要件は、製品のライフサイクルの短縮を要求し、しばしばソフトウェア開発の伝統的な方法と衝突した。

クライスラー総合報酬システム（C3）は、クライスラーの給与計算システムを研究対象とし、言語としてSmalltalk、データアクセス層（英語版）としてGemstoneを用いて、オブジェクト技術の最善の利用方法を見極めるために始まった。 クライスラーは、システムのパフォーマンスチューニング（英語版）のために、著名なSmalltalk実践者であるケント・ベックを招き入れた[5]が、開発プロセスに関するいくつかの問題点を指摘したことで、彼の役割は拡大した。 彼はこの機会を利用して、開発プラクティスのいくつかの変更 -親しい共同研究者であるウォード・カニンガムとの業績に基づいたもの- を提案および実施した。 ケント・ベックは、手法の初期のコンセプトの説明を残している[8]:

初めてチームのリーダーを任された時に、テストやレビューなど、私が理にかなっていると思ったことを少しだけやってもらいました。2回目はもっとたくさんのことをやってもらいました。私は、「機雷にかまうな、少なくともこれは良いシステムになるぞ」と考え、[そして]チームに、私が必要不可欠だと思うこと全てのツマミを10に上げ、それ以外はすべて省いてくれと求めました。

ケント・ベックは、これらの方法の開発と改良の支援のために、ロン・ジェフリーズ（英語版）をプロジェクトに招いた。 ロン・ジェフリーズはその後、C3チームに習慣としてのプラクティスを浸透させるためのコーチを務めた。

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]。 XPの支持者は、これが、システムの変更に明日より多くの努力を必要とすることがあるという欠点を認めている; 彼らの主張は、関係が生まれる前に変更される可能性のある将来の要件に投資しないという利点によって、これは十分に補償されるということだ。 将来の不確実な要件を考慮してコーディングや設計をすることは、必要ではないかもしれないものにリソースを費やすリスクを意味し、重要な機能を遅らせてしまう可能性がある。 「コミュニケーション」の価値に関連して、設計とコーディングのシンプルさは、コミュニケーションの質を向上させるはずである。 非常にシンプルなコードによるシンプルな設計は、チーム内のほとんどのプログラマーが簡単に理解できる。

フィードバック

[編集]

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

  • システムからのフィードバック: ユニットテストを書いたり[5]、定期的に統合テストを実行することで、プログラマーは、変更した後にシステムの状態から直接フィードバックを得ることができる。
  • 顧客からのフィードバック: 機能テスト（別名：(受け入れテスト）は、顧客とテスターが作成する。彼らは、システムの現状について具体的なフィードバックを得られる。このレビューを2～3週間に1回のペースで計画することで、顧客は容易に開発の舵取りができる。
  • チームからのフィードバック: 顧客が計画ゲームで新しい要求を出すと、チームは直接、実装にかかる時間を見積もる。

フィードバックは、コミュニケーションとシンプルさに密接に関係している。 システムの欠陥は、特定のコードが壊れることを証明するユニットテストを書くことで簡単に伝達される。 システムからの直接のフィードバックは、プログラマーにこの部分を再コーディングするように伝える。 顧客は、ユーザーストーリー[5]として知られる機能要件に従って、定期的にシステムをテストすることができる。 ケント・ベックを引用すると、「楽観主義はプログラミングの職業上の危険である。フィードバックが治療法である。」[12]

勇気

[編集]

いくつかのプラクティスは勇気を体現している。 1つは、明日のためではなく、常に今日のために設計とコーディングをするという戒めである。 これは、設計の行き詰まりを避け、余計なものを実装するために費やす多くの労力を回避するための取り組みである。 勇気により、開発者は必要に応じてコードのリファクタリングを快適に行える[5]。 つまり、既存のシステムを見直し、将来の変更をより簡単に実装できるようにする。 勇気のもう一つの例は、コードを捨てるタイミングを知ることだ: そのソースコードを作成するためにどれだけの労力が費やされていたとしても、陳腐化したソースコードを削除する勇気である。 また、勇気とは永続性を意味する: プログラマーは複雑な問題に一日中悩まされても、翌日にはすぐに問題を解決しているかもしれない。だが、それは永続性がある場合に限られる。

リスペクト

[編集]

リスペクトの価値には、自尊心だけでなく、他者への尊敬も含まれる。 プログラマは、コンパイルを中断させたり、既存のユニットテストを失敗させたり、仲間の作業を遅らせたりするような変更をコミットしてはならない。 チームメンバーは、常に高品質を目指し、リファクタリングを通して目の前の解決策に対して最善の設計を追求することで、自分の仕事を尊重する。

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

ルール

[編集]

XPのルールの最初のバージョンは、1999年にドン・ウェルズ[13] によってXPのウェブサイトで公開された。 29のルールが、計画、管理、設計、コーディング、およびテストのカテゴリで提供されている。 計画、管理、設計は、XPがこれらの活動をサポートしていないという文句に対抗するために、明示的に書き出されている。

XPのルールの別バージョンは、ケン・アウアー[14]によってXP/Agile Universe 2003で提案された。 彼は、XPはそのルールによって定義されるのであり、そのプラクティス（より多くのバリエーションがあり、あいまいさにさらされる）ではないと感じていた。 彼は2つのカテゴリーを定義した: ソフトウェア開発が効果的に行われる環境を規定する "交戦規定(Rules of Engagement)"と、 交戦規定の枠組みの中での分刻みのアクティビティとルールを定義する "ルールズ・オブ・プレイ(Rules of Play)"である。

以下、ルールの一部を示す（不完全）:

コーディング

テスト

  • 全てのコードは、ユニットテストを持つ
  • 全てのコードは、リリース前にすべてのユニットテストを通す
  • バグがあれば、バグを調べる前にテストを書く(バグとは、ロジック内の誤りではない; 書かれていないテストである)
  • 受け入れテストは頻繁に実行され、結果は公開される

原則

[編集]

XPの基礎となる原則は、先ほど説明した価値観に基づいており、システム開発プロジェクトにおける意思決定を促進することを目的としている。 原則は、価値よりも具体的で、より実践的な状況でのガイドラインに変換しやすいことを目指している。

フィードバック

[編集]

エクストリーム・プログラミングでは、フィードバックが頻繁かつ迅速に行われることが最も有用であると考えられている。 また、あるアクションとそのフィードバックの間の遅延を最小限に抑えることが、学習や変化をする上で非常に重要であると強調している。 伝統的なシステム開発手法とは異なり、顧客との接触がより頻繁に繰り返される。 顧客は開発中のシステムを明確に理解しており、必要に応じてフィードバックを与え、開発の舵取りをすることができる。 顧客からの頻繁なフィードバックがあれば、開発者が誤った設計決定をした場合でも、開発者がそれを実装するのに多くの時間を費やす前に、迅速に気付き、修正することができる。

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

シンプルさを前提に

[編集]

これは、すべての問題を、あたかもその解決策が「非常にシンプルである」かのように扱うことだ。 伝統的なシステム開発手法では、将来を見据えた計画を立て、再利用性を考慮したコーディングを行うように言われてきたが、エクストリーム・プログラミングはこれらの考え方を否定する。

エクストリーム・プログラミングの支持者は、一度に大きな変更を加えてもうまくいかないと言う。 エクストリーム・プログラミングでは、漸進的な変更を適用する: 例えば、システムは3週間ごとに小さなリリースを行うかもしれない。 多くの小さな段階が作られると、顧客は開発プロセスと開発中のシステムをより詳細に制御できるようになる。

変化を受け入れる

[編集]

変化を受け入れるという原則は、変化に逆らうのではなく、変化を受け入れるということだ。 例えば、イテレーションでの会議の一つで顧客の要求が劇的に変化したことが判明したら、プログラマーはこれを受け入れ、次のイテレーションのために新しい要件の計画していく。

プラクティス

[編集]
→詳細は「エクストリーム・プログラミング プラクティス」を参照

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

詳細スケールフィードバック

[編集]

継続的プロセス

[編集]

共有理解

[編集]

プログラマーの福祉

[編集]

物議を醸している側面

[編集]

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

変更管理委員会は、プロジェクトの目的と複数のユーザー間の制約に潜在的な矛盾があることを示している。 XPの迅速な手法は、プログラマーが妥協した目的や制約の文書化ではなくコーディングに集中できるようにするのに、統一されたクライアント視点をプログラマー達が想定できるかどうかにある程度依存している[15]。 これは、複数のプログラミング組織、特にプロジェクトのシェアを競い合う組織にも当てはまる[要出典]。

他にも、エクストリーム・プログラミングの潜在的な議論の余地のある側面としては、以下のようなものがある:

  • 要件は、仕様書ではなく自動受け入れテストとして表現される。
  • 要件は、すべてを事前に取得しようとするのではなく、漸進的に定義される。
  • ソフトウェア開発者は通常、二人一組で作業することが求められる。
  • 事前の大規模設計（英語版）がない。ほとんどの設計作業は、「可能で最も単純なもの」から始まり、テストの失敗によって必要になった場合にのみ複雑さを追加することで、その場で漸進的に行われる。批評家はこれを「システムの外観をデバッグする」ことと比較し、要件が変更されたときだけ再設計するよりも、再設計の労力が増えることを危惧している。
  • プロジェクトに顧客担当者（英語版）が付き添う。この役割はプロジェクトの単一障害点になる可能性があり、それがストレスの原因になると気づいた者もいる。また、技術的なソフトウェアの機能やアーキテクチャの使用を指示しようとする非技術的な担当者によるマイクロマネジメントの危険もある。

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

スケーラビリティ

[編集]

ThoughtWorks（英語版）は、最大60人の分散型XPプロジェクトにおいて、それなりの成功を収めている[要出典]。

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

分離可能性と対応

[編集]

2003年に、マット・ステファン（英語版）とダグ・ローゼンバーグは、書籍『Extreme Programming Refactored：The Case Against XP』を出版した。 この本は、XPプロセスの価値に疑問を投げかけ、XPプロセスを改善する方法を提案している[6]。 これにより、記事、インターネットニュースグループ、およびWebサイトのチャット界隈で長い議論が起きた。 この本の核心的な議論は、XPのプラクティスは相互に依存しているが、すべてのプラクティスを採用しようとする意志がある/可能な実際的な組織はほとんどないというものであり、したがって、プロセス全体が失敗するというものである。 また、本書は他の批判も行っており、XPの「集団所有」モデルを社会主義に例え否定的に描いている。

XPのある側面は『Extreme Programming Refactored』の出版以降、変化している; 特に、XPは現在、必要な目標が満たされているのであれば、プラクティスの変更を受け入れている。 XPはまた、プロセスに一般的な用語を使うようになってきている。 これらの変更により以前の批判は無効であると主張する人もいれば、これは単にプロセスを骨抜きにしているだけだという意見もある。

他の著者は、統一された方法論を形成するために、古い方法論とXPを調和させることを試みた。 これらのXPのいくつかは、 ウォーターフォール・モデルのような、置き換えを求めていた: 例: プロジェクトのライフサイクル: ウォーターフォール、高速アプリケーション開発(RAD)、およびそのすべて。 JPモルガン・チェースは、能力成熟度モデル統合(CMMI)およびシックス・シグマのコンピュータプログラミングの方法とXPを組み合わせてみた。 彼らは、3つのシステムが互いをよく補強し、よりよい開発をもたらし、相互に矛盾しなかったことを見つけた[17]。

批判

[編集]

エクストリーム・プログラミングの初期の話題性と、ペアプログラミングや継続的設計（英語版）などの論争の的になっている教義は、 マクブリーン[18] ベームとターナー[19]、 マット・ステファンとダグ・ローゼンバーグ[20] などからの批判を集めている。 しかし、批判の多くは、アジャイルの実践者によって、アジャイル開発への無理解であると信じられている [21]。

とりわけ、エクストリーム・プログラミングは、マット・ステファンとダグ・ローゼンバーグの書籍『Extreme Programming Refactored』で考察と批判がされている[6]。

批判には次のようなものがある:

  • 方法論が人によりけり、アジャイルはこれを解決していない[要出典]
  • 成果物を定義しないことで顧客からお金を垂れ流すための手段としてよく使用される [要出典]
  • 構造と必要な文書の欠如 [要出典]
  • 上級レベルの開発者のみに作用する[要出典]
  • 不十分なソフトウェア設計を包含している[要出典]
  • 顧客は莫大な費用をかけて頻繁に会議をする必要がある[要出典]
  • 採用するにはあまりにも多くの文化的変化が必要[要出典]
  • より困難な契約交渉につながる可能性がある[要出典]
  • 非常に非効率になる可能性がある: コードのある領域の要件が多くの反復によって変化する場合、同じプログラミングを数回繰り返す必要があるかもしれない。一方、計画にあってそれに従うのであれば、コードの1つの領域は1回しか記述されないことが期待される[要出典]
  • プロジェクトの開始時には、誰も全体のスコープ/要件を知らないので、見積もりを出すのに必要な労力の現実的な見積もりを作ることは不可能[要出典]
  • 詳細な要件文書がないため、スコープ・クリープのリスクを増大させる可能性がある[要出典]

アジャイルは機能駆動型である: 非機能的な品質属性をユーザーストーリーとして表現するのが困難[要出典]

関連項目

[編集]

参照

[編集]
  1. ^ "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006
  2. ^ a b UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003.
  3. ^ a b USFCA-edu-601-lecture Extreme Programming.
  4. ^ “Manifesto for Agile Software Development”. 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), December 2001
  6. ^ a b c Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6. https://archive.org/details/extremeprogrammi00matt 
  7. ^ Larman 2003.
  8. ^ Interview with Kent Beck and Martin Fowler. (2001-03-23). http://www.informit.com/articles/article.aspx?p=20972 
  9. ^ 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. pp. 1–10. doi:10.1145/2961111.2962590. ISBN 9781450344272. https://www.researchgate.net/publication/304014117 
  10. ^ Lisa Crispin; Tip House (2003). Testing Extreme Programming. ISBN 9780321113559 
  11. ^ "Everyone's a Programmer" by Clair Tristram. Technology Review, November 2003. p. 39.
  12. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 978-0-321-27865-4 
  13. ^ “Extreme Programming Rules”. extremeprogramming.org. 2019年3月26日閲覧。
  14. ^ Ken Auer Archived September 20, 2008, at the Wayback Machine.
  15. ^ John Carroll; David Morris (July 29, 2015). Agile Project Management in easy steps, 2nd edition. In Easy Steps. p. 162. ISBN 978-1-84078-703-0. https://books.google.com/books?id=oqFKCgAAQBAJ&pg=PT162 
  16. ^ Cutter Consortium. “Industrial XP: Making XP Work in Large Organizations - Cutter Consortium”. cutter.com. 2019年3月26日閲覧。
  17. ^ Extreme Programming (XP) Six Sigma CMMI.
  18. ^ McBreen, P. (2003). Questioning Extreme Programming. Boston, MA: Addison-Wesley. ISBN 978-0-201-84457-3 
  19. ^ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6 
  20. ^ Stephens, Matt; Doug Rosenberg (2004). The irony of extreme programming. MA: Dr Dobbs journal. http://www.drdobbs.com/the-irony-of-extreme-programming/184405651 
  21. ^ 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.

外部リンク

[編集]
ウィキメディア・コモンズには、エクストリーム・プログラミングに関連するカテゴリがあります。
ウィキクォートにエクストリーム・プログラミングに関する引用句集があります。
「https://ja.wikipedia.org/w/index.php?title=エクストリーム・プログラミング&oldid=96883670」から取得