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

to askycn：
得了吧，多看看外面的世界吧。现在很多实施 CMM 的企业，要么是外包类的企业，需要靠 CMM 得到单子。要么就是想要从国家相关部门骗取一些资金。以前 o6z 说 CMM 只适合外包类的企业，差不多已经是我们的共识了（外包类软件企业和其它软件企业的区别，拜托你自己用脑子去想一想）。国家相关部门现在也在反思盲目照搬印度模式的危害，请你不要低估中国进步的速度。

你说 CMM 象旅游地图的说法充其量也只是一个未经过证实的隐喻。假设这个隐喻是合适的，这张地图是否是正确的地图？假设这是上海市的地图，它是不是 20 年前的上海市地图？这些问题的答案，天知道！
强烈建议你把以前我们关于 CMM 讨论的所有垃圾贴找来读读，你就不至于这样妄自尊大了。

cmmi比较cmm还是有进步的。它开始克服cmm自身带来的阶段性的思维，也就是所谓从cmm1-2-3-4-5这样的思维。
这个问题在如果只是用平常的思维方式，看不到其在软件开发过程中的谬误。但是如果放在现实的环境去，就会发现其非常的可笑。例如cmm要求scm，那么随着你的企业的组织结构的变化，项目的变化，其要求会有很大的不同。而在cmm2中解决的问题，在cmm3和以后的级别就会成为最迫切需要解决的问题。又例如，当你的项目需求你首先实现一个更高级别的kpa的时候，你不应该受到级别的困扰而去实现它。例如当你面对一个变化非常快的领域，那么自适应性和自优化能力就是最迫切需要解决的问题，你就不能因为那是cmm5才会解决的问题，而放弃你的追求。
但是cmmi对于这个问题的克服还不完全，还没有完全解决这个问题。
同时我们还应该注意到cmm和cmmi评审的是你的组织的过程的成熟性，而不是在评审你的组织的能力。作为一个项目发包者，或者叫甲方，对于乙方的要求首先是看其能力是否达到项目的要求，而不是其过程是否成熟稳定。也就是先要解决可能性的问题，才可能解决成功率的问题。而你的组织在低级别项目的成功率再高，同实现高级别的目标的能力也没有任何的关系。因为更高级别的项目需要的往往是完全不同的能力和组织形式。同时过程的成熟度，同对领域的了解不存在任何的联系。也就是说你的需求作的再好，评审再严格，测试再完备，部署再细致，依然不能代表你就解决了客户需要解决的问题。
从这个角度来说cmm根本就只是解决了一个甲方根本不需要紧密关注的问题。而实际上cmm只是软件工程研究范围中非常小的一个领域的标准，这和它在很多人心中的地位差距是非常明显的。
最后说说现今cmm实施中的一个问题，这个问题在很多年轻人看来是完全的年龄歧视。我们看到非常多的SPEG组织中都是一些年纪非常轻的新人，他们对于组织的理解和过程的把握是不可能有深入的理解的。因为这些理解是必须建立在长期的接触的基础上的。同时由于年轻，其在组织中的地位和话语权往往是不能得到保证。而实施过程的改造又需要组织的所有人的积极努力。由于其地位和信任度没有得到一个长期的检验，其制定的政策和实施政策的力度都不可能得到保障。而大家去研究cmm实施建议的时候都会看到SPEG的组成的建议，就会理解那些研究和制定cmm的人早就看到了这个问题。可惜的是现在一些最热忱的支持cmm的人，往往就有意的忽略了这个。这其实就是一个态度的问题，可以说从最初这些人就完全的漠视cmm的基础。因此我们可以从这一点看出那些人究竟是怎么对待cmm的。
实际上我们现在对于cmm的种种争论，并不是同那些真正的支持cmm的人的辩论，而往往是同一些伪cmm的争吵。这样的事情其实是cmm标准最大的悲哀。不可否认cmm在软件工程的前进路途中是一个时代的产物，是那个时候人们种种研究成果中的一个。但是在现在增量迭代方法确定了主流地位的时代，我们必须安装现在的学术和工程观点去看cmm的种种做法。

不敢妄自尊大，呵呵，你们以前的观点我都看过，总体上来说都是推崇XP怀疑CMMI，同时混淆过程和度量的概念，而理由都是基于国内企业CMMI的失败经历，从而质疑CMMI的科学性和成功的可能性，进而怀疑推崇CMMI的人的人品和能力。这个脉络划出来蛮有意思的。

对于CMMI只适合外包企业这种观点，我都懒得辩驳。问个问题好吧，能不能细细谈一下外包企业的业务特点以及和其它做项目的公司的区别呢？

