极限编程 XP

完整的团队

XP项目的所有贡献者都是这个团队的成员并且坐在一起工作。

该团队必须包括一名业务代表，即“客户”，负责提供需求、设定优先级并指导项目。客户或她的助手最好是一个真正的终端用户，熟知对应的业务领域并且知道具体需求。团队当然会有程序员，也可能包括测试人员，他们帮助客户定义客户验收测试。分析师可以充当客户的助手，帮助定义需求。通常还会有一位教练，他帮助团队保持在正轨上运行，并引导整个极限编程的过程。可能会有一名经理，负责提供资源、处理外部沟通、协调活动。

注意，这些角色都不必定专属于某个人：XP团队中的每个人都可以尽其所能做出贡献。最好的团队没有专家，只有具备特殊技能的普通贡献者。

规划游戏

XP规划解决了软件开发中的两个关键问题：预测截止日期将完成什么，以及确定下一步要做什么。这里的重点是指导项目，比准确预测需要什么和需要多长时间要简单得多。

XP中有两个关键的规划步骤，用于解决这两个问题：

发布计划（release planning）。客户向程序员展示所需的功能，程序员估算它们的复杂度。客户基于成本估算以及功能的重要性制定项目计划。最初的发布计划必然是不精确的：在团队开始工作之前我们不知道它们会以多快的速度进行，同时优先级和早期的估算都不是真正可靠的。同时，即使第一个发布计划的准确度足以支持决策，XP团队也会基于实际情况定期修改发布计划。

迭代规划（Iteration Planning）。XP团队在两周的“迭代”中构建软件，在每次迭代结束时交付运行可用的软件。在迭代规划过程中，客户将展示未来两周所需的功能。程序员将它们分解为任务，并估计它们的成本（颗粒度比发布计划中更详细）。根据过往迭代中完成的工作量，团队将针对当前迭代中要纳入的工作签署承诺。

这些规划步骤非常简单，但每隔几周总体的进度情况就完全展示出来，它们为客户提供了非常好的信息和出色的管控节奏。

在XP中没有“百分之九十完成”：一个功能故事要么已经完成，要么就是还没有完成。这种对可见性的关注产生了两种很好的结果：一方面，基于这样的可见性，如果进度不符合预期，客户就可以取消项目。另一方面，足够透明的进度为将来要完成什么提供更可靠的决策，以至于XP项目往往能以更少的压力和负担交付更多需求。

客户测试

作为展示每个所需功能的一部分，XP客户定义了一个或多个自动验收测试，以表明该功能是可工作的。团队构建这些测试，并使用它们向自己和客户证明该功能正确地被实现。自动化很重要，因为当项目的时间紧迫，常规的手动测试就会被跳过，团队因此妥协了质量，这就像夜晚最黑的时候关灯一样。

优秀的XP团队对待客户测试的方式与对待程序员测试的方式相同：一旦测试运行，团队就会保持测试正确地运行。这意味着系统只会改进，始终向前推进，从不倒退。

轻量发布

XP团队通过两种重要方式实践轻量发布：

首先，团队发布在运行中并且经过测试的软件，在每次迭代中交付客户选择的业务价值。客户可以将此软件用于无论是支持评估还是向最终用户发布（强烈建议）等任何目的。最重要的方面是，在每次迭代结束时客户都可以有一个看得见摸得着的软件，这使一切保持透明和真实。

其次，XP团队也会尽可能高频次地发布给终端用户。为了保证高频次发布的高质量，持续集成、用户测试和测试驱动开发等几个比较关键的实践，可以有效提升发布质量。

简约设计

XP团队构建简约但始终合乎需求的设计。从简单出发，随着程序员的测试增加，设计会不断改进，并且在产品开发过程中保持这种状态。XP团队使设计完全符合系统的当前设定的功能。没有浪费的行为，并且软件总是为下一次演进保持就绪的状态。

在XP中，设计不是一次性的，也不是提前就准备好的，而是贯穿项目始终的一项工作。发布计划和迭代计划活动中都有设计环节，此外，在整个项目过程中，团队还通过重构进行快速设计和设计修订。像极限编程这样的增量迭代交付，在整个开发过程中都非常注重设计。

结对编程

在XP过程中所有产出的软件都是由两个程序员并排坐在同一台机器上构建的。这种做法确保所有生产环境的代码至少由一名其他程序员审查，最直接的结果就是产生更好的设计、更好的测试和更好的代码。

让两个程序员做“一个程序员的工作”可能看起来效率很低，但事实恰恰相反。一项结对编程的研究表明在同等工时下，结对可以比两个程序员单独工作产生更好的代码。不仅平衡了后期修复质量所消耗的工时，同时也保护了用户体验。

