1 CMM/CMMI

众所周知，软件开发的风险大，是由于软件开发过程能力低，软件开发组织不能很好地管理其软件过程，导致软件开发组织手握优秀的开发方法和技术而无法发挥其预期作用。一些项目的成功也仅仅不能保证以后的开发会进展顺利。而且软件的质量是一个很复杂的属性，需要更专业的知识和能力来度量与认识。实施CMM/CMMI评估，可以帮软件组织来认识和提高软件质量，帮助软件企业对软件开发过程进行管理和改进，增强开发与改进能力，将软件开发从一个比较无规律、不成熟、混乱的过程变成有规律的、成熟的并且可管理的过程，从而使组织能按时地、不超预算地开发出高质量的软件。CMM/CMMI主要应用在两大方面：能力评估和过程改进。

2 CMM/CMMI不适合在当前软件开发当中应用

虽然CMM/CMMI可以帮助组织更好地管理其软件开发过程，但它并不适合在当前软件开发当中应用，主要有以下几点原因：

2.1 对CMM/CMMI的本质认识出现了问题。

它们将CMM/CMMI评估视作软件开发过程或者软件开发方法，认为使用CMM/CMMI就可以解决本身软件质量差的问题，通过评估就可以直接提升软件开发的质量。更有人习惯于将其比作敏捷开发的对立面，认为两者是重型和轻型的软件过程。

但CMM/CMMI并不是一个过程，但它把软件开发视作一个过程；也不是告诉你怎么去做一件事情，但它对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。它是各个进程的一个关键的元素，在很多领域里面一个集成的点。它是这样的一个基本架构，能够用来度量你的有效性和实用性；能够找出这样的一些机会，继续改进的机会，包括在商业目标、策略还有降低项目的风险等方面。CMM的定义中就说明了它是“对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述”，而CMMI则是前者的一个自动的、可扩展的框架，因而能够从总体上改进组织的质量和效率。CMM/CMMI本身是能力成熟度模型和模型集成，它是标准，用来评估软件组织的开发过程是否规范，如果企业刻板遵循标准本身，将标准当成方法，是对CMM/CMMI的本质认识出现了问题，从而适得其反，反而不如不进行CMM/CMMI评估。

2.2 对CMM/CMMI的错误使用导致其不能产生预期效果。

不少软件组织过度依赖和信任CMM/CMMI评估。它们将CMM/CMMI评估视为解决软件质量和提升自身软件开发能力的万能灵药，认为通过评估就可以解决自己组织的软件开发质量和开发效率不高的问题。通过了CMM/CMMI评估并不表示高品质的软件开发，并不表示组织达到最高水平，也并不表示开发效率达到最高，其标准本身与项目的品质没有直接关系。CMM/CMMI只是一种形式测试，就像学生上学一样，假如每个学生都会遵循课表按时上下课，平时也都按时提交作业，但并不能保证他们最后的考试成绩都很高，或者期末的大作业质量都优秀。CMM/CMMI对过程和能力进行评估，是大型项目开发的必要条件，但不是品质高的充分条件，并不能保证组织实际开发的软件高质量，因为CMM/CMMI不检测程序的内容，只是检测程序的形式，是否有各种会议、步骤等，至于会议开了什么内容，没有任何关系。遵循CMM/CMMI可以保证组织按照一定的流程进行开发生产，有较高的效率，但是是否能够高效产出高质量软件还是要根据实际判断。如果组织过度拘泥于CMM/CMMI形式，反而会失去了灵活性，也可能失去市场。例如CMM水平5 是最高水平，取得CMM5的最多的国家是印度，但是印度的软件质量很差，这折射了这种形式测试的局限性。

机械照搬CMM/CMMI条文也是导致CMM/CMMI未发挥其威力的原因之一。软件组织缺乏对CMM/CMMI的认知，缺乏对软件开发经验的总结，认为CMM/CMMI为不可改变的准则，所以组织容易机械照搬CMM/CMMI条文，违背了CMM/CMMI的精神，因为CMM/CMMI本身就是优秀软件工程经验的集成，用来指导软件开发实践。组织应该结合自身项目经验进行聚合，具体情况具体分析，逐步完善适合自身的软件开发过程，一味照搬只能做做表面文章而没有实际帮助。

而对于一些企业而言，CMM/CMMI的认证只走走形式，在评估完成之后只留下一大堆文档，而在真正的开发过程中依旧不遵守标准，导致效果并不是很好。这种情况原因在于人员对CMM/CMMI的抵触情绪和领导层的执行力度小，使企业白白浪费资源而无法获益；CMM/CMMI的出发点是好的，如果从内而外遵守标准，其所带来的开发能力和开发质量的提升会使组织长期受益。所以组织对CMM/CMMI是否重视也是影响其效果的因素。

