极限编程XP只是TDD和结对编程吗？敏捷开发的XP实践

相信你肯定听过大名鼎鼎的TDD（测试驱动开发）和结对编程，或许还知道它们是极限编程的关键实践。

不过极限编程（Extreme Programming，简称XP）的关键实践远不止这些，涵盖业务实践、团队实践和技术实践，与Scrum一样，绝对称得上是敏捷开发实践的经典。

实际上，鲍勃大叔在《敏捷整洁之道》一书中称，极限编程的实践是所有敏捷过程中，定义得最好、最完整、最不混乱的，其他敏捷过程都是极限编程的子集或变体，比如极限编程实践中面向业务的实践相当于Scrum流程。极限编程是敏捷本质核心的原型，也是最好的代表。

极限编程之父 Kent Back 在《解析极限编程：拥抱变化》一书中详细阐述了极限编程的实践^[2]^。罗恩·杰弗里斯用 Circle of Life（生命之环）来描述极限编程实践。

外圈展示了极限编程面向业务的实践，中间的圈是面向团队的实践，最里面一圈是技术实践。

面向业务的实践为软件开发团队和业务沟通的方式以及业务和开发团队管理项目的原则提供了框架。包括：

1、计划游戏（Planning Game）：外圈的核心。把项目分解为特性、故事和任务，关注速率图和燃尽图。为特性、故事和任务的评估、优先级排序和排期提供了指引。

2、小步发布（Small Releases）：指导团队以小块的方式开展工作。

3、验收测试（Acceptance Tests）：为特性、故事和任务提供“完成”的定义，应当由业务方负责说明需求的规格。向团队展示如何制定明确的完成标准。

4、完整团队（Whole Team）：传达这样一种理念，软件开发团队由许多不同的职能人员组成，包括程序员、测试人员和管理人员，为同一个目标而工作。

面向团队的实践提供了开发团队在团队内进行沟通和管理的框架和原则。包括：

1、可持续节奏（Sustainable Pace）：软件项目是一场马拉松，为了获胜需要均匀配速。每周工作40小时，还要保障充足的睡眠。这些可以防止开发团队在完成任务之前过快地消耗资源和精力。

2、代码集体所有（Collective Ownership）：任何团队成员都可以随时检出代码，并改善项目中的任意模块。团队集体拥有代码。这确保团队不会被项目分割成一对信息孤岛。

3、持续集成（Continuous Integration）：开发人员每隔一两个小时就把代码合并入主干。使团队专注于频繁地进行反馈闭环，以随时了解他们目前的进展。

4、隐喻（Metaphor）：隐喻的概念是，为了有效地进行沟通，团队需要一个受限制的、有纪律的词汇表，包括项目中的术语及概念。隐喻是为了团队和业务部门的交流使用。其实，隐喻就是DDD中的统一语言（Ubiquitous Language），这才是隐喻该有的名字。

顺便提下Scrum的站会：

每日站会是可选的，即使开也不一定每天都开，大型团队也只花10分钟左右，基本思路是团队成员站成一圈，并回答3个问题：

（1）上次会议之后我做了什么？

（2）下次会议之前我将做什么？

（3）什么阻碍了我？

这才是站会的“正确姿势”。

如果可以再加个问题，可以加上：（4）你想要感谢谁。公开表示认可，让团队气氛更融洽。

敏捷是一组原则、实践和纪律，帮助小型团队构建小型软件项目。

技术实践用于指导和约束程序员，来确保得到最高的技术质量。包括：

1、结对编程（Pair Programming）：两人（或更多人）可以一起解决同一个编程问题，而且相当有效，也算是代码评审的一种形式。这一点也引起了大量争议。结对是可选的，也是有间歇性的。让技术团队及时分享知识、及时审查和实时协作，推动团队不断创新并保持准确性。

2、简单设计（Simple Design）：仅编写必要的代码，使程序结构保持最简单、最小和最富表现力。规则包括，所有测试通过，揭示意图（已于阅读和自我表达），消除重复，减少元素。简单设计指导团队避免精力浪费。

3、测试驱动开发（Test Driven Development）：先写一个失败的测试，然后写刚好使测试通过的生产代码。TDD可以描述为以下3条简单的规则：

（1）开发者先编写一个因为缺乏生产代码而失败的测试，然后才能编写生产代码。

（2）只允许编写一个刚好失败的测试——编译失败也算。

（3）只允许编写刚好能使当前失败测试通过的代码。

测试是程序员的完美文档，编写代码变成一连串的小成功，让人很有成就感。遵循三原则可以带来强大的好处：更少的调试，高质量的相近文档，有趣、完备的测试以及解耦。

但实践TDD真正的原因是勇气，让我们有勇气去修改代码，让代码保持整洁有序。敢于修改代码，这让我们表现得更像是一个专业人士。

TDD是技术团队在快速推进的同时得以保持最高质量的安全绳。

4、重构（Refactoring）：TDD 三规则结合重构过程，就是广为人知的“红-绿-重构”。重构鼓励对所有工件进行持续的改进和完善。

（1）创建一个失败的测试。

（2）使测试通过。

（3）清理代码。

（4）返回步骤1。

这些实践与《敏捷宣言》的目标高度一致。

极限编程这是一个多么令人振奋的名字，学习并践行极限编程，把我们的编程推向极限，把我们的敏捷开发实践推向极限！

参考：