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

to icewarmed：
我不想谈很多理论上“应该会”的事情。看上去很美的东西未必真的很美，CMM 这样试图无所不包的“大方法论”正是这类东西。如果你真的打算成为一个好的方法论研究者，一定要见多识广。除了 SEI 的 CMM/PSP/TSP 那几本教材以外，《人月神话》、《人件》、《敏捷宣言》、RUP、XP 系列丛书、FDD、Crystal、ASD、Scrum、Lean、DSDM、MSF 都要认真看过。有比较才能有鉴别，各方面的观点都应该听说过，思考过，甚至连 TDM 所说的“CMM 就是软件行业的耻辱柱”这样在一些人听起来非常刺耳和偏激的言论也不放过。古人说闻过则喜，不要故意放过自己所不喜欢的观点。

想起了两个凡是，呵呵。我再加一个：
我是一个商人，总是喜欢从成本的角度考虑问题。凡事都要讲一个性价比。我们去菜场买西红柿都要问一下价格，在同样质量的前提下，有 8 毛一斤的我不会买两块一斤的。有很多证据可以证明严格执行 XP 可以以更低的成本达到与 CMM 所宣称的相同的效果，那么为什么我要去买两块一斤的 CMM？
而且，凡事要计划，计划是要准备根据实际情况做出修正的（计划就是用来改的），而不是一成不变的。XP 那个开车的比喻很恰当，你开车是要随时根据路况调整你的方向的，而不是朝着一个方向一头开过去。
凡事要记录，记录确实是很重要的，但是上升到凡事的高度未免过了。而且记录是你成功的保证吗？我仍然要说 CMM 最多可以记录成功，但是无法保证任何人成功。
凡事要review，这个我完全同意。问题是这个 review 是不是一定要搞成非常正式的 review 会议？review 更多地是个人的工作习惯，是不是一定要上升到制度的高度？你要去研究研究心理学，很多事情作为强制性的制度反而无法达到预期的效果。要注意：人是有逆反心理的，而且绝大部分人不喜欢严格而繁琐的制度。为了让他们保持在最佳的状态以便达到最高的工作效率，在大部分场合下制度最好能顺着人的天性来。你该不会认为一定要“存天理，灭人欲”吧？
凡review要有checklist。我要再提出一个问题：软件开发最关键的究竟是不是度量（这个在 CMM 里面被提到了非常高的地位）？是不是任何工作都可以量化了，我们就一定会成功？达到这个目标所付出的成本是不是我们在有限的资源限制的条件下可以承受的？根据的我观察，所有大谈特谈理想条件下（可以利用的资源是无限的！）应该如何如何的人（不是特指，千万不要对号入座）都没有多少实际开发经验。其实真正做项目的时候可以利用的资源（人数、时间、开发人员的能力）是很有限的，最主要的就是做出一个权衡。需要设定几个目标，划分出优先级，把最重要的几点做好，不可能什么都尽善尽美，那样做也没有什么意义，而且可能会有很高的成本。

