qe-xp-practices

エクストリームプログラミング（XP）のプラクティス

<default_to_action> XP のプラクティスを適用する際は、以下の手順に従います。

1. すぐに価値を生み出すプラクティスから始めます
2. 支援となるプラクティスを徐々に取り入れます
3. コンテキストに合わせて調整します
4. 結果を測定します

XP の中核となるプラクティス（優先順位順）：

プラクティス	ここから始める	最初に取り組む理由
TDD	✅ はい	あらゆることの基盤
継続的インテグレーション	✅ はい	迅速なフィードバック
ペアプログラミング	✅ はい	知識の共有
集合的所有権	CI＋TDD の後	セーフティネットが必要
小規模リリース	CI の後	インフラに依存

ペアプログラミングのクイックスタート：

Driver-Navigator (Classic):
- Driver: Writes code
- Navigator: Reviews, thinks ahead
- Rotate every 20-30 min

Ping-Pong (with TDD):
A: Write failing test
B: Make test pass + refactor
B: Write next failing test
A: Make test pass + refactor

</default_to_action>

クイックリファレンスカード

XP の 5 つの価値

価値	意味	プラクティス
コミュニケーション	誰もが、全員が何をしているか把握している	デイリースタンドアップ、ペアプログラミング
シンプルさ	動作する最もシンプルなもの	YAGNI、小規模な設計
フィードバック	早く、頻繁にフィードバックを得る	TDD、CI、短いイテレーション
勇気	真実を伝え、適応する	リファクタリング、間違いを認める
尊重	誰もが価値をもたらす	持続可能なペース、ペアプログラミング

中核となるプラクティス

プラクティス	説明	メリット
ペアプログラミング	2 人の開発者が 1 台のワークステーションを使う	品質＋知識の共有
TDD	レッド・グリーン・リファクタリング	自信＋設計
CI	1 日に複数回インテグレーションする	迅速なフィードバック
集合的所有権	誰でも何でも変更できる	ボトルネックがない
持続可能なペース	週 40 時間	長期的な生産性
小規模リリース	頻繁にリリースする	リスクの低減

---

ペアプログラミング

ペアを組むタイミング

状況	ペアを組む？	理由
複雑またはリスクの高いコード	✅ 常に	複数の視点が必要
新しい技術	✅ 常に	学習を加速できる
オンボーディング	✅ 常に	知識の移転
重大なバグ	✅ 常に	2 人で考えるほうがよい
簡単なタスク	❌ 省略	かかる手間に見合わない
調査のためのスパイク	❌ 省略	調査結果の話し合いにはペアを組む

ペアプログラミングで行うこと・避けること

行うこと：

• ✅ 20～30 分ごとに役割を交代する
• ✅ 一緒に休憩を取る
• ✅ 考えを声に出す
• ✅ 質問する
• ✅ セッションは最長でも 2～4 時間にする

避けること：

• ❌ 許可なくキーボードを取る
• ❌ ペアプログラミング中にスマートフォンを確認する
• ❌ 会話を独占する
• ❌ 一日中ペアを組む（疲れます）

---

アンサンブル（モブ）プログラミング

セットアップ： 3 人以上の開発者が 1 つの画面を共有し、ドライバーを交代します

[Screen]
   ↓
[Driver] ← Directions from navigators
   ↑
[Navigator 1] [Navigator 2] [Navigator 3]

交代： ドライバーは 5～10 分ごとに交代します

最適な用途：

• 複雑な問題の解決
• アーキテクチャに関する意思決定
• 新しいフレームワークの学習
• ブロッカーの解消

---

継続的インテグレーション

CI ワークフロー：

1. Pull latest from main
2. Make small change (<2 hrs work)
3. Run tests locally (all pass)
4. Commit and push
5. CI runs tests automatically
6. If fail → fix immediately

ベストプラクティス：

• 頻繁にコミットする（小さな変更にする）
• ビルドを高速に保つ（10 分未満）
• 壊れたビルドはすぐに修正する
• ビルドが壊れている状態でコミットしない

---

シンプルな設計の 4 つのルール

（優先順位順）

1. すべてのテストに合格する - 正しく動作する
2. 意図が明確に伝わる - 明快で表現力のあるコード
3. 重複がない - DRY の原則
4. 要素を最小限にする - 先回りしたコードを書かない

---

エージェントの統合

// Agent-human pair testing
const charter = "Test payment edge cases";
const tests = await Task("Generate Tests", { charter }, "qe-test-generator");
const reviewed = await human.review(tests);
await Task("Implement", { tests: reviewed }, "qe-test-generator");

// Continuous integration with agents
await Task("Risk Analysis", { prDiff }, "qe-regression-risk-analyzer");
await Task("Generate Tests", { changes: prDiff }, "qe-test-generator");
await Task("Execute Tests", { scope: 'affected' }, "qe-test-executor");

// Sustainable pace: agents handle grunt work
const agentWork = ['regression', 'data-generation', 'coverage-analysis'];
const humanWork = ['exploratory', 'risk-assessment', 'strategy'];

---

エージェントの連携に関するヒント

メモリの名前空間

aqe/xp-practices/
├── pairing-sessions/*   - Pair/ensemble session logs
├── ci-metrics/*         - CI health metrics
├── velocity/*           - Team velocity data
└── retrospectives/*     - XP retrospective notes

フリートの連携

const xpFleet = await FleetManager.coordinate({
  strategy: 'xp-workflow',
  agents: [
    'qe-test-generator',   // TDD support
    'qe-test-executor',    // CI integration
    'qe-code-reviewer'     // Collective ownership
  ],
  topology: 'parallel'
});

---

よくある反論

反論	回答
「ペアプログラミングでは 2 倍遅くなる」	コードを書く速度は 15％遅くなりますが、バグは 15％減り、全体としてはプラスです
「TDD をする時間がない」	デバッグにはテストより時間がかかります
「CI のセットアップは難しい」	まずはシンプルに始めましょう。アクション 1 つ、テスト 1 つです
「集合的所有権は混乱を招く」	テストと CI がなければ、そのとおりです

---

関連スキル

• tdd-london-chicago - TDD の詳細
• refactoring-patterns - 安全なリファクタリング
• pair-programming - AI 支援ペアプログラミング

---

覚えておくこと

XP のプラクティスはシステムとして機能します。 無作為につまみ食いしないでください。

• TDD は集団的オーナーシップを可能にします
• CI は小規模なリリースを可能にします
• ペアプログラミングは集団的オーナーシップを可能にします
• 持続可能なペースがすべてを可能にします

エージェントとの連携： エージェントは XP の効果を高めます。人間とエージェントでペアを組みます。エージェントが反復的な作業を担当し、人間が判断力と創造性を発揮します。