Loading article…
エクストリームプログラミング（ XP）は、ソフトウェアシステムを実装するために使用されるアジャイルソフトウェア開発手法。この記事では、この手法で使用されるプラクティスについて詳しく説明します。エクストリームプログラミングには、ソフトウェアエンジニアリングのベストプラクティスから派生した、4つの領域に分類された12のプラクティスがあります。 [ 1 ]
ペアプログラミングとは、2人が協力して1つのタスクに取り組むプログラミング手法です。一方のプログラマーはワークステーションを操作し、主にコーディングの詳細に集中します。もう一方のプログラマーは全体像を把握することに重点を置き、最初のプログラマーが作成したコードを継続的にレビューします。プログラマーは数分から数時間ごとに役割を交代します。
ペアは固定されておらず、プログラマーは頻繁にパートナーを交代するため、全員が互いの作業内容を把握し、自分の専門外の部分も含め、システム全体に精通した状態を維持できます。このように、ペアプログラミングはチーム全体のコミュニケーションを促進する効果もあります。（これは共同所有の概念とも密接に関連しています。）
エクストリームプログラミングにおける主要な計画プロセスは、プランニングゲームと呼ばれます。このゲームは、通常週に1回、イテレーションごとに1回開催されるミーティングです。計画プロセスは、次の2つの部分に分かれています。
プランニングゲームの目的は、製品を納品へと導くことです。納品物が必要となり、生産される正確な日付を予測することは困難であるため、プランニングゲームは、シンプルなアプローチを用いて「プロジェクトを納品へと導く」ことを目指します。[ 2 ]プランニングゲームのアプローチは、ソフトウェアシステムだけでなく、開発フレームワークでも使用されています。例えば、ビジネスアジリティの文脈でチームによって使用されています。[ 3 ]
これは、要件を収集し、それぞれの要件が作業に与える影響を見積もるという反復的なプロセスです。
企業側がこれ以上要件を提示できなくなった場合、コミットメント段階へと進む。
この段階では、コスト、メリット、スケジュールへの影響を判断します。構成要素は以下の4つです。
ビジネス側は、ユーザーストーリーをビジネス価値に基づいて分類します。そして、それらを3つの山に分けます。
開発者はユーザーストーリーをリスク別に整理します。さらに、リスクの低いもの、中程度のもの、高いものの3つのグループに分類します。以下は、その方法の一例です。
ユーザーストーリーのすべてのインデックスが追加され、ユーザーストーリーに低リスク（0 ～ 1）、中リスク（2 ～ 4）、高リスク（5 ～ 6）のインデックスが割り当てられます。
ステアリングフェーズでは、プログラマーとビジネス担当者がプロセスを「操縦」できます。つまり、変更を加えることができるのです。個々のユーザーストーリーや、異なるユーザーストーリー間の相対的な優先順位が変わる可能性があり、見積もりが間違っていることが判明する可能性もあります。これは、計画を適切に調整する機会です。
チームのベロシティを考慮し、ストーリーポイントを計画します。イテレーション期間は1～3週間です。
イテレーション計画の探索フェーズでは、タスクを作成し、その実行時間を見積もることが目的となります。
イテレーション計画のコミットメントフェーズでは、プログラマーにはさまざまなユーザーストーリーを参照するタスクが割り当てられます。
タスクの実装は、イテレーションのステアリングフェーズ中に行われます。
単体テストとは、コードの一部（クラス、メソッドなど）の機能をテストする自動テストです。XPでは、最終的なコードを記述する前に単体テストを作成します。このアプローチは、プログラマーが自分のコードが失敗する可能性のある条件について考えるように促すことを目的としています。XPでは、プログラマーがコードが失敗する可能性のある条件をこれ以上思いつかなくなった時点で、そのコードの作成が完了したとみなされます。
テスト駆動開発は、以下の手順を迅速に繰り返していくことで進められます。各手順は最大でも数分、できればそれよりもずっと短い時間で完了します。各ユーザーストーリーは通常1～2日の作業時間を要するため、ストーリーごとに非常に多くのサイクルが必要になります。
上記のプロセスをより厳密に行う方法については、アンクル・ボブのTDDの3つのルールを参照してください。[ 4 ]
XP（エクストリームプログラミング）では、「顧客」とは料金を支払う人ではなく、実際にシステムを利用する人のことです。XPでは、顧客は常に待機し、質問に対応できる状態にあるべきだとされています。例えば、財務管理システムを開発するチームには、財務管理者が必ず含まれているべきです。ソフトウェア製品を提供するために必要なすべてのスキルがチーム内に備わっている必要があります。
開発チームは常に最新バージョンのソフトウェアを使用するべきです。チームメンバーによってローカルに保存されているバージョンが異なる場合があるため、数時間ごと、または大きな中断が発生した際には、各自の最新バージョンをコードリポジトリにアップロードするように努めるべきです。 継続的インテグレーションによって、プロジェクトサイクル後半におけるインテグレーションの問題による遅延を回避できます。
XPの原則は、今日必要なものだけをプログラミングし、それをできるだけシンプルに実装することを推奨しているため、システムが停滞してしまうことがあります。その兆候の一つは、二重（または多重）メンテナンスが必要になることです。つまり、機能変更を行うと、同じ（または類似の）コードの複数のコピーに変更を加える必要が生じるのです。もう一つの兆候は、コードのある部分の変更が他の多くの部分に影響を与えることです。XPの原則では、このような状況が発生した場合、システムはアーキテクチャを変更してコードをリファクタリングし、よりシンプルで汎用的なものにするよう促している、とされています。
ソフトウェアの提供は、実際の機能を頻繁にリリースすることで行われ、具体的な価値を生み出します。小規模なリリースは、顧客がプロジェクトの進捗状況に確信を持つのに役立ちます。これにより、顧客は実際の経験に基づいてプロジェクトに関する提案を行うことができるため、チーム全体の意識を維持することができます。
コーディング標準とは、開発チーム全体がプロジェクト全体を通して遵守することに同意した一連のルールです。この標準は、選択したプログラミング言語内でのソースコードの一貫したスタイルとフォーマット、および欠陥の可能性を減らすために避けるべきさまざまなプログラミング構造とパターンを規定します。[ 5 ] コーディング標準は、言語ベンダーによって指定された標準規約（たとえば、Sunが推奨するJavaプログラミング言語のコーディング規約）である場合もあれば、開発チームによって独自に定義されたものである場合もあります。
エクストリームプログラミングの支持者は、可能な限り自己文書化できるコードを推奨しています。これにより、コード自体と同期が取れなくなる可能性のあるコードコメントの必要性が減ります。 [ 6 ]
プログラマーはソフトウェア設計において「シンプルイズベスト」のアプローチを取るべきです。新しいコードを書くたびに、作者は「同じ機能を実現するもっとシンプルな方法はないか？」と自問自答する必要があります。答えがイエスであれば、よりシンプルな方法を選択すべきです。複雑なコードをよりシンプルにするために、リファクタリングも活用すべきです。
システムメタファーとは、顧客、プログラマー、マネージャーなど、誰もがシステムの仕組みを説明できるストーリーのことです。これは、クラスやメソッドの命名規則であり、チームメンバーが名前だけで特定のクラスやメソッドの機能を容易に推測できるようにするものです。例えば、図書館システムでは、特定のアイテムloan_records(class)に対してクラスを作成しborrowers(class)、アイテムの返却期限が過ぎた場合は、そのアイテムに対してmake_overdue操作を実行する場合がありますcatalogue(class)。このように、各クラスや操作の機能は、チーム全体にとって明確です。
このコンセプトは、プログラマーやソフトウェア開発者は週40時間以上働くべきではなく、ある週に残業があった場合は、翌週も残業をしてはならないというものです。開発サイクルは継続的インテグレーションの短いサイクルであり、完全な開発（リリース）サイクルがより頻繁に行われるため、XPのプロジェクトは、他のプロジェクトで必要とされるような典型的な過酷な労働時間（残業を必要とする時間）を伴いません。
また、この概念には、人は十分な休息をとることで最高のパフォーマンスを発揮し、創造性も最大限に発揮できるという点も含まれている。
持続可能なペースを実現するための重要な要素は、頻繁なコードマージと、常に実行可能でテスト済みの高品質なコードです。継続的なリファクタリングの手法は、チームメンバーの思考を常に新鮮で鋭敏なものに保ちます。チーム内での緊密な協働作業は、週末にリフレッシュする必要性を生み出します。
十分にテストされ、継続的に統合され、頻繁にデプロイされるコードと環境は、予期せぬ本番環境の問題や障害の発生頻度、およびそれに伴う夜間や週末の作業を最小限に抑えます。