エクストリームプログラミングの実践

エクストリームプログラミング（ XP）は、ソフトウェアシステムを実装するために使用されるアジャイルソフトウェア開発方法論です。この記事では、この方法論で使用されるプラクティスについて詳しく説明します。エクストリームプログラミングには、ソフトウェアエンジニアリングのベストプラクティスから派生した4つの領域にグループ化された12のプラクティスがあります。 ^[1]

ペア プログラミングとは、2 人のプログラマーが 1 つのタスクで共同でプログラミングしてコードを作成するプログラミング方法です。1 人のプログラマーはワークステーションを制御し、主にコーディングの詳細について考えます。もう 1 人のプログラマーは全体像に焦点を当て、最初のプログラマーが作成しているコードを継続的に確認します。プログラマーは、1 分から 1 時間ごとに役割を交換します。

ペアは固定されていません。プログラマーは頻繁にパートナーを交代するため、全員がお互いの作業を把握し、自分のスキルセット外の部分も含めてシステム全体に精通しています。このように、ペアプログラミングはチーム全体のコミュニケーションを強化することもできます。(これは共同所有権の概念とも密接に関係しています)。

エクストリーム プログラミングにおける主な計画プロセスは、計画ゲームと呼ばれます。このゲームは、反復ごとに 1 回、通常は週に 1 回行われる会議です。計画プロセスは 2 つの部分に分かれています。

• リリース計画: これは、どの短期リリースにどのような要件が含まれているか、いつリリースするかを決定することに重点を置いています。顧客と開発者の両方がこれに関与します。リリース計画は、次の 3 つのフェーズで構成されます。
  • 調査フェーズ: このフェーズでは、顧客がシステムに対する価値の高い要件の短いリストを提供します。これらはユーザー ストーリーカードに書き込まれます。
  • コミットメント フェーズ: コミットメント フェーズでは、ビジネス部門と開発者が、含まれる機能と次のリリースの日付についてコミットします。
  • ステアリング フェーズ: ステアリング フェーズでは、計画を調整したり、新しい要件を追加したり、既存の要件を変更または削除したりできます。
• イテレーション計画: 開発者の活動とタスクを計画します。このプロセスでは顧客は関与しません。イテレーション計画も 3 つのフェーズで構成されます。
  • 探索フェーズ: このフェーズでは、要件がさまざまなタスクに変換されます。タスクはタスク カードに記録されます。
  • コミットメント フェーズ: タスクがプログラマーに割り当てられ、完了までにかかる時間が見積もられます。
  • ステアリングフェーズ: タスクが実行され、最終結果が元のユーザー ストーリーと一致します。

プランニング ゲームの目的は、製品を納品に導くことです。成果物が必要になり、生産される正確な日付を予測するのは難しいですが、代わりに、直接的なアプローチを使用して「プロジェクトを導く」ことを目指しています。^{[2]プランニング ゲームのアプローチは、ソフトウェア システムだけでなく、開発フレームワークでも使用されています。たとえば、}ビジネス アジリティのコンテキストでチームによって使用されます。^[3]

これは、要件を収集し、それぞれの要件の作業への影響を見積もる反復的なプロセスです。

• ストーリーを書く: ビジネスには問題がつきものです。会議中、開発部門はこの問題を定義し、要件を取得しようとします。ビジネスの問題に基づいて、ストーリー (ユーザー ストーリー) を書く必要があります。これはビジネス部門によって行われ、システムの一部に何をしてほしいかを示します。開発部門がこのストーリーに影響を与えないことが重要です。ストーリーはユーザー ストーリー カードに書き込まれます。
• ストーリーの見積もり: 開発部門は、ストーリー カードで示されている作業を実行するのにかかる時間を見積もります。開発部門は、問題を分析または解決するためのスパイク ソリューションを作成することもできます。これらのソリューションは見積もりに使用され、全員が問題を明確に視覚化したら破棄されます。繰り返しますが、これはビジネス要件に影響を与えない可能性があります。
• ストーリーを分割する: 反復計画を開始する前に、設計上のすべての重要な複雑さに対処する必要があります。開発でストーリーを見積もることができない場合は、ストーリーを分割して再度記述する必要があります。

