作为最著名的软件过程管理参考模型之一，能力成熟度模型CMM以及后续的集成模型CMMI，该模型在实践当中经常被误用。Brooks在《没有银弹》一章中提到的——“软件开发的四个内在特性是: 复杂性 不一致性 不可见性 可变性”，由于软件开发的这些内在特性，使得描述软件开发过程的软件开发与组织方法也天然带着一定的抽象性，由此带来了很多概念上的误导和实践中的争论。
因此在我们探讨CMM/CMMI不适合应用在当前软件开发中之前，需要先探讨什么是软件过程，什么是软件过程管理，然后讨论CMM/CMMI的概念，最后再探讨为什么CMM/CMMI不适用于软件开发。
软件过程的由来
软件自诞生开始，其规模以及在一个完整计算机系统中所占的比重一直呈上升趋势，类似硬件产品的“摩尔定律”，软件产业也有一个类似的“摩尔定律”，即: 类似功能的软件产品的规模每隔18个月，其规模(比如代码行)会翻倍，而用户获取该软件或者服务的代价将下降。“摩尔定律”对于软件系统的开发和维护带来很多负面影响，为了解决这些问题，对软件开发进行有效地组织和管理非常重要，由此诞生并且演化了一系列的所谓软件过程与方法。
伴随着不断演化的软件过程与方法，软件开发的组织与管理当中出现了大量方法上的争议和由此带来的各种误解以及混乱，其根源在于对软件项目管理和软件过程管理概念区分不清晰。所以接下来我们需要先对这两个概念进行解析。
软件项目管理
软件项目管理被称为规划和带领项目团队的艺术和科学。其管理的对象是各类软件项目，具体而言是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。可以再细分为两种管理视角——软件过程与生命周期模型
- 软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这组实践之间往往有一定的先后顺序，作为一个整体来实现事先目标。
- 生命周期模型是对一个软件开发过程的人为划分，是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分，往往不包括技术实践。
软件过程管理
软件过程管理的管理对象是软件过程，这种管理的直接目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效。如果将软件项目管理视为传统行业的产品生产管理的话，软件过程管理则应该是对生产该产品的流水线的设计、建设、维护、优化以及升级改造。软件过程管理一般包括了软件过程的建立、执行、监控、评估以及改进等活动。
CMM/CMMI是什么
CMMI概念
CMMI(Capability Maturity Model Integration)即能力成熟度模型集成，是一套包括多个学科、可扩充的模型系列，其前身包括4个成熟度模型(即CMMI的源模型)，他们分别为面向开发的SW-CMM、面向系统工程的SE-CMM、面向产品集成的IPPD-CMM、以及设计外购协作的SS-CMM。所谓CMMI模型，是指CMMI刻画了软件团队/组织从不成熟到成熟的每个阶段的特征——即所谓的路线图roadmap。与实际的开发模型没关系。这个路线图其实也是CMMI模型最为精华的部分，甚至都可以在很多其他的领域借鉴。CMMI好处
- 改进进度和预算的可预测性
- 改进开发周期
- 提高生产率
- 改进质量(质量缺陷)
- 增加客户的满意度
- 提高员工的士气
- 增加投资回报和低质量成本
有两种通用的评估方法用以评估组织软件过程的成熟度: 软件过程评估和软件能力评价。
- 软件过程评估: 用于确定一个组织当前的软件工程过程状态及组织所面临的软件过程的优先改善问题，为组织领导层提供报告以获得组织对软件过程改善的支持。软件过程评估集中关注组织自身的软件过程，在一种合作的、开放的环境中进行。评估的成功取决于管理者和专业人员对组织软件过程改善的支持。
- 软件能力评价: 用于识别合格的软件承包商或者监控软件承包商开发软件的过程状态。软件能力评价集中关注识别在预算和进度要求范围内完成制造出高质量的软件产品的软件合同及相关风险。评价在一种审核的环境中进行，重点在于揭示组织实际执行软件过程的文档化的审核记录。
CMM/CMMI不适用于软件开发的原因
CMM/CMMI并不是一种具体的软件过程或者软件开发方法
软件过程改进是一个持续的、全员参与的过程。CMM/CMMI建立了一组有效地描述成熟软件组织特征的准则，该准则清晰地描述了软件过程的关键元素，并包括软件工程和管理方面的优秀实践。企业可以有选择地引用这些关键实践指导软件过程的开发和维护，以不断地改善组织软件过程，实现成本、进度、功能和产品质量等目标。CMMI应该是过程改进模型而非软件过程或者软件过程模型。
然而在不少文献中，CMM/CMMI都被视作一种官僚化和教条主义的重型软件过程，并且与当前软件开发大环境格格不入。事实上，按照CMM/CMMI模型的要求，一个软件组织应当定义使用本软件组织特点的软件过程，并且不断优化该过程，来更好地实现软件组织的商业目标。再实践中，软件组织为了迎合基于CMM/CMMI模型的“Verification”评估方法，刻意准备大量文档化证据，导致CMM/CMMI被视作在软件项目管理中必须满足的某种标准，这显然是对CMM/CMMI模型意图和使用方法的曲解。CMM/CMMI并不能作为检验软件过程优劣的标准
实践中，很多人会将达到一定成熟度水平视作某个软件组织的研发能力，并且试图进行横向比较，认为成熟度较高的企业，其研发能力应该强于成熟度较低的企业。而事实上，由于企业所处的环境以及要实现的目标等方面的差异，过程改进对于不同企业的含义是不一样的。因此，成熟度等级不适宜脱离企业环境直接横向比较；同处于相同的成熟度等级，也并不能说明这些企业的研发能力也是相同的。CMMI不是过程优劣的标准，也不适用作公司之间的能力比较。CMM/CMMI与其他软件过程或者软件开发方法的比较是没有任何意义的
很多人习惯于将CMM/CMMI作为敏捷方法的对立面，试图来解释和说明敏捷方法的优势。事实上，这种语境之下所谓的CMM/CMMI方法其实已经不是一个过程管理的参考模型了，而是某个特定软件组织为了迎合或者满足CMM/CMMI评估的需要所定义出来的某个具体软件过程。显然，将这个为了特定目的而定义出来的软件过程的缺点视作CMM/CMMI模型的缺点是不合适的。所以诸如“CMMI vs Agile”的比较都是不恰当的，前者本质不是一种软件过程模型，而是一种过程改进。
根据Humphrey再《Managing the Software Process》一书中对软件过程管理这一术语的解释来看，所谓软件过程管理应该同时包含按照既定过程的执行和不断提升过程能力两个方面的内容，所以，软件过程改进应被视为软件过程管理的一部分。其常用的参考模型就是PDCA和IDEAL，这两个过程改进的元模型。软件过程管理和软件过程改进两者不能割裂，既不能脱离改进谈管理，也不能脱离管理谈改进。因此CMM/CMMI模型可以被称为软件过程管理参考模型，也可以被称为软件过程改进参考模型，但并不是软件过程模型或软件过程管理模型。
对CMM/CMMI模型的误解
-
CMMI模型需要适当裁剪以适应公司的实际情况
CMMI模型不需要裁剪，模型本身仅仅刻画成熟度路线图上不同阶段的特征。大部分公司都不具备能力来裁剪这个模型，真要裁剪，也是应该由CMMI的模型的提出方和维护方SEI干。真正需要裁剪的是公司内部定义的组织级开发流程和开发规范，这个需要裁剪以适应具体的项目场景，与CMMI模型的裁剪是完全不同的概念。 -
CMMI模型太重了，不适合互联网时代的轻量级开发
这个说法的错误之处在于，不一定是CMMI重或者轻，而是，CMMI根本就不是开发模型。 -
CMMI模型只适合大公司、大项目，不适合小项目
首先没人检验过；其次，项目的大小衡量本身也缺乏值得信赖的参考依据；最后，接受这种说法的人还是把CMMI当成是一种特殊的开发模型。 -
CMMI模型只适合需求不变或者很少变化的场合，不适合需求不确定，变化很多的场合
CMMI不是开发模型，与需求变化与否无关，谈不上适应或者不适应。 -
CMMI与敏捷开发的对比
这种说法是错的。最根本的原因是CMMI不是开发过程，而大部分敏捷则是具体的开发过程。两者根本就是风马牛不相及的事物，不具备冲突的基础。所以不存在两者之间的权衡和借鉴。此外，也不存在CMMI的抽象是其不足。所有的模型都是抽象的，抽象恰恰是模型的本质特征之一。模型通过抽象来强化特征与目标之间的关系，这才能帮助我们理解其内在机理，指导具体实践。
引用
- 本文大部分观点是基于《软件过程与管理方法综述》 荣国平，张贺，邵栋，王青
- 只言片语说软件的新浪博客系列
- 南京大学软件学院《软件工程与管理》课程ppt
最后，再次感谢荣国平老师以简明扼要的文字，阐明了软件开发领域容易混淆的部分，发人深思，值得我继续潜心钻研。
