eXtreme Programming

eXtreme Programming——通常就简称 XP——是敏捷一族中要求最高的成员。East Agile Tracker 首先是为 XP 打造的；其余一切都由此衍生。

本页介绍 XP 是什么、它为何奏效，以及如何以本工具为规划界面来实践它。

XP 是什么

XP 由 Kent Beck 于 20 世纪 90 年代末创立。第一本书——Extreme Programming Explained: Embrace Change——于 1999 年出版。它和许多事物一样，始于一个备受挫折的团队，他们当时正试图在克莱斯勒交付一套薪资系统。

XP 的押注是：在软件中应对不确定性的正确方式，是去做那些奏效的事，并更频繁地去做。测试？时时刻刻测试。集成？每小时集成。交谈？不停地交谈。规划？每个迭代都规划，并随着所学不断重新规划。

“XP 是一种轻量级方法论，适用于在需求含糊或快速变化的情况下开发软件的中小型团队。” — Kent Beck

五项价值观

XP 命名了五项价值观，其余一切都悬于其上：

沟通——团队会交谈。每天。关于工作、设计、障碍。可能的话面对面。孤岛是敌人。
简单——做能用的最简单的东西。如果你真的需要，可以稍后再增添复杂性。你多半不会需要。
反馈——来自代码（测试）、来自团队（结对编程、评审）、来自用户（频繁发布）。快速获得它。
勇气——对进度、估算和设计讲真话。扔掉不奏效的代码。重构正拖着你后腿的东西。
尊重——团队中的每一个人——以及如今团队中的每一个智能体——都贡献价值。彼此以此相待。

各项实践

XP 以其十二项原始实践闻名，分为四个领域：

规划（Planning）

Planning Game——团队和客户一起规划：接下来做什么、以什么顺序、每一块有多大。
Small Releases——频繁发货。以天计，而非以月。就具体的东西获得反馈。
User Stories——需求是一场场对话，被捕捉为从用户视角写下的简短故事。“作为一个用户，我想要 X，以便 Y。”

设计（Designing）

Simple Design——能通过测试并表达出每一个所需概念的最简单的设计。不多一分。
Refactoring——改进已经能工作的代码的设计。持续不断地。
System Metaphor——一个关于系统如何运作的共享故事，用来让设计决策保持一致。

编码（Coding）

Pair Programming——两名开发者，一个键盘。一人驾驶，一人导航。频繁互换。
Collective Code Ownership——任何人都可以改进任何代码。没有封地。
Continuous Integration——一天多次集成并测试代码。立刻捕捉到破坏。
Coding Standards——约定好的风格，让代码读起来就像出自一人之手。

测试（Testing）

Test-Driven Development（TDD）——先写失败的测试，再写让它通过的代码。
Acceptance Tests——客户以代码或可执行的形式，定义每个故事的“完成”意味着什么。

XP 为何奏效

XP 让人不舒服。结对编程迫使你出声思考。TDD 迫使你在写代码之前就知道成功长什么样。持续集成杀死了你最爱的那些长期存活的分支。小步发布意味着你无法躲在一份六个月的路线图背后。

它之所以奏效，是因为所有这些事都缩短了反馈闭环。你越快发现自己错了，纠正的代价就越低。XP 从根本上说，就是把反馈闭环收紧到极致。

它同样关乎勇气与尊重。你只能在一个彼此足够信任、敢于出声犯错的团队里实践 XP。

有纪律的故事模型

East Agile Tracker 编码了一套特定的规划理论。把本节当作为什么数据模型长成现在这样的操作手册——以及实践中该做（和不该做）什么的实地指南。

为什么这四种故事类型很重要

一切皆是故事，但故事有四种，而这种区分正是要点所在：

Features 带点数，是唯一“计入”速率的东西。这迫使你把工作切分为用户可观察的价值。
Bugs 不计点（为零）。缺陷不挣分，这让返工的代价变得可见，而非受到奖励。
Chores 同样不计点——没有直接用户价值的必要工作（基础设施、重构、搭建）。把它们保持在零，会推动团队尽可能把它们捆绑进功能里，以让价值导向的框架保持诚实。
Releases 是零点标记，用来锚定里程碑，并让工具去预测一个日期。

真正重要的是其行为效应：当缺陷和杂务不计分时，团队会自然而然地倾向于将工作表达为面向用户的功能，并对缺陷成本变得格外敏感。这是一种编码进数据模型的规划纪律。

单一的有序待办列表

三个区域，一条规则。

Icebox 是未排优先级的想法池。
Backlog 是一份严格有序、单一优先级的清单——不允许并列，不许“P1/P1/P1”。
Current 区域容纳活动中的迭代。

产品负责人自上而下地掌管顺序，而其不变量是：待办列表的顶部永远是最重要、规格最完善的，越往下，清晰度合理地递减。靠近顶部却带着含糊验收标准的故事，是一个规划缺陷。Icebox 可以是一片坟场；Backlog 不可以。

速率驱动的自动规划

这是大多数团队在别处拙劣地重新实现的部分。Tracker 式的规划会从近期被接受的点数计算出一个滚动平均速率，并自动把那么多点数的故事拉入下一个迭代——你不必手动“承诺”一个 sprint，经验数据替你做了。有两个值得保留的后果：

你只估算功能，用相对点数（Fibonacci 的 1/2/3/5/8，或我们更紧凑的 0/1/2/3），而非小时。估算是一场定大小的对话，而非一项承诺。
你不玩弄速率。为“显得快”而虚增点数，或者给杂务打点，都会破坏那个让整个系统保持诚实的预测。速率是一台度量仪器，而你不会去篡改自己的仪器。

