eXtreme Programming

eXtreme Programming — 通常は単に XP — は、アジャイル一族で最も要求の厳しいメンバーです。East Agile Tracker は XP を第一に作られており、その他すべてはそこから導かれます。

このページでは、XP とは何か、なぜそれが機能するのか、そしてトラッカーをプランニングの土台としてどう実践するかを扱います。

XP とは

XP は 1990 年代後半に Kent Beck によって生み出されました。最初の書籍 — Extreme Programming Explained: Embrace Change — は 1999 年に出版されました。それは、多くの物事と同じように、Chrysler で給与計算システムをリリースしようと苦闘していたチームから始まりました。

XP の賭けは、ソフトウェアの不確実性に対処する正しい方法は うまくいくことを行い、それをより頻繁に行うこと だというものです。テスト？常にテストする。統合？ 1 時間ごとに統合する。対話？絶えず対話する。計画？イテレーションごとに計画し、学ぶにつれて再計画する。

「XP は、曖昧な、あるいは急速に変化する要求に直面しながらソフトウェアを開発する、中小規模のチームのための軽量な方法論である。」 — Kent Beck

5 つの価値

XP は、それ以外のすべてがぶら下がる 5 つの価値を挙げています。

コミュニケーション — チームは対話する。毎日。作業について、設計について、障害について。可能なら対面で。サイロは敵である。
シンプルさ — うまくいきうる最もシンプルなことを行う。本当に必要になれば後で複雑さを加えられる。おそらく必要にはならない。
フィードバック — コードから（テスト）、チームから（ペアプログラミング、レビュー）、ユーザーから（頻繁なリリース）。素早く得る。
勇気 — 進捗、見積もり、設計について真実を語る。うまくいかないコードは捨てる。足を引っ張っているものはリファクタする。
尊重 — チームの全員 — そして今や、チームのすべてのエージェント — が価値を貢献する。それにふさわしく互いを扱う。

プラクティス

XP は、4 つの領域に整理された 12 のオリジナルプラクティスで有名です。

計画

計画ゲーム — チームと顧客が一緒に計画する: 次に何が来るか、どの順序で、各ピースはどれくらいの大きさか。
小さなリリース — 頻繁に届ける。数か月ではなく数日。具体的なものについてフィードバックを得る。
ユーザーストーリー — 要求は会話であり、ユーザーの視点からの短いストーリーとして捉えられる。「ユーザーとして、Y のために X が欲しい。」

設計

シンプルな設計 — テストを通し、必要なすべての概念を表現する、最もシンプルな設計。それ以上はなし。
リファクタリング — すでに動いているコードの設計を改善する。絶えず。
システムメタファー — システムがどう動くかについての共有された物語。設計上の決定を一貫させるために使う。

コーディング

ペアプログラミング — 2 人の開発者、1 つのキーボード。1 人が運転し、1 人がナビゲートする。頻繁に交代する。
コードの共同所有 — 誰でもどのコードでも改善できる。縄張りはない。
継続的インテグレーション — 1 日に何度もコードを統合しテストする。破壊を即座に捕まえる。
コーディング標準 — 合意されたスタイル。1 人が書いたかのようにコードが読めるように。

テスト

テスト駆動開発（TDD） — まず失敗するテストを書き、それからそれを通すコードを書く。
受け入れテスト — 顧客が、コードまたは実行可能な形式で、各ストーリーの「完了」が何を意味するかを定義する。

なぜ XP は機能するのか

XP は居心地が悪いものです。ペアプログラミングはあなたに声に出して考えることを強います。TDD はコードを書く前に成功がどう見えるかを知ることを強います。継続的インテグレーションはあなたお気に入りの長命なブランチを葬ります。小さなリリースは、6 か月のロードマップの陰に隠れることを許しません。

それが機能するのは、これらすべてがフィードバックループを短くするからです。間違っていたと早く気づくほど、修正は安くつきます。XP は根本的に、フィードバックループを可能な限りきつくすることについてのものです。

それはまた 勇気と尊重 についてのものでもあります。XP は、声に出して間違えるほど互いを信頼し合えるチームでのみ実践できます。

規律あるストーリーモデル

East Agile Tracker は、特定のプランニング理論を符号化しています。このセクションは、データモデルがなぜこのような姿をしているかの理由を説明する操作マニュアルとして、そして実践で何をすべきか（そして何をすべきでないか）の実地ガイドとして扱ってください。

なぜ 4 つのストーリータイプが重要なのか

すべてがストーリーですが、4 種類あり、その区別こそが要点です。

Feature はポイントを持ち、ベロシティに「数えられる」唯一のものです。これが、作業をユーザーが観測できる価値へとスライスすることを強います。
Bug は見積もりなし（ゼロ）です。欠陥はクレジットを得ないため、手戻りのコストは報酬ではなく可視化されます。
Chore も見積もりなしです — 直接のユーザー価値がない必要な作業（インフラ、リファクタ、セットアップ）。それらをゼロに保つことで、価値の枠組みを誠実に保つため、チームは可能な限り chore を feature にまとめるよう圧力を受けます。
Release は、マイルストーンを固定しツールが日付を予測できるようにするための、ゼロポイントのマーカーです。

