作为合适于高速变化的网络和Web软件开发的编程方法，极限编程（XP）正在被广为提倡。本文从CMM（CMM是一个描述软件开发过程及改进级别的五层模型）的角度，对这个流行的方法学进行了检视。首先，本文提供了XP和CMM的纵览，然后以CMM的角度对XP进行检视。结论是类似于XP等诸如此类的轻量级方法论促进了很多工程化的实践，但是，这些实践可能是有争议的和反产业化的。对于那些对过程改进感兴趣的人来说，应该慎重考虑在企业的业务环境中采用XP的那些思想，因为XP可以被用来从事许多CMM级别2和级别3的实践。反过来，正在采用XP的企业应该仔细考虑那些在CMM中描述的管理和基础架构的问题。

目前，极限编程（XP）已被视为适用于高速变化的网络和Web软件开发的编程方法，尽管对这种方法还有争议，但一些人已在规则严格的软件过程开发模型中使用了它，如在软件能力成熟度模型中。许多正在向e-Commerce迁移的企业也已经具备了CMM规定的初始级别，他们希望了解XP是否并如何能充分从事CMM实践。

关于软件CMM

软件成熟度模型是一个用于构建企业级的被软件组织和周边组织所广泛采用的能力的模型。软件CMM是一个为软件企业描述了良好的工程化实践和管理实践并且规定了改进等级的五层模型。关于CMM的描述非常多，软件CMM对软件开发和维护的过程管理和质量改进概念提供了应用常识；同时软件CMM也是一个行业开发指导，从数百名请求开发现发行版本的CMM软件专家获取输入；软件CMM又是一个组织改进的模型，它隐含了区别于其他任何特定项目的一套等级，但是它已经被证明了在组织转化中是有效的。

那些用于说明模型的实践、子实践和例子是用于指导软件专家在项目中实现哪些过程的必要性做出合理的、充分的、决定的信息性材料。这些信息性材料关注于大项目和大的企业，尤其是在一个可定制的开发或者维护环境中。即使如此，只要应用了常识，在诸如小的创业公司、小项目或者电子商业等截然不同的环境中应用CMM的解释和裁减的程度是相对较小的。软件CMM的评级部分试图抽象化以达到至少从组织优势的角度获得高性能的软件组织的“通用事实”。

除了当一个企业没有分包合同所以不适用软件分包合同管理以外，这些关键过程域和他们的目标适用于任何软件企业。那些关注创新多过操作性优势的公司也许对一致性、可预测性和可靠性不予重视，但是在高度创新的环境中，表现优秀仍然非常重要。

极限编程中的“极限”

极限编程是由Kent Beck、Ron Jeffries和Ward Cunningham提出的一种轻量级（或者敏捷）软件方法论（过程）。XP的应用目标是面向模糊的和（或）快速变化的需求的小型到中型团队。XP团队应当是地理上紧密的，通常少于10个成员。

构成XP基础的关键前提是被一些诸如对象/模式、关系数据库和信息隐藏等技术确认的高成本的变更。作为这个前提的后果，相应的XP过程力图成为高度动态的过程。Beck的书也因此被命名为《拥抱变更》（embrace change），并且XP团队利用短循环的迭代生命周期来应对变更。在XP生命周期中的四个基本的活动是编码、测试、听取反馈和设计。动态机制通过四个方面体现出来：与客户和在团队内部保持持续的沟通，总是关注最简单的解决方案，通过单元测试和功能测试形成快速的反馈（在其他机制中）和主动应对问题的勇气。

XP赞成的绝大多数原则，例如最小化、最简化、进化生命周期、短循环周期、用户参与、良好的编码标准等等，都是具有普遍意义和在任何纪律明确的过程中合适的。

极限编程的12个实践

在实际中，XP是一个高度纪律化的过程。最简化意味着关注系统的最高优先级、最有价值的部分，而不是针对现在还不现实的问题，甚至是当需求和操作环境改变之后就不在需要的问题来设计解决方案。

XP可以被简述为12个实践。虽然很多其他的实践也被认为是XP的一部分，但是这12个实践是一个基础集合。

◎计划——基于业务优先级和技术估计快速地决定下一个发布的范围。客户从业务的角度决定范围、优先级和日期，而技术人员估计和跟踪进度。

◎较小的发布版本——快速地提出一个简单的系统作为初次产品。每个小的周期（2周）发布新的版本。计划和小的发布依赖于客户提供的对功能的简要描述。发布之间相隔2周，而且团队和客户必须对每个故事（简单用例）应该在一个2周的时期内完成达成一致。

