CMM到底给我们带来了什么？

CMM中有用户满意这个KPA么？

CMM只是说该做什么，而没有说如何做，我们从中只是学习分析问题的方法

CMM关注的是整个软件过程而不关心采用什么技术或框架

我们需要来讨论一下在 21 世纪的今天，究竟是什么构成了软件企业的核心竞争力。
如果 CMM 对于增强软件企业的这些核心竞争力帮助不大甚至在某些方面反而形成了阻碍，那么仅仅引用一些书本上的宣传是没有任何意义的。毕竟商业是实打实的东西，每天银子都在不停地流出去，这不是开玩笑的事情。

另外对于外包类的软件企业和自主设计开发的软件企业，其核心竞争力有相当大的差别，这个是我们需要分别讨论的。对于大型软件企业例如华为，和中小型软件企业，其核心竞争力也是有很大差别的。考虑到目前中国绝大多数软件企业都是中小型软件企业，我们讨论清楚了这些企业的核心竞争力才是最有帮助的。

不同类型软件企业核心竞争力的问题讨论清楚后，我们对于 CMM 所适用的范围和场合也就有了一个比较清晰的认识。

对你说的复杂系统工程和认知学很感兴趣，也许对软件开发方法论而言，他们是最根本的基础，复杂系统工程学我有一些了解，认知学没有概念。能不能谈谈认知学的基本内涵？

据我所知,似乎没有。

个人意见，CMM体系中注重的是流程，认为软件开发甚至可以推广到任何事只要按照卓有成效的流程运作就可以完成其时间再现性。也就是说你按照一个标准去做了，那么你就可以得到一个可以预见到的结果。正如前面所说，软件开发的工程学恰恰只能说是经验积累，因为每次开发，每个项目都有其个体性，所以统计学上的数据并不能给下次开发带来质量上的飞跃。而CMM认为，如果时间足够长，数据足够多并且准确的话，那么我们可以打倒我们预期的要求和效果，可以复制我们的成功。这正是现实与理想之间的差距。根据我们实施的经验来说，现实告诉我们，这样的数据积累可以对于项目的健康运行，打倒组织既定的目标，是有帮助的，可是，无情的事实也告诉我们，这样的帮助并没有SEI所宣传的那么大。我情愿相信是因为我们的数据收集还不够完善，我们的流程还有有待改进的地方。

另一方面，上面说过，CMM认为我们按照既定的策略去走就可以达到组织的目标，可是对于客户的目标我们有没有达到呢？不知道。客户的目标不在于你可以告诉他你交付的系统中可能存在哪些bug，他关心的只是他用这套系统可不可以帮助他达到他自己的商业目的，可不可以对他的业务带来有效的帮助。这些CMM并没有给予帮助，是不是也因为CMM的价值观所决定的呢？

对于迭代开发的先天性不适，这个是CMM所固有的问题。这个问题和CMM所适应的项目规模实际上是一个问题。从CMM产生的背景上可以看出，CMM是总结了大型项目，高风险项目的经验从而得来的，所以这样产生的方法论就有其普适性的问题。XP明确告诉大家，其在中型规模以下项目中可以得到较好的效果，因为随着项目规模的增大，其中的不可控因素也迅速增多，这样对于XP这样一种讲求适应变化的方法论不是好事。但CMM并没有说明其适应范围，给我的感觉好像是包治百病的样子。这个疑问我曾经向主任评估师提出来过，可是他并没有给出明确答案。

总之，随着CMM的推广越来越深入，我对于其理念接受程度也越来越深，可是不知道为什么我总觉得有什么地方不对劲，好像是CMM给我画下了一个蛮大的饼，可是我总是看得到，摸不到。所以提出以上疑问，希望有达人可以给予指点。

青海渔风
--------

我发现在这里的讨论的人，很多是将敏捷过程与CMM/CMMI对立起来。我就觉得很有谈一下两者关系的必要了。

摘要：
======
CMM/ CMMI与敏捷过程不是互相对立的。在CMM/ CMMI框架下，敏捷过程是可以得到推广和应用的，这也是与我在项目中的实践相一致的。

正文：
=====