重要なのは行動への影響です。bug と chore が得点しないとき、チームは自然と作業をユーザー志向の機能として表現しようとし、欠陥のコストを鋭く意識するようになります。これはデータモデルに符号化されたプランニングの規律です。

単一の順序付きバックログ

3 つのゾーン、1 つのルール。

Icebox は優先順位付けされていないアイデアの溜まり場です。
Backlog は厳密に順序付けられた、単一の優先順位リストです — 同順位はなく、「P1/P1/P1」もありません。
Current ゾーンはアクティブなイテレーションを保持します。

プロダクトオーナーが上から下までの順序を所有し、不変条件は バックログの最上部は常に最も重要で最もよく仕様化されている ことで、下に進むにつれて明確さが正当に減少していきます。上部近くにあるのに受け入れ基準が曖昧なストーリーは、プランニングのバグです。Icebox は墓場であってよいのですが、Backlog はそうではありません。

ベロシティ駆動の自動プランニング

これは、ほとんどのチームが他所でうまく再実装できない部分です。トラッカー型のプランニングは、最近受け入れられたポイントから移動平均のベロシティを計算し、その分のポイントのストーリーを自動的に次のイテレーションへ引き込みます — あなたが手動でスプリントに「コミット」するのではなく、経験的なデータがそれを代行します。保つ価値のある 2 つの帰結があります。

見積もるのは feature のみ で、時間ではなく相対ポイント（Fibonacci 1/2/3/5/8、または私たちのより引き締まった 0/1/2/3）を使います。見積もりはサイジングのための会話であり、約束ではありません。
ベロシティを操作しない。「速く見せる」ためにポイントを水増ししたり、chore にポイントを付けたりすると、システム全体を誠実にしている予測が崩れます。ベロシティは測定機器であり、自分の機器をいじってはいけません。

その見返りは、リリース日の予測が交渉ではなく計算になることで、ステークホルダーとの会話が「金曜日までに X をコミットできますか」から「現在のベロシティでは、このリリースは Y 日あたりに着地します — スコープ/日付のトレードオフはこうです」へと変わることです。

ストーリーのライフサイクルと受け入れループ

状態機械は Start → Finish → Deliver → Accept / Reject です。決定的な状態は Deliver です。エンジニアはストーリーを delivered とマークしますが、プロダクトオーナーが受け入れ基準に照らして明示的に accept する（あるいは reject して差し戻す）までは完了ではありません。これは受け入れをスプリント末のデモまで先延ばしにするのではなく、すべてのストーリー 1 つ 1 つに顧客フィードバックループを組み込みます。

受け入れ基準は、ストーリーが開始される前に、理想的には受け入れテストに直接対応づけられるよう Given/When/Then の形式で、ストーリーに記載されるべきです。INVEST は、ストーリーが適切に形成されているかどうかの健全性チェックです。

Independent（独立している） — 他のストーリーなしにリリースできる。
Negotiable（交渉可能） — 凍結された仕様ではなく、意図を捉える。
Valuable（価値がある） — ユーザーまたはステークホルダーにとって。
Estimable（見積もり可能） — チームがサイジングできる。
Small（小さい） — イテレーションに余裕をもって収まる。
Testable（テスト可能） — 実行できる受け入れ基準を持つ。

ケイデンス

プランニングのセレモニーは軽く、規則的です。

新しいストーリーをポイント付けし、バックログ上部の受け入れ基準を固める、週次の イテレーション計画ミーティング。
フローとブロッカーに焦点を当てた、短い デイリースタンドアップ。
プロセスを調整するための、イテレーションごとの レトロスペクティブ。

イテレーションは通常 1 週間か 2 週間です — 悪い見積もりを安く発見できるほど短いのです。

プランニングを機能させるエンジニアリングプラクティス

トラッカー型のプランニングは XP の目に見える半分です。エンジニアリングの半分なしには崩れ落ちます。

テストファースト / TDD と本物の受け入れテストスイートこそが、「delivered」に意味を持たせるものです。
継続的インテグレーション と小さく頻繁なリリースが、サイクルタイムを短く保ち、ベロシティをでこぼこではなく安定したものにします。
ペアプログラミング（または強力なレビュー）が仕掛り作業を低く保ちます — 始める前に終わらせる — これがサイクルタイムに対する最大の梃子です。
手の空いたプロダクトオーナー こそが、受け入れ/却下ループの停滞を防ぐものです。

注意すべきアンチパターン

繰り返される失敗。