◎隐喻——用简单的、共同参与的描述整个系统如何工作的故事来指导所有的开发工作。“隐喻”提供了项目的一个远景描述。

◎简单的设计——在任何时刻都尽可能的简单。因为XP强调持续的重设计，所以详细设计等的文档存在的价值不大，而在绝大多数情况下维护者几乎不相信除了代码以外的任何东西。

◎测试——持续的写能保证无瑕疵运行的单元测试；客户写测试以证明功能已经被完成。“测试然后编码”意味着一个失败的测试项是一个编码的入口评判标准。

◎精化——在不改变行为的前提下通过消除重复、改善通信、简化系统或者增加灵活性来重构系统。

◎结对编程——所有的产品代码都是由两个程序员在一台机器上完成。

◎团队的所有权——任何人在任何时间都可以改进系统的任何代码。团队的所有权意味着在任何时间，任何人可以修改系统的任何一段代码。XP强调的持续集成、频繁回归测试和结对编程都是力图保护在这里出现的问题。

◎持续的集成——当一个任务完成的时候，在一天之内集成和构建系统多次。持续的回归测试意味着没有作为需求变更的结果的功能回退。

◎每周工作40小时——把每周工作不超过40小时作为纪律固定下来；永远不要连续两周加班。

◎与客户一道工作——专职与项目组一起工作的客户真正及时地回答问题。

◎编码规范——制定用于整个代码文件的强调沟通的编码规范。

当采用XP的时候，建议在一个时刻上采用一个XP的实践，永远从事对于团队来说最急迫的问题。正如有人可能认为的一样，XP对于变更的看法是，它只是“规则”——团队只要对评估变更的影响能达成一致就可以在任何时刻改变规则。XP的倡导者认识到XP是群体性密集活动，没有任何单个的人能学会它。尽管如此，必须认识到XP是一个说明出现的行为的“系统”或者“方法论”，并且为了获得XP（宣称的）最大利益，需要一个合理的基本实践的完整集合。

设计体现沟通和最简化

尽管实现过程在不同的环境中可能完全不一样，但是在任何现代软件项目中，XP的价值都能得到体现。沟通和最简化原则是不可或缺的，没有他们甚至很小的项目都面临不可克服的难题。XP的沟通和最简化原则对采用软件CMM的企业来说也是基本的设计原则。当定义过程时，企业应该获取所需要的基本信息的最小集，利用良好的软件设计原则（比如信息隐藏和抽象）来构造这些定义，并且强调可用性和有效性。

当一个系统逐渐变得庞大的时候，一些XP实践也就变得很难实现。当项目变得庞大时，好的体系架构对于项目的成功也就变得日益关键。基于体系结构的设计、变更设计、精化和相似的设计哲学强调以一种系统化的方式来处理变更的需要。这些概念包括基于体系结构的设计和整合的产品团队，可能在一个大项目的环境中更加合适，也许在团队中再结合XP。在某种意义上来说，强调灵活性的体系化设计是任何好的面向对象方法论的目标，所以XP（包括精化）和面向对象是互相合适的。多纪律的团队也是有问题的，因为XP针对的是只有软件的项目。

极限编程过程严谨

使用XP进行过程改进的重要原因是，它几乎不触及软件CMM强调的管理和组织问题。在XP假设的这种高度合作的环境中合适地使用它要求初步进化的管理和合适的组织架构。CMM风格的过程纪律——甚至是到了刻板的程度，XP是严谨的过程，而且XP过程是一个定义明确的过程。

CMM和XP可以被认为是互补的。软件CMM指出了通常要做什么，但是没有说怎么样去做，而XP是一系列的最佳实践，包括了相当精确的“怎样做”的信息——是一个对某种特定环境的实现模型。

在级别2层次上，需求管理被故事、共同工作的客户和持续的集成描述。软件项目计划，被计划比赛和小型发布描述。XP的计划策略隐含着Humphrey的谚语：“如果您不能更好地计划，那就更多地计划”，软件项目跟踪和勘误被“大型可视表格”、项目速率和小型发布的承诺描述出来。承诺过程为XP中的客户和XP团队设置了在战术层面上的明确期望，并且在项目战略层面上最大化了灵活性。在XP中对每周40工时的强调是一个没有在CMM中描述但是被考虑为一个最佳实践的通用管理关注点。XP也强调了在CMM范围之外的开放的工作空间，人以群分的观点。

