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

一、前言

  CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成，其目的是帮助软件企业对软件过程进行管理和改进，提高软件开发与过程改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。
  然而自CMMI的前身CMM诞生至今，它也没有真正地在软件组织开发组织中得到普及。这其中既有一部分原因是人们对CMMI的较多误解，但也不可否认，CMMI自身也有一些不适合在软件开发过程中应用的原因。
  下面试从三个方面探讨为什么CMMI不适合在当前软件开发中应用。

二、实践中的难点和误解

  很多人对CMMI有极大误解并根据他们自己的想象构造出所谓的CMMI的特点，比如认为CMMI重文档、流程繁琐、把人看成机器等等。如果根据这些捏造出的子虚乌有的特点就认为CMMI不适合在软件开发过程当中应用，未免对CMMI太不公平。
  我们应该注意到，这些误解有一部分只是基本概念方面的误解，可以毫不费力地将其澄清并纠正。另一部分误解的产生，则是由于CMMI的实践过程的种种原因，自然而然地产生，并始终难以避免。这一部分误解，其产生的根源在于CMMI在实践过程中的一些难点和问题，这些误解一定程度上反映了现实。如果不解决这些问题，误解就很难消除，那么人们根据这些误解就认定CMMI不适合应用在软件开发中也是情理之中的事。
  从本质上讲，本部分提出的问题都不是CMMI本身的问题，但它们在当下的实践中难以解决，还是阻碍了CMMI在软件开发过程中的应用。

1.“CMMI重文档”——证据验证的缺点

  CMMI有两种评估方法，证据验证（verification）和证据发现（discovery）。证据验证要求组织提供大量文档化证据，证明他们进行了某项工作，随后由专人检查文档验证。证据发现则不要求文档化证据，由专人实地考察发现该组织完成了哪些工作。证据验证相较于证据发现而言，时间和金钱成本都更低，而做一次CMMI认证则是固定的收费，那毫无疑问CMMI认证组织会选择证据验证。软件开发组织为了迎合CMMI认证组织，也只能准备大量文档。
  虽然理论上说，CMMI并不一定要求文档，但在实践中毫无疑问是要求大量的文档。所以认为CMMI重文档，虽是误解，也是现实。
  这就导致软件开发组织在开发软件的同时，不得不花费大量精力维护被视为目标的文档，甚至为了写文档而写文档，而这些文档的作用或许并没有我们想象的那么大。
  除非CMMI认证组织能提出一种新的花费小又不需要文档的评估方法，否则CMMI重文档的误解（现实）仍会继续下去。

2.“CMMI流程繁琐”——客户要求

  CMMI并不意味着繁琐的流程，组织其实可以根据自己的特点和需要制定合适的软件过程。但是由于客户的强烈要求，软件开发组织必须要通过CMMI的认证，为了迎合或满足CMMI评估的需要，组织也只能违背初衷，定义出一个满足某种标准的重型的、教条的软件过程。
  顾客总是会选择CMMI等级高的组织，他们认为，满足CMMI越高等级的组织，其研发能力就越强。
  实际上，每个组织面对的问题、应用领域都不同，CMMI等级不能作为评判软件开发组织研发能力的标准。很可能一家CMMI2级的组织开发出的软件，会比CMMI5级的组织开发出的更好。所以组织没有必要一味地追求超过真实需要的最高的CMMI等级。
  可以预见，只要客户仍然提出对CMMI等级的要求，就很难根据组织特点和需要制订出真正合适的软件过程。

