极限编程(XP)简介
这篇文章是我最近在团队内做极限编程分享的内容整理。
极限编程(XP)的定义
极限编程中的「极限(Extreme)」是指将我们认同的有效软件开发原理和实践应用到极限，频繁地去实践，如：“如果单元测试很重要，那我们就做测试驱动开发。如果集成测试很重要，那就要在一天中进行多次集成，并且反复进行回归测试”。结对编程在提出时更多的是强调”如果代码评审很好，那么我们就一直进行代码评审”，所以我们要做结对编程。结对编程就是两人用同一台电脑完成同一个任务，其中一人负责编码，另一人负责审查代码，从而能够时时刻刻地进行代码评审。
XP 在敏捷中所处的位置
我们先抛开精益，这一块不是我们今天要讨论的。事实上，源自丰田汽车的精益生产方法对敏捷有着巨大的影响。
从图中的包含关系可以看到，Scrum 和 XP 都是敏捷方法的一种，二者有不少交集，但更多的是不同，二者都在敏捷方法中占据着非常重要的位置。
用 Scrum 就可以号称敏捷了吗？
是的，但还不够。
我们先来回顾一下什么是敏捷，我喜欢用这句话来解释敏捷：持续不断地交付对用户最有价值的产品。不管怎么定义敏捷，一定离不开「短周期地频繁交付」。大家思考一个关键问题：当产品的交付周期由以前的数月缩短至 1 - 2 周，甚至进一步缩短到数天时，配置管理和质量保障相关的实践应该如何升级以应对如此频繁的交付上线？这是个现实而又尖锐的问题，仅靠 Scrum 我们是做不到的。
只要召开了每两周一次的Planning, Review, Retro 三大会议和每天的 Daily Scrum，只要用户故事以卡片的形式被记录被追踪，只要迭代范围和进度以燃尽图的形式呈现出来，是否就可以声称我们已经“敏捷”了？答案当然是否定的。这仅仅是安抚我们的情绪，当然这确实为 Scrum 招来了红火的生意，因为 Scrum 的引入的成本实在是很低。在 Scrum 中，我们是不提配置管理（CI/CD）和质量保证（TDD）、自动化测试等。正因为此，Scrum 的门槛低，大家都能采纳，这迎合了很多团队的需求，能够让过程变得有规律可循，并达到一些效果。但如果真的想做好，技术环节的实践一定是逃不掉的。在整个敏捷的实施过程中，持续交付是最难的，需要一定的技术提升，而不仅仅是靠流程。
有越来越多的组织，尽管引入了某些（如 Scrum）敏捷的流程、方法和工具，号称已经“敏捷”，却发现自己仍然深陷代码质量差、软件缺陷多、测试跟不上、返工严重、进度缓慢的状况，大家甚至产生出对敏捷的怀疑情绪。
XP 和 Scrum 的核心区别
简单地说，XP 更关注技术和工程实践，而 Scrum 更关注团队协作和管理实践。这是我总结的二者核心区别，其实很好理解。
极限编程是第一批敏捷开发方法中最具实效的一种。在各种敏捷方法中，极限编程最为重视工程实践。
极限编程核心的测试驱动开发、持续集成、用户故事等具体落地的实践，给研发团队提供了明确有效的指导，使他们得以随时保持软件处于可工作、可交付的状态，使迭代交付高质量软件成为可能。所以我们可以说，没有 TDD，没有持续集成的敏捷只停留于形式，不是真正的敏捷。
极限编程的规则非常简单，采用极限编程很像在玩拼图游戏，你会看到很多小片的拼图，每一个小片单独看起来没有意义，组合起来就会看见一幅完整的图景。这些规则乍一看可能显得幼稚笨拙，但在它们背后有着坚实的价值观和原则支撑。
XP 规则
计划
- 编写用户故事。
- 根据发布计划制定发布时间表。
- 进行频繁的小规模发布。
- 将项目分解成迭代。
- 用迭代计划驱动每个迭代。
管理
- 为团队提供专注开放型办公空间。
- 可持续的节奏。
- 以站会开始每一天。
- 团队开发速度可度量。
- 让团队坐在一起。
- 调整有缺陷的规则。
设计
- 简单原则。
- 设定一个系统隐喻。
- 在设计交流中使用CRC卡。
- 使用Spike方法降低风险。
- 不要过度设计或过早添加不必要的功能。
- 尽可能地重构代码。
编程
- 客户紧密参与团队协作。
- 遵循编码规范。
- 优先编写测试。
- 通过结对编程构建生产代码。
- 一次仅限一对程序员集成代码。
- 持续集成。
- 选一台机器专用于代码集成。
- 代码集体所有。
测试
- 所有代码都必须有单元测试。
- 发布前必须跑通所有单元测试。
- 发现一个Bug要增加一个单元测试。
- 经常性进行验收测试并公布测试结果。
XP 规则间关系
下图是我整理的上述规则之间的关系，各规则之间有着强烈的联系，从关系中可以隐约看出极限编程出现了左右两部分的实践，左边偏项目流程，和 Scrum 重合的部分基本在左边，右边偏工程实践，是极限编程的核心实践。
获得一项技能的唯一方式，就是刻意练习，极限编程也一样，保持专注并大量重复的联系，才能将极限编程实践运用得游刃有余。