另外一点是，CMMI到底是不是只有评审没有实质？本来是一个答案很明确的问题，而大家在谈论CMM的作用的时候，常常忽视这个问题。谁都知道这个资质不是一切，偏偏那么多公司为了资质而资质之后，把本来由于管理混乱而导致的项目失败归咎到CMM身上。为什么不扪心自问一句，在号称CMM X的时候，你到底有没有达到CMM X的要求？

知道为什么印度的企业能在这方面成功么？人家从80年代就开始积累软件开发的经验，而现时国内的大小公司，寄希望于两三年内就达到CMM level 5所要求的水平，现实么？各位CTO,CIO们失败的同时，不约而同地拉了CMMI做替罪的羔羊。

cmmi和cmm除了评审是不是应该还有实质呢？或者说cmm除了标准是不是还代表了方法。这个问题确实是一个非常重要的问题，但是这不是软件工程的问题，而是一个类似法律的问题。同时这个问题也往往是一些人招摇撞骗的时候不愿意提及的问题。
我们都知道cmm是一种标准，它是SEI受DoD委托制定的评审外包企业软件开发过程成熟度的标准。但是可惜的是DoD现在有了2176这个推荐标准过程。其标准的特性使得其不能带有方法的内容。这是因为标准是衡量众多参与企业的不同过程的实施成熟的标准，如果带有方法的内容，那么就不能做到公平和一致。而同时cmm其实还是有方法偏好的，也就是TSP和PSP。可惜的是这个方法偏好由于其操作的繁琐，往往被组织所抛弃。同时由于其标准的不能涉及方法的属性，造成在评审的时候，一些组织其已经非常成熟的过程为了实施cmm，而不得不进行改变。这也是一种cmm的弊端。同时由于为了实施cmm，而在混乱的组织内采取强制手段强行的推广一个被设计的过程，造成了过程的针对性的缺失，这也是一个CMM弊端。真正的实施cmm，应该是从现有的开发过程中去固化一些行之有效的方式，不断的积累，经过一个渐进的过程，达到cmm的目标。而cmm评审的时效性，又造成这个过程的不可能被认真的完成。
同时我们还必须看到，一个作为标准的cmm，出现了跳级和以小代大等问题，这里面固然有人弄虚作假的因素，而更重要的是cmm自身的不完善才造成了这些人有空子可钻。要追究责任首先就要追究方法的责任，而不是谴责那些人。这就象一个政策法规被人钻了空子去作坏事，首先要解决的是政策法规的问题，其次才是从道德上去谴责那些钻空子者。而从商业和人权的角度看这些人的作为完全是无可厚非的，应该受到批判的是制定这些政策的人的愚蠢或者无能。

好，不管怎样，先支持一下这种不带刺的探讨。
不过反对意见还是要说的：
1. 且不说当你面对一个变化非常快而又有一定复杂度的问题时任何方法论或者指南性质的东西包括XP都不能轻易解决问题，就你提出的自适应和自优化问题，你觉得解决这个问题的基础是什么？毫无疑问的是知识积累，而这恰恰是CMMI最关注的一个方面。我们不是为了KPA而KPA，所以在实践过程中，不要以为各个级别的KPA中间有什么遥远的隔阂。我所在的项目组，在只通过了3级的评审的时候，同样采用了5级的部分实践，比如Defect prevention brainstorm. 虽然由于4级所要求的一些量化管理的数据收集得不够完整而不能得到完整的定量的结果，但是对于总体的质量趋势定性把握的效果还是很明显的。
2. CMMI从来没有要求过什么中心地位，大家都明白没有银弹，但是往往都寄希望于CMMI就是银弹。就像我上一个帖子所指出的，CMMI指所以成了漩涡中心，是因为有很多人把它当作替罪羊。伪软件工程主义者从来不从自身找理由，而是责怪CMMI和RUP，为什么不责怪XP？我想，原因是很多人根本就没有机会在自己的公司推动XP的实践，否则一定会责怪TDD怎么这么难做，Pair programming的人怎么这么不合拍。
3. 你所谈的问题确实存在于实施失败的公司中，但是你是不是有意无意地忽略了成功地公司呢？不拿印度的公司说事，我以前呆过的，深圳那个有名的ERP厂商，目前核心团队已经在按CMMI 5的要求做事。这是成功的事实，我可不可以由此宣告CMMI所向无敌呢？所以拿失败的经验来说明CMMI没什么用处是不成立的。CMMI自有其用武之地。而这个帖子不应该被用来质疑CMMI，而是应该帮助充满困惑的贴主解决他在实施中遇到的问题才是。看看你们都说到哪里去了。