企業がそれ以上の要件を提示できなくなったら、コミットメント フェーズに進みます。

このフェーズでは、コスト、利点、スケジュールへの影響を判断します。次の 4 つのコンポーネントがあります。

• 価値による並べ替え: ビジネスは、ユーザー ストーリーをビジネス価値で並べ替えます。
• リスクによる並べ替え: 開発では、ストーリーをリスク別に並べ替えます。
• 速度の設定: 開発によって実行できる速度が決まります。
• スコープの選択: 次のリリースで完了するユーザー ストーリーが選択されます。ユーザー ストーリーに基づいてリリース日が決定されます。

ビジネス側は、ユーザー ストーリーをビジネス価値によって分類します。次の 3 つのグループに分けます。

• 重要: システムが機能しない、または意味を持たないストーリー。
• 重要なビジネス価値: 重要なビジネス価値を持つ、重要ではないユーザー ストーリー。
• あると便利なもの: 大きなビジネス価値がないユーザー ストーリー。

開発者は、ユーザー ストーリーをリスク別に並べ替えます。また、ユーザー ストーリーを低リスク、中リスク、高リスクの 3 つのグループに分類します。次に、このアプローチの例を示します。

• リスク インデックスを決定する: 各ユーザー ストーリーに、次の各要素について 0 から 2 までのインデックスを付けます。
  • 完全性（ストーリーの詳細をすべて知っていますか？）
    • 完了 (0)
    • 未完了 (1)
    • 不明 (2)
  • ボラティリティ（変化する可能性はありますか？）
    • 低い (0)
    • 中 (1)
    • 高い (2)
  • 複雑さ（構築するのはどれくらい難しいか？）
    • シンプル (0)
    • 標準 (1)
    • 複合体 (2)

ユーザー ストーリーのすべてのインデックスが追加され、ユーザー ストーリーに低 (0 ～ 1)、中 (2 ～ 4)、高 (5 ～ 6) のリスク インデックスが割り当てられます。

ステアリング フェーズでは、プログラマーとビジネス パーソンがプロセスを「ステアリング」できます。つまり、変更を加えることができます。個々のユーザー ストーリー、または異なるユーザー ストーリーの相対的な優先順位が変わる可能性があり、見積もりが間違っていることが判明する可能性もあります。これは、それに応じて計画を調整するチャンスです。

計画するチーム速度ストーリーポイントを検討します。反復期間は 1 ～ 3 週間です。

反復計画の探索フェーズでは、タスクを作成し、その実装時間を見積もります。

• 要件をタスクに変換します。タスク カードに配置します。
• タスクの結合/分割: タスクが小さすぎるか大きすぎるためにプログラマーがタスクを見積もることができない場合、プログラマーはタスクを結合または分割する必要があります。
• タスクの見積もり: タスクの実装にかかる時間を見積もります。

反復計画のコミットメント フェーズでは、さまざまなユーザー ストーリーを参照するタスクがプログラマに割り当てられます。

• プログラマーはタスクを受け入れます: 各プログラマーは自分が責任を負うタスクを選択します。
• プログラマーがタスクを見積もります。プログラマーがタスクの責任者になったので、タスクの最終的な見積もりを出す必要があります。
• 負荷係数を設定する: 負荷係数は、1 回の反復内でプログラマー 1 人あたりの実際の開発時間の理想的な量を表します。たとえば、週 40 時間で会議に 5 時間費やした場合、負荷係数は 35 時間以下になります。
• バランス調整: チーム内のすべてのプログラマーにタスクが割り当てられると、タスクの推定時間と負荷係数が比較されます。次に、プログラマー間でタスクのバランスが取られます。プログラマーの作業量が多すぎる場合は、他のプログラマーがそのプログラマーのタスクの一部を引き継ぐ必要があり、その逆も同様です。

タスクの実装は、反復のステアリング フェーズ中に実行されます。

