エクストリーム・プログラミング
エクストリーム・プログラミング、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]:
ケント・ベックは、これらの方法の開発と改良の支援のために、ロン・ジェフリーズをプロジェクトに招いた。 ロン・ジェフリーズはその後、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]として知られる機能要件に従って、定期的にシステムをテストすることができる。 ケント・ベックを引用すると、「楽観主義はプログラミングの職業上の危険である。フィードバックが治療法である。」[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]。 批判には次のようなものがある:
アジャイルは機能駆動型である: 非機能的な品質属性をユーザーストーリーとして表現するのが困難[要出典] 関連項目
参照
参考文献
外部リンク
|
Portal di Ensiklopedia Dunia