青海渔风
--------
既然有人倚老卖老（从首先注意一个人的年龄中可见一斑），抱着敬畏之心，细读之下，竟是无知者无畏。
首先介绍一下我自己，我是askycn的同事，这可免去你的猜疑。我刚注册了ID，发现十天后方可发帖，但是，有些话如骨鲠在喉，不吐不快，就麻烦askycn帮我发出这段了。

我这里只想随意引用几段话，谈谈我的看法。
[ozzzzzz]“其实从根本上来说CMM就不是一种关于质量的体系，具体是什么我也很难做出一个明确的定义。”
有一句话，叫“无知者无畏”，在还没有弄清楚CMM是什么之前，就可以妄下断言，恐怕也非治学之精神。

[ozzzzzz]“而其产生的背景也促使其带有众多冷战时期的思维模式和观点，从而更加强调质量，而对成本关心的太少。而对于成本的不关注，被认为是在美洲和欧洲主流软件工程从来不接受cmm为一种主流学说的重要原因。”
带有冷战思维的模式与观点，好大的帽子。建议多谈一些实际一些东西，少戴一些帽子。帽子只是用来装神弄鬼，糊弄无知的人的，而在明眼人面前，只是一种把戏而已。真正个子高的人，从来是不需要用帽子来增加高度的。
因为CMM对于质量的关注，而忽视成本，从而不被美洲与欧洲主流软件工程接受为一种主流学说。我不想说这是对还是错。但是，CMM好象出身也是名门世家。在名气上，未必比各位的帖子中的RUP，MSF，XP等等差啊，本人对于这些都有一些了解，工作中也分别有一些应用。但是，好象CMM虽然未必强了过去，也未必弱了三分啊？我前两天，在软件员看到了一个另外一个印度公司的LOGO，在LOGO上特定标上SEI/CMM Level 5的标志，国内的公司，如华为等，都将通过CMM5作为重点放在自己的宣传材料中，而且据我所知，我们很多重要的美国客户，对于软件承包商有强制性的CMM标准要求。我不知道，ozzzzzz所谓CMM并非主流学说出自何处？如是自创，不妨多给出些资料，分享一下（别说什么手头有大批资料，但不便公开。如果人人如此，大家都可以说我自己的观点有一堆权威资料支撑，空对空，也就没有必要了）；如果是引述别人观点，也请注明出处，我好找来阅读。

另外，从引文一中，ozzzzzz说CMM根本就不是一个质量体系，引文二中，又说CMM关注质量。CMM关注质量，但是又不成体系，如你所言，CMM果然是无用之极了。正如一个人要创立一个门派，但是，却又不能自圆其说。但却又弄得天下信徒万千，并成就了一些著名企业（至少我手头的资料告诉我，印度几大软件公司都是通过了CMM5的。微软是一个常被人提起的例外。但就算是微软公司，本人在参加其MSF的培训时，他们也还是特地将MSG拿来也CMM进行了一些比较，然后，告诉我们，MSF与CMM是有着一定的对应关系的。）

关于CMM提高了软件成本的问题。这正好可以在这里提一下有关质量与成本这样的一个美丽的误会。
何为质量？何为成本？这是一个问题。
我们在做软件的时候，如何界定一个软件的质量好坏呢？我发现各位在讨论的过程中提及这样的一个重要的评价CMM的参数。对于软件而言，质量不在于你在开发过程中发现了缺陷的东西，而在于你交付的软件，在其生命周期中，出现的缺陷的多少。

也就是说，当你产品安装到客户的机器上之后，你的产品里还有多少个缺陷，以及其严重程度，才是你的软件质量的真正含义。

但是，有人或许马上会说：每个产品在拿到客户那里的时候，都是无缺陷的。我告诉你，这是一个美好的愿望。永远不要相信它是真的。
又人会说：好，假设其是有缺陷的，可是这个缺陷是如何度量呢？因为只有度量之后，才能够知道其好坏啊？
好问题。我告诉你，我们公司交付给客户的产品，可以明确告诉对方，这个产品可能包含多少个什么样级别的缺陷。并且我们的客户会相信我们提供的数字。

正是因为有了CMM，我们可以告诉客户，我们交付的产品可能会有多少缺陷。正是因为有了CMM，我们的客户者相信了我们说的数字。正是有了CMM，我们才真正知道，我们的产品质量是多少，然后，才有谈改进的可能。所谓，改进，就是不断降低交付产品中包含的缺陷数量。

