极限编程（XP）的核心实践通常包括测试驱动开发、持续集成、结对编程、小步发布和持续重构，它们分别从工程质量、协作方式和交付节奏三个方向缩短反馈周期。不同XP资料在实践数量和命名上略有差异，本文按常见清单说明每项实践的作用及相互依赖关系，帮助读者理解XP“快速反馈、持续改进”的运作机制。
要点总览（TL;DR）
- XP的核心实践通常包括测试驱动开发、持续集成、结对编程、小步发布和持续重构，它们分别从工程质量、协作方式和交付节奏三个方向缩短反馈周期。
- 测试驱动开发把需求转成可执行断言，形成回归保护；持续重构在测试保护下改善代码结构，两者互为支撑。
- 持续集成缩短代码与系统之间的反馈，结对编程缩短人与人之间的反馈，两者互补而非替代。
- 小步发布以短周期交付可运行增量，前提是自动化测试与持续集成到位，否则频繁发布容易把质量问题带到生产环境。
- 这些实践构成一条从编码到业务使用的连续反馈链，团队可按成熟度分批引入，不必一次全部落地。
XP的核心实践由哪几组构成
XP的实践清单在不同书籍和培训材料中并不完全一致。Kent Beck在《解析极限编程》中列出过十余项实践，常见的有测试驱动开发、持续集成、结对编程、小步发布、持续重构、简单设计、集体代码所有权、编码规范、现场客户、每周40小时工作制等。数量差异来自作者对“核心”范围的取舍，也来自XP后续版本的调整。理解XP时，把清单当作一组相互配合的做法，比记住固定条目更有用。
按解决的问题分组，可以更清楚地看到各项实践的分工：
| 分组 | 常见实践 | 主要解决的问题 |
|---|---|---|
| 交付节奏 | 小步发布、短周期迭代、现场客户 | 缩短从需求到可用成果的周期，让业务反馈尽早进入 |
| 工程实践 | 测试驱动开发、持续重构、简单设计、编码规范、集体代码所有权 | 保持代码可修改，降低变更成本 |
| 协作方式 | 结对编程、持续集成、每周40小时工作制 | 减少理解偏差，保持团队可持续的工作节奏 |
分组只是理解工具，实践之间存在交叉。例如持续集成既属于工程实践，也依赖团队协作约定；结对编程既是协作方式，也直接影响代码质量。下面按“代码层反馈—人员层反馈—交付层反馈”的顺序展开。
测试驱动开发与持续重构如何互相支撑
测试驱动开发（TDD）的基本循环是“红—绿—重构”：先针对一个小的行为写测试，运行并确认它失败；再写最少的实现代码让测试通过；最后在测试保护下清理代码结构。这个循环把需求转成可执行的断言，开发者在写实现之前先明确“什么算完成”。
TDD的作用体现在三个方面。第一，测试成为回归保护，后续修改如果破坏已有行为，会立即被发现。第二，先写测试迫使开发者从调用方视角设计接口，接口往往更简洁、更易用。第三，测试本身是需求的可执行记录，新成员可以通过阅读测试理解系统行为。
持续重构指在不改变外部行为的前提下，持续改善代码的内部结构，例如消除重复、拆分过长函数、调整命名和模块边界。重构的前提是有一套能快速运行的测试：没有测试，重构就变成高风险改动；有了测试，开发者可以在每次小改动后立即验证行为未变。
两者形成互相支撑的关系：测试是重构的安全网，让结构调整可以小步进行；重构则让测试代码和产品代码保持可读、可维护，避免测试随着系统演变成难以修改的负担。实践中常见的做法是，每次重构后运行全部相关测试，确认绿灯后再继续下一步。
持续集成与结对编程分别解决什么问题
持续集成的做法是开发者频繁把代码合并到主干，每次合并触发自动构建和自动化测试，结果尽快反馈给团队。它的作用是把集成从“发布前的一次大动作”变成“每天多次的小动作”，让冲突、接口不匹配和回归问题在引入后不久就被发现。持续集成要求主干保持可运行状态，构建失败时团队优先修复，而不是继续叠加新代码。
结对编程的组织方式是两名开发者共用一台工作站，一人操作键盘编写代码，另一人实时审阅、提出问题和设想边界情况，两人按约定轮换角色。它的作用包括：代码在产生过程中就得到评审，减少事后返工；知识在两人之间直接传递，降低关键模块只被一个人理解的风险；复杂设计在讨论中更快收敛。
两项实践的互补性在于反馈对象不同。持续集成缩短的是代码与系统之间的反馈：合并后几分钟内就知道有没有破坏构建。结对编程缩短的是人与人之间的反馈：设计意图、命名习惯和隐含假设在编码当下就被讨论。一个团队可以只做其中一项，但两项同时存在时，代码层面的问题和理解层面的问题都能更早暴露。
小步发布在XP中承担什么角色
小步发布指以短周期交付可运行的增量，每次发布包含一组完整、可用的功能，而不是等到大量功能完成后一次性上线。它的核心作用是缩短从需求提出到业务方看到可用成果的周期，让真实使用反馈更早进入开发循环。反馈越早，调整方向的成本越低。
小步发布成立有前提条件：需要有自动化测试覆盖关键行为，需要有持续集成保证每次合并后的代码可构建、可验证，还需要发布过程本身足够顺畅，例如具备可重复的构建和部署流程。缺少这些条件时，频繁发布容易把质量问题带到生产环境，团队会本能地拉长发布间隔。
需要区分的是，小步发布关注“交付可运行增量”的节奏，Sprint规划、执行、评审和回顾属于迭代管理的组织动作，两者可以配合使用，但概念边界不同。小步发布不要求团队必须采用某种迭代框架，它要求的是每次交付物完整可用、质量可控。
这些实践如何组合成一套反馈机制
把单项实践放回整体，可以看到一条连续的反馈链：测试驱动开发在编码层面把需求转成断言；持续集成在合并层面验证这些断言并暴露集成问题；小步发布把通过验证的增量交给业务方使用；业务反馈回到团队后，通过持续重构调整设计，再进入下一轮测试驱动开发。结对编程贯穿其中，让设计和问题在两人讨论中更早澄清。
这条链的强度取决于最薄弱的环节。缺少自动化测试时，持续集成的构建结果参考价值有限，小步发布也难以保证增量质量；没有持续集成时，小步发布容易把未发现的集成冲突带到用户面前。因此实践引入有先后依赖，团队可以按成熟度分批推进，例如先建立测试与持续集成，再缩短发布周期，最后稳定结对编程的节奏。
举一个具体例子：某需求要求订单金额按新规则计算。开发者先写测试覆盖新旧规则边界，运行失败后实现计算逻辑，测试通过后提交并触发持续集成；集成流水线发现另一分支修改了金额字段类型，构建失败，团队当天修复；修复后增量随小步发布上线，业务方在使用中发现某类折扣未覆盖，反馈进入下一轮测试与重构。整个过程里，缺陷在编码、集成、使用三个环节分别被不同实践拦截。
在工具承载层面，XP实践产生的需求、测试用例、缺陷和集成结果需要被记录和关联，团队才能追踪反馈链。ONES 敏捷研发管理解决方案打通需求、研发、测试流程，将需求提出方、产品经理、研发和测试连接起来；测试工程师可依据迭代需求和验收标准编写测试用例，未通过用例可转为缺陷提交至项目并指派修复；Code Integration 与 Pipeline Integration 可将构建、部署与项目、迭代整合，在 ONES Project 内查看持续集成数据。这些能力承载的是实践落地后的记录与流转，具体实践方式仍由团队约定。
XP实践与Scrum、看板的区别及常见误解
XP、Scrum和看板常被放在一起讨论，但关注点不同。XP的重心在工程实践，回答“代码怎么写、质量怎么保”；Scrum的重心在角色与迭代管理，回答“谁负责什么、一个迭代如何规划、评审和回顾”；看板的重心在流动与在制品限制，回答“工作如何顺畅流过各阶段、哪里堆积”。三者可以组合使用，例如用Scrum组织迭代、用XP实践保证工程质量、用看板观察流动效率。
| 对比维度 | XP | Scrum | 看板 |
|---|---|---|---|
| 主要关注 | 工程实践与代码质量 | 角色、事件与迭代管理 | 工作流动与在制品限制 |
| 典型做法 | 测试驱动开发、结对编程、持续集成、重构 | Sprint规划、每日站会、评审、回顾 | 可视化看板、限制在制品、管理流动 |
| 反馈来源 | 测试、构建、发布与结对讨论 | 迭代评审与回顾 | 周期时间与队列变化 |
常见误解有三类。其一，把结对编程理解为两个人做同一份重复劳动；实际上结对是持续的设计讨论和实时评审，两人角色分工不同并定期轮换。其二，把持续集成理解为“每天合并一次代码”；持续集成强调的是每次合并都触发自动构建和测试，频率通常远高于每天一次，重点是快速验证而非合并动作本身。其三，把重构理解为重写；重构是小步、可验证的结构调整，外部行为保持不变，重写则是替换实现，风险和范围都大得多。
XP实践并非全部强制。团队可以根据项目风险、人员经验和工具条件选择引入顺序，例如先从测试驱动开发和持续集成开始，再逐步尝试结对编程和小步发布。需要说明边界的是，Sprint规划、执行、评审、回顾属于迭代管理的组织方法，Product Backlog的维护与优先级排序属于需求池管理，本文不展开其操作细节。
常见问题
团队刚开始尝试XP，应该先引入哪几项实践？
通常建议先建立测试驱动开发和持续集成这两项基础实践。测试驱动开发为代码变更提供回归保护，持续集成让每次合并后的构建与测试结果尽快可见，两者共同构成后续小步发布和持续重构的前提。等这两项稳定运行后，再尝试结对编程和小步发布，团队对反馈节奏的适应会更平稳。
如果团队当前连自动化测试都很少，可以先从关键模块补测试开始，不必要求所有代码一步到位。引入顺序取决于项目风险与人员经验，没有统一标准。
结对编程会不会降低开发速度？
结对编程在编码阶段投入了两名开发者，短期看单位时间的代码产出可能下降，但它在代码产生过程中就完成了评审和设计讨论，能减少事后返工和知识集中在个别人身上的风险。是否划算取决于任务复杂度：设计决策多、风险高的任务更适合结对，机械性的简单修改则未必需要。
团队可以按任务类型选择性结对，并通过轮换角色保持知识流动，而不必对所有工作都采用同一方式。
持续集成和每天合并一次代码有什么区别？
持续集成的重点是每次合并都触发自动构建和自动化测试，并把结果尽快反馈给团队，合并频率通常远高于每天一次。每天合并一次但合并后不验证，集成冲突和回归问题仍可能积累到发布前才暴露。
落地时更值得关注的是主干是否保持可运行、构建失败后团队是否优先修复，而不是合并动作本身的次数。
小步发布需要哪些条件才能成立？
小步发布要求每次交付的增量完整可用，并且质量可控。支撑条件包括：自动化测试覆盖关键行为，持续集成保证合并后的代码可构建、可验证，发布过程本身可重复执行。缺少这些条件时，频繁发布容易把未发现的问题带到生产环境，团队往往会本能地拉长发布间隔。
小步发布关注交付节奏，Sprint规划、执行、评审和回顾属于迭代管理的组织动作，两者可以配合使用，概念边界不同。
XP实践和Scrum、看板可以一起用吗？
可以。XP的重心在工程实践，回答代码怎么写、质量怎么保；Scrum的重心在角色与迭代管理；看板的重心在工作流动与在制品限制。三者关注点不同，组合使用时各管一块，例如用Scrum组织迭代、用XP实践保证工程质量、用看板观察流动效率。
组合方式需要团队自行约定，XP实践也并非全部强制，可按项目风险、人员经验和工具条件选择引入顺序。
