实施CMMI3有感：CMMI绝对是软件公司的特大毒瘤！

[wangyongc]

公司实施了一段CMMI3，很有感触，总结一下：
1 CMMI文档过多过滥
抽象看，好像CMMI的文档每一项都能说出它的用处来，但为什么这些“有用”的文档却不能在软件开发实践中起到促进作用，反而成为一种累赘呢？可能有以下几点：
1）现实中这些“有用”的文档都只是可能有用，而非一定有用。而且每份文档能起到作用的概率都很小，只是小概率事件。为了应对大量的小概率时间，而写大量的文档，付出相当大的工作量；即使这个小概率事件在一个较长时间内发生了一次，CMMI文档为此节省的成本，一般也无法抵消大量文档编写导致的成本升高。更何况不用CMMI也要写必要的文档，这个小概率未必就一定造成损失。
这就好比，每次赶飞机都提前2小时到机场以避免误机一样，坐一千次飞机耽误了2000小时。另一个人每次都提前三十分钟到机场，虽然偶尔有一次误了机，导致的损失也比不上2000小时的时间损失。
2）项目开发人员都不是作家，没有几个人有下笔成章的文笔能力。编写文档往往本身成为一个大的时间开销。假定每个人都有随手把心中所想转化为文档的能力是不切实际的。
3）软件开发人员的工作成效往往是在特定时段创造的，就是通常大家说的“灵感来了”。这种状态一旦被打断，下次进入这种状态就比较困难，勉强去做可能比高效状态效率低得多，出错概率还高。CMMI繁琐的文档和会议常常打断开发人员的思路，客观上延长了项目开发的周期，提高了出错量。
4）CMMI把高度创造性的开发过程当成机器的开动运转和停止，忽视了人的主观能动性和人在不同状态下工作效率的很大差异，必然遇到开发人员的普遍抵制。
2 CMMI定位是精细化管理，需要过程、交付、量化数据来支撑，如果还是依赖人员的检查、海量的Excel文件汇总，势必导致技术人员抵触，这样CMMI必然流于形式，所以结合业界成功实施CMMI公司的经验：CMMI必须要借助IT手段来推行。否则就是一大祸害。

[Johnyin]

关于ＣＭＭＩ３　，确实很少碰到能把它用好的企业．　但它是个工具，能否用好还得看人．　 本人并不排斥它，因为它也有很多好处，并非一无是处．　个人觉得其重点就两个方面：　 过程和数据．　如果不知道它的特点而盲目引用，结果可想而知：费时费力不讨好． 文档是跟过程相关的，你觉得文档多，其实就是说过程厚重了，应该是可以裁减的．

[wangyongc]

如果部分人抵触，可以说是个别人的问题，几乎所有人抵触，连领导也对CMMI很讨厌

[Johnyin]

那为何要搞ＣＭＭＩ呢，肯定有个源头吧．　 我当年实行ＣＭＭI 也是很多人觉得不爽,但真正走好后还是很规范的.中间过程比较麻烦.

[hua_zhixing_]

对CMMI的感触与LZ差不多， 个人觉得，不能完全抵触CMMI，也不能盲目照搬。 质量管控的人员和开发人员应该结合自身实际情况和CMMI规范， 再通过会议讨论认为哪些文档是必要的，哪些是没必要，再决定写哪些文档， 而不是把CMMI需要的文档全部都写。 CMMI应该作为参考，而不是教条，否则就成了形式主义和教条主义了。不过，当组织达到某种规模时，这方面的问题难免。

[wangyongc]

引用 5 楼 Johnyin 的回复:

那为何要搞ＣＭＭＩ呢，肯定有个源头吧．　 我当年实行ＣＭＭI 也是很多人觉得不爽,但真正走好后还是很规范的.中间过程比较麻烦.

为了拿证书，便于接项目，就是这个原因。拿了证书以后，惯性地实行了一段时间，结果上上下下都怨声载道，基本上不了了之了。

[Johnyin]

为了拿证接项目这就难怪了... CMMI3 是重过程的管理方式, 适合管理大型项目和周期较长的产品.适合"组织级"的管理优化. 对于单个的项目而言,如果适应了作坊式开发,或者敏捷的方式,再改成ＣＭＭＩ确实会怨声载道．毕竟有太多的新规矩要 制定和遵守． 根据企业自身特点选择合适的方式吧．如果老板都不上心，你也不用费那个劲了．

[wangyongc]

