敏捷软件开发——极限编程概述

极限编程实践包括以下几个方面：

Whole Team 完整团队

极限编程希望客户、经历和开发人员能够密切的工作在一起，这样每个人都可以知道别人所遇到的问题，并能够通过合作来解决这些问题。强调开发人员与客户之间的紧密合作，这样就能够及时的得到客户的需求反馈来对变化作出反应。

User Stories 用户故事

用户故事是对于用户需求的一种助记的方法。它可以被用来对某个需求的实现按照优先级和成本估计进行调度，选择优先要实现的功能。

Short Cycles 短交付周期

XP每两周交付一次可工作的软件。在这个每两周的迭代期间，开发人员努力开发可工作的软件来满足客户的某些需求。在每个迭代器的末尾，系统将向客户演示并获得反馈。XP包括两种计划，迭代计划（iteration plan）和发布计划（release plan）。

一个迭代计划一般只有两周，它将产生一次较小改动，这些改动可能不会加入最终的产品中。开发人员首先对于本次迭代有一个预估的能完成的工作量，然后由客户根据这些工作量选择一些重要的用户故事来作为本次迭代计划。一旦迭代计划开始，这些用户故事的定义和优先级将不再被改变。

发布计划的时间跨度一般有三个月（6个迭代周期左右），它将产生一个比较重大的改动，并且会被加入到最终的产品中。与迭代计划不同的是，发布计划并不是一成不变的，你可以在任何时间改变此次发布的内容，取消某个用户故事，或是加入一个新的用户故事，又或者改变某个用户故事的优先级。

Acceptance Tests 验收测试

验收测试用来验证系统的行为是否与客户预期的一样。验收测试通常由业务分析员、质量保证人员和测试人员编写。开发人员可以从这些测试中获得用户故事的真正的行为细节。验收测试将成为项目中真实的需求文档。关于每个项目feature的细节内容在验收测试中被描述，并且成为最终判断这些feature是否被正确的实现的判断标准。

一旦一个验收测试通过，它将被加入到已通过的验收测试中，并且将不允许再次运行失败。这些不断增长的验收测试每天将被运行多次，在每次系统被构建时也要运行。

Pair Programming 结对编程

结对编程可以极大地提高团队间知识的传播范围。结对编程并没有降低编程人员的效率，相反，它显著地降低了软件的缺陷率。

Test-Driven Development (TDD) 测试驱动开发

使用测试驱动开发，在产生代码的同时将拥有一组比较完整的测试用例。这些测试用例允许开发人员来验证程序是否运行正确。每当你对程序做了一次小改动后，你都可以通过运行测试用例来保证它没有破坏现有的系统行为。这个对重构十分有帮助作用。

当你在写能够使测试用例通过的代码时，这些代码将是可测试的。更重要的是，这将产生一个强烈的愿望将模块解耦，以至于我们可以独立的测试它们。因此，用这种方式设计的代码趋向于松耦合。

Collective Ownership 集体所有权

每个人都有权利签出任何代码模块并加以改进。没有任何一个单独的开发人员专门负责某个专门的模块和技术。

Continuous Integration 持续集成

开发人员在每天可以多次签入他们的代码并将其集成到源码树中。签入的规则十分简单，第一个签入的人成功，其余的人需要合并现有的代码。一旦开发人员的改动被集成到系统中，将会构建新的系统。然后将运行系统 中所有的测试用例，包括所有正在运行的验收测试。如果有一些测试用例运行失败，那么需要立即修复它。当所有的测试用例都运行通过，此次改动的签入也宣告完成。

因此，XP团队每天将多次构建系统，他们从端到端来构建整个系统。

Sustainable Pace 可持续的开发速度

软件开发项目不是一次短跑，而是一场马拉松比赛。如果团队在一开始冲刺地很猛，以最快的速度进行工作，那么它将完成任务之前耗尽它所有的精力。为了更快的完成任务，整个团队需要以一个可持续的速度进行开发，保持一个稳定的、适度的速度。

XP的一个准则是团队不应该过度工作。唯一的例外是在一个发布周期的最后一周，这时才应该为最后的发布进行冲刺。

Open Workspace 开放的工作空间

开放的工作空间是指团队中的每个人都在能听见的范围内。这样每个人都有机会知道其他人正陷入麻烦之中，每个人都知道别人的状态。开发人员可以更密切地交流。

The Planning Game 计划游戏

计划游戏的本质是业务人员与开发人员之间责任的划分。业务人员来决定一个feature有多重要，开发人员决定这个feature要花费多大的开销去实现。

Simple Design 简单设计

考虑能使系统运行起来的最简单的方法。先尝试使用最简单的方法去实现它，例如，如果能用写文件来实现就不要使用数据库，只有当真正地迫切地需要时，才把它加入进来。不要重复你的代码，如果你发现你的代码重复，就应该消除它，最好的方法是创建抽象层来减少耦合。

Refactoring 重构

重构是一种通过产生一系列微小的转变使得系统在不改变其行为的基础上改进其结构的实践方法。虽然每一次的转变很微小而琐碎，几乎不值得去做。但是把这些转变放在一起，它们就能够组成对于系统的设计和架构的巨大的转变。

在每次进行细小的转变之后，我们通过运行单元测试来确保我们没有破坏任何系统。然后做下一次转变，接着再下一次。再每次转变之后运行单元测试，通过这种方式，我们可以保持系统在改变设计时是能够正常工作的。

重构是一件我们需要时时不断去做的事。通过重构，我们可以持续地保持代码尽可能的干净、简单和具有表达力的。

Metaphor 隐喻

隐喻是一种将整个系统联系在一起的巨大的视图。归本到底，隐喻是一个名字的系统。这些名字提供了系统中所存在的元素的词汇表，来帮助人们定义它们之间的关系。同时，隐喻也是一个系统的视图。它可以指导开发人员选择合适的名字、选择函数的位置、创建合适的新的类及方法。