说完质量，再说成本就比较容易了。
成本简单地说是为了研发软件所做的投入。首先，成本是一个全生命周期的概念，它不仅包括生产过程中的投入，还包括用户现场部署之后，维护过程中的投入。在其生命周期结束之前，成本是一直发生的。在说明成本的时候，还要考虑两个方面：一是成本的可控程度，一个是成本的数量。对于客户而言，成本肯定在100万美元以下，比成本可能在50万到150万之前，更具有吸引力。成熟的客户会选择前者。

我们在说CMM是好还是坏的时候，应该比较的是在达到相同质量的情况下，看软件全生命周期付出的成本的高低及其可控程度。


这里特别要注意相同质量。怎么样去说相同质量？就必须能够度量。而在目前已知的软件产品相关的模型中，CMM是一个能够在产品部署之前明确以数量的方式告诉你质量的模型。而且是已知的模型中，成本控制较为成功的一个。是否是最低，这是见仁见智的。

在看完了这里的系列帖子之后，觉得讨论还是应该集中到CMM或是其相关的话题上来。所以，如果大家对于本帖中有关CMM的观点，如果有不同意见，欢迎，大家讨论，交流。

最后说一句：学无先后，达者为师。以CMM这样一个引入国内尚未有多少年月的概念而言，22岁与36岁，区别本无太大。佛有一个字为悟。而且，所谓的经验也可能化为成见，往往与可能妨碍自己对于新事物的理解。慎之。

其一，CMMI不是政策法律。连政策法律都让人钻空子，CMMI有什么理由要完美无缺？ 换句法说，这帮人连法律都能找到空子钻，有什么东西他找不到空子钻？XP行吗？2176行吗？
其二，很简单，人大常委制定了法律，有人钻空子犯罪了，按你的意思，先别急着抓罪犯，先把人大代表们关起来好了，长篇大论地批判一番，其次，我们才去抓罪犯。可能么？世上没有完美的东西，推论之前不要忘了公理。

首先我们必须明确我们的讨论是建立在认为cmmi会在某些环境下有效这个论点的基础上，同时我们也需要承认在某些环境下其不有效。而那些伪软件工程人士往往是嘴里承认，缺不去说明到底cmm在什么时候有效。这样作显然是一种道德的问题，而不是水平问题。
说cmmi关注知识的积累，这一点我需要证据，同时也需要我们对于知识这个词汇进行明确的定义。这一点刚好是我们最近研究的方向，可惜任何cmm的资料对于我都是没有用处的，我希望你能提供这样的资料，以支持你的论点。
同时对于快速变化的环境是不是过程方法论就失去了其使用的意义，这一点显然是不需要讨论的。任何一个对敏捷体系稍微有些研究的人就会明白，应该怎么面对这样的环境，并且提出众多的方法。这个方面的资料众多，不需要我去提供。
cmmi没有要求中心地位，但是搞cmmi的人确实在要求这个地位。我说过cmm从来就不是主流，大家可以去问问美国的各个软件公司的技术人员，看看他们对于cmm的4认知程度是多大，看看各个大学软件工程的研究结构和个人对于cmm研究的热度是多大。
同时我们研究的领域是工程学而不是科学，所以我们更加应该关注的事情就同一般的学术研究有所不同。你说出那么多组织不是实施cmm成功了的例子，但是如果又存在众多失败的例子，那么这个学派在工程学的角度看就不是成功的。同时要证明cmm的成功，还必须证明其实施组织在没有实施cmm的时候的失败或者不完善，以及这些问题代理的后果，在实施以后得到了合乎成本的改善。