感觉推出CMMI的机构应该提供相应的IT工具，否则那么多文档，一致性极难保证，一个时间改掉或者后期模块做调整，要翻阅很多文档去做相应改动，工作量比修改代码还大得多。所以CMMI客观上阻止了代码和架构的优化，让不良的设计持续到底，最终烂掉。

[wangyongc]

比如中后期想优化修改架构，面对的阻力大得惊人，而越大型的项目，不去优化越容易在一段时间维护以后变成垃圾。 所以个人认为大型项目和周期长的项目走CMMI更是找死。

[wangyongc]

大型项目，到最后自己明知道有很多设计和代码问题，而这些问题有足够把握解决能使得更便于扩展和维护，也被CMMI的文档吓倒就不敢去做了。所以遵循CMMI的大型项目最后都成了垃圾和一堆废品

[Johnyin]

引用

感觉推出CMMI的机构应该提供相应的IT工具，否则那么多文档，一致性极难保证，一个时间改掉或者后期模块做调整，要翻阅很多文档去做相应改动，工作量比修改代码还大得多。所以CMMI客观上阻止了代码和架构的优化，让不良的设计持续到底，最终烂掉。

工具肯定是有的.我用过CC CQ 对ＣＭＭＩ３的支持就比较好．　大型项目如果你不规范管理，后继的变更，维护，换人等等会更加糟糕． CMMI阻止了代码和架构的优化? 肯定不会.只不过你目前可能都是手工文档在做.所以你的配置管理会比较繁琐. 如果来了一个变更, 如何进行影响分析? 如何进行配置项识别? 没有相应的东西支撑,估计都是靠拍脑袋,查代码或者干脆依赖做完后测试. 如果事先你就能知道要改哪些文档,哪些代码,变更处理会更加有利. 如果你不用其他工具想把ＣＭＭＩ做好，确实比较困难． 我经历过做得好的，每个版本的需求和最终做出的程序完全一致，工期估算也很准确，项目计划几乎毫无偏差地被执行．

[wangyongc]

引用 12 楼 Johnyin 的回复:

引用

感觉推出CMMI的机构应该提供相应的IT工具，否则那么多文档，一致性极难保证，一个时间改掉或者后期模块做调整，要翻阅很多文档去做相应改动，工作量比修改代码还大得多。所以CMMI客观上阻止了代码和架构的优化，让不良的设计持续到底，最终烂掉。

工具肯定是有的.我用过CC CQ 对ＣＭＭＩ３的支持就比较好．　大型项目如果你不规范管理，后继的变更，维护，换人等等会更加糟糕． CMMI阻止了代码和架构的优化? 肯定不会.只不过你目前可能都是手工文档在做.所以你的配置管理会比较繁琐. 如果来了一个变更, 如何进行影响分析? 如何进行配置项识别? 没有相应的东西支撑,估计都是靠拍脑袋,查代码或者干脆依赖做完后测试. 如果事先你就能知道要改哪些文档,哪些代码,变更处理会更加有利. 如果你不用其他工具想把ＣＭＭＩ做好，确实比较困难． 我经历过做得好的，每个版本的需求和最终做出的程序完全一致，工期估算也很准确，项目计划几乎毫无偏差地被执行．

用了CMMI，不管你有没有工具，当你提出要对代码和架构做大的重构的时候，肯定会被一致反对的，沟通比较繁琐的时候，大家都有惰性，不想变更现状。

[以专业开发人员为伍]

这个主要还是为了应付那些官僚老爷。

[以专业开发人员为伍]

你打开一本20年前的软件“国标”来看看，不管哪一个文档，基本上都是一大堆罗列的“xxxx性、xxxx性、xxxx性”之类的定性术语上。这种文档根本就是说是非的，而不是说流程的。根本就是事后说三道四用的，而不是事前准备驱动你尽快开发出优秀产品用的。 这就好像你去吃饭，别人已经点好了餐，而你还在那里默念“这个性、那个性”之类的是非判断，甚至要给人家厨师上一堂“标准化课程”，你才敢在这个饭馆吃饭。结果可想而知。这种人就是契诃夫笔下的那个打扮得不男不女的“套中人”。 我们不是20年前美国国防部的官老爷，也不使用它来苛刻要求那些巨型武器公司的产品的。针对中国的软件公司的行为标准，我们应该比这些东西少更多地“是非”纠结，多删除一些东西。 我们少纠结一些“是什么”的争论，多一些“如何做”的实践。

[以专业开发人员为伍]