不要再缘木求鱼了，多做一些踏踏实实提高开发人员技能的工作吧。技术确实不是万能的，但是没有技术是万万不能的。CMM 仅供参考还是不错的，但是如果要“认真彻底地执行”，还是免了吧。我们还有很多更重要和更紧迫的事情需要去做。挂 CMM 之名行敏捷之实是我现在能给出 PIG（不是贬义啊，呵呵）的最好的建议。如果能踢开 CMM，还是直接光明正大地说我们其实就是敏捷一派好了。没有什么见不得人的，因为本来敏捷在几年前就已经成为软件开发方法的主流了，而且敏捷实际上有着比 CMM 更加严密的理论体系（例如 Crystal），完全可以满足理论研究狂热者的需要。根据我同在国外的朋友的交流，CMM 除了在印度，其实在美国也从来就没有成为过软件开发方法的主流。CMM 只能解决软件开发下游环节的一些问题，所以我对 o6z 说的 CMM 只适合外包类的软件企业是同意的。而对于其它类型的软件企业，CMM 甚至有可能成为企业发展的紧箍咒。我甚至怀疑欧美大厂把 CMM 推销给印度人就是一个不怀好意的圈套，为的是把他们限制在软件开发的下游环节，始终无法与自己竞争。你只要看看他们自己是否“认真彻底地”执行了 CMM 就可以做出判断了。如果真的是香饽饽他们自己为什么不用呢？把 CMM 当作中国软件行业的万灵药同样是我所不能苟同的，除了更加强化我们躯干国家的地位（请参考以前我的帖子中提到过的头脑国家和躯干国家的区别），以及甚嚣尘上的所谓“软件蓝领”说造成的开发人员普遍缺乏敬业精神好高鹜远疏于技艺以外，我们还能得到些什么东西呢？为什么我们就不能欣然接受软件开发方法的多样性，而一定要接受一个千秋万代一统江湖的大方法论呢？这是不是计划经济时代任何时候都需要有一个官方的理论体系，都需要整齐划一统一口径的思维惯性所留下的遗毒呢？

对软件度量，有些东西还是有价值的比如ODC,SRE这些东西，也不能一概的否定，只是如果为了度量而度量，那就不可救药了，自己会给自己搞死的。
CMM基本的假设使它比较适合外包的业务模式，就是那种不求有功，但求无过的价值观，这点上和敏捷宣言是不同的。如果一直做外包做到老，把自己做成来料加工的巨无霸，没有什么问题，如果开发真正的软件产品，按CMM走并不合适。
怎么搞，得看自己要干什么，有多少资源；大家都在说CMM的好和不好，那关于CMMI呢？

如果没有比尔·盖茨，什么样的制度能让微软成功？如果没有Anders Heijsberg（拼写可能错了），什么样的制度能让Borland拥有DELPHI？如果没有Rickard Oberg，什么样的制度能让JBoss想起来用动态代理实现RMI？

换个角度继续提问。为什么连核心团队都人来人往？为什么一个项目结束之后不能得到一个“胶凝团队”？为什么牛人在公司里留不住？如果一位管理者解决不了这些问题，却想把这些显而易见的管理问题推给项目经理、推给程序员来解决，那么对于这个企业的失败，我们究竟应该认为是谁的无能招致的？

