【IT168 技术文章】
作为合适于高速变化的网络和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（宣称的）最大利益，需要一个合理的基本实践的完整集合。
