实施CMMI3有感：CMMI绝对是软件公司的特大毒瘤！
公司实施了一段CMMI3，很有感触，总结一下：
1CMMI文档过多过滥
抽象看，好像CMMI的文档每一项都能说出它的用处来，但为什么这些“有用”的文档却不能在软件开发实践中起到促进作用，反而成为一种累赘呢？可能有以下几点：
1）现实中这些“有用”的文档都只是可能有用，而非一定有用。而且每份文档能起到作用的概率都很小，只是小概率事件。为了应对大量的小概率时间，而写大量的文档，付出相当大的工作量；即使这个小概率事件在一个较长时间内发生了一次，CMMI文档为此节省的成本，一般也无法抵消大量文档编写导致的成本升高。更何况不用CMMI也要写必要的文档，这个小概率未必就一定造成损失。
这就好比，每次赶飞机都提前2小时到机场以避免误机一样，坐一千次飞机耽误了2000小时。另一个人每次都提前三十分钟到机场，虽然偶尔有一次误了机，导致的损失也比不上2000小时的时间损失。
2）项目开发人员都不是作家，没有几个人有下笔成章的文笔能力。编写文档往往本身成为一个大的时间开销。假定每个人都有随手把心中所想转化为文档的能力是不切实际的。
3）软件开发人员的工作成效往往是在特定时段创造的，就是通常大家说的“灵感来了”。这种状态一旦被打断，下次进入这种状态就比较困难，勉强去做可能比高效状态效率低得多，出错概率还高。CMMI繁琐的文档和会议常常打断开发人员的思路，客观上延长了项目开发的周期，提高了出错量。
4）CMMI把高度创造性的开发过程当成机器的开动运转和停止，忽视了人的主观能动性和人在不同状态下工作效率的很大差异，必然遇到开发人员的普遍抵制。
2CMMI定位是精细化管理，需要过程、交付、量化数据来支撑，如果还是依赖人员的检查、海量的Excel文件汇总，势必导致技术人员抵触，这样CMMI必然流于形式，所以结合业界成功实施CMMI公司的经验：CMMI必须要借助IT手段来推行。否则就是一大祸害。
[解决办法]
关于ＣＭＭＩ３ ，确实很少碰到能把它用好的企业． 但它是个工具，能否用好还得看人．
本人并不排斥它，因为它也有很多好处，并非一无是处． 个人觉得其重点就两个方面：
过程和数据． 如果不知道它的特点而盲目引用，结果可想而知：费时费力不讨好．
文档是跟过程相关的，你觉得文档多，其实就是说过程厚重了，应该是可以裁减的．
[解决办法]
那为何要搞ＣＭＭＩ呢，肯定有个源头吧．
我当年实行ＣＭＭI 也是很多人觉得不爽,但真正走好后还是很规范的.中间过程比较麻烦.
[解决办法]
对CMMI的感触与LZ差不多，
个人觉得，不能完全抵触CMMI，也不能盲目照搬。
质量管控的人员和开发人员应该结合自身实际情况和CMMI规范，
再通过会议讨论认为哪些文档是必要的，哪些是没必要，再决定写哪些文档，
而不是把CMMI需要的文档全部都写。
CMMI应该作为参考，而不是教条，否则就成了形式主义和教条主义了。不过，当组织达到某种规模时，这方面的问题难免。
[解决办法]
为了拿证接项目这就难怪了...
CMMI3 是重过程的管理方式, 适合管理大型项目和周期较长的产品.适合"组织级"的管理优化. 对于单个的项目而言,如果适应了作坊式开发,或者敏捷的方式,再改成ＣＭＭＩ确实会怨声载道．毕竟有太多的新规矩要
制定和遵守．
根据企业自身特点选择合适的方式吧．如果老板都不上心，你也不用费那个劲了．
[解决办法]