Backlog を真の優先順位ではなく駐車場として 扱う。
ベロシティをよく見せるために bug と chore を見積もる。
イテレーション内に終わらせられない 巨大なストーリー を抱える。独立してデリバリー可能になるまで分割する。
誰も受け入れていないために、ストーリーが Delivered に積み上がるのを放置する。

これらのいずれもが、経験的なシステムを静かに希望的なプランニングへと戻してしまいます。トラッカーはあなたがそれを行うのを止められません。ただそれを可視化できるだけです。すべてのイテレーションの終わりに Delivered 列を見てください — それが増えているなら、それがあなたへのシグナルです。

East Agile Tracker での XP

トラッカーは、XP チームが Pivotal Tracker の時代から欲しかったプランニングの土台です。すべての概念が直接対応します。

ユーザーストーリー → ストーリー

XP のユーザーストーリーは East Agile Tracker のストーリーです。それらを Feature タイプで書きます。会話には説明を、継続的な議論にはコメントを使います。受け入れ基準は説明に記します。

計画ゲーム → ボード

XP の計画ゲームは、優先順位と大きさについてのビジネスとチームの間の会話です。East Agile Tracker では:

プロダクト担当者が Backlog にストーリーを書き、優先順位で並べる。
チームが feature をポイントで見積もる（Fibonacci または East Agile スケール）。
システムがベロシティからイテレーションを自動計画する。
チームが Current 列の上部からストーリーを開始する。

それだけです。「ゲーム」は会話の中にあり、トラッカーはただスコアを記録します。

小さなリリース → リリース（ストーリータイプ）

XP は頻繁にリリースせよと言います。Release は East Agile Tracker の 4 つのストーリータイプの 1 つです。すべての出荷マイルストーンにリリースを作成し、それを出荷するイテレーションへドラッグします。リリースは Started/Finished/Delivered を飛ばし、出荷したときに直接 Accepted へ進みます。

継続的インテグレーション → ストーリー状態機械

状態機械はそれ自体が CI ではありません — それはあなたのビルドシステムです — が、Finished → Delivered → Accepted の経路は、XP が説明する顧客受け入れループを反映しています。作業を終え、顧客に届け、動作が確認されたら受け入れる。

ベロシティ → 「昨日の天気」

XP はそれを 昨日の天気 と呼びます。前回のイテレーションでどれだけ終わらせたかが、今回どれだけ終わらせるかの最良の予測です。East Agile Tracker はベロシティを自動的に計算し — 直近のイテレーションの平均、設定可能な戦略 — それを使って次のイテレーションのキャパシティを自動計画します。

受け入れテスト → レビュー

トラッカーのストーリーレビューは受け入れに対応します。レビュアー（顧客、プロダクトオーナー、あるいはそれを担うエージェント）を割り当てます。彼らは承認または却下します。却下するとストーリーは Started へ差し戻されます。

ペアプログラミング → 共同所有

XP チームはコードでペアを組みます。トラッカーでは、これは 1 つのストーリーに複数のオーナー として現れます。両方のペアをそのストーリーに割り当てれば、両方の名前がカードに表示されます。

エージェントとの XP — 新しいプラクティス

XP は、AI エージェントが意味のある形でソフトウェアに貢献できるようになる前に書かれました。私たちはこれを、25 年で XP への最も重要なアップデートだと考えています。

私たちの実践では — そしてトラッカーがそのために作られているのは — エージェント は名前を持つ XP チームメンバーです。独自の役割、独自のペアパートナー（人間またはエージェント）、独自の監査証跡を持ちます。プランニングの土台において 人間のチームメンバーができることは何でもできます: 見積もり、ストーリーの所有、コメント、遷移、レビューの受け入れ。

XP の価値は今も成り立ちます。コミュニケーション: エージェントはイベントストリームを読み、コメントを投稿することでコミュニケーションします。シンプルさ: エージェントはあなたが付与した役割に制約されます。フィードバック: すべてのエージェントのアクションは監査ログにあり、即座にレビュー可能です。勇気: エージェントが何を正しくやり、何をやらなかったかについて正直であってください。尊重: エージェントのチームメイトは価値を貢献します — それを認めてください。

私たちはエージェントをトラッカーの中に置いてコーディングをさせるのではありません。プランニングの土台を、人間とエージェントが一緒に働くために提供します。コーディングエージェント — Claude Code、Codex、あなた自身のもの — を用意し、API を介してトラッカーに接続してください。エージェントはストーリーを引き受け、作業を行い、コメントし、遷移させます。あなたはその証跡をレビューして受け入れます。

これが インクルーシブなアジャイルプランニング です。それは XP であり、実際に持っているチームとともに行うものです。

さらに読む

Extreme Programming Explained — Kent Beck の基礎となる書籍、1999 年。
アジャイルマニフェスト — 一族が始まった場所。
アジャイル開発 — より大きな全体像。
操作手順 — トラッカーの実践ガイド。
API ガイド — あなたのコーディングエージェントを接続する。