Loading article…
エクストリームプログラミング（XP）は、ソフトウェアの品質と変化する顧客要求への対応力を向上させることを目的としたソフトウェア開発手法です。アジャイルソフトウェア開発の一種として、[ 1 ] [ 2 ] [ 3 ]生産性を向上させ、新しい顧客要求を採用できるチェックポイントを導入するために、短い開発サイクルで頻繁なリリースを行うことを推奨しています。
エクストリームプログラミングの他の要素には、ペアプログラミングや徹底的なコードレビュー、すべてのコードの単体テスト、実際に必要になるまで機能をプログラミングしないこと、フラットな管理構造、コードのシンプルさと明瞭さ、時間の経過とともに問題がよりよく理解されるにつれて顧客の要件が変わることを想定すること、顧客やプログラマー間の頻繁なコミュニケーションなどが含まれます。[ 2 ] [ 3 ] [ 4 ]この方法論は、従来のソフトウェアエンジニアリングの実践の有益な要素を「極限」レベルにまで引き上げるという考えからその名前が付けられています。たとえば、コードレビューは有益な実践と考えられています。極限まで行うと、コードは継続的にレビューされることがあります（つまり、ペアプログラミングの実践です）。
ケント・ベックは、クライスラー総合報酬システム（C3）給与計算プロジェクトに携わっていた際にエクストリームプログラミングを開発しました。[ 5 ]ベックは1996年3月にC3プロジェクトのリーダーに就任しました。彼はプロジェクトで使用される開発手法の改良に着手し、その手法に関する書籍（『エクストリームプログラミング解説』、1999年10月出版）を執筆しました。[ 5 ]クライスラーは、ダイムラー・ベンツが同社を買収した2000年2月に、7年後のC3プロジェクトを中止しました。 [ 6 ]ワード・カニンガムもXPに大きな影響を与えた人物です。
エクストリームプログラミングの手法の多くは以前から存在しており、この手法は「ベストプラクティス」を極限まで推し進めています。たとえば、「テストファースト開発、各マイクロインクリメントの前にテストを計画して記述する」という手法は、1960年代初頭のNASAのマーキュリー計画ですでに使用されていました。 [ 7 ]全体の開発時間を短縮するために、ソフトウェアがテスト準備完了になるのと並行して（または直前に）正式なテストドキュメント（受け入れテスト用など）が作成されてきました。NASAの独立したテストグループは、プログラマがソフトウェアを記述してハードウェアと統合する前に、正式な要件と論理的な制約に基づいてテスト手順を記述することができます。XPはこの概念を極限まで推し進め、ソフトウェアコードの小さなセクションの動作を検証する自動テスト（ソフトウェアモジュール内で使用されることもあります）を記述し、大きな機能のみをテストするのではなく、ソフトウェア全体をテストします。
1990年代のソフトウェア開発を形作った主な影響要因は2つある。
急速に変化する要件は、より短い製品ライフサイクルを要求し、しばしば従来のソフトウェア開発手法と衝突した。
クライスラー総合報酬システム（C3）は、クライスラーの給与システムを研究対象とし、Smalltalkを言語、GemStoneをデータアクセス層として、オブジェクト技術の最適な使用方法を決定するために開始されました。クライスラーは、システムのパフォーマンスチューニングを行うために、著名なSmalltalk実践者であるケント・ベック[5]を招きましたが、開発プロセスにいくつかの問題があることに気づいたため、彼の役割は拡大しました。彼はこの機会を利用して、頻繁に協力しているワード・カニンガムとの作業に基づいて、開発プラクティスにいくつかの変更を提案し、実装しました。ベックは、メソッドの初期構想について次のように説明しています。[ 8 ]
初めてチームリーダーを任された時は、テストやレビューなど、自分が合理的だと思ったことを少しずつやってもらうように頼みました。二度目は、もっと大きな責任が伴いました。「もうどうにでもなれ、少なくともこれで良い記事が書けるだろう」と思い、チームには、自分が不可欠だと思ったことはすべて最大限までやり、それ以外はすべて省くように頼みました。
ベックは、これらの手法の開発と改良を支援するため、ロン・ジェフリーズをプロジェクトに招いた。その後、ジェフリーズはコーチとして、これらの手法をC3チームに習慣として定着させるための活動を行った。
XPの原理と実践に関する情報は、オリジナルのWikiであるCunninghamのWikiWikiWebでの議論を通じて広く世界に広まりました。様々な貢献者がこれらのアイデアについて議論し、発展させ、いくつかの派生的な手法が生まれました（アジャイルソフトウェア開発を参照）。また、XPの概念は、 1999年頃からXPウェブサイト（ http://www.extremeprogramming.org ）上のハイパーテキストシステムマップを使用して説明されてきました。
ベックは、自身の著書『エクストリーム・プログラミング解説』（1999年、ISBN 1990）を皮切りに、XPに関する一連の書籍を編集した。 0-201-61641-6）彼のアイデアをより多くの人々に広めた。シリーズの著者たちは、XPとその実践に関する様々な側面を取り上げている。シリーズには、その実践を批判する書籍も含まれている。
『エクストリームプログラミング解説』では、エクストリームプログラミングを、より高品質なソフトウェアをより生産的に開発するために人々を組織化するソフトウェア開発手法として説明している。
XPは、長い開発サイクルではなく、複数の短い開発サイクルを行うことで、要件変更のコストを削減しようと試みます。[ 9 ] この原則では、変更はソフトウェア開発プロジェクトの自然で避けられない望ましい側面であり、安定した要件セットを定義しようとするのではなく、変更を計画する必要があります。
エクストリームプログラミングは、アジャイル開発手法に加えて、多くの基本的な価値観、原則、実践方法を導入する。
XPは、ソフトウェア開発プロセスにおいて実行される4つの基本的な活動、すなわちコーディング、テスト、リスニング、および設計について説明しています。これらの活動はそれぞれ、以下で説明します。
XPの支持者たちは、システム開発プロセスにおいて真に重要な成果物はコード、つまりコンピュータが解釈できるソフトウェア命令のみであると主張する。コードがなければ、動作する製品は存在しない。
コーディングは、最適な解決策を見つけるために利用できます。また、プログラミング上の問題に関する考えを伝えるのにも役立ちます。複雑なプログラミング問題に取り組んでいるプログラマーや、解決策を他のプログラマーに説明するのが難しいプログラマーは、問題を簡略化してコーディングし、そのコードを使って自分の意図を説明することができます。この立場を支持する人々は、コードは常に明確かつ簡潔であり、複数の解釈は不可能だと主張します。他のプログラマーも、自分の考えをコーディングすることで、このコードにフィードバックを与えることができます。
テストはエクストリームプログラミングの中心です。[ 10 ]エクストリームプログラミングのアプローチは、少しのテストでいくつかの欠陥を取り除けるなら、多くのテストでさらに多くの欠陥を取り除くことができるというものです。
システム全体の統合テストは、当初は互換性のないインターフェースを早期に検出するための毎日の終業活動として推奨されていました。しかし、システム全体の統合テストは、システム全体のインターフェースの安定性に応じて、週に1回以下、またはそれ以下の頻度に減らされています。[ 11 ]
プログラマーは、顧客がシステムに何を求めているのか、そしてどのような「ビジネスロジック」が必要なのかを注意深く聞き取る必要があります。顧客に対して、問題解決の技術的な側面や、与えられた制約内で問題が解決可能かどうかについてフィードバックを提供できるよう、これらのニーズを十分に理解していなければなりません。顧客とプログラマー間のコミュニケーションについては、プランニングゲームでさらに詳しく取り上げられています。
シンプルさという観点から言えば、システム開発に必要なのはコーディング、テスト、リスニングだけだと言えるかもしれません。これらの作業を適切に行えば、必ず動作するシステムが完成するはずです。しかし、実際にはそうはいきません。設計をせずに開発を進めることはできますが、いずれ行き詰まってしまいます。システムが複雑化しすぎて、システム内の依存関係が不明瞭になってしまうのです。これを回避するには、システムのロジックを整理する設計構造を作成することが重要です。優れた設計は、システム内の多くの依存関係を回避します。つまり、システムの一部を変更しても、他の部分に影響を与えないということです。
エクストリームプログラミングは、1999年にコミュニケーション、シンプルさ、フィードバック、勇気という4つの価値観を最初に認識しました。そして、 『エクストリームプログラミング入門』の第2版で、新たに「尊重」という価値観が追加されました。以下に、これら5つの価値観について説明します。
ソフトウェアシステムを構築するには、システム要件をシステム開発者に伝える必要があります。正式なソフトウェア開発手法では、この作業はドキュメント作成によって行われます。エクストリームプログラミングの手法は、開発チームのメンバー間で組織的な知識を迅速に構築し、共有するための方法と見なすことができます。その目的は、すべての開発者がシステムのユーザーと同じ視点を持つようにすることです。そのため、エクストリームプログラミングでは、シンプルな設計、共通のメタファー、ユーザーとプログラマーの協働、頻繁な口頭でのコミュニケーション、そしてフィードバックを重視します。
エクストリームプログラミングでは、最もシンプルな解決策から始めることを推奨しています。追加機能は後から追加できます。このアプローチと従来型のシステム開発方法との違いは、明日、来週、または来月のニーズではなく、今日のニーズに合わせて設計およびコーディングすることに重点を置いている点です。これは、「You aren't gonna need it」（YAGNI）アプローチとして要約されることもあります。[ 12 ] XPの支持者は、このアプローチでは、システムを変更するために明日より多くの労力が必要になる場合があるという欠点を認めていますが、関連性が生じる前に変更される可能性のある将来の要件に投資しないという利点によって、この欠点は十分に補われると主張しています。不確実な将来の要件に合わせてコーディングおよび設計すると、必要ないかもしれないものにリソースを費やすリスクがあり、重要な機能が遅れる可能性があります。「コミュニケーション」の価値に関連して、設計とコーディングのシンプルさはコミュニケーションの質を向上させるはずです。非常にシンプルなコードを備えたシンプルな設計は、チームのほとんどのプログラマーが簡単に理解できます。
エクストリームプログラミングにおいて、フィードバックはシステム開発のさまざまな側面に関係する。
フィードバックはコミュニケーションとシンプルさと密接に関係しています。システムの欠陥は、特定のコードが壊れることを証明する単体テストを作成することで簡単に伝えることができます。システムからの直接的なフィードバックは、プログラマーにその部分を再コーディングするように指示します。顧客は、ユーザーストーリーとして知られる機能要件に従って、システムを定期的にテストすることができます。[ 5 ]ケント・ベックの言葉を借りれば、「楽観主義はプログラミングの職業病である。フィードバックはその治療法である。」[ 13 ]
勇気を体現する実践はいくつかあります。その一つは、明日ではなく今日のために常に設計とコーディングを行うという戒律です。これは、設計に囚われて他のことを実装するのに多くの労力を要さないようにするための努力です。勇気があれば、開発者は必要に応じてコードをリファクタリングすることに抵抗を感じなくなります。 [ 5 ]これは、既存のシステムを見直し、将来の変更をより簡単に実装できるように修正することを意味します。勇気のもう一つの例は、コードを捨てるべき時を知ることです。どれだけの労力をかけて作成したソースコードであっても、古くなったソースコードを削除する勇気です。また、勇気は粘り強さを意味します。プログラマーは複雑な問題に丸一日行き詰まるかもしれませんが、粘り強さがあれば、翌日にはすぐに問題を解決できるかもしれません。
尊重という価値観には、他者への尊重だけでなく、自己尊重も含まれます。プログラマーは、コンパイルエラーを引き起こしたり、既存の単体テストを失敗させたり、同僚の作業を遅らせたりするような変更を決してコミットしてはなりません。メンバーは、高品質なコードを記述し、リファクタリングを通じて目の前のソリューションに最適な設計を追求することで、自身の仕事を尊重します。
先に挙げた4つの価値観を実践することで、チームメンバーからの尊敬を得ることができます。チームの誰もが、評価されていない、あるいは無視されていると感じるべきではありません。これにより、高いモチベーションが維持され、チームとプロジェクトの目標に対する忠誠心が育まれます。この価値観は他の価値観に依存しており、チームワークを重視しています。
XPのルールの最初のバージョンは、1999年にドン・ウェルズ[ 14 ]によってXPウェブサイトで公開されました。計画、管理、設計、コーディング、テストのカテゴリに29のルールが示されています。計画、管理、設計は、XPがこれらの活動をサポートしていないという主張に反論するために明示的に挙げられています。
XPルールの別のバージョンは、2003年のXP/Agile UniverseでKen Auer [ 15 ]によって提案されました。彼は、XPはプラクティス（より多様性と曖昧さを伴う）ではなく、ルールによって定義されると考えていました。彼は2つのカテゴリを定義しました。「Rules of Engagement」は、ソフトウェア開発が効果的に行われる環境を規定し、「Rules of Play」は、Rules of Engagementの枠組み内での分単位の活動とルールを定義します。
以下はルールの一部です（一部抜粋）。
コーディング
テスト
XPの基盤となる原則は、先に述べた価値観に基づいており、システム開発プロジェクトにおける意思決定を促進することを目的としています。これらの原則は、価値観よりも具体的であり、実際の状況においてより容易に指針として活用できるように設計されています。
エクストリームプログラミングでは、フィードバックは頻繁かつ迅速に行われる場合に最も効果的であると考えられています。行動とフィードバックの間の遅延を最小限に抑えることが、学習と改善にとって極めて重要であると強調しています。従来のシステム開発手法とは異なり、顧客とのやり取りはより頻繁に行われます。顧客は開発中のシステムを明確に把握しており、必要に応じてフィードバックを提供したり、開発の方向性を指示したりすることができます。顧客からの頻繁なフィードバックにより、開発者が誤った設計判断を下した場合でも、開発者が多くの時間を費やす前に、迅速に発見して修正することができます。
単体テストは、迅速なフィードバックの原則に貢献します。コードを書く際に単体テストを実行すると、変更に対するシステムの反応を直接フィードバックできます。これには、開発者のコードをテストする単体テストだけでなく、すべてのソフトウェアに対してすべての単体テストを実行することも含まれます。このプロセスは、単一のコマンドで開始できます。このようにして、開発者の変更によって、開発者がほとんど、あるいは全く知らないシステムの他の部分で障害が発生した場合、自動化されたすべての単体テストスイートが障害を即座に明らかにし、開発者に変更とシステムの他の部分との互換性のなさ、そして変更の削除または修正の必要性を警告します。従来の開発手法では、自動化された包括的な単体テストスイートがないため、開発者が無害だと考えたコード変更はそのまま放置され、統合テスト時、あるいはさらに悪いことに、本番環境でのみ問題が発生する可能性がありました。そして、統合テストの数週間、あるいは数か月前にすべての開発者が行ったすべての変更の中から、どのコード変更が問題を引き起こしたのかを特定することは、非常に困難な作業でした。
これは、あらゆる問題を「極めて単純な」解決策であるかのように扱うという考え方です。従来のシステム開発手法では、将来を見据えた計画と再利用性を考慮したコーディングが推奨されますが、エクストリームプログラミングはこれらの考え方を否定します。
エクストリームプログラミングの提唱者たちは、大きな変更を一度に行うのはうまくいかないと主張します。エクストリームプログラミングでは、段階的な変更を適用します。例えば、システムを3週間ごとに小規模なリリースで更新するといった具合です。このように小さなステップを積み重ねることで、顧客は開発プロセスと開発中のシステムをより細かく制御できるようになります。
変化を受け入れるという原則は、変化に抵抗するのではなく、変化を受け入れることを意味します。例えば、反復的な会議で顧客の要求が劇的に変化したことが明らかになった場合、プログラマーはそれを受け入れ、次の反復に向けて新しい要求を計画する必要があります。
エクストリームプログラミングは、4つの分野に分類される12の実践方法から成ると説明されている。
XPの手法については激しい議論が交わされてきた。[ 5 ]エクストリームプログラミングの支持者は、現場の顧客[ 5 ]が非公式に変更を要求することで、プロセスが柔軟になり、正式な間接費を削減できると主張している。XPの批判者は、これにより、費用のかかる手戻りや、以前に合意または予算化された範囲を超えたプロジェクトの範囲拡大につながる可能性があると主張している。
変更管理委員会は、複数のユーザー間でプロジェクトの目的と制約に潜在的な衝突があることを示す兆候です。XPの迅速な方法は、プログラマーが統一されたクライアントの視点を想定できることに多少依存しており、プログラマーは妥協の目的と制約の文書化ではなく、コーディングに集中できます。[ 16 ]これは、複数のプログラミング組織が関与する場合、特にプロジェクトのシェアを競う組織にも当てはまります。
エクストリームプログラミングのその他の潜在的に物議を醸す側面には、以下のようなものがある。
批評家は、不安定な要件の問題、ユーザーの競合に対する妥協の文書化の欠如、全体的な設計仕様や文書の欠如など、いくつかの潜在的な欠点を指摘している[ 5 ] 。
Thoughtworks社は、最大60人規模の分散型XPプロジェクトで一定の成功を収めたと主張している。
2004年に、XPの進化形としてインダストリアル・エクストリーム・プログラミング（IXP）[ 17 ]が導入されました。これは、大規模で分散したチームで作業する能力をもたらすことを目的としています。現在では23のプラクティスと柔軟な価値観があります。
2003年、マット・スティーブンスとダグ・ローゼンバーグは『エクストリーム・プログラミング・リファクタリング：XPへの反論』を出版し、XPプロセスの価値に疑問を投げかけ、改善策を提案した。[ 6 ]これがきっかけとなり、記事、インターネットのニュースグループ、ウェブサイトのチャットエリアで長きにわたる議論が巻き起こった。本書の核心的な主張は、XPのプラクティスは相互依存的であるが、実際にすべてのプラクティスを採用しようとする組織はほとんどなく、そのためプロセス全体が失敗に終わるというものだ。本書では他にも批判を展開しており、XPの「共同所有」モデルを社会主義に否定的になぞらえている。
『エクストリーム・プログラミング リファクタリング』の出版以降、XPのいくつかの側面は変化しました。特に、XPは現在、必要な目標が達成される限り、プラクティスの変更を受け入れるようになっています。また、XPではプロセスを表す用語がますます汎用的になっています。これらの変化によって以前の批判が無効になると主張する人もいれば、単にプロセスが希薄化されているだけだと主張する人もいます。
他の著者は、統一された方法論を形成するために、XP を従来の方法論と調和させようと試みてきました。これらの中には、ウォーターフォール方式などの XP が置き換えようとしたものもありました。例:プロジェクトライフサイクル: ウォーターフォール、ラピッドアプリケーション開発(RAD) など。JPMorgan Chase & Co. は、 XP を能力成熟度モデル統合(CMMI) およびシックスシグマのコンピュータプログラミング手法と組み合わせようとしました。彼らは、3 つのシステムが互いにうまく補強し合い、より良い開発につながり、互いに矛盾しないことを発見しました。[ 18 ]
エクストリームプログラミングの初期の話題性と、ペアプログラミングや継続的設計などの物議を醸す原則は、マクブリーン[ 19 ] 、ボームとターナー[ 20 ] 、マット・スティーブンスとダグ・ローゼンバーグ[ 21 ]などから特に批判を集めた。しかし、アジャイル実践者の多くは、これらの批判の多くはアジャイル開発の誤解であると考えている[ 22 ] 。
特に、エクストリームプログラミングは、マット・スティーブンスとダグ・ローゼンバーグの『エクストリームプログラミング リファクタリング』でレビューされ、批判されている。[ 6 ]
{{cite book}}:|work=無視されました (ヘルプ){{cite book}}:|work=無視されました (ヘルプ)