然而一个独立的SQA组不太可能成为XP文化的一部分。软件质量保证可以被结对编程的文化来描述；在XP环境中结对编程以保证对编码规则的遵从是一个典型的SQA的责任。

软件配置管理被团队所有权、小型发布和持续集成部分描述。虽然没有完整和明确的描述，配置管理隐含在这些XP实践中。团队所有权对大型系统也许是有问题的，在这样的环境下沟通渠道需要正规化以保证有效性，否则可能导致SCM的失败。

在级别3这个层次上，组织过程焦点被团队层面上而不是组织层面上描述，但是在一次采用一个XP的实践和“公正的规则”的哲学上后面隐含着关于过程的焦点。因为XP聚焦在软件工程过程而不是组织架构方面，这个或者其他组织层面上的过程是采用XP的企业需要描述的范围。同样的，过程定义和培训程序被在XP的多种书、文章、教程和网站中部分描述，但是企业资产是在XP范围之外。

软件产品工程化被XP用很多方式描述出来，它们包括隐喻、简单设计、精化、封存过程、编码标准、单元测试和功能测试。设计文档的缺乏在很多诸如高实时、大型系统或者虚拟团队的环境下应该是一个问题。在这样的环境中，良好的设计是成功的关键，而精化策略将冒很大的风险。

跨组合作以共同工作的客户和结对编程来描述。虽然仅限于软件的内容促使多纪律的环境，但是XP在沟通的重点看来会导出一个和集成产品和过程开发一样的基于跨组合作的解决方案。

虽然缺乏组织结构可能会减少它的有效性，但是在代码阅读和编程的意义上，结对编程可能比结对回顾更强。目前在结对编程上的经验数据虽然稀少但是看上去却是非常有效的。对照和比较结对编程和结对回顾这两项技术仍然是一个基于经验进行研究以作为做出具有充分数据支持的结论的领域。

虽然缺陷防止可能在快速的（迭代）循环中的反馈得到了部分描述，但是很少的级别4和级别5的关键过程域被XP以严谨的统计方式来描述。

许多在XP中部分或者根本没有描述的关键过程域在实际项目中毫无疑问是存在的。尽管这样的结论不是那么显而易见，XP不能在没有管理和基础架构支撑的情况下生存。

结论

大多数XP的项目方法是由充分考虑了任何环境的成功实践构成。然而任何这样的实践的价值在和处理同样问题的其他方法相比较的时候都存在争议，所以它们中间的任何一个都不应该被武断地拒绝。

把这些实践按照方法论组合在一起可能是一个和并发工程一样意义上的范例进化。并发工程中的概念已经（存在）数十年了；集成这些范例为一个系统导致一个在如何构建产品中的范例进化。与此相同，XP也提供了一个在编程方面的系统视角，正如软件CMM提供了一个在组织过程改进方面的系统视角一样。需要改进它们能力的组织应该利用它们良好的思想的优点并在选择和实现这些思想中实践常识（规则）。

软件CMM关注于设置有效和高效过程的管理问题，伴随着系统化的过程改进。XP是一个特殊的实践集——一个方法论——它在小的、共同办公的环境中是有效的。特别是和其他的好的工程和管理实践相结合的时候，它们都有可以协作增效的思路。XP是否应该效仿出版物中所说的一样被用于性命相关或者高可靠性系统是有疑问的。虽然缺乏设计文档和对体系结构的不重视可能被大多数现有知识的专家认为是冒险的决定，但是XP的好处之一就是它可以改变和改进以适应不同的环境。

改变XP的风险就是在它的环境中快速提供价值（功能）的特性可能不再出现。选择和改进软件过程的重点仍然应该是让常识（规则）起主要作用——而且当回答具有挑战性的问题时尽可能地利用数据以提供有力的洞察力。

可以得出结论，诸如XP的敏捷方法论提倡很多好的工程化实践，虽然其中一些实践在一个狭小的领域之外可能是有争议的和反产业化的，但是当在一个合适的环境中被充分实现的时候，XP从事了许多CMM级别2和级别3的实践。对于那些对过程改进感兴趣的人来说，应该慎重考虑在组织的业务环境中采用XP中的那些思想，因为XP可以被用来从事许多CMM级别2和级别3的实践。反过来，正在采用XP的组织应该仔细考虑那些在CMM中描述的管理和基础架构的问题。