【IT168 技术文章】
目前国内对于XP方面的研究和应用此起彼伏，各种关于XP的书籍争相出版，对于以XP为代表的"敏捷软件工程"方法的争论也在网络上随处可见。之所以出现这样的情况，是因为国内的用户在软件项目的实施过程中遇到了很多问题，例如项目的交付时间推迟、用户需求变更频繁等，我们的软件工程师迫切的希望能够找到解决问题的"银弹"。对于高度动态、通过非常短的迭代周期来应对需求变化的极限编程方法论来讲，确实能够从一定程度上解决问题。但是，对于国内的软件开发项目来说，XP并非"银弹"，它的一些非常好的实践不是都适合国内的情况。本文结合一个具体的软件开发项目，讨论一下XP 在国内的应用情况。
一． XP简介
1.1 传统软件开发方法
在最近的数十年中，很多企业的CEO们都面临着增加盈利的压力，因此，他们采用各种方法，例如裁员、业务外包、BPR、ERP、CRM等等。以上种种，使得世界500强的大部分企业在20世纪90年代的后期一直保持者二位数的利润增长。但是很多迹象表明，在传统的企业业务模型中已经没有多少可供削减开支的地方，因此，需要进行彻底的改革。在软件开发领域，情况更是如此。
自上个世纪60年代以来，软件工程思想逐渐形成与发展，也出现了很多软件开发模型与方法，例如瀑布模型、快速原型、增量模型和螺旋模型等[1]。而在90年代以后，卡耐基梅隆软件学院推出的CMM，更是对于软件开发的过程管理，提出了确切的衡量指标。但是，最近的研究表明，有50％的项目会拖延交付，有30％以上的项目会超出预算，软件开发领域的项目情况比软件工程刚刚提出的时候相比，只是有很小的提高。详细的数据[4]（数据来自美国GSM研究机构, Michael Mah）如下表所示：
政府信息部门 ( 1979 )
50% 超出预算60％ 延期交付45％ 不能使用29％ 无法交付2％ 交付后不能使用
来自各个行业的210个项目 ( 1997-1999)
40％ 项目延期交付，平均延期交付时间67%30% 项目超出预算，平均超支167％
传统的软件开发过程，以RUP为代表，强调项目的可控性，是一个用例驱动的基于UML和构件式架构的迭代增量式开发过程。RUP定义了初始、细化、实现和部署4个阶段，分别对应着关键里程碑的划分。RUP对于角色、流程、工件和活动的要求是灵活、可配置的，所以它广泛的适用于各种类型的项目。但是，在RUP的各个流程碑，都规定了要交付的成果，尤其是对于需求的变更以及文档，它强调及时的更新与同步。以上这些都决定了RUP是一种重量级的软件开发方法，比较适合大中型的项目和产品开发。
1.2 XP以及其核心价值
最近，出现了很多轻量型的软件开发方法，例如水晶模型、适应模型以及极限编程等。它们都强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用[2]。
Kent Beck在XP的开篇之作《Extreme Programming Explained - Embrace Change》中提出了极限编程这一创新的软件过程方法论。极限编程是一种高度动态的过程，它通过非常短的迭代周期来应对需求的变化。在极限编程中，包括四个基本活动：编码、测试、聆听与反馈，XP项目的状态变迁如下图所示[3][4]：
Kent Beck指出，XP有四个核心价值是我们应该注意的[3][4]：
. 沟通：项目中发现的问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的，因此，在XP项目中没有沟通是不可能的。
. 简单：XP认为应该尽量保持代码的简单，只要它能工作就可以。Kent Beck指出与其实现一个复杂的的系统，不如设计一个能够满足目前需要的、简单的系统，因为你所考虑的情况可能永远都不会发生。
. 反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。
. 勇气：这是最重要的核心价值。因为XP强调要"拥抱变化"，因此对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。
下面我们将要谈到的XP的非常好的实践就体现了上述四个核心价值。实际上，XP中并没有多少新的观点，它的一些非常好的实践也都是长久以来都在使用中的。
1.3 XP的适用环境
从XP项目状态图以及它的核心价值中我们可以看到，XP弱化针对未来需求的设计，非常注重当前的简化。它的实践，有一个非常关键的假设就是开发人员只注重眼前需求而依赖重构来适应需求的变动所带来的风险与开销要小于需求变化使得事先充分设计失效的代价；反之，实施XP就是不明智的[5]。
因此, XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，XP在平衡短期和长期利益之间做了巧妙的选择。
我们可以看到，XP并不是解决问题的"银弹"，它也有不适合的情况。Beck曾经建议在以下情况下不宜采用XP：
. 中大型的项目（项目团队超过10人）；
. 重构会导致大量开销的应用；
. 需要很长的编译或者测试周期的系统；
. 不容易进行测试的应用；
. 团队人员异地分布的项目；
. 不能接收XP文化的组织和团队；