CMMI最近的情况似乎不好，据说SEI要放弃，而回到CMM。
CMM的问题实际上在于没有遵守通行的质量保障体系的一般性做法，也就是没有认真地研究传统行业成熟的质量保证系统的基本原理。CMM的根本问题不在于细节上的繁琐，而在于基本思想的非工程化倾向，实施手段的非人为色彩，评审标准的过渡色彩。
下面我来分析一下通常情况下的传统质量保障体系，我以我比较了解的医药行业的GMP来说明。GMP是一种保障药品及其类似产品生产的操作准则，在我们国家有强制性的国家标准，而WHO也有相应的标准。这个体系承诺，按照其方法进行实施，可以保证产品的最终质量，符合最初的制定的质量标准。这一点上CMM所提出的质量，实际上是一种生产者对产品技术指标的看法，而非用户的看法。这实际上是一种最大的违背质量管理基础性错误。而由于这个错误，其也必定造成不能承诺按照其过程生产的产品，可以符合最初的质量诉求。而一个质量保障体系，如果不能满足生产合乎最终产品的质量要求的这个最基本目标，我不知道它存在的意义是什么？
GMP是一种操作规范，但是GMP实际上还涉及了非常多的对于操作的硬件环境的要求，而不仅仅是对于生产者生产活动的要求。比如你生产环境的温度湿度这些最基本环节因素，以及粉尘和微生物指标，人员密度，某些环节的空间大小，人员和物料流动的通道，以及等等类似的周边环境。这些环节对于最终的消费者是不可能去考察的，但是这些又是对药品的最终质量造成了极其重大的影响的环节。比如我们如果不在一个干净的环境下生产口服液，虽然可以在最后使用其它手段来达到微生物指标，但是由于有了前期的污染，药品的药性是否已经发生了改变，对人的影响是否是无害的，就很难只是通过最终的质量检测予以证实。而CMM的体系根本就不涉及一个全面的生产过程，只是对于软件开发过程中的生产软件的流程进行的指导。而就是由此，CMM实际上也根本不可能完成对于软件产品质量的保障。
GMP所采取的都是具体而量化的指标，比如重量度量的误差究竟是多少，环境微生物浓度究竟是多少，温度湿度究竟是多少。而CMM根本就没有这样一个具体和量化的体系。最基本的CMM在2级中就要求必须将客户的需求文档化，清晰化。但是是不是文档化的需求就真正的是客户的需求，以及究竟如何判断客户需求究竟要清晰到什么程度根本就没有提及，最终的结果实际上就非常可能是签署了一大堆的协议，但是客户究竟想要什么还是不清楚。这样的手段作为一种保障软件开发企业自身的商业手段是可以推广的，但是作为一种对软件产品质量的控制手段可以说是贻笑大方的。
GMP对于生产等环节的控制是提供了具体的技术手段的，比如多久要测试一次环境，多少产品要抽查一次，等等都是进行了具体的规定的。而CMM所提供的手段落实到最后，实际上就是建立在文档基础上的评审，从根本上来说还是依赖具体的人的操作，而非依赖技术体系和管理制度的规范化。实际上从这一点就可以看出，CMM根本上还是在走coding-fix的老路，只不过是经过了一种更加华丽的包装。
其实从根本上来说CMM就不是一种关于质量的体系，具体是什么我也很难做出一个明确的定义。

CMM是不是一个资质的标准呢？其实同样也不是。资质是用来衡量一个组织（个人也是一种组织）从事某些活动的综合素质。基本上要包括技术能力，管理能力，实施能力，人员构成，资金状况，经营活动的纪录，以及其它一些具体的指标。CMM显然不能覆盖，哪怕是大部分覆盖这些能力，其涉及的具体要素可以说太少了。
同时资质往往还是分级别的，也就是高级的必须满足低级的一切要求。但是CMM从理论上看，认为不同的级别有不同的KPA需要去完成，而不是在传统资质那样，去对基础能力指标的扩展。比如医院必须有床位，不同的级别必须达到某种最低的要求，并且逐级增加。虽然从理论上说CMM也是应该如此，但是CMM更加关注的是在级别提高基础上的引入新的KPA的实现，这就造成了大量的高级的组织实际上还存在大量的低级组织的问题。比如SCM的问题就普遍性的存在与所有的CMM组织中，没有问题往往就是那些在CMM2级上停滞不前的，也没有进行过PIG组织。
资质中很重要的部分是人员和业务经历的时间要素，比如是否进行了多少年的专业活动，是否在多少年中完成过多少多大规模的项目。而CMM恰恰没有对于这些最核心要素的要求。

嘿嘿，这句话可谓醍醐灌顶。这几天关于文档的意义我想了很多，得出来的结论无非是文档具有传承经验，把因为人员流动引起的影响降低到最小的作用。可是这又引起了我的一个困惑，难道文档的作用仅仅只限于此吗？那么我们花了大力气写的详尽无比的文档，如果没有人员流动的话，难道就没有作用了吗？

看了gigix的话才明白，原来我的结论一直建立在默认了软件团队中人员流动很多，团队构成不稳定的前提下。我们一直想在开发过程中想着怎样把因为人员不稳定带来的影响减到最小，而不是想着如何才可以减少人员的流动，提高人员的忠诚度。看来，我们承担了比我们应该承担的更多的责任。