• タスク カードを取得する: プログラマーは、自分が担当しているタスクの 1 つに対するタスク カードを取得します。
• パートナーを見つける: プログラマーは、別のプログラマーと一緒にこのタスクを実行します。これについては、ペア プログラミングの実践でさらに詳しく説明します。
• タスクの設計: 必要に応じて、プログラマーはタスクの機能を設計します。
• テスト駆動開発（TDD）を使用してタスクを実装します（下記参照）
• 機能テストの実行: 機能テスト (関連するユーザー ストーリーとタスク カードの要件に基づく) が実行されます。

ユニット テストは、コードの一部 (クラス、メソッドなど) の機能をテストする自動テストです。XP では、ユニット テストは最終的なコードがコーディングされる前に作成されます。このアプローチは、プログラマーが自分のコードが失敗する可能性のある条件について考えるように促すことを目的としています。XP では、プログラマーがコードが失敗する可能性のある条件をこれ以上思いつかなくなった時点で、特定のコード部分は終了したとされています。

テスト駆動開発は、次のステップを素早く繰り返すことで進行します。各ステップは最大でも数分、できればそれよりも短い時間で完了します。各ユーザー ストーリーには通常 1 ～ 2 日の作業が必要なので、ストーリーごとにこのようなサイクルを非常に多く実行する必要があります。

• ユニット テストの作成: プログラマーは、製品コードに機能が完全に実装されていないために失敗する最小限のテストを作成します。
• 新しいテストが失敗するのを確認します。プログラマーは、テストが実際に失敗することを確認します。時間の無駄のように思えるかもしれませんが、このステップは、製品コードの状態に関する確信が正しいことを確認するため、重要です。テストが失敗しない場合、プログラマーは、テスト コードにバグがあるかどうか、または製品コードが新しいテストで説明されている機能をサポートしているかどうかを判断する必要があります。
• コードを記述する: プログラマーは、新しいテストに合格するために必要なだけの製品コードを記述します。
• テストの実行: ユニット テストを実行して、新しい本番コードが新しいテストに合格し、他のテストが失敗していないことを確認します。
• リファクタリング:本番コードとテストコードの両方からコードの臭いを取り除きます。

上記のプロセスのより徹底したバージョンについては、Uncle BobのTDDの3つのルールを参照してください。^[4]

XP では、「顧客」は料金を支払う人ではなく、実際にシステムを使用する人です。XP では、顧客は常に近くにいて、質問に応じられる状態にあるべきであるとされています。たとえば、財務管理システムを開発するチームには、財務管理者が含まれている必要があります。ソフトウェア製品の提供に必要なすべてのスキルがチームに揃っている必要があります。

開発チームは常に最新バージョンのソフトウェアで作業する必要があります。さまざまなチーム メンバーがさまざまな変更や改善を加えたバージョンをローカルに保存している可能性があるため、数時間おきに、または大きな中断が発生したときに、現在のバージョンをコード リポジトリにアップロードするようにする必要があります。 継続的インテグレーションにより、プロジェクト サイクルの後半でインテグレーションの問題によって発生する遅延を回避できます。

XP の原則では、現在必要なものだけをプログラミングし、それをできるだけ単純に実装することを推奨しているため、システムが行き詰まることがあります。その症状の 1 つは、二重 (または多重) メンテナンスの必要性です。つまり、機能の変更によって、同じ (または類似の) コードの複数のコピーの変更が必要になります。もう 1 つの症状は、コードの一部の変更が他の多くの部分に影響を及ぼすことです。XP の原則では、このような状況が発生すると、システムは、アーキテクチャを変更してコードをリファクタリングし、より単純で汎用的なものにするように指示している、とされています。

ソフトウェアの提供は、具体的な価値を生み出すライブ機能を頻繁にリリースすることで行われます。小規模なリリースにより、顧客はプロジェクトの進捗に自信を持つことができます。顧客は実際の経験に基づいてプロジェクトに関する提案をすることができるため、チーム全体のコンセプトを維持するのに役立ちます。

コーディング標準とは、開発チーム全体がプロジェクト全体を通じて遵守することに合意した一連のルールです。この標準では、選択したプログラミング言語内でのソースコードの一貫したスタイルと形式、および欠陥の可能性を減らすために避けるべきさまざまなプログラミング構造とパターンを指定します。^[5] コーディング標準は、言語ベンダーによって指定された標準規則（例：Sunが推奨するJavaプログラミング言語のコード規則）または開発チームによって定義されたカスタム規則である場合があります。

