XP是与众不同的，它具有快节奏、高效率、轻量等鲜明特点。其开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，就可以看见一幅完整的美丽的图片。

极限编程（Extreme Programming，XP）是一项针对业务和软件开发的规则，它的作用在于将业务需求和开发技术的力量集中在共同的、可以达到的目标上。

XP是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效地响应客户的需求变化，哪怕是在软件生命周期的后期。

RUP强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。XP是一种突破传统软件开发理念限制全新的方法论，即继承了传统观念中的精华，又响应的补充了新的元素。和所有的软件开发方法论“从实践中来到实践中去”一样，XP实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5年，已经被成功地应用在许多大型的公司。

XP的成功得益于它对客户满意度的特别强调，XP是以开发符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效地响应客户的需求变化，哪怕在软件生命周期的后期。同时，XP也很强调包括项目经理、客户、开发者在内的团队合作。只有软件项目团队团结在一起来保证高质量的软件。

XP其实是一种保证成功的团队开发的简单而有效的方法。

XP有独具特色的价值观:交流，简易，回馈，勇气。XP的核心价值观并不是对软件开发过程本身的要求与规定，而是在精神层面对软件开发团队的要求与指引。

XP程序员之间紧密的相互交流，XP程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP程序员就可以自信地面对需求和软件技术的变化。

XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们哪些改变。

XP属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量级开发方法而言。简单地理解，“量”的轻重是指用于软件过程管理和控制的、除程序的量以外的“文档量”的多少。

XP等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助“预见、管理、决策和控制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装上阵。

极限编程强调软件开发团队将任务或产品细分为可以在较短周期解决的多个子任务或模块，并且强调测试、代码质量和及早发现问题。

通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更做出响应。

XP的制胜绝招

如果从中国传统的武侠角度来看待软件开发的方法，那么每一种方法都有其独到的招数，XP也不例外，XP理论体系的表现实际上是覆盖软件项目生命周期的具体项目实施方法，那么也就是XP的多种制胜绝招。

计划游戏(The Planning Game)

计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。正是通过持续不断的计划游戏，才使得项目真正的能够适应需求的变化，并且主动的迎合变化。

结对编程(Pair programming)

所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。这保证所有的代码都有至少两个开发人员了解情况，降低因为个别开发人员离开之后带来的风险。

测试(Testing)

XP中的测试包括:单元测试和验收测试，值得注意的是XP引入了客户参与测试的概念。技术人员的测试报告中往往只关注功能性和程序强壮性方面的测试点，而客户参与的测试则能更早的发现问题，有助于尽早的解决问题。

重构(Refactoring)

重构是对代码本身进行改进而不影响功能展现的行为，XP提倡在实现功能前和实现功能后进行重构，保证采用{zy}化的技术方式来最恰当的实现功能。在没有代码实现之前和代码实现之后对问题的看法{jd1}是不一样的，因此XP强调在代码实现之后对代码的重构。

简单设计(Simple Design)

XP所提出的简单设计并不是说设计工作本身要简化，而是在保证设计工作能够指导系统实现的前提下尽量简单。XP并不提倡在开发之前做详细入微的设计，而是提倡设计工作伴随着开发逐渐深入，这样能够保证设计工作是xx符合系统要求的。

共同拥有代码(Collective Code Ownership)

团队中每一个成员都拥有代码的签出和修改权，要求每一个成员都要对代码负责。这也是XP积极和激进的一面，在保证代码质量的同时也有利于提高团队协作效率。

持续集成(Continuous Integration)

持续的代码集成有利于降低项目整体的风险，因为在每一次集成过程中都是所有代码经过单元测试的，因此要求所有代码都要能够正常运行，而代码的集成有利于提前发现代码潜在的问题。

现场客户(On-site Customer)

XP要求有一位在开发现场的客户帮助开发团队来对开发出来的产品进行持续测试，避免开发人员的想当然行为影响最终提交产品的使用价值。在很多项目中，往往是开发人员闭门造车几个月后，真正进行试运行时客户才发现眼前的软件并不是他们想要的。