在我的理解与实践中，CMMI/ CMMI是一个宏观的战略框架；而敏捷过程则是微观的手段与方法。CMM/CMMI关注的是产品的质量，进而关注生产软件产品的流程；而敏捷过程是一种工艺，是一个实例化的流程。

在实践中，两者并非对立，而是互为补充的。

CMM/ CMMI因其对于质量的关注，从而标识出很多的KPA，并给出很多的最佳实践。但是，CMM/ CMMI从来都没有对于具体如何去部署这些KPA提出规定与要求。比如软件要做配置管理，但是，CMM/ CMMI从来就没有对于配置管理要用什么样的工具，哪些文档要进行管理作出强制性的定义。相反，它是很柔性的。各个企业／项目可以根据自己的需要，进行适当的裁剪。

举个简单的例子：CMM/ CMMI规定必须做配置管理。它要求在项目中，必须有一个角色来负责配置管理的工作。但是，测试代码是否需要管理？它没有做出规定。你们项目中如果不做测试，或者认为测试不重要，那么，测试代码完全可以不做管理。

那么如何和ＣＭＭ统一起来呢？于是在CMM/ CMMI中规定项目有一个配置管理计划。也就是说，你必须先说明哪些东西是需要进行配置管理的，即cI (Configuration Item），你自己说要管理的东西，你就必须在项目以后的执行过程中进行管理，你自己认为没有必要管理的东西，那么，可以不管。

那么，这样的质量能够保证么？不一定能。比如如果需求不进入配置管理的话，就会造成需求变更的无序。这时候怎么办呢？不要紧，正是持续改进KPA的要求。当你发现需求如果不被标识为配置管理项，软件质量无法保证的时候，这时候，企业自己就会意识到软件需求作为配置管理项的必要性，这时候，在下一个项目中，需求就可以被列入配置管理计划。这就是一次改进。如果一直这样改进下去，就是持续改进。

简单小结一下：在静态分析中，单个项目中配置项数量的多少，并不影响配置管理KPA的实现，只要做到在项目的配置管理计划中规定的配置管理项被管理了，我们就认为配置管理ＫＰＡ被实现了。至于这是不是最优的，那是动态优化的过程。

这个例子举得长了一点，只是因为我发现这里有一些人，没有这方面的具体而成功的实践案例，这个例子正好可以提供一些侧面的资料。

回到CMM/ CMMI与敏捷过程相互协作的问题。
CMM/ CMMI是一个柔性的宏观的框架。在开发中，它并不反对你采用XP，或者所谓敏捷过程。我这里再举一个在CMM框架下，测试驱动开发的例子。

在我最新完成的项目中，在代码与测试阶段，采用了测试驱动开发的方法。在详细设计完成之后，测试用例文档与测试用例程序同步于产品代码的编写。在产品开发人员的代码完成之前，测试代码已经完成。而且交付产品开发人员使用。（这是一个自动化的测试程序）。这样，开发人员在完成自己的代码部分的时候，准备知道自己的代码工作符合预期。结果是，当开发人员开发完成之时，它的可以直接进入部署阶段。

要知道，CMM/ CMMI并没有规定所有的测试工作必须在开发完成之后，所以，测试案例和测试代码编写可以先于产品代码完成，前提是你必须在项目计划中做这样的规定（这是CMM的要求）。

然后，CMM没有规定你能否使用测试驱动开发，但是，作为一个实现了CMMI 5级的企业，有持续改进的要求。所以，它允许你在项目中尝试使用新的模式。所以，它至少允许测试驱动开发在项目中去验证的机会。

当测试驱动开发在项目中应用，项目完成之后，作为 CMMI5，有一个KPA就必须去总结项目中的经验，得失。从而将其知识化。而如何去评价这些得失，经验或教训，就必须拿数据，在CMM4级中，有KPA要求企业去收集这样的数据。

当根据CMM5级的KPA，这些效果得到了数据的支持，并且发现它的确是好的实践之后，就会被加入企业级的知识库。

在下一次有同类项目启动之时，新项目的项目经理会在知识库中去搜索（这同样也是CMM中有这样的要求），找到这样的最佳实践，由新项目的项目经理去决定是否应用并作适当的裁剪。如果在新项目中得到了应用或借鉴，那么，知识就发挥了作用。

简单小结一下：CMM/ CMMI，它本身的规定，允许了在项目的实践中，采用任何新的技术手段与开发方法，同时，它提供了将这些方法知识化的要求与方法，另外它还要求后续项目要对于这些知识加以运用。这就使得如果一个企业从来没有运用过敏捷过程，它的项目组可以在CMM框架下引入这个过程，并且在项目结束之后，进行总结，并持续优化如何去将敏捷过程用得更好。

青海渔风
========

本帖谈谈CMM/ CMMI在认知中的几个误区

1. CMM 只适合于大的团队
这是一个常见的误区。因为一个直观的感觉是，要做CMM，要写一堆文档，要有QA，要有Review，要配置管理。似乎很多与写代码没有关系工作，都要人来做，不是一个大的团队是没有办法完成的。

这是一个很大的误会。在小团队的情况下，CMM同样也是可做的。
具体拿配置管理来举例。
假设你是三个人的小团队。这时候，其中的一人可以兼CM（配置管理员）的角色。于是，在项目开始的时候，它负责写一个配置管理计划。因为团队人员比较少，项目比较小，对于配置项进行裁剪，在本项目中，只对于代码进行管理，要求每天上传。然后，它负责建立VSS，并规定大家代码的上传位置。并每个月检查一次大家的代码是否都上传了。最后，进行培训，明确告诉项目组的每一个人员，代码是需要管理的，然后并教项目组成员使用VSS。

在上面的例子中，已经完成了配置管理的过程。有人会问，我现在没有做配置管理，我同样做了这些事啊？

如果你真有这样的疑问，那么，你问得好。事实上，CMM在设计之初就充分考虑了“质量成本”的问题，即为了将质量提高到一个水平，项目组需要付出的成本。在上面的例子中，我们的成本其实是很低的。

另外一个问题是，在这样的例子中，质量提高了么？与我平时做有什么不同呢？
注意，不同在于三个方面。一是有配置管理计划；第二是明显的培训计划，第三是每个月定期检查。
配置管理计划将默认的东西文档化了。项目组中人来人往，每个人的默认是不一样的。所以，文档化之后，这个默认就更为统一了。而且即使后来有人进入项目组之后，也可能通过文档知道项目的配置管理范围。从而使项目执行行为变得可以预期（注意这里的可以预期，在CMM中，非常强调这一点）。

关于培训，项目组中的每个人都必须被明确告知，代码是需要被管理的。这一点很重要。如果你不告诉项目中的成员，有人天天上传，有人一个月上传一次，这就使得如果代码出现问题，同步出现问题。所以，让大家都知道，每天上传，消除了潜在的不一致。

关于每个月的检查，一种更为正式的说法就是CM Audit（CM审核），它就是检查CM Plan的执行情况，并作出反馈。

以上就是在例子中，CMM下的配置管理，与我们日常工作中的不同。以及其对于质量造成的影响。要注意的是，在上面的例子中，项目的状态变得可以预期。如果没有做计划，没有做培训，没有做审核，你项目的状态就不可预期。质量也就无法保证。

看，在一个三人的项目中，配置管理同样可以得到应用。其实CMM其它KPA也是一样的。因为CMM从来就是一个柔性可配置的系统。

至于有人说，国内有些企业中专职的执行与CMM有关的人员也说CMM只适用于大型团队，这其实只能够说明，其对于CMM的理解水平还没有达到一个层次。事实上，在我们公司，小项目，大项目，都有效地执行了CMM，只不过，小项目在执行CMM的KPA的时候，做了很多的简化，从而有效地控制了“质量成本”。当然，在做了这些简化之后，项目的状态“可预期”能力，就比更复杂的CMM活动弱了一些。

to 青海渔风：
我正想要问你呢，好在你已经开始谈这个问题了。下面是我在你发贴之前的原话。

要算算成本账，对于中小型软件企业，实施 CMM 的管理成本不是可以忽略不计的。有意回避这个问题，并不是很严肃的讨论态度。
据我所知，目前上海的中小型软件企业，做一个项目的利润是很薄的。为了增加利润，不得不同时接很多开发项目，并且压缩一个项目中的人员数量。平均一个项目包括 PM 在内也就只有 4、5 个人左右。为了成功实施 CMM，这 4、5 个人至少要有一个人完全脱离开发，做与 CMM 相关的工作。一般情况下，这些事情是肯定压在 PM 身上。可是人的精力是有限的，在项目进度紧张的时候，很难分心去做好与 CMM 相关的工作。除非你让我们确信 CMM 可以达到与 XP 相同的轻量级。而你说的这些效果严格实施 XP 也完全可以达到啊，为什么一定还需要 CMM 呢？另外 CMM 的可裁减性实在是不敢恭维。也许你因为有多年的开发和管理经验，知道哪些重要哪些不太重要，根据你的团队和项目的实际情况做出了适当的裁减。但是如何对于 CMM 进行裁减，这些指导和技能在 CMM 的经典教材之中根本就没有涉及。如果换了一个经验不是非常丰富的人（这就是 o6z 强调年龄的原因，结果被某个心高气傲的人指责为倚老卖老），他怎么知道什么重要什么不重要？肯定只有一股脑地照搬了。如果是这样，还不如按照 XP 的方式来做，至少 XP 的每一项最佳实践看起来都是非常明确的，没有什么二义性。

这里最大的问题就是由于严重的资源限制，中小型软件企业根本就无法达到 CMM 的理想状态。主要的原因就是没有足够的人力，因此无法满足足够的角色划分。项目非常紧张的时候，包括 PM 在内一起上阵做开发的情况是很多的。还有，通过了 CMM 也不意味着就可以一直按照 CMM 的管理方式坚持下去（实际上软件公司在通过了 CMM 认证之后，取消了 CMM 相关的管理设施的情况是很常见的。从降低成本以利于公司发展的角度，你甚至都很难对此做出异议）。另外对于采用了一些新技术的项目，造成混乱是完全无法避免的，CMM 如何很好地解决这个问题？技术在不断发展，达到可重复的最佳途径就是我们永远都不采用新的技术，这样做可能吗？

这个状态就像现在 PC 利润那么薄了，你一再说 Windows XP 的优点，可是商家甚至连 Windows XP 区区的几百元也承受不了了。
这些具体的问题我们是否需要讨论？是否需要针对特定的场景讨论出一个实施软件工程的合适方法？当然你也可以简单的骂我：活该，谁让你跑到这样一个抠门公司里面去的？自己认倒霉吧。

看了这么多话，我不想做任何理论上的辩驳。我们讨论的是工程上的问题，那么容我给你几个工程实践中的例子。

1.如果承认了CMMI的标准被歪曲了，却把由此造成的过错的责任推给CMMI本身，这就是典型的伪软件工程者。伪软件工程者为过程而过程，为了标准而标准，当然很容易认为项目失败是过程或者标准的错。这个可以从他们对RUP的类似态度中得到验证。o6z前面提到了GMP，以及ISO和HACCP等等国际通行的标准，在实际实施过程中同样遇到了CMMI类似的问题，甚至被歪曲得比CMMI更厉害，但是你能就此否定这些标准体系的科学性和可行性么？真正的原因其实在于实施者自身，理解力，态度，能力等等各方面都有问题。这样的人，做什么过程都会失败，不是么？这个论坛里的很多XP的狂热分子，你们能给我几个在国内用XP做项目而成功的公司的例子么？我的一个同学在咨询公司做过HACCP的实施，失败了，下岗的是客户那边负责这个事情的副总，而不是HACCP本身。从一个侧面来讲，这才是正确的态度。

2. “成本可控制完成成为对于internet时代的企业的一种玩笑”？这句话是个彻头彻尾的玩笑。成本不可控制的公司在现在这个年代连玩都不要玩。IBM，Dell,HP,MS,SAP以及包括你们自己所在的公司的成本都不可控制么？

3. CMMI是标准不是方法，所以CMMI不会告诉你解决方案的细节。这个因果关系本来就应该这样说。而认为CMMI只关心Bug数量而不关心Bug的产生原因以及预防方法，这只能是一个没做过CMMI甚至连CMMI的书都没看懂的人说的话。事实就是CMMI5的一个KPA，Defect prevention。

4.对于客户所关心的问题，CMMI不关心么？事实就是，印度的公司为什么能够和欧美企业保持长久稳定的合作关系？仅仅是成本的原因么？就拿我所在的公司来说，报价比它便宜的公司有的是，比如很多国内的企业，便宜得就跟大白菜一样，然而照样拿不到单。CMMI不是做不好这一点，而是失败者所理解的，所做的达不到这个要求。

5.至于什么是正确得研究方向，确实不是你我所能决定的，既便是XP的创始人，也未曾宣称过什么“正确的研究方向”，因为说这句话本身就忽视了工程和科学的探索性本质。但是工程界的公理就是，要证明你是对的，拿出你的事实出来。不过除了看到o6z的保密申明之外好像没看到什么事例出现啊？

6.软件的柔性本质恰恰说明了依赖的统计学方法的CMMI或者其他类似的如净室的理论上正确性。稳定的过程恰恰是对CMMI的一大误解，我一再强调，CMMI和具体过程无关，它只是离散控制的框架。而统计学方法对所谓柔性的系统是否就是不可靠的呢？这个问题确实无须讨论，理论上，统计学的书已经很多，早有定论和实例，事实上，IBM的成功和CMMI在印度的成功明确表明了基于统计学方法的控制系统在软件开发中的可行性。我的问题是，除了统计学方法，你还有什么方法么，比如在XP过程中，你用什么方法来收集和分析你的数据？愿闻高论。

7.区分滥竽充数者不是标准的责任，就像前面提到的，任何东西都有空子可钻。CMMI甚至不是软件工程上的银弹，更不是社会学范畴的银弹，很明显，伪软件工程者并不理解这一点。CMMI的意义，不管你承不承认，印度软件公司的崛起都证明了这一点。

8.把CMMI关于需求分析的要求简化为写一篇数百页的用户文档然后逼着用户签字画押，这种理解实在歪曲的太远，借用o6z的一句话，纯属娱乐。同时这句话也让我明白了一些失败了的CMMI的实施，在需求分析这一块是怎样的一个粗放的做法。说实话，还没开始就已经失败了。事实就是，CMMI2的“Requirements Management”，CMMI3的“Requirements Development”。

9. CMMI不是屋顶，所以不存在掀翻的问题。把CMMI当作屋顶的，同样犯了伪软件工程主义的错误，从而得到了一个武断的结论，其作用不过是想在本来已经是替罪羊的CMMI身上再踩两脚而已。事实是，CMMI是开放的标准，并不排斥过程和改进。为什么不排斥。因为我们已经做了。不过不好意思，由于涉及商业机密不便公布相关资料，敬请谅解

看了那个可怕的例子，我对于cmm原来还残存的一些好感已经降低到最低。好在我相信SEI还是一个负责任的组织，他们不会认由这些荒滩的事情长久发生下去。

这些就是所谓的裁减的奥秘。
而根本的问题在于CMM系统不能支持主流开发模式，也就是增量迭代开发，这一点是其致命的问题。而这也是其不符合DOD要求的最的问题。当然作为一种标准cmm不可能明确的提出方法偏好和抵制一种方法的。而在现实中往往有些认拿出cmm的kpa来套这个那个方法，说你看这个方面就是什么什么kpa，那个方面就是什么kpa，所以cmm和你的方法是不矛盾的。这样的把戏就如同代码行bug被偷换为质量的事情经常性的发生在我们周围。
判断他们是否由矛盾，并是不是看敏捷是不是做了cmm要求作的事情，而是要看在cmm的要求下，敏捷要求的核心实践是不是可以得到实施。其实很简单的一个短周期迭代cmm下就不可能很好的实现，所以用诈辨的方法来论证cmm和agile的友好关系是无用的。
在同时我们还必须看到，cmm是一个过程标准，而不是质量标准，这使其不可能成为一种关于质量的体系。当然我这里并不是否认cmm对于质量的关注，而是在否认cmm对于质量关注的方式。而这一点由于大家都是技术人员，而非流程咨询顾问，我们不会去到企业中去给客户系统BPR和TQC等服务，因此我就没有必要在这个问题上给大家作科普。
同时建议他们去好好学习一些关于TDD的基本概念，用那样的例子来说明在cmm下可以实施tdd，是非常不不合适的。

北京红工场软件公司，按照标准的XP实践开发出国内第一个JDO产品。