有些软件组织进行CMM/CMMI评估本身带有非原始目标。有人曾统计过CMM/CMMI在中国的实施状况，发现一些进行CMM/CMMI评估的机构的目标分为三个：一是拿政府的钱，为自己贴金。一些地方政府在CMM/CMMI热潮开始的时候纷纷出台政策，鼓励企业进行CMM/CMMI认证，但是一些企业领导者对CMM/CMMI是什么都不知道，就纷纷去进行评估。二是为自己的业务拿牌照。CMM/CMMI的“从业执照”成为了大批从事软件外包的软件企业掌中宝。三是少数企业真正为了软件过程的提升。软件过程的提升才是CMM/CMMI的原始目标，然而大多数企业并不以此目标为主，所以有很大可能偏离CMM/CMMI的初衷，从而并不会给企业本身的软件开发带来多大益处。

2.3 软件过程从一开始就不合理，使用CMM/CMMI框架进行软件质量控制并不有效。

著名的Ivar Jacobson博士举了一个非常形象的例子：这是一个农夫和他的奶牛的故事。在奶牛喝水的途中（称为“牛路”）有一片庄稼地，牛会吃掉很多庄稼。农夫看到这种情况后，意识到必须对奶牛喝水的过程进行改进，所以他就在这条道路上铺上了沥青。结果，农夫得到了一个好的“牛路”，牛走得更快了，但是并没有真正解决牛吃庄稼的问题。这个问题应该有更好的问题解决方式，就是为牛喝水寻找一条全新的道路。类似的，软件组织利用CMM/CMMI框架进行软件质量控制的过程，就像是这个农夫为牛路铺沥青的过程。对于软件组织来说，如果从一个错误的软件过程开始，即使你在这个上面再改进，得到的永远只是“牛路”，因为你把软件开发过程固化了，使日后再想对它进行改造，变得更加困难。软件组织更应该考虑的是要选择一条更好的路，也就是在一开始时，就采用能够开发出好的软件的过程。然后在这个好的软件过程的基础上，对这个软件进行度量，改进这个软件的过程,也就是进行CMM/CMMI要求的改进。

再引用Ivar Jacobson博士的话：“把一个好的软件过程变得可度量非常容易，但是把一个可度量的软件过程变成一个好的软件过程却很难”。可见在进行CMM/CMMI要求的改进前，软件组织必须保证软件过程的质量，如果质量不过关，那么把已经经过CMMI改进的、可度量的过程变成一个真正的能够开发出好软件的过程是几乎不可能的事情，几乎得从头再来，造成的各种损失无法挽回。

当前的开发环境对于软件开发的容错率比较低，一旦没有认识到软件过程的不良，在以后的开发过程中就会产生很多问题，甚至造成开发效率下降、软件质量不高等问题，那时想改进已是难上加难，一旦从头再来，则会被市场和机会所抛弃。所以软件组织应当在一开始便评估软件过程优劣，如果这一点做不到，就更别谈CMM/CMMI了。

2.4 CMM/CMMI本身存在一些缺点，导致其并不适合当前的软件开发。

CMM/CMMI从总体上改进组织的质量和效率，其目的也是为了降低成本，集中生产，但CMM/CMMI本身存在评估耗资不菲、耗时长、过程复杂从而导致结果不理想的缺点，这与CMM/CMMI的目的存在冲突。如果对于大型企业而言，改进组织的开发方法能够提升的生产力大于CMM/CMMI所评估的成本的话，那么CMM/CMMI评估还是有一定必要的；但是对于新创或者小型组织来说，评估的成本可能会使组织损失巨大，不仅仅是资金上的损失，为准备评估所消耗的时间以及人力资源，就可能使组织错失某些商业机会，失去市场导致更大的损失。当前软件更新换代频繁，而且新产品如果不能尽快投入市场，则会错失良机。对于新创或者小型组织而言，软件开发快，开发成本低，软件投入及时才是关键，例如在《精益创业》中提到的“最小化可行产品”，就是用最快的方式实现的最早期的产品，它并不拥有完全符合CMM/CMMI的开发过程，但是节省了时间资源，并且符合当下软件开发潮流。所以CMM/CMMI是否适合当前开发，还是要根据实际情况，根据组织规模大小、资金、时间、人力资源等综合考虑，要考虑CMM/CMMI所带来的益处是否多于弊端。

3 总结

参考资料：

[1] 荣国平，张贺，邵栋，王青.软件组织与管理方法综述
[2] 张友生, 徐锋. CMM/CMMI在中国的实施状况调查 告[J]. 计算机工程与应用, 2006, 42(7):31-32.
[3] CMM_百度百科https://baike.baidu.com/item/CMM
[4] CMMI_百度百科https://baike.baidu.com/item/CMMI
[5] 合理的软件过程是软件质量的基础－论CMM/CMMI的缺点 https://blog.csdn.net/lujar/article/details/83087256