cmm究竟是不是一个质量标准，这个问题我想稍微知道cmm是什么的人都可以回答。
而目前的状况看cmm在现实的环境中脱离了其标准的本质，被一些别有用心的人赋予了不应该的属性。这一点社会现实，如果联这一点都不承认，我们当然就能论断其认知程度究竟如何。
同时冷战时期的开发由于其特定的历史环境，造成了其关注点同现在不同。同时那个时期的项目来源同现在也差别巨大。这一点我想任何稍微有些历史知识的人就会理解。这绝对不是帽子，而是其客观存在的事实。使用一种以那个时候的资料为统计数据的方法，在现今已经完全改变的环境下，本身就不是一种值得夸耀的做法。
同时我们也应该看到很多公司以cmmi为荣，但是这并不能从工程学的角度证明什么，而恰恰可以说明cmmi在市场推广的角度在被大量的使用。
cmm不是质量体系，但是这不能代表其就不关注质量，也不能推导出一个方法关注质量就必然是一个质量体系。而要说cmm信众万千，这个论断确实就太有意思了，不过其在讨论中根本只能成为一种活跃气氛的论点。
说道所谓美丽的误会，这一点恰恰是推广cmm的一些人不知道什么原因造成的。他们往往以所谓的实施前后代码行bug数作为他们的论据，而不是以客户的满意和使用为评价标准。
成本的可控制性又是cmm一直夸耀的，但是这也是一种冷战时期思维的成为。因为现在的环境已经成为最不可控的因素，因此所谓的成本可控制完成成为对于internet时代的企业的一种玩笑。他们看重的是今天你的成本和你完成的事情给企业的利益。或者说开口的项目已经组织内开发的项目已经越来越多。
而说客户会相信你，在国内客户相信你的理由很多，我看cmm恐怕是最不值得去追求的一个理由，因为别的方法更加便宜。
同时客户是不是会对你的所谓可能的bug数量有兴趣还是问题。而我们更加应该bug究竟是怎么产生的，以及如何去在没有交给用户前解决这些bug，而cmm不提供这些。因为cmm是标准不是方法。而同时一个非常重要的问题是客户往往最先关心的是你能否尽快的实现他们关心的功能，这一点cmm并不能让他们得到什么。
所谓的讨论相关问题的发言，在我看来提供的论据都来自cmm的宣传资料而不是cmm的研究和探讨。更加可惜的是他们依然不能转变思维的习惯，到正确的工程学研究的方向上来。


我只能解释一下。那些人之所以可以被认为是罪犯，因为是他们违反了法律。而如果法律没有禁止他们那样作，他们的做法就不是犯罪。同时一个法律如果初衷是去制止一个行为。但是如果一些人实施其他方法达到了未实施这个行为，而取得实施这个行为后的目的，你也不能认为他们是犯罪。

写来写去，忽然想到还有一个问题没有说到。
CMM的动机中有一个是，为了作某件事情，你应该制定一个流程，并且按照这个流程去完成，控制你的行为达到这个流程的要求，你就可以产生你需要的结果。我不知道这样的想法究竟有多狂妄，反正我想他们至少是没有学习过复杂系统工程和认知学。
软件所面对的问题就在于你不知道你究竟要什么。而同时每一次开发都会面对不同的需求，如果需求相同则说明你的开发是没有必要的。这样的本质属性，有人写了一本说说明这个问题，并被印度人封为软件开发的圣经。因为这样的属性，造成其过程必然是变化而柔性的，过程的稳定恰恰说明其不合乎软件开发的基本规律。所以另外一个人说CMM是软件企业的耻辱，这个话也是登在《程序员》杂志上的。
而对于这些柔性的过程，对于cmm的评审来说是困难的。而有因为其柔性的本质，其所产生的基于统计学的推测也是不可靠的。这些问题我觉得我们不需要讨论。
而同时我们知道目前cmm的评审十分混乱，你究竟如何区分那些滥竽充数者呢？问题不是又回到了cmm被提出的时候的原点了吗?CMM的意义究竟在什么地方呢？或者说一个标准已经不能反映其所代表的对事务的评价水准，这个标准存在的必要性在什么地方？

是的，这也是我为什么在项目开发那么忙的时候还要抽时间去看《面向使用的软件设计》的原因。方便易用是用户最关心的问题之一。还有一个用户最关心的问题是你是否提供了真正满足他们需要的功能。即使你的实现里面有些 bug，如果你尽早提供了他们所渴望的功能，用户仍然会赞许你的工作。我又要说一句所有 CMM 推广者立即会群起而攻之的话：其实这些 bug 并不是最重要和首先需要解决的问题。提供真正满足用户需要的功能很容易吗？至少在我看来不容易。你必需要充分理解该行业的业务，需要建立良好的领域模型。需要耐心细致的沟通，还需要对用户加以适当的引导，因为用户说的不一定就是他们真正想要得到的东西。通过编写 500 页的需求文档并且要求用户签字画押，如果反悔自己承担所有成本会对这个目的有所帮助吗？

CMM 对于这两项最重要的用户关注有所帮助吗？我看帮助不大。即使是有帮助，也是隔靴揣痒。
至于 bug 的控制，XP 和 TDD 提供了有效和实用的方法，这个是连 CMM 推广者也承认的。现在的问题就是是否还需要 CMM 这个标准，CMM 这个屋顶需不需要掀翻的问题。如果通过大量的分析，最终发现其实即使没有这个昂贵的标准，我们一样可以达到殊途同归的目的（假设 CMM 推广者和我的目的相同，不是软件工程/过程改进的狂热爱好者，而是以用户的关注和如何为用户做好服务作为最优先考虑的问题）。那么这个标准对于我们来说是不是一个鸡肋？况且对于大部分中小型软件企业（100 人以内），还是一个如此昂贵的鸡肋。