最近公司也在进行CMMI的３级评估，公司实施CMMI确认可以提高组织级的能力成熟度。这里我不想去谈论CMMI的优点，仅想去分析下CMMI带来的问题。CMMI只会告诉你要做什么而不好告诉你如何做， CMMI无法保证项目的真正成功，这些就不多说了。

 1.CMMI扼杀优秀人员的效率，激情和创造力。

程序员最大的乐趣在于思考和创造，而CMMI的一大堆规程和过程无疑会极大的阻碍我们的这种激情。现在组织要求你的就是按照规范按部就班的去做事情，然后输出一大堆的文档，往往你工作的60%或者更多的时间会花费在写文档上面而不是花费在思维的乐趣上。你不用去考虑这里有没有更优化的算法，可以采用的新技术，你只用按照组织已有的技术和规范去完成你的工作。所以在这里我们更能够体会到生产和创造的不同，生产就是要求你完成一个产品后完全以葫芦画瓢的方式去重复的拷贝，而创造却是会给你足够的空间去分析和考虑事物，找到解决问题的优化方案。

 2.CMMI忽略人的主观能动性。

一个机器每天能够产出多少基本没有偏差，而一个有独立意识的人生产率确千差万别，首先是不同的人生产率差别很大。其次是同一个人生产率差别也会很大。今天遇到一个技术难题要查资料，可能会延误2-3天或者更长的时间，今天自己遇到什么事情心情不好可能编码效率只有平时的20%，这些都是完全真实发生的事情。而这些我们是很难估计和预测到的。

CMMI假定每个个体都会按照制订的规程去认真的完成每一件事情，而这个假设往往又是很难成立的，工作责任心强的会认真的去完成，而工作责任心差的只会敷衍了事。就如CMMI要求你要进行工件的评审和制订相关的里程碑和检查点，但CMMI确无法保证你能够很好的达到评审的效果，评审的效果究竟如何很难衡量。

 3.CMMI重视文档轻视沟通。

沟通是传递和交流信息最简洁高效的方式，一个我们通过10分钟能够沟通确认清楚的问题，可能你需要化30－60分钟或更常的时间才能够描述清楚每一个细节。文档不能代替语言，语言不能代替表情，声色俱备的当面沟通才是获取信息的最佳途径。而CMMI各阶段输出的文档很多时候成为一种摆设和花瓶而无人问津。

 4.CMMI和敏捷和迭代的开发方法有冲突

敏捷是以测试驱动的快速增量迭代方式，敏捷方法强调沟通和重构，敏捷方法去适应变更而不是恐惧变更。敏捷方法没有明确的各阶段文档输出，强调源代码和注释就是最好的文档。迭代的方法可能有设计的相关输出，但是一个逐步细化和求精的过程，项目的初始阶段也可能有编码等相关活动，而CMMI强调规程，文档和证据，这些估计敏捷和迭代都很难提供清晰的证据。

所以我们在实施CMMI过程中更多的是采用瀑布和增量1模型，明确出各个阶段和里程碑，去产出相关的工件，去控制过程。而这对前期需求就不明确的项目将是致命的风险和打击。

5.CMMI假定项目成员技能满足要求
CMMI强调要技能项目成员技能的评估，项目成员技能无法达到时候要组织专门的培训，关键问题是项目成员技能无法达到的时候我们仍然要进行项目，而不是等待项目成员全部合格才开始项目，特别是项目成员存在流动时候这种人员技能无法满足情况会给项目带来严重的风险。

作者：人月神话