跟胖子一起研究cmm的动机

cmm的原始动机有很多，我今天分析其中的几个。

首先我关注的是cmm希望能够满足组织间能力成熟度的对照评价。
实际上真正被关注的是组件间开发能力的评价，而由于cmm本身的限制，其提供的只能是这个评价的一个参数。而这里其实就有很大的问题。比如评价一个军队的战斗力，不能仅仅是评价其组织的能力，还应该评价其装备和指挥思想以及基础人员的基本素质。而就一个开发团队来说其过程显然是受其使用技术和面向的商业环境以及开发的产品的约束更大，当然过程能力也会有反作用，不过这个反作用不应该是其决定作用的一个因素。一个好的过程自然会让技术得到更多的发挥，也可以更加适应市场环境，同时能够更加针对性的推出产品。不过显然市场环境，企业的技术能力和所使用的技术，以及其产品，更加是受客观环境的约束和企业决策管理的制约，过程能力无论如何不可能起到决定因素。而如果我们从发包方的角度看，他们希望的是能够评价究竟谁更加能够完成他们的项目。这里显然是具有更多类似项目经验的具有更大的竞争力。而同时使用的技术也是被予以更多的关注，这就好比人们认为武器更加先进的一方战斗能力更容易取得上风。而过程能力由于其自身的限制，应该是最后才被考虑的。这也就是为什么cmm更加被做纯粹编码外包的企业所重视的原因，因为在这个时候其技术和商业环境以及产品都是固定的，是被发包方所规定的。而这本身也就是表明你赚取的只能说最稀薄的那块利润。
那么我们是不是就能够比较容易的对比企业间过程的能力呢，或者说是不是就能够使用cmm的方法很简单的做出这个评价呢？这里显然又出现了一个问题，比如我做代码外包，你衡量我的需求分析过程是不是符合难道就真的那么重要吗？而需求分析显然是cmm2的最基本要求。而这是不是说cmm初始级别的企业其实也可以满足纯粹代码外包的能力呢？
而我们分析过程能力的一个必须要件scm，也存在很多的疑点。一个5人的团队的scm能力显然无法同一个50人团队的scm能力直接比较。而一个50个月的项目和一个5个月的项目，scm的能力也很难比较。同时一个采用软件公有制的团队，同一个软件私有制的团队，能力的比较又该如何做呢？
另外软件项目计划能力显然对与非设计外包的企业用处不大，而软件项目控制能力其实也并非那么需要被重视。
而更加重要的是，存在很情况是某些项目只能某些人才能够被接受，这人是不是说明cmm初始级其实就可以解决问题。那么我们投资做cmm的评估意义何在，更加直接的说我们搞过程改进的意义又在哪里呢？

cmm的另外一个动机也被我关注——cmm提供了一个过程改进的框架，或者说途径。
这里其实我们真正需要的是提供一个改善我们软件开发能力的通道，而傻子都知道找到有能力的人员并且留住他们是最有效、最便捷的途径，为什么cmm却认为这个是cmm初始阶段的特征呢？这里有2个解释，一个是cmm认为过程绝对是决定因素，依靠能人不行。这显然是在骂cmm是比傻瓜还弱智。另外一个合理的解释是，有能人是一个基础过程，不管什么时候都必须满足这个条件，因此cmm就把这个问题当公理一样了。而这是不是就说明本身前期在国内的某些宣传是撒谎呢？
又比如scm这个基础实践。我们都知道在混乱情况下的scm保证更加困难，也就是说完成本身所代表的能力就更高。而随着过程的改进，可控制性的提升，显然应该说对scm能力的需求就不那么强烈了。这个时候我们去维持一个我们已经不需要那么强大的能力是不是有必要呢？而同时如果是随着能力的增加，所面临的项目可能更加复杂，环境更加恶劣，这个时候是不是又需要提高我们的scm。而更加重要的是，可能随着新技术或者新的市场策略，scm也需要改变策略，这个时候我们该如何评价这个能力呢？当然这也就是cmmi提出的一个原始动因。不过企业的发展显然是在二维空间，而不是一个线性的通道中，这个也是一个问题。