小型发布(Small Release)

持续发布不同的小版本产品，并且保证每一个版本的产品都有稳定的且业务价值上的增强。小型的发布是及时发现问题并且解决问题xxx的一种途径。

每周40小时工作制(40-hour Week)

XP认为大量的加班会消磨开发人员的激情与斗志。而理想状况下应该是，每天的八小时所有开发人员都精力充沛充满热情的全身心投入到工作中，正常下班之后都感到疲劳和满足。这已经是超出了技术范围之外的问题了，足见XP作为软件项目的开发规则其实并不仅仅是怎么样写好代码的一些规则，更蕴含有团队管理的深层次理论。

编码规范(Code Standards)

没有一个统计的编码规范会造成团队的每一个成员无法迅速的掌握其他开发人员写出的代码，影响团队整体的协作性。

系统隐喻(System Metaphor)

XP中的系统隐喻为开发团队提供了一幅统一的画面，使用这一画面，任何一个开发人员都能够xx的描述系统的整体结构，新增模块的实现方式等。

XP带给我们的变化

通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。是这样么？XP认为事实并非如此。

在大多数项目中开发人员的人力成本费用往往是硬件费用的20倍左右，也就是说如果一个项目中开发人员人力成本是200万那么可能需要的购买硬件的费用应该是10万。但是,有开发人员会这样说:“经过我们对技术的改进，发现一种方法可以节省20%的硬件开销”，然而他们所付出的代价是代码的冗余、不便于维护甚至是垃圾代码的产生，他们会说:“但是我们节省了20%或者2万，很大的节省”。

反之，如果开发人员写出的代码简单而且容易扩展，那么将至少节省10%的后续维护等方面的人力成本，一笔更大的节省，这是我们所有开发团队{ldz}一定会注意到的一些事情。另外一个对最终用户来说很重要的问题,就是程序的bugs。XP不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，从而{zd0}程度的降低项目的风险。

在编码的所有阶段，测试人员都不断增加测试用例。当找到bug时，在改正bug的同时，还针对这个bug添加新的相关测试，形成一种完善的bug处理机制，保证同一个bug不出现两次，这样的做法为最终的产品提交打下坚实的基础。需求变更是所有项目中都不能避免的问题，经过大量实践发现，多数的需求变更都是在最终用户切身使用过软件产品之后提出的。

因为在一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP却不一样，它通过加强最终用户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP中，提倡让最终用户参与到软件产品的开发中来，{zd0}限度的降低了需求变化带来的风险。

之所以说XP是一种积极的轻量级软件开发指导方法，是因为XP更加注重于具体的开发过程，因为只有对开发过程进行严格的规范和管理才能获得更高的代码质量。因为最终客户关心的软件产品质量的决定因素就在于代码的质量，只有对微观代码质量有保证才能提高宏观的软件产品质量。

我们什么时候用XP

XP方法的产生是因为难以管理的需求变化，在很多软件项目中从一开始最终用户可能并不是很xx的知道他们要的系统是怎么样的，由他们提交给开发团队的需求可能是每隔一段时间就会发生变化。在大多数软件开发项目中不断变化的需求是{wy}的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。

XP方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个业务逻辑复杂、技术要求高的系统，而且对于项目开发团队来说，没有相关系统的开发经验，这个项目{jd1}是一个新的挑战，项目的风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP将可以减少风险，增加成功的可能。

XP方法是为小团体开发建立的，在2-10个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一贯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。XP方法需要一个扩展的开发团体，XP团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。

另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。

记住:哪儿有需求，哪儿就应该有测试的方法。

XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈和勇气”的态度来对待XP;轻松愉快地来感受XP的实践思想;自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值;有勇气接受它，或改进它。

在XP方法的众多优势的之中，{zh1}一条是生产力。在同样的合作环境下，XP项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP方法学的真正目标。XP真实追求的目标是:在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，这是很重要的方面，你就可以选择XP了。

图1 项目人员合作图

极限编程的核心价值观

极限编程中有独具特色的核心价值观：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。