极端编程(eXtreme Programming)是一种开发纪律，以简单性、交流、反馈和勇气为基本宗旨。它的做法是以有效的实践规则将整个团队紧密联系起来，通过充分的反馈使团队能随时知道自己的状况和恰当的调节规则以适应自己的特殊情况。

在极端编程XP（XP=eXtreme Programming）中，每一个项目贡献者都是“团队”完整的一部分。这个队伍是围绕着一个每天和队伍坐在一起共同工作的商业代表——“客户”建立起来的。

核心实践：整体团队

极端编程的队伍采用一种简单的方式来进行规划和跟踪，以决定下一步要做什么和预知项目什么时候会完成。聚焦于商业价值，团队通过一系列的通过了客户定义的测试和完全集成的小的发布来创作软件系统。

核心实践：规划策略，小发行版，客户测试

极端编程者通过成对和小组的方式共同工作，通过简单设计和强制测试的代码，不断的提升设计以确保设计总是适合当前的需求;

核心实践： 测试优先开发 设计改进

极端编程队伍会总是保持系统能够集成并且在所有的时间运行。程序员以成对的方式编写所有的产品代码，并且在所有时间内都共同工作。他们以相似的形式编码以保证所有成员都可以按需要理解和改进所有的代码。

核心实践：持续集成 编码标准

极端编程队伍分享一个公共并且简单的系统蓝图。所有成员可以按照一种不时保持同步的节奏进行工作。

核心实践：系统比喻，可接受的步伐

一个XP项目的所有参与者都作为一个团队的成员坐在一起。这个团队必须包括一个业务的代表——“客户”，他提供需求，设置优先度，并掌管整个项目的方向。最好这个客户或者他的助手是一个最终用户，了解该领域，知道什么是所需要的。团队当然还要有程序员。团队可能会包含测试员，他帮助客户定义客户验收测试。分析员可以作为客户的助手，帮助客户定义需求。通常还会有一个指导,他帮助整个团队跟踪、推动开发进程。也可能会有一个管理者，他提供资源、处理对外交流和分工协作。这些职责中没有任何一个是必须某个个人独有的：每一个XP团队的成员都以任何他们所能做到的方式参与，最好的团队没有专家，只有一些有着特殊的技能的一般的参与者。

XP的计划解决软件开发中的两个关键问题：预知在责任期内哪些东西将被完成，并且确定下一步需要做什么。重点是把握项目的正确轨道——这是相当简单明了的——更胜于希望精确预知哪些东西将会需要以及可能花费多少时间——这是相当困难的。在XP这里有两个关键的规划步骤，用来解决这两个问题：

发布计划是一个实践让客户向程序员们演示所希望获得的特性，然后程序员们评估它们的难度。当手中有了代价的评估和这些特性的重要程序的认知之后，客户安排一个项目计划。最初的发布计划需要留有足够的余地：优先级以及评估都不是真实可靠的，并且知道团队开始工作以前，我们都无法确切地了解队伍的开发进度。甚至最初的发布计划也不是足够精确能进行决断，所以XP队伍通常会不时地校正发布计划。

迭代计划是一个实践籍此可以为团队提供每几个开发周的导向。XP队伍通过两周的“迭代”来建立软件系统，在每一个迭代结束时提供可以运行的有实际用途的软件系统。在进行迭代计划时，客户演示下两周内希望完成的特性。程序员们将它们分割成若干个任务，并且评估它们的成本（比发布计划要细致一些）。基于在之前的迭代中完成的工作，团队签定当前迭代中将要承担的工作。

这些计划十分的简单，然而他们为客户提供了非常好的信息和极好的操纵控制。每隔几周，多少进展都可以一目了然。在XP中没有“百分之九十完成”：一个特性故事要么完成了，要么没有完成。关注可视结果方法在于一个很好的小的对立论点：一方面来说，非常直观地，如果进度不能令人满意，客户可以在某一个位置取消项目。从另一方面说，进度是显而易见地，并且判断哪些东西将会完成的能力是很完善的，因此XP项目往往可以在较少的压力下完成更多的需要的东西。