使用极限编程开发方法，在非常务实地编制了必要的“安全网”之后，我可以有勇气去在几天之内将多个核心架构重新调整，即使立刻出现500个严重bug，也可以有勇气在两天之内完美地消除掉。当我们遇到“肯定会被一致反对的”的观点时，往往可以断定这人肯定是没有跟我们一样熟练使用极限编程开发方法的，是出于没有自动化软件测试技术所带来的胆怯（尽管理论头头是道，但是很少道理已经被写成了自动化程序，他们的道理都是不可执行的“自然语言文字”）。 我们是有了其它技术手段之后，才反对CMMI。而不是盲目抛弃它的。

[wangyongc]

CMMI有点像空想社会主义，忽视人性的作用。人都是有沟通惰性的，能自己决定的事，执行最迅速；需要两个人沟通的话，效率低一半；需要三个人以上协商沟通的话，都有畏惧心理，经常久拖不决、不了了之。CMMI把本来一个人很快能做好的事情，搞成层层上报审批，能搞好才怪。

[wangyongc]

引用 16 楼 sp1234 的回复:

使用极限编程开发方法，在非常务实地编制了必要的“安全网”之后，我可以有勇气去在几天之内将多个核心架构重新调整，即使立刻出现500个严重bug，也可以有勇气在两天之内完美地消除掉。当我们遇到“肯定会被一致反对的”的观点时，往往可以断定这人肯定是没有跟我们一样熟练使用极限编程开发方法的，是出于没有自动化软件测试技术所带来的胆怯（尽管理论头头是道，但是很少道理已经被写成了自动化程序，他们的道理都是不可执行的“自然语言文字”）。 我们是有了其它技术手段之后，才反对CMMI。而不是盲目抛弃它的。

我也很推崇敏捷和极限编程，软件开发跟机械产品研发有根本不同，试图用建筑机械行业的流程管理软件开发注定失败，CMMI就是一个例子。软件质量取决于人的素质和积极性，试图用过程管理来提高质量很难很难。 在CMMI实施的时候，明明有很好的重构方案，而且有十分的把握做好，但就是面对各部门的重重阻力不能去做，十分郁闷。

[sun51]

·为了过CMMI L3或为了CMMI而CMMI，确实无聊 ·从完成公司的商业目标来看，CMMI确实是好东西。CMMI的是方法论，操作层面上的东西需要根据公司或项目 实际情况来确定。 ·举个例子：“需求双向一致性跟踪”，对于一个维护周期超过10年的项目，如果需求做不到一致性跟踪，那么这个项目将是非常艰难。 ·CMMI在很过公司被妖魔化了，很多开发人员把CMMI看成了写很多多余文档，和各种“仪式”表演，但是不要因此我认为CMMI是垃圾或毒瘤。

[洛linlee]

引用 18 楼 wangyongc 的回复:

CMMI有点像空想社会主义，忽视人性的作用。人都是有沟通惰性的，能自己决定的事，执行最迅速；需要两个人沟通的话，效率低一半；需要三个人以上协商沟通的话，都有畏惧心理，经常久拖不决、不了了之。CMMI把本来一个人很快能做好的事情，搞成层层上报审批，能搞好才怪。

看完所有人的帖子吧，觉得你的抵触情绪特别多。不知道你是不是先做一个认同，就是CMMMI提供的是一个目标以及做好目标目标可能会涉及的方方面面。是指导性思想。怎么做，方法在执行者。 另外，你是否太强调个人能力了？公司到达一定规模，不是个人的“快好省”就代表整个项目里里外外上上下下都能有序地快好省的。所以想想它为什么会出现，出现后不是适应所有公司的，一定程度上适应也得做改良。 申明我是菜鸟，不要打我～

[C-Rianbow]

1-1）、pdp没有做好导致楼主产生偏见 1-2）、写文档不是写文章，切勿偏见 1-3）、依赖于产生“灵感”的人来做项目的话，并非是有成熟意向软件工程企业的做法 1-4）、如果深入了解ma过程域，楼主即不会有此观点 2、不管是人工、还是软件手段，文档量、检查量的多少都是依据组织过程改进情况和过程定义来决定的，cmmi的opf明确说明要过程改进，对于不符合不适合的东西要及时改进，这是贵公司epg的职责所在。 接触it手段推行，的前提是线下流程比较成熟。

[zizzfish]

楼上说的很专业。 楼主对CMMI基本不了解，强调个人英雄主义。CMMI不是一个模型而是一个体系，每个公司要根据自己的实际情况制定流程体系。没有体系、没有文档那开发还不乱成一锅粥。