个人认为，CMMI整体的减法指导思想是错的

去年，公司开始培训cmmi的相关内容，也准备过级，为了配合过级，制定了一系列的体系文件，但在实际运作过程中收效甚微。

近期，我准备带领团队，根据自己的理解做出一些调整。

总体感觉，CMMI体系很庞大，在整个软件开发过程中，对于具体细节的工作有很好的指导意义，但是，我参加整个培训和经过一段时间的管理实践，最大的感觉是CMMI整体的指导思想从根本上就是“错”的，而对于具体工作的研发过程和操作步骤有很好的参考价值，也许从二级到三级或从三级到四级是正确的，也可能过级并不是很难，但至少对于手工作坊的软件公司从一级向二级过渡时的指导思想是错的，我这样来理解也许会被很多CMMI高手拍砖，但是欢迎拍砖。

那么为什么说CMMI总体指导思想是错的，我是这样来理解的，CMMI和RUP都强调做减法，要想真正做好减法，首先必须对CMMI体系有深刻的理解，并且对自己做做的项目有足够的认识才能够做好减法，但是实际情况是怎样的？项目随着时间的推移会发生很多需求变更，项目的范围也可能会越来越大，做好减法的项目规范往往不仅束缚了人的灵活性，同时也不能满足项目发展的实际需要，感觉越来越别扭。

因此我的理解是首先扎扎实实地了解CMMI体系中每个步骤的标准做法，然后制定最小项目的管理规范，在此基础上作“加法”，当然现在正在尝试这样做，实际运行效果还有待时间检验。

为什么说要做“加法”而不是做“减法”呢？

其实，这个世界的发展就是由加法构成的，而绝对不是由减法构成的，因此，我认为无论做什么事情，加法都比减法重要，加法是为了达到目标，做事要循序渐进，减法是先知告诉你为了达到目标，可以少做一些事情。

举个例子来说，各类软件工程的教材上都说软件工程其实是参照建筑工程发展而来的，也都举例说明盖一个狗窝和盖一个帝王大厦的区别。

假设我们用CMMI的减法指导思想来盖一个狗窝，那么怎么做？

首先，拿到CMMI体系文件，然后拿出裁剪指南，根据裁剪指南，什么事是需要的呢？

经过一系列的裁剪，好像没有什么事情（文档）是不能裁剪的，于是都裁剪掉了，于是盖狗窝这个“项目”失控了。。。

那么如果按照加法原则又是如何做呢？

其实，无论是盖狗窝还是该帝王大厦，都有类似之处，都有一些事情是必须要做的，加法的原则就是首先有一个规范做事的最小集合，这个最小集合不仅包括该做的事情（文档），也包括对事情（文档）质量的要求，那么对于盖狗窝这类事情，完全没有必要把文档复杂化，要坚持简单的原则。

那么我们来看做加法的最小集合是什么？

1、合同或协议（可选）：首先，盖狗窝也有成本，有成本那必然涉及到成本预算，如果是商业行为，就必然存在合同或协议，但有时这不是必须的，而且很多实际情况下，对于小项目而言，项目已经结束了，可能合同还没有签订都有可能，也可能用户直接付款，不用签订合同；

2、建设方案（必须）：既然是商业行为，不说明如何盖狗窝是不行的，必须要有一个如何盖狗窝的建设方案（可能是一页纸的构思草稿），这个不能省略；

3、验收报告（可选）：如果有合同，最好有验收报告，但是对于盖狗窝这么小的事情，用户可能不要求你一定要有书面验收；

4、施工计划（必须）：虽然用户不需要书面的施工计划，但是作为一个管理类的项目，施工计划是一定要有的，但是对于盖狗窝这么简单的事情，计划可以简化成一句话：某年某月某日上午，安排某人盖一个狗窝；

5、需求分析（可选）：如果建设方案能够说明要做什么了，那么需求分析就是可选的了，对于盖狗窝这件事，完全没有必要要写一个完整的需求分析报告；

6、界面原型（必须）：虽然说盖狗窝这件事比较简单，但是狗窝也有各种形状和大小，不向用户说清楚是不行的，向用户说清楚最好就是做原型；

7、系统设计（必须）：作为一个软件开发项目，系统设计是必须要有的，但是盖狗窝这件事实在是太简单了，那么系统设计就用一张纸写清楚吧；

8、程序开发（必须）：这就不用解释了吧；

9、系统测试（必须）：狗窝盖好后，要检查一下是否坚固耐用，这是必须要做的，那么是否必须要写测试用例和测试报告呢，我看测试用例能免就免了吧，既然做了测试，测试报告是一定要写的，否则怎么能够证明做了测试呢，但是测试报告就简化成一句话吧：某日张三检查了一下狗窝，可以使用。。。

10、配置管理（必须）：这还用解释吗，所有的文档都必须要存档保留；

11、QA（必须）：有计划就有QA，有QA就有QA报告，但是QA报告也简化成一句话吧：某日，李四给王五盖了狗窝，盖好后，张三做了测试。。。

12、系统上线（必须）：这也不用解释了吧，狗窝盖好后，狗当然要去住。。。

这样，最小集合就出来了，比盖狗窝大的项目在此基础上做加法吧，不仅要增加文档的种类，文档的厚度（内容）也要相应增加。。。

这就是我认为的做加法和做减法的区别，个人认为，做加法更加可行。。。