结对除了提供更好的代码和测试外，还可以在整个团队中促进知识流通。随着结对对象的轮换，每个人都能从别人的专业知识中获益。程序员通过学习以提高他们的技能，从而对团队和公司更有价值。结对，即使是XP之外，对每个人来说都是一个巨大的收获。

测试驱动开发

极限编程痴迷于反馈，在软件开发中，良好的反馈需要良好的测试。不同于传统的开发过程：开发代码->编写测试->运行测试；

测试驱动开发的实践遵循以下路径：

编写失败的自动化测试->运行失败的测试->开发代码使测试通过->运行测试->重复。

优秀的XP团队实践“测试驱动开发”，在很短的时间周期内添加测试代码，然后使其工作，这样团队几乎毫不费力地生成了测试覆盖率接近100%的代码。这意味着程序员可以立即得到关于他们工作成果的反馈，并且这些测试也为软件设计的改进提供了宝贵的支持。

重构

极限编程专注于在每一次迭代中都提供业务价值。为了在整个项目中实现这一点，软件必须经过精心设计。重构过程的重点是消除重复，提高代码的“内聚性”，同时降低“耦合性”。至少三十年来，高内聚性和低耦合性一直被认为是设计良好的代码的标志。

XP团队从一个好的、简约的设计开始，并且总是有一个又好又简约的软件设计。这使他们能够保持自己的开发速度，并且随着项目向前推进通常会提高速度。

当然，重构得到了全面测试的有力支持，以确保随着设计的演进，没有任何东西被破坏。因此，客户测试和程序员测试是一个关键的使能因素。XP的各个实践是相互支持的：它们在一起组合比单独实施更强大。

持续集成

极限编程团队始终保持系统完全地集成，开发人员应该每隔几个小时将代码集成并提交到代码库中。在任何情况下，永远不要将更改保留超过一天。持续集成通常可以避免碎片化的开发工作，每个人都需要使用最新版本，而不应该基于导致集成问题的过时代码进行更改。

持续集成类似是一种“现在付一点钱，或晚点给更多钱”的行为。也就是说，如果你在整个项目中持续、高频地进行小规模集成，就不会在项目快截止的时候才发现需要花几周来集成系统代码，然后花不可预知的时间来修复层出不穷的缺陷，我们称之为“集成地狱”。

其精要在于，确保系统始终在最新版本中工作。

代码共有

在极限编程项目中，鼓励每个人为项目的各个部分贡献新的想法。任何开发人员都可以更改任何一行代码来添加功能、修复错误、改进设计或重构，而没有人会成为变更的瓶颈。这意味着所有代码都得到了更多人的关注，从而提高了代码质量并减少缺陷。

在实践中，集体共有实际上比让一个人专属负责某个模块更具有可靠性，尤其是人员随时可能离开项目。除了提升代码质量外，结对编程实践还可以在整个团队中传播知识。

编码标准

XP团队遵循一个通用的编码标准，因此系统中的所有代码看起来都像是由同一个非常有能力的个人编写的。这里要强调的是，标准的具体内容并不重要：重要的是所有的代码风格看起来都很相似，以一致的模式和风格进行编码，以便每个人都能阅读每个人的代码，保持系统始终运行和集成。

系统隐喻

极限编程团队开发了一个关于程序如何工作的共同愿景，我们称之为“隐喻”。这是对程序是怎样工作的简单比喻，比如作为对基于代理的信息检索系统的描述，其隐喻可以为“这个程序就像一个蜂巢，出去寻找花粉，然后把它带回蜂巢”。

系统隐喻本身就是对一个具有特定目标的简单设计，其目的是能够向新人不通过倾倒大量项目文件的方式解释系统。所以首先其本身应该有能帮助新人快速做出贡献的信息结构，其次是使命名类和方法要保持一致。

有时，可能没有一个足够诗意的隐喻，但是在任何情况下，无论有没有生动的图像，XP团队都会使用一个通用的名称系统，以确保每个人都了解系统是如何工作的，以及在哪里可以找到你想要的功能，或者找到你要添加的功能的正确位置。

可持续的速度

极限编程团队将长期在一起工作，并以一个能够长久持续的速度努力工作。现在人们很清楚，死亡行军式地推进项目既没有生产效益，也没有生产出高质量的软件。加班会耗尽团队的精神和动力。当你的团队变得疲惫和士气低落时，无论继续工作多少小时，他们“完成”的工作都会减少，而不是增加。今天的过度工作偷走了未来的发展进步。尤其是当你的团队本月工作量增加，下个月工作量减少时，你无法制定符合实际的计划。与其强迫人们做超出人类可能的事情，不如召开发布计划会议来改变项目范围或时间。

可持续的节奏有助于你规划发布和迭代，防止你陷入死亡行军。找到你的团队在整个项目中保持一致的完美速度，每个团队都不一样。