「エクストリーム・プログラミング」の版間の差分

削除された内容追加された内容

インライン

2020年9月5日 (土) 07:42時点における版

エクストリーム・プログラミング、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は、この概念を極限のレベルにまで引き上げて、機能という大きなテストしかしないのではなく、ソフトウェアコーディングの小さなセクションでさえも動作を検証する自動テスト（時にはソフトウェアモジュールの内部）を記述する。

背景

XP は、既存の開発方法論に対するアンチテーゼとしてみることができる。既存の開発手法においては、SPA、CMM（能力成熟度モデル）にもとづく厳格なソフトウェア開発手法、あるいは重量開発手法（この名称は軽量開発手法論者によって使用され始めたもので異論がある）が用いられてきた。ここでは、ドキュメントが重視され、正しいソフトウェアを作るためには仕様が正しく定義されて、正しい手順（たとえば仕様凍結など）を踏む必要があるとされてきた。しかし、現実のソフトウェア開発において、このような前提のもとでの開発は数限りなく失敗を引き起こしてきた。

従来の手法は、変更コストは開発が進むにつれ増大するという前提に立っている。それ故に、将来発生するかもしれない仕様やロジックの変更は可能な限り早い段階で検出しなくてはならないとしていた。しかし実際には、初期の段階で将来起きうる全ての問題を予見することはほぼ不可能であるため、従来の手法はしばしば開発に失敗を引き起こしてきた。

ケント・ベックらは、書籍『Extreme Programming Explained - Embrace Change』の副題「変化を享受せよ」にあるように、このようなソフトウェア開発に伴う変化を、確定させ凍結しようとするのではなく、当然あるべきものとして積極的に対応できることを目指した。実際、XPが台頭した1990年代後半のIT革命のアメリカでは、電子商取引サイトを代表として、ビジネス条件が日々刻々と変化する、開発スピードが最優先であるような状況が生まれていた。そうではなくても、ダウンサイジング・オープン化の潮流の元で、ソフトウェア開発全般には難易度の高い短期開発が必要となっていた。その状況下で、XPはブームとなった。

5つの価値

XPでは、そのすべての原理となる5つの価値が存在する。それは、

コミュニケーション
シンプル
フィードバック
勇気
尊重

である。これら5つの価値は各プラクティスに影響を与え、XPの根幹をなす。

プラクティス

XPには、開発チームが行うべきいくつかのプラクティス（習慣、実践）が定められている。これらのプラクティスを実行することが、XPを実行することと言える。

初期には12のプラクティスであったが、数度の改定を得て数が19に増え、対象者の立場ごとに4種類に分類されるようになった。しかし、本質的には変化することなく、その内容をより理解しやすくするための改定となっている。

共同のプラクティス

反復: 開発を反復から構成する（⇒反復型開発）。全体の開発期間はイテレーションと呼ぶ1〜2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返し、徐々に完全なシステムを構築していく。またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。; このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。
共通の用語: 用語集を作成し、チーム全員（開発者・管理者・顧客）の使用する用語とその概念の不一致を解消する。
開けた作業空間: 会話しやすく、作業に打ち込める雰囲気を作る。顧客も含めて一箇所に集まって作業を行う。
回顧（頻繁な振り返り）: 現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。

開発のプラクティス

テスト駆動開発

実装を行うより先に、テストを作成する。実装は、そのテストをパスすることを目標に行う。テストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。なお、このテストは、部品単位での正確性を確認するユニットテスト（ホワイトボックステスト）と、全体が顧客の要求を満たしているかを確認する受け入れテスト（ブラックボックステスト）の観点で作成する。テストは、自動テストであることが推奨される。なぜなら、それによって、コードの共同所有、リファクタリング、頻繁な結合が可能になるため^[8]、開発が進んでも変更コストの増大を抑制することができる^[9]^[10]。

ペアプログラミング