作为每一个所要求特性的演示的一部分，XP客户定义一个或者多个自动进行的接受测试来表明特性已经能够实现。团队实现这些测试并且用它们来向自己和客户证明特性已经被正确的实现了。由于时间的压力，自动化是很重要的，手工测试将被跳过。这就像当黑夜来临的时候，就可以关掉你的灯一样。

最好的XP团队会将他们的客户测试当作程序员的测试一样对待：一旦测试运行了，从此之后团队会保持它能够一直正确运行。这意味着系统只能够被改进，总是向前的，从不会倒退。

XP团队通过两个重要的方式实践小发行版本：

第一，团队在每一个迭代发布可以运行的，测试过的软件系统，提供客户选择的商业价值。客户可以为任何目的使用这个软件系统，无论是评估还是发布给最终用户（强烈推荐）。最重要的方式是在每一个迭代结束的时候软件系统是可见的，并且提交给了客户。这保证了任何事情都是公开和真实的。

第二，XP团队尽可能频繁地发布给他们的最终用户。XP网站项目每天都进行发布，居家项目则每月或者更频繁地发布。甚至可以简包装的产品可以每季度地发运。

这么频繁地创建好的版本也许显得不太可能，但是XP团队每时每刻都在进行着发布。更多信息可以参看持续集成，并请注意这些频繁的发布通过XP中随处可见的测试（如同客户测试和测试优先开发中所描述的）变得现实了。

XP团队建构软件系统为一个简单的设计。他们从简单开始，并且在整个程序员测试和设计改进过程中，他们保持着简单的设计。一个XP团队保持着设计总是刚好适合系统当前的功能要求。这里没有多余的投入，并且软件系统总是为将来做好了准备。

在XP中设计并不是一次性完成的事情，也不是一件从上到下的事情，它是自始至终的事情。在发布计划和迭代计划中都有设计的步骤，在快速设计过程中集合了团队的能力并且在整个项目过程地构中改进设计。在类似于极端编程这样的递增和迭代过程中，良好的设计是本质。这是在整个开发过程中必须更多的关注设计的原因。

在XP所有的产品软件都是由两个程序员并排坐在一起，在同一台机器上共同完成的。这个实践保证了所有的产品代码都至少有一个其它的程序员进行了审视，而结果是更好的设计，更好的测试和更好的代码。

让两个程序员去做“一个程序员的工作”看起来有些效率低下，但是实际上刚好相反。研究表明成对编程在让程序员们单独工作相同的时间内会得到更好的代码。这证明了：两个头脑加在一起比一个好得多。

很多程序员在还没有尝试过的情况下就反对成对编程。这确实需要一些实践来做好它，而且你需要认真地实践数周以上的时间来看到结果。百分之九十的学习过成对编程的程序员都会喜欢这样，因此我们向所有的团队强烈推荐它。

除开提供更好的代码和测试之外，成对也提供了知识在团队中间传递。当成对地程序员交换伙伴时，每个人都会从其它的某个人那里学到新的知识。程序员们在学习，他们的技术在提高，他们对团队和公司来讲变得更有价值。成对，即使它本身在XP过程之外实施，也是每个人的巨大成功。

极端编程围绕着反馈，而在软件开发中，好的反馈需要好的测试。最优秀的XP团队实践“测试优先开发”，在一个很小的循环中增加一个测试，然后让它能够工作。几乎是轻而易举的，团队提供的代码接近100%都有测试程序覆盖着，在绝大多数情况下这是很重要的进步。（如果你的程序员已经提供了更多的现有测试程序，你会拥有更多的力量。将它们保存下来，他们只会提供帮助的！）

仅仅写了测试程序还是不够的：你必须要运行它们。这里，极端编程也是极端的。这些“程序员测试”，或者说“单元测试”是一个完整的集合，每当程序员们发布任何代码到代码库的时候（成对的程序员通常每天发布两次或者更多次），每一个程序员测试必须能够正确的运行。每时每刻都是百分之百运行！这意味着程序员们可以立刻得到有关他们做得究竟如何的反馈。进一步说，这些测试提供了软件设计改进时无价的支持。

