一些对CMM和XP做过深入研究的人看到这个题目可能会嗤之以鼻——搞错没有？这一个度量的标准，一个是方法论，不是同一范畴，怎么能放在一起比较？
的确，CMM仅指明了每个等级该做什么，并没有告诉人们如何去做，而XP则从方法论上告诉了人们如何去实践。两者不属于同一范畴，但同样对于软件开发而言，它们之间又有那么多的可比性，本文根据个人对两者的理解，谈下个人的观点。
为了便于对CMM和XP不熟悉的朋友理解，在行文前先对两者做以简单介绍。
关于CMM
CMM (能力成熟度模型)是英文Capability Maturity Model缩写。CMM的定义是：有关软件企业或组织的软件过程进程中各个发展阶段的定义、实现、质量控制和改善的模型化描述。
CMM根据软件开发过程能力成熟度共分5个等级，分别是初始级、可重复级、已定义级、已管理级和不断优化级。CMM5个等级共计18个关键过程域、52个目标、300多个关键实践。
CMM的核心思想是过程管理。从第二级开始，每个级等定义了相应的定义和规范。下图很好的表述了5个级别的联系。
CMM中18个关键过程域,分布在2至5级中：
第2级(可重复级)有6个关键过程域,主要涉及建立软件项目管理控制方面的内容。
即：需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件子合同管理(SSM)、软件质量保证(SQA)、软件配置管理(SCM)
第3级(定义级)有7个关键过程域,主要涉及项目和组织的策略,使软件组织建立起对项目中的有效计划和管理过程的内部细节。
即：组织过程焦点(OPF)、组织过程定义(OPD)、培训程序(TP)、集成软件管理(ISM)、软件产品工程(SPE)、组间协调(IC)、同级评审(PR)
第4级(管理级)有2个关键过程域,主要的任务是为软件过程和软件产品建立一种可以理解的定量的方式。
即：定量过程管理(QPM)、软件质量管理(SQM)
第5级(优化级)有3个关键过程域,主要涉及的内容是软件组织和项目中如何实现持续不断的过程改进问题。
即：缺陷预防(DP)、技术变更管理(TCM)、过程变更管理(PCM)
关于XP
XP（Extreme Programming）是一种敏捷软件工程方法，和传统的瀑布模型一样，XP也是一种软件开发模型，极限编程模型。
XP共包含四个核心价值和十二个关键实践。分别是：
四个核心价值——
沟通：项目中发现的问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的，因此，在XP项目中没有沟通是不可能的。
简单：XP认为应该尽量保持代码的简单，只要它能工作就可以。Kent Beck指出与其实现一个复杂的的系统，不如设计一个能够满足目前需要的、简单的系统，因为你所考虑的情况可能永远都不会发生。
反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。
勇气：这是最重要的核心价值。因为XP强调要"拥抱变化"，因此对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。
十二个关键实践——
1． 有计划的开发（planning design）
XP要求要求根据项目进展和技术情况，确定下一版本的功能开发范围；
2． 简单设计( Simple Design )
XP要求代码的设计应该尽可能的简单，只要满足当前功能的要求即可；
3．小版本发行( Small Release )
以较小的增量经常向客户发行版本，然后根据用户反馈决定下一步的开发计划；
4．测试驱动开发( Test-driven )
在编写代码前先编写测试内容，而后再进行编码，直至所有的测试项都得以通过；
5．代码重构( Code Refactoring )
代码重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加软件灵活性和提高性能；
6．系统隐喻( System Metaphor )
通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。XP不需要事先进行详细的架构设计，而是在迭代周期中不断的细化架构；
7．成对编程( Pair Programming )
XP认为在项目中采用成对编程比独自编程更加有效。成对编程是由两个开发人员在同一台电脑上共同编写代码，通常一个人负责写编码，而另一个负责检查代码的正确性与可读性；
8．每周40小时工作制( 40-hour Week )
XP要求项目团队人员每周工作时间不超过40小时，加班不得连续超过两周，否则会影响生产率；
9．持续集成( Continuous Integration )
XP提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试；
10．代码规范( Code Standards )
XP强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档；
11．现场客户( On-site Customer )
XP要求至少有一名实际的客户代表在整个项目开发周期在现场负责确定需求、回答团队问题以及编写功能验收测试；
12． 代码集体所有（Collectively Ownership）
代码公有，提高了代码的透明度，这就意味这每个人都可以在任何时候变更任何代码。
CMM与XP
上面介绍了一些CMM和XP的常识知识，接下来该对两者做以对比分析了。
首先，在适用范围上，CMM主要是面对重型项目(200人以上)的，而XP主要是面对一些轻型项目（50人以下）；
其次，对于需求比较明确的，一般不会变化或者变化比较小的比较适合实施CMM，而对于一些软件需求不明确，需求变化难以控制的项目更适合采取敏捷开发（XP）方法；
再者，实施CMM需求各种复杂文档规范，而以XP为代表的敏捷开发则尽可能避免这些文档；
第四，CMM讲的是做什么，并没有告诉人们如何去做，而XP讲的是如何去做，是方法论；
第五，实施CMM的企业采用的多是瀑布的开发模型，而采取XP开发方法则为迭代开发模型；
CMM现状
无论是CMM还是XP，都有它们存在的价值，实施CMM自然有它的好处，首先获得CMM认证的企业，政府都给予一定的补贴，政府大力支持；再者通过CMM认证，不管其内部具体做的如何，但对于外界而言，至少在企业实力和形象上给人的感觉良好，同样的条件，其接单的胜算就要大出很多。做为你，如果有一个项目让你负责招标，同样良家实力、条件相当的企业来竞表，他们开出的条件都相当，一家通过CMM认证，另一家未通过任何认证，你说你会把项目交给谁来做？肯定是通过CMM认证的那家了！当然，也有人可能不已为然：谁给的回扣多就让谁做贝！这就另当别论了。
所以，也正是因为此，目前很多企业做CMM认证，只是单纯的为了认证而认证，具体落实到实施上，那些所谓的形形色色的文档和评审也只是走走形式罢了。这些严重的违背了CMM的初衷。
下面是曾在实施CMM的一家公司做过的一位员工的感受：“转眼脱离CMM已经一年多了，我去了一间开发人员20来人的公司，今天老总宣布一个震惊的消息，正式启动CMM3……我有一种想哭的感觉。”
如果听到CMM几个字，让员工有种想哭的感觉，痛苦到这种程度，你认为他们能把CMM开展的好吗？
答案是否定的！
当然，这绝不是否定CMM的好处，实施CMM肯定有做的成功的，但并不是所有的企业都适合CMM。
XP现状
实际上XP的风头已远远被CMM的所压制，但这能说XP就不好吗？下面让我们听听思特沃克软件技术总经理郭晓提到的一个案例——
美国一家比较大的保险公司，有一个项目需要做。当时印度有一家公司非常有名，他们使用CMM，他们觉得做出估测这个项目大概两百万美元，最后这个项目是公司用敏捷式方法做出来的。一共花了8个月时间，整个项目成本一共是110万美元。印度这家公司很奇怪，又派了另外一批人来，结果他们做确实需要200万美元需要12个月时间。所以他们也开始逐渐使用敏捷式的开发应用方法。
提到CMM，我想软件从业人员没有不知道的，至于XP，我想知道的可能就不多了。
我想一个最主要的原因就是XP没有相应的认证，如果有相应的认证了，那么可能有很多软件企业就开始追逐起XP来了，并不是为了XP的软件开发思想方法，也不是为了把XP给落到实处，而是为了那个证！
结束语
实际上，我倒认为规定开发人员在开发过程中或者项目结束写些技术总结以及写些日常项目博客是个很不错的方法。
CMM不是软件企业的制胜法宝，XP也不是软件企业成功的秘籍，小平同志说得好：“黑猫白猫，能逮住老鼠就是好猫。”对企业而言，更是如此，不管采取这种规范还是那种开发方法，只要能够开发出高质量的软件，能够给企业带来更多利润的方式方法就是好的。下面还是郭晓的一段话——
如果说，要真正赶上最新一轮的创新浪潮有几个重要的标志，一个是要赶上最新的CMM的转向敏捷开发，印度已经开始这方面的工作。从体系架构角度讲，除了一些先进的架构理念，还有一些架构模式等等，还有开源代码的应用，不仅仅是操作系统，包括数据库、应用服务器、各种开发工具等等有很多的开源工具。
上面这段话的核心思想也就是，无论对于CMM还是XP而言，都没有一层不变的，俗话说：并无常形，水无常势。社会在进步，科技在发展，环境在变化，一切都在变化之中，为了适应新的变化，CMM和XP本身也需要做出变化来适应变化。当然，对于企业而言，自己有自己的实际情况，无论在实施CMM还是采取XP都要具体问题具体分析，在战略上做到高瞻远瞩，在战术上做到灵活多变，在激烈的竞争中，能找到一条适合企业生存和发展的道路才是根本！
| 