プログラミングは、二人一組で行う。一人がコードを書き、もう一人はそれをチェックしながら、仕様書を確認したり全体構造を考えたりするなど、ナビゲートを行う。二人は、この役割を定期的に交代しながら仕事を進める。ナビゲータのサポートにより、以下の効果が得られる。

細々とした問題の解決に要する時間が短くなる。
常にコードレビューを行うことができる
集中力が持続する。
コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ。

リファクタリング: 完成済みのコードでも、随時、改善処置を行う。この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。テストが作成されていることが前提になる。
ソースコードの共同所有: 誰が作ったソースコードであっても、開発チーム全員が断りなく修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。
継続的インテグレーション: 単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。少なくとも一日に一回は、結合テストを行う。また、全体のコンパイルおよび自動テストを行うための継続的インテグレーション用のコンピュータを準備することが推奨されている^[11]。
YAGNI: You Aren't Going to Need It.（必要なことだけ行う）。先を見据えて、前払い的に機能を増やし、実装を複雑化させることは避ける^[12]。むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。これにより、後のイレギュラーな変更に対応しやすいようにする。シンプルで洗練され、安定性の高い機能・コードのまま、同時に将来的な汎用性も高めることは問題ないが、把握を難しくし、不安定化を招く機能・コードは、可能な限り削り落とす。

管理者のプラクティス

責任の受け入れ

援護

四半期毎の見直し

ミラー: 今どういう状態かをチームに知らせる。
最適なペースの仕事: 知的作業には、週40時間の労働時間が最適である。特にXPでは、集中力を高めて効果を高めることを重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適切ではない。そのため、計画的に開発スピードの調整を行う。

顧客のプラクティス

ストーリーの作成: 求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。
リリース計画: どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。
受け入れテスト: イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。もし満足できない場合は、それを指摘する。
短期リリース: 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする。

これらの個々のプラクティスが、お互いを補いあい補強しあう事で、XPという一つの方法論を成り立たせている。

しかし、ソフトウェア業界の現状においては、この全てのプラクティスを同時に実行することは非常に困難であるため、テスト駆動開発やリファクタリングなど、単独でもある程度有効なプラクティスだけが、一部導入されているケースが多い。

プログラマの受入れ

XPを熱狂的に受け入れたのは、プログラマであった。XPは、ドキュメントよりも、ソースコードを重視する。また、中長期的な計画に従うことよりも、細かく計画を見直し修正していくことに重きを置く（逆に、このような特徴は、プロジェクト管理者にとっては、XPを採用することに二の足を踏む一つの要因となっていた）。また、XPではテスト駆動開発を奨励しており、プログラムコードとテストコードを一体的に同時に開発していく。プログラマがXPを好む理由は、このようなプログラマの不安を解消する仕掛けを具体的なプラクティスとしてさまざまに備えているためである。

参考文献

ケント・ベック(著)、長瀬嘉秀(監訳)、永田渉、飯塚麻理香(訳)『XPエクストリーム・プログラミング入門：ソフトウェア開発の究極の手法』ピアソン・エデュケーション、2000。ISBN 489471275X

参照

^ "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006
^ ^a ^b UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003.
^ ^a ^b USFCA-edu-601-lecture Extreme Programming.
^ “Manifesto for Agile Software Development”. Agilemanifesto.org (2001年). 2019年3月26日閲覧。
^ ^a ^b Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001
^ Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6
^ Larman 2003.
^ Unit Tests
^ Surprise! Software Rots!
^ Acceptance Tests
^ Dedicated Integration Computer
^ Never Add Functionality Early

外部リンク

[Informatics85-1] "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006

[UPenn49-2] UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003.

[USFCA601-3] USFCA-edu-601-lecture Extreme Programming.

[MASD-4] “Manifesto for Agile Software Development”. Agilemanifesto.org (2001年). 2019年3月26日閲覧。

[Cworld92-5] Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001

[SR-6] Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6

[FOOTNOTELarman2003-7] Larman 2003.

