开发方法 · 敏捷宣言与极限编程XP

从出生证明讲起：2001 年 2 月，在美国犹他州，17 位「无政府主义者」共同发表了《敏捷软件开发宣言》。必懂的几条：尽早地、持续地向客户交付有价值的软件是最重要的；拥抱变化，即使在开发后期，敏捷过程能够驾驭变化；经常交付可工作的软件，从几周到几个月，时间范围越小越好；业务人员和开发者紧密合作；最有效率的沟通方式是面对面地交流；可以工作的软件是进度首要的度量方式；要简单，尽可能减少工作量；最好的架构、需求和设计来自自我组织的团队；团队定期总结如何更有效率并自我调整。

十二条，17 位签署人，数字别混——1 是年份，17 是人头。这 17 位是这么自嘲的，原文加了引号，考试更可能考的是：至此，敏捷软件联盟建立起来，敏捷软件开发方法进入了大发展的时代。这份宣言是敏捷方法的灯塔，所有的敏捷方法都在向这个方向努力。目前已形成多种敏捷方法，其中 XP 传播最为广泛——这就是为什么教材把 XP 当主讲。

XP 上场。极限编程，英文 Extreme Programming。它的雏形形成于 1996 到 1999 年间，Kent Beck、Ward Cunningham、Ron Jeffery 夫妇在开发 C3 项目——全称 Chrysler Comprehensive Compensation，克莱斯勒综合薪酬项目——的实践中总结出 XP 的基本元素，之后 Kent Beck 和朋友们完善提高，形成了极限编程方法。考过「XP 源于哪个项目」，答 C3 项目。

原文定性：XP 是一种轻量、敏捷、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同有七条：第一，在更短的周期内，更早地提供具体、持续的反馈信息；第二，迭代地进行计划编制，先迅速生成总体计划，再在整个开发过程中不断发展它；第三，依赖于自动测试程序来监控开发进度，并及早地捕获缺陷；第四，依赖于口头交流、测试和源程序进行沟通；第五，倡导持续的、演化式的设计；第六，依赖于开发团队内部的紧密协作；第七，尽可能达到程序员短期利益和项目长期利益的平衡。这七条里考得最狠的是第三条——自动测试监控进度。

XP 由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。接下来按这个骨架讲：先价值观，再实践，一共十二个。

四大价值观，考试第一梯队。XP 的核心是沟通、简单、反馈、勇气四大价值观，它们是 XP 的基础，也是灵魂。真题四个选项长得极像，干扰项把「勇气」换成「尊重」——注意「尊重」不是四大价值观之一，原文的说法是：在四大价值观之下，隐藏着一种更深刻的东西，那就是尊重，因为这一切建立在团队成员相互关心、相互理解的基础上。尊重是「隐藏的第五个」，不是四大之一。

逐个说。沟通：程序员常给人内向、不善言谈的印象，项目中的许多问题就出在缺乏沟通的开发人员身上；传统方法希望借完善的流程和面面俱到的文档、报表、计划替代口头沟通，却又引入效率不高的新问题。所以 XP 组合结对编程这样的实践，鼓励口头交流、通过交流解决问题。简单：XP 秉承「够用即好」，只要今天够用就行，不考虑明天的新问题——这和传统方法要求预先规划、预留扩展空间完全相反。

补一层：沟通和简单之间有微妙的互相支持关系——沟通得越多，越容易明白哪些工作需要做；系统越简单，需要沟通的内容越少，沟通也更全面。然后是反馈：很多项目在需求分析之后很长一段时间没有任何反馈信息，整个开发过程对客户和管理层像黑盒子，进度完全看不到；XP 更进一步，通过持续、明确的反馈来暴露软件状态的问题。及时良好的反馈有助于沟通，简单的系统更有利于测试和反馈。

第四个，勇气：应用 XP 时每时每刻都在应对变化——沟通良好，会有更多需求变更的机会；系统保持简单，新变化会带来重新开发的需要；反馈及时，会有更多打断思路的新需求。开发团队因此处于变化之中，需要有勇气面对快速开发和可能的重新开发。勇气有来源：来源于沟通，它使高风险、高回报的试验成为可能；来源于简单，面对简单的系统更容易鼓起勇气；来源于反馈，及时获得每一步前进的状态，让人更勇于重构代码。

十二个最佳实践，先给个总印象：原文说它们没有一个是创新的概念，大多数概念和编程一样老，其主要创新点在于提供一种良好的思路将这些最佳实践结合在一起，并且确保尽可能彻底地执行。逐个来，前四个偏计划与设计。第一，计划游戏：先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划；计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。

第二，小型发布：XP 秉承「持续集成、小步快走」的哲学，每次发布的版本应尽可能小，前提是有足够商业价值、值得发布；小型发布使集成更频繁，客户获得的中间结果和反馈越频繁，能实时了解项目进展、提出更多意见，实现更高的客户满意度。第三，隐喻：根据词典的解释，是「一种语言的表达手段，用来暗示字面意义不相似的事物之间的相似之处」，常用于四个方面——寻求共识、发明共享语汇、创新的武器、描述架构；找不到合适的隐喻不必强求，顺其自然。