极端编程在每一个迭代都关注于提供商业价值。为了在整个项目过程中完成这个目标，软件系统必须有良好的设计。可选择性可能会降低并且最终停滞。因此XP采用一种持续改进设计的过程，称为“重构”，来自于Martin Fowler 的书名，“重构：改进现有代码的设计”。

重构的过程关注在去掉重复（一个低劣设计的明确标志），以及提高代码的“内聚”，还有减少“耦合”。高内聚和低耦合在最近三十年以来被公认为是良好设计的特点。结果就是XP团队从一个好的简单的设计出发，并且总是让软件系统有一个好的简单的设计。这让他们能保持他们的开发速度，并且通常在实际上提高了项目开发速度。

重构自然是通过全面的测试来提供有力的支持的，这些测试用来确认当设计改变的时候不会破坏系统中的任何东西。因此客户测试和程序员测试都是有效的评价因素。XP的实践是相互支持的：他们会比各自独立时更为强壮。

极端编程队伍总是保持的系统完全地集成在一起。我们说每日建构版本是为弱者提供的：XP团队每天都要构建系统很多次。（一个40人的XP团队每天至少集成八到十次！）

这个实践的好处可以通过回想你可能听说过的（或者是亲身参与过的）项目来了解：当系统构建是每周或以更低的频率进行时，通常会陷入“集成的地狱”，在那里所有东西都不能运行而且没有人知道为什么。

极少进行集成会给软件项目带来一系列的问题。第一个，尽管集成是发行好的工作代码的条件， 但是团队并不去实践它，而且通常它被委派给那些对整个系统并不十分了解的人。第二，极少集成的代码通常是——我宁愿说总是——错漏百出。

在一个极端编程项目中，每一对程序员都可以在任何时候改进任何一处的代码。这意味着所有的代码在很多人的关注下获得更多的收益，这样就提升了代码质量并且减少了缺陷。这里还有另外一个重要的好处：当代码仅由单个人负责的时候，要求的特性往往会放到了错误的位置，因为一个程序员发现他需要一个特性但是那段代码却不归他管理。代码的所有者太忙了而不能去增加这个特性，所以这个程序员只好把这个特性加进了这个特性本不应该存在的他自己的代码中。这导致了难看的，难于维护到代码，充斥着重复和低（差）的内聚。

如果有人在他们所不理解的代码上进行盲目的修改时，集体代码所有权可能带来问题。XP通过两种关键技术来避免这类的问题：通过程序员测试来捕获错误，成对编程则表明在不熟悉的代码上工作的时候最佳途径是找一个这方面的专家作为伙伴。为了确保在需要是进行好的修改，这种实践将知识延伸到了整个团队。

XP团队遵循一个公共的编码标准，因此系统中所有的代码看上去都像出自单独一个——非常有能力的——人之手。这个标准的规定并不重要：重要的是要让所有的代码看上去很相似，用来支持集体代码所有权。

极端编程团队对于程序如何运作形成一个共识，我们称之为“系统比喻”。在最佳状态时，系统比喻是关于程序如何运作的一个简单的灵魂描述，例如用“这个程序工作时就像一箱子蜜蜂，外出寻找花粉并带回蜂箱”作为一个基于代理的信息查询系统的描述。

有些时候一个十分诗意的想象可能不会出现。在任何情况下，无论有没有生动的比喻，XP团队都会选用一个公共的命名系统来确保每个人都能理解系统是如何工作的，以及到哪里去找到你所需要的功能，或者找到你要增加功能的正确位置。

极端编程团队都会在这里很长的一段时间。他们努力的工作，并且在一个能够不断维持的步伐下。这意味着在有效的时候他们会加班工作，而且他们经常这样工作来保证每周都有最大的生产力。这恰当的解释了死亡竞赛式的项目既不会有生产力也不会创造有质量的软件系统。XP团队在这里是要胜利而不是要死亡。