【理想流】CMMI批判（一）

最新推荐文章于 2018-03-17 16:54:30 发布

leezy_2000

最新推荐文章于 2018-03-17 16:54:30 发布

阅读量2.7k

点赞数 1

分类专栏：理想流实战项目管理文章标签：文档搜索引擎配置管理任务语言

本文链接：https://blog.csdn.net/leezy_2000/article/details/6892387

版权

理想流同时被 2 个专栏收录

64 篇文章 0 订阅

订阅专栏

实战项目管理

13 篇文章 7 订阅

订阅专栏

CMMI这个模型的根本问题不在于模型本身是否成熟，而在于这一模型所牵连到的诸多困难通常很难克服，最终导致这一模型在实际应用中，大多时候的结局只能是形式大于内容。

CMMI批判之二

CMMI的边界

CMMI起源于美国国防部，这一出身直接决定CMMI是为了解决大型项目中所遇到的问题来到这世上的，并最终导致CMMI成为一个庞大且复杂的方法论。

大方法论意味着其复杂度偏高，复杂度偏高也就意味着推行成本以及ROI（Return On Investment）为负的风险增高。

这世界上并不先验的存在着因为这是CMMI，所以实施他一定适合当前项目，一定可以获得正收益这样的因果。

即使不经过论证，单纯从哲学的角度出发，至少也可以说，一定情况下的项目实施CMMI是没有收益的。因为既然CMMI不是绝对真理，那就必然有它适合的地方，也有它不适合的地方。而这个问题似乎历来被人们所忽略，似乎也没有人试图去分析究竟什么样的情况下不适合实施CMMI？

许多人是在盲目的谈流程会为项目带来好处，但却很少关注为什么流程会为项目带来好处。而一旦在这一点上迷失，不知道CMMI边界何在，那就会误以为流程可以解决所有问题，滥用流程也就成为一种必然。

个人以为，流程之所以能给项目带来好处，主要在于以下两点：

①设想一下，假设说一个团队只有一个人，那这时候，流程以及步骤就只有一个作用，避免某些事情被忘记，换句话说就是使历史经验得以累积。比如，不要这次记得做风险管理，下次却没做；不要这次做风险管理时考虑到了需求变更风险，下次却没考虑到。这个时候，流程以及模板即使需要，也不需要做的很细，反倒是对经验数据的记录成为重点。

②而一旦软件规模膨胀，小组成员也就必然增多，沟通路径也就必然变的繁杂，并最终导致软件行业著名的规模不经济（diseconomy of scale）现象。当沟通路径从一条变为N条的时候，沟通路径将变为n*(n-1)/2。

在这样一种前提下，如果没有流程约束小组成员的行为，那么信息流乱窜，最终必然导致灾难性后果。换句话说，这种情形下，流程的一个作用是理顺信息流，并统一全体人员的方向。

CMMI中诸多过程域，从目的来看，翻来跳去也出不了这个范畴，比如风险管理的主要目的是前者。而需求管理等的主要目的是后者。至于配置管理等则是两者兼顾。

这里需要单独一提的是度量与分析。CMMI自身很大的一个目的是促使组织积累日常数据，并对组织行为是否异常进行监查及预测。也许有人认为这点不同于上文所提的①与②应被单列。但我个人认为实际能完成监察及预测的是与监察及预测相关的任务，而非定义了监察及预测相关步骤的流程。所以即使就度量及分析这样的过程域而言，流程所能起的作用仍是①与②。

也就是说，如果一个组织的问题不是出于以上两个原因，那么流程改善对增强组织的竞争力没有帮助。

这个结论很关键，这意味着如果你项目组当前的问题是由于沟通不畅或者有些步骤经常被遗忘，那么你需要改善流程。但如果问题是人的主动性乃至能力不够，那么虽然貌似和流程有一定关系，但却决不是流程所能解决的问题。

流程以外影响项目开销的因素还有很多，比如：需求分析师的能力，程序员的能力，人员流动性，团队凝聚力等。除此之外，需要特别提起的是创新能力。

前面曾经提到，CMMI的出身决定他更适用于大型项目。但除此之外，这一出身也决定了它的另一个特性。CMMI最终的目的是把项目质量控制到一定范围内，并持续改善，所以它专注于成熟度，专注于软件的质量。这对大型的军工性的项目无疑的是合适的。但对创新性项目却未必合适。举个极端的例子，在Google的搜索引擎来到这个世上后，也许CMMI能帮助这个搜索引擎持续稳定的运行，但却对他来到这世上毫无帮助。

很不幸的是，在国内，似乎有一种趋势，那就是CMMI是一剂灵药，适用于各种类型软件项目，适用于解决各种类型的问题。即使变更代码行数每个项目周期只有只有千行左右的项目，也要使用CMMI。这似乎从起点就错了，也是对什么是CMMI的边界认识不清楚所导致的必然结果。