エクストリームプログラミングの支持者は、可能な限り自己文書化されたコードを推奨しています。これにより、コード自体と同期しなくなる可能性のあるコードコメントの必要性が減ります。 ^[6]

共同コード所有権（「チームコード所有権」や「共有コード」とも呼ばれる）とは、全員がすべてのコードに責任を持つことを意味します。したがって、誰でもコードのどの部分でも変更できます。共同コード所有権は、組織のポリシーであるだけでなく、感情でもあります。「開発者は、システムコンテキストを理解し、問題のコードに貢献し、コードの品質が高いと認識し、製品がユーザーのニーズを満たすと信じ、チームの結束力が高いと認識している場合、チームコード所有権をより強く感じます。」^[7]ペアプログラミング、特に重複ペアローテーションは、この実践に貢献します。異なるペアで作業することで、プログラマーはシステムコンテキストをよりよく理解し、コードベースのより多くの領域に貢献します。

コードの共同所有権により、開発者がエラーを見つけたらすぐに修正できるため、全体的なバグを減らすことができ、開発が加速する可能性があります。ただし、プログラマーは、よく理解していないコードを変更すると、バグが混入する可能性もあります。十分に明確に定義された単体テストは、この問題を軽減するはずです。予期しない依存関係によってエラーが発生した場合、単体テストを実行すると、失敗が表示されます。

共同コード所有権は、メンバーのバックアップの改善、知識と学習の分散、コードに対する責任の共有、コード品質の向上、手直しの削減につながる可能性があります。しかし、メンバー間の対立の増加、バグの増加、開発者の思考フローの変化と推論の中断、開発時間の増加、またはコードの理解の低下につながる可能性もあります。^[8]

プログラマーはソフトウェア設計に「シンプルがベスト」というアプローチを取る必要があります。新しいコードを書くときはいつでも、作成者は「同じ機能を導入するより簡単な方法はあるか?」と自問する必要があります。答えが「はい」であれば、より簡単な方法を選択する必要があります。複雑なコードをよりシンプルにするために、リファクタリングも使用する必要があります。

システム メタファーは、顧客、プログラマー、マネージャーなど、誰もがシステムの仕組みについて語ることができるストーリーです。これは、クラスやメソッドの命名概念であり、チーム メンバーが特定のクラス/メソッドの名前だけからその機能を簡単に推測できるようにします。たとえば、ライブラリ システムはloan_records(class)に対して を作成しborrowers(class)、アイテムが期限切れになった場合は に対して make_overdue 操作を実行する場合がありますcatalogue(class)。各クラスまたは操作の機能は、チーム全体に明らかです。

プログラマーやソフトウェア開発者は週 40 時間以上働いてはならず、ある週に残業があったとしても、次の週にはそれ以上残業があってはならないという概念です。開発サイクルは継続的インテグレーションの短いサイクルであり、完全な開発 (リリース) サイクルはより頻繁であるため、XP のプロジェクトは他のプロジェクトで必要とされる典型的なクラッシュ タイム (残業が必要) に従いません。

また、この概念には、人は十分に休息を取ると最高のパフォーマンスを発揮し、最も創造的に活動できるという考えも含まれています。

持続可能なペースを実現するための鍵となるのは、頻繁なコードマージと、常に実行可能でテストが網羅された高品質のコードです。常にリファクタリングを行う作業方法により、チーム メンバーは新鮮で機敏な思考を身につけることができます。チーム内での緊密な共同作業方法により、週末にリフレッシュする必要性が生まれます。

十分にテストされ、継続的に統合され、頻繁にデプロイされるコードと環境により、予期しない運用上の問題や停止の頻度も最小限に抑えられ、それに伴う業務時間外の夜間や週末の作業も最小限に抑えられます。

• 継続的インテグレーション
• 多段階継続的インテグレーション
• クラス責任コラボレーションカード

• XPプラクティス
• ケント・ベックのXPプラクティス
• ロン・ジェフリーズ XP プラクティス