[8] Unit Tests

[9] Surprise! Software Rots!

[10] Acceptance Tests

[11] Dedicated Integration Computer

[12] Never Add Functionality Early

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

@@ 3行目: / 3行目: @@
 エクストリーム・プログラミングの他の要素には、[[ペアプログラミング|ペアでの]]プログラミングや広範な[[コードレビュー]]の実施、すべてのコードの[[単体テスト|ユニットテスト]]、[[YAGNI|機能は実際に必要となるまでは追加しない]]、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある<ref name="UPenn49">[http://www.cis.upenn.edu/~matuszek/cit591-2003/Lectures/49-design-patterns.ppt UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003].</ref><ref name="USFCA601">[http://www.cs.usfca.edu/~parrt/course/601/lectures/xp.html USFCA-edu-601-lecture Extreme Programming].</ref><ref name="MASD">{{cite web|url=http://agilemanifesto.org |title=Manifesto for Agile Software Development |year=2001 |publisher=Agilemanifesto.org |accessdate=2019-03-26}}</ref>。この方法論は、伝統的なソフトウェアエンジニアリングのプラクティスの有益な要素を「極端な（エクストリームな）」レベルに持っていくという考えからその名前を取っている。例えば、[[コードレビュー]]は有益なプラクティスと考えられており、これを極端にすれば、コードを「継続的」にレビューする、つまり、[[ペアプログラミング]]のプラクティスとなる。
+== 歴史 ==
+[[ケント・ベック]]は、{{仮リンク|クライスラー総合報酬システム|en|Chrysler_Comprehensive_Compensation_System|label=クライスラー総合報酬システム}}（C3）給与計算[[プロジェクト]]での業務の中で、エクストリーム・プログラミングを開発した<ref name=Cworld92/>。ケント・ベックは1996年3月にC3[[プロジェクトマネジメント|プロジェクトリーダー]]になった。彼はプロジェクトで使用された開発方法論を改良し始め、その方法論に関する本を書いた (''エクストリームプログラミング'', 1999年10月出版)<ref name="Cworld92">[http://www.computerworld.com/article/2585634/app-development/extreme-programming.html Computerworld-appdev-92 "Extreme Programming", ''Computerworld'' (online), December 2001]</ref>。[[クライスラー]]は7年後の2000年2月、[[ダイムラー (自動車メーカー)|ダイムラー・ベンツ]]が同社を買収した際にC3プロジェクトをキャンセルした<ref name="SR">{{cite book | last1 = Rosenberg | first1 = Doug | last2 = Stephens | first2 = Matt | title = Extreme Programming Refactored: The Case Against XP | year = 2003 | publisher = Apress | isbn = 978-1-59059-096-6 | url-access = registration | url = https://archive.org/details/extremeprogrammi00matt }}</ref>。
+エクストリーム・プログラミングの多くのプラクティスは以前から存在していた。この方法論は、「[[ベストプラクティス]]」を極端なレベルに引き上げる。 たとえば、「テストファースト開発のプラクティス、各マイクロインクリメントの前にテストを計画して書く」は、1960年代初頭のNASAの[[マーキュリー計画]]で早くも使われていた{{sfn| Larman | 2003}}。総開発時間を短縮するために、一部の正式なテストドキュメント({{仮リンク|受け入れテスト|en|Acceptance_testing|label=受け入れテスト}}のためのものなど)は、ソフトウェアのテストの準備がされるのと並行して(あるいは少し前から)開発されてきた。NASAの独立テストグループは、プログラマーがソフトウェアを書いてハードウェアと統合する前に、公式な要件と論理的限界に基づいてテスト手順を書くことができた。XPは、この概念を極限のレベルにまで引き上げて、機能という大きなテストしかしないのではなく、ソフトウェアコーディングの小さなセクションでさえも動作を検証する自動テスト（時にはソフトウェアモジュールの内部）を記述する。
 == 背景 ==