第四，简单设计：强调简单的价值观，引出简单性假设原则，落到实处就是简单设计实践。注意原文专门辟谣：许多批评者指责 XP 忽略设计，这是不正确的——XP 的简单设计不是要忽略设计，而是认为设计不应该在编码之前一次性完成，因为那样只能建立在「情况不会发生变化」或者「我们可以预见所有的变化」之类的谎言的基础上。

第五，测试先行：有些团队的程序员会以「开发工作太紧张」为理由忽略测试，导致恶性循环——越是没空编写测试程序，代码的效率与质量越差，花在找缺陷、解决缺陷的时间也越多，实际产能大大降低；产能降低，时间更紧张，压力更大。所以 XP 把测试放在编码前面。第六，重构：一种对代码进行改进而不影响功能实现的技术，XP 需要开发人员在「闻到代码的坏味道」时，就有重构代码的勇气；重构的目的是降低变化引发的风险、使得代码优化更加容易。

第七，结对编程：20 世纪 60 年代就有类似实践，长年研究的结论是结对编程的效率反而比单独编程更高——一开始牺牲一些速度，之后逐渐加快，主要原因是大大降低了沟通成本、提高了工作质量。它被誉为 XP 保证工作质量、强调人文主义的最典型实践，应用得当还能使团队协作更顺畅、知识交流共享更频繁、团队稳定性更牢固。第八个就是真题主角，我放慢讲。

先讲动机：XP 鼓励结对编程，而且认为结对编程的组合应该动态地搭配，根据任务的不同、专业技能的不同进行最优组合，因此每一个人都会遇到不同的代码，代码的所有制就不再适合于私有，因为那样会给修改工作带来巨大的不便。定义原文是：所谓集体代码所有制，就是团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时 XP 强调，代码是谁破坏的——指修改后出现问题——就应该由谁来修复。

对，而且四个干扰项各有各的坏：「只有架构师拥有修改权」反着来；「归公司所有、个人不负责」把「负责」抠掉了，这四个字恰恰是定义的另一半——拥有和负责是绑定的；「项目经理统一管理」纯属杜撰。另外补一句原文的评价：集体代码所有制是 XP 与其他敏捷方法的一个较大不同，也是从另一个侧面体现了 XP 中蕴含的很深厚的编码情节。这个「与其他敏捷方法的较大不同」的定位也可以出判断题。

剩下四个收尾。第九，持续集成：在小型发布、重构、结对编程、集体代码所有制这些最佳实践中多次提到，持续集成是这些最佳实践的基本支撑条件。第十，每周工作 40 小时：这是最让开发人员开心、管理者反对的一个实践；XP 认为加班最终会扼杀团队的积极性，最终导致项目的失败。要解释的是，40 不是一个绝对数，它代表的意思是团队应该保证按照「正常的时间」进行工作——这也体现了 XP 关注人的因素比关注过程的因素更多一些。

第十一，现场客户：为了保证开发出来的结果与客户的预想接近，最重要的是需要将客户请到开发现场。XP 项目中时刻保证客户负责业务决策，开发团队负责技术决策；有客户在现场明确用户故事、并做出相应的业务决策。第十二，编码标准：拥有编码标准可以避免团队在一些与开发进度无关的细枝末节问题上发生争论，也给重构、结对编程带来便利；但 XP 编码标准的目的不是创建一个事无巨细的规则列表，而是要能够提供一个确保代码清晰、便于交流的指导方针。

数对了。最后压轴一句，考过原文复述：有句经典名言「1 加 1 大于 2」最适合表达 XP 的观点，Kent Beck 认为，XP 方法的最大价值在于在项目中融会贯通地运用这 12 个最佳实践，而非单独使用。当然，可以使用其中的一些实践，但这并不意味着就应用了 XP 方法；XP 方法真正能够发挥其效能，就必须完整地运用 12 个实践。判断题问「团队只采用结对编程和重构就算应用了 XP」——错，原文说得很死。

两个方向：一是考它的用途清单——寻求共识、发明共享语汇、创新的武器、描述架构，四个用途问「不包括哪个」；二是考它「比较令人费解」的地位，原文自己承认隐喻相对而言比较令人费解，还提示找不到合适的隐喻不必强求、顺其自然——判断题说「每个项目都必须找到合适的隐喻」，错。另外「简单设计不是忽略设计」这个辟谣句也常挖空。

本集必背：敏捷宣言 2001 年 2 月、犹他州、17 位签署人，可工作的软件是进度首要度量方式；XP 雏形 1996 到 1999 年、出自 Kent Beck 等人的 C3 项目；XP 由价值观、原则、实践、行为四部分组成；四大价值观沟通、简单、反馈、勇气——尊重是价值观之下更深刻的东西，不属于四大；简单是够用即好；结对编程效率反而更高；集体代码所有制是人人拥有全部代码并对全部负责，谁破坏谁修复；每周 40 小时的 40 不是绝对数；12 个实践要完整运用而非单独使用，1 加 1 大于 2。

敏捷家族的其他成员：FDD 特征驱动开发——它反着来，类是个人所有的；Scrum——Sprint、三个会议、五大价值观，其中「简单」混进 Scrum 价值观里就是个陷阱；还有水晶方法和开放式源码。下一集把敏捷收官。