3.“忽略员工的因素”——不良的组织文化、高层管理者的急功近利

  组织在咨询顾问的建议和有远见的管理者的倡议下决定用CMMI指导软件过程改进，在高层管理者看来这些目标的实现似乎不用花费太大代价就能实现。但实际花费的代价可能要大得多，因为很可能会出现很多意料之外的问题。以往在遇到问题时，中层管理者担心触怒高层管理者，有意识地隐瞒了一些问题。高层管理者不知道修复这些问题所需的额外代价，仍要求员工在一个不合理的期限内完成过程改进目标，这种情况下，员工就有了第一层压力。
  引入一个新过程、新实践或新工具的最初几个月中，中层管理者和员工肯定会犯错误。除非高层管理者能意识到错误不可避免并愿意适当降低目标，否则员工一定会隐瞒自己的错误，这是员工的第二层压力。
  面对两层压力，员工不会为过程改进可能带来的效果而欣喜，只会应付眼前的工作以达成标准并希望过程改进的实施尽早结束。这种情况下，组织很难从过程改进中受益。
  这个问题可以归结为不良的组织文化、高层管理者的急功近利，忽略了员工才是软件过程改进的真正实施者。所以要采用CMMI，就必须先改造企业文化，为过程改进的实施做好准备。这恰恰是当下准备采用CMMI实施过程改进的软件组织忽视的地方。

4.“难以长期坚持”

  上面已经对“CMMI重文档”、“CMMI流程繁琐”、“忽略员工的因素”这三点在实践中难以避免的原因进行了阐述，从中不难看出，只要组织通过了CMMI等级认证，过程改进的结果就难以继续坚持下去。

三、CMMI本身的原因

1.只说明应该做什么，没说明具体怎么做

  CMMI只说明了为了更好地支持达成项目目标，应该实施哪些活动。至于活动具体怎么实现,全由组织自己设计决定。这本是CMMI的一个优点，因为所处环境和面对问题等差异，不同组织可以选择合适的具体实践。这样，小公司可以根据自己的体量、成本等因素考虑，将某些活动的实践简化，不必像大公司那样做的全面周到。
  如果一个企业的SEPG（软件工程过程小组）足够强大和专业，将能够定义出符合公司实际的研发流程和模板。但可惜的是，目前各公司对SEPG组织的作用普遍重视不够，很多公司设立SEPG组的目的就是为了应付等级评估评估，而国内真正够专业的SEPG人员也相当稀少，导致很多公司直接使用国外公司及咨询公司提供的研发流程和模板，从而使CMMI根本没有在本企业落地，使得此问题不但得不到解决，反而使不良影响急速扩大。

2.忽略了人的成熟度

  CMMI的目标是将软件企业建设成为高成熟度的组织，而成熟的组织势必要由成熟的人、成熟的团队组成。不成熟的人、不成熟的团队不可能组成成熟的组织。
  组织中绝大多数人的成熟，要求个人不仅具备岗位本身所需的知识和技能，更要具备能完成过程改进活动的能力。个人不仅要能够胜任本职工作，更需要根据过程改进目标，相应持续提升自身能力，提高自身对岗位的契合度。
  组织中绝大多数团队的成熟，要求团队成员能流畅配合以完成分配给本团队的工作，能比较好地达成团队间合作，能贯彻执行过程改进活动。
  许多组织以为采用了CMMI就万事大吉，就一定能提高组织成熟度，而忽略了对人、团队的成熟度的培养。就算为了应对CMMI评估而对人员进行了培训，也只是暂时的，一旦评级通过，这种培训通常也就终止了。何况当下互联网企业人员流动频繁，也很难做到持续对新成员进行培训。

四、软件开发组织的思量

1.耗资不菲

  进行CMMI等级评估耗资不菲，通常需要数十万元、半年时间，大公司可能就更多了。这对小公司无疑是个庞大的负担。

2.风险

  进行过程改进，就要额外耗费大量资源，势必会影响到组织当前项目的正常开发，可能会导致延期等问题，这无疑是一种风险。虽然从长远看，进行过程改进可能带来生产效率的提高，但对于一家孤注一掷把所有资本都压在一个关键项目上的组织来说，可能集中所有资源优先开发这个项目更加重要，相比之下过程改进并非眼下重要的事情。
  大公司会在进行过程改进活动时仍有余力开发项目，但小公司就不得不考量这种做法的风险性了。

3.动力不足

  前面说过，CMMI等级不能作为判断研发能力强弱的标准。大多数组织默认处于2级，少部分做得好的可能已经到了3级，这种情况下组织通常已经能很好地完成项目的开发工作。而获得CMMI高等级认证并不能确保研发能力有质的提高，这就使这些原本就能很好地完成项目开发的组织缺乏采用CMMI进行过程改进的动力，何况那还需要大量的投入。