回报是：发布日期预测变成一项计算而非一场谈判，而与利益相关者的对话，从“你能不能承诺周五前做完 X”转向“以当前速率，这次发布大约落在日期 Y——这里是范围/日期之间的权衡”。

故事生命周期与验收闭环

状态机是 Start → Finish → Deliver → Accept / Reject。关键的状态是 Deliver：工程师把故事标记为已交付，但直到产品负责人对照验收标准明确接受它——或者拒绝它，将其打回——它才算完成。这把一个客户反馈闭环烘焙进了每一个故事，而非把验收推迟到迭代末的演示。

验收标准应在故事开始之前就附在它上面，最好采用 Given/When/Then 形式，以便直接映射到验收测试。INVEST 是检验故事是否成形的理智核验：

Independent——可在不依赖其他故事的情况下发布。
Negotiable——捕捉的是意图，而非一份冻结的规格。
Valuable——对某个用户或利益相关者有价值。
Estimable——团队能给它定大小。
Small——能从容地装进一个迭代。
Testable——拥有可被执行的验收标准。

节奏

规划仪式轻量而规律：

每周一次迭代规划会，给新故事打点，并把待办列表顶部的验收标准敲定下来。
一个聚焦于流动和阻碍的简短每日站会。
每个迭代一次回顾，以调整流程。

迭代通常是一周或两周——短到一个糟糕的估算可以被廉价地发现。

让规划奏效的工程实践

Tracker 式的规划是 XP 可见的那一半；没有工程的那一半，它就会塌掉。

测试优先 / TDD 和一套真正的验收测试套件，是让“delivered”有意义的东西。
持续集成和小而频繁的发布让周期时间保持短暂，于是速率是稳定的而非忽高忽低的。
结对编程（或强力评审）让在制品保持在低位——先完成再开始——这是周期时间上最大的那个杠杆。
一位随时在场的产品负责人，是让接受/拒绝闭环不致停滞的东西。

需要警惕的反模式

那些反复出现的失败：

把 Backlog 当作停车场，而非一份真正的优先级顺序。
给缺陷和杂务估算，让速率显得更好看。
携带无法在一个迭代内完成的巨型故事。一直拆分，直到每个都可独立交付。
任由故事在 Delivered 里堆积，因为没人在接受。

这其中任何一项，都会悄无声息地把一个经验性的系统，重新变回一厢情愿的规划。本工具无法阻止你这么做；它只能让这些事变得可见。每个迭代末都看一看你的 Delivered 列——如果它在增长，那就是你的信号。

配合 East Agile Tracker 的 XP

本工具正是 XP 团队自 Pivotal Tracker 时代以来一直想要的那个规划界面。每个概念都直接对应：

User Stories → Stories

XP 的用户故事就是 East Agile Tracker 的故事。把它们写成 Feature 类型。用描述来记录对话；用评论进行持续讨论。验收标准属于描述。

Planning Game → 看板

XP 中的 Planning Game 是业务和团队之间关于优先级和大小的一场对话。在 East Agile Tracker 中：

产品方在 Backlog 中写故事，并按优先级排序。
团队用点数估算功能（Fibonacci 或 East Agile 尺度）。
系统根据速率自动规划迭代。
团队从 Current 列的顶部开始故事。

就这样。这场“游戏”活在对话里；本工具只负责记分。

Small Releases → Releases（故事类型）

XP 说要频繁发布。Release 是 East Agile Tracker 四种故事类型之一。为每一个发货里程碑创建一个发布；把它拖入它发货的那个迭代。发布会跳过 Started/Finished/Delivered，在你发货时直接走到 Accepted。

Continuous Integration → 故事状态机

状态机本身并非 CI——那是你的构建系统——但 Finished → Delivered → Accepted 这条路径，映照着 XP 所描述的客户验收闭环。完成工作、把它交付给客户、在确认可工作时接受。

Velocity → “昨日天气”

XP 称之为昨日天气：你上一个迭代做了多少，是你这一个迭代将做多少的最佳预测。East Agile Tracker 会自动计算速率——近期各迭代的平均、策略可配置——并用它来自动规划下一个迭代的产能。

Acceptance Tests → Reviews

本工具中的故事评审对应着验收。指派一名评审者（客户、产品负责人，甚至是充当这一角色的智能体）。他们批准或拒绝。拒绝会把故事送回 Started。

Pair Programming → 共同负责

XP 团队在代码上结对。在本工具中，这体现为一个故事上有多个负责人。把两位结对者都指派给该故事；两个名字都会出现在卡片上。

配合智能体的 XP——新实践

XP 写就之时，AI 智能体还无法对软件做出有意义的贡献。我们认为这是 XP 二十五年来最重要的一次更新。

在我们的实践中——也是本工具所为之打造的——一个智能体是一名具名的 XP 团队成员。它有自己的角色、自己的结对伙伴（人类或智能体），以及自己的审计轨迹。它能在规划界面里做人类团队成员所能做的任何事：估算、担任故事负责人、评论、流转、接受评审。

XP 的价值观依旧成立。沟通：智能体通过读取事件流和发布评论来沟通。简单：智能体被约束在你授予它们的角色之内。反馈：智能体的每一个动作都在审计日志里，可即刻评审。勇气：对你的智能体做对了什么、做错了什么，要诚实以告。尊重：智能体队友贡献价值——予以认可。

我们不把智能体塞进本工具里去做编码。我们把规划界面交给人类和智能体共同协作。你带来编码智能体——Claude Code、Codex、你自己的——并通过 API 把它接入本工具。智能体领走故事、做工作、评论、流转。你审阅轨迹并接受。

这就是包容性敏捷规划。它就是 XP，配上它实际拥有的团队。