文档最忌讳繁琐无比，事无巨细的都要说明，如果是这样我直接去看代码好了。实际上多数人都默认文档的抽象程度比代码级别高，看文档比看代码省事。但是如果你的文档过于细节化，那么你的代码很难做到同步于文档。这将是一个巨大的威胁。很多人抱怨要看一堆没文档的代码，但是他们很少真的看到过合适的文档。实际上文档的作用应该是让阅读者快速找的代码的位置，而不是用文字说明代码的作用，那些应该是单元测试的事情。
人员的流动带来的最大问题，实际是知识的流失。文档可以固定下一部分的知识，但是如果文档的抽象层次不够，这些知识并不能很容易的被掌握，那么这些就是无用功。

现在大家都用高级语言开发了，我想对文档的重视的那些观点很多是因为当时的语言可能都是汇编之类的，表达能力还不够，文档当索引就够了。
直接对代码下功夫！WORKING SOFTWARE over Comprehensive Documentation

哈哈，这个帖子还真是火热。
   看了大家的帖子，基本上分为两部分。我想我应该属于中间者吧。
   其实大家在讨论CMM的时候，应该分开来看，将CMM模型、CMM模型与软件过程、CMM认证、中国企业的CMM认证实施情况四个部分。
1.单纯看CMM模型，我实在找不出它的KPA有什么问题，配置管理、QA、测试、项目管理，它着重描述的软件开发中的关键点至少在目标上来说是恰如其分的。当然，它的一个方面，也是大家所诟病的就是每个KPA的评估是根据文档的，以及文档的数量。
2.CMM模型与软件过程，几乎95％以上的人都将CMM与RUP等同起来，或者说将CMM与敏捷过程完全剥离开来，其实这是不恰当的。CMM的模型是考量软件过程中关键点来评估软件过程的成熟度，而与这些点是怎么样的串联以及关系是没有任何要求和强制的。
3.CMM认证，和大多数人一样，我虽然承认模型中的可取性，但我并不认同CMM的认证。如果我承认软考或者其他认证的可取性一样，但并不认同参与认证一样，尤其要通过一个这样的认证需花费巨大的成本，没有几百万的直接投入是不可能通过的。
4.CMM之所以这么臭，也就是和最后一点相关系了。我不清楚gigix是否说的属实（不过我清楚中国信息产业部也有自己的认证，相反和CMM还不同，并不承认CMM，为此还争论过很久），但是，真是绝大多数软件企业不是内修本事，而是尽做些表面文章,而媒体、行业又在大肆吹捧（我实在觉得中国的软件行业好浮躁，喜欢抄概念），所以作为从业者的我们，多少对其都会有些抵触。
    CMM对于软件过程的真正部分，也就是开发这一块评估是相当弱的，也是由于这是最难评估的。另外实施CMM的都是用UP的，也就是有固定规则的过程，所以在这种情况下开发部分的持续集成是比较难以实施的。其实啊，对于大团队多独立模块的持续集成（也就是日集成）我一直都是保留疑问的（也正是因为我在这个方面缺乏经验。）

的确，没有gates就没有ms，但是这个问题扯开了就变成是英雄造时势还是时势造英雄了。毕竟gates只有一个，管理上更关注的是gates建立ms后，如何能够作成百年老店，能够长久不衰

管理和过程，更多是关注如何把整个组织整合好，从方针制定的领导者，到具体进行实施的工程师，使他们的行为可预知的，可控的。这样他的客户才能够对他的产品放心，买的放心，用的放心。

psp、tsp和印度公司的规程，要求的文档很多，还有很多会议，实际上，该讨论的问题还是要讨论，该规避的风险还是要规避，任何的管理，至少是要有计划，有检查，有总结的，我觉得这些要求并不过十分过分。过分的是囫囵吞枣，领导层在还没有理解为什么，就要求一定要这样作；而操作层在没有理解为什么的时候，就闹起来，结果什么也没有办好。一地鸡毛