cmm的一个动机显然是上面这个动机的一个引申，也就是可制定一个标准来评价企业发展的前后过程能力。
问题又来了，过程能力的提高应该看的是过程能力所带来的收益和其成本的比例，以及这个效率同其他成本付出的收益之间的比较。而本身我看不到cmm在4以前能够提供这个能力，那么是不是说我们要走一大段的黑路，这难道合乎最基本的企业管理思想吗？

上面是cmm这些动机所带来的问题，然而这些动机无疑都是非常重要的。cmm可能不能满足这些动机，但是cmm提出的这些动机也确实是非常有前瞻性和突破性的。也许cmm不能告诉我们如何满足它们，但是提出他们本身就是一个巨大的进步。这为我们今后以此为起到进行我们自己的过程改进提供了一个基础的平台，是一个巨大的贡献。
对比组织间的过程能力，无疑会带来企业自身能力的一个评估过程，这是现在竞争性环境先的必然考量。而提供一个框架供企业进行过程改进的参考，无疑也是大多数人所希望看到了。而能够标准化的衡量企业的过程能力，无疑也对企业进行过程改进，增强竞争力提供了一个可靠的参数。

而实际上cmm最初的的原型，是一套企业开发情况的问答题，企业可以按照它来检视其自身的开发过程情况，然后可以针对做出的改进。这个做法无疑是有效而面向实践的。实际上如果我们也来搞一套自己的类似cmm的东西，也是应该按照这个样本来做的。

同时我们还可以发现，cmm提纯出的19个关键过程域是很正确的，它实际上理顺了我们过程中所需要做的工作，这是一个很有价值的分类。不过这其中也是有问题的，下面一个帖子我就会具体的拿出一个做分析。

又是排版。。。看过之后不知所云


以上




不合理，我认为是客户需要才作cmmi的，就如同监理是带表了国家承认，ＣＭＭＩ带表了被ＣＭＭ承认你挣不挣到钱不归ＣＭＭＩ管。。。

下次一定注意排版问题。其实熟悉我的人应该知道，最开始我是习惯写没有标点，且句子很长的帖子的。现在这个样子，其实已经影响了我的写作。不过在写作效率和可读性之间，我会现在可读性。

嘿嘿，满足客户需要是你的目标，而我这里说的是cmm的动机。注意我的措辞，其实有很多非常细腻的东西的。而这其实也带来了可读性的问题，不过要想解决这个问题我觉得责任不在我。

可以说我写帖子还是比较认真的，以前虽然是意识流，但是也是字斟句酌的推敲好才动手。而现在我更加注意细节上的东西。当然语病和错别字还是很多，不过关键的点都是有所考虑的。比如上个说cmm的帖子，我提到了agile的16条，马上就有人说agile不就有个12条，我的这个16来自哪里？这里我卖个关子，大家自己找答案。

难道16=12+4？

个人觉得：CMM并不一无是处。CMM提供了一个框架和途径，通过这个框架和途径可以比较有效地保证开发过程和开发结果的质量问题。国外资本主义发展比较久了，特别硬件产品的开发与生产，其实老外就想生产硬件一样地生产软件而已。

很多XP的书说自己已经满足大多数CMM的要求

CMM这个框架和途径，我在前面已经说了，其思想根本就不关系质量，也不关系生产，因为它根本就不是来自工业工程这个学科的。可以说是一种歪理邪说。在国内的实际操作已经说明了这个问题。
我这里强调的是CMM构建这个框架的方法和背后的理念其实还是有很多对方值得我们研究借鉴的。这个是有很大不同的。具体情况请参考以前讨论cmm的帖子。我就不多说了。

严格的说xp的做法满足的cmm到2-4的一些关键过程域的范围，但是要说xp符合cmm确实是一种玩笑的说法。如果cmm真的只是认为你对一个范围有所涉及就认定你是满足了的，那么这个标准也就太可笑了。

我并不觉得CMM好，但我是从这几个基础上来看待CMM：
软件需求方
1、人们对软件的依赖程度决定了软件的价值；
2、人们对软件的满意程度决定了软件的质量；
软件提供方
1、规范的生产过程保障了软件产品的质量，“需要评价体系”；
2、任何生产都不能依赖于“能人”；
3、软件生产的本质是“知识”从一种形式转化成另一种形式，或者说是纯脑力劳动。那么纯脑力劳动的结果以及结果的质量，往往极大地依赖于劳动者的劳动热情，那么能不能把这种依赖降低，甚至为无？