无聊之胡思乱想 —— 关于CMM和CMMI

        春节长假结束之后回到公司，我参加了有关CMMI的training。整个课程总有7个部分，涉及的内容十分广泛：从基于风险的项目管理到软件生命周期，再到项目计划和跟踪等等。而到上个星期为止，课程已经过半，而我对于CMMI有了一点点的认识，也引发了一些思考。
        还是先从认识开始吧。当你第一次看到CMMI这个名词的时候，或许你会不由得想起CMM。是的，CMMI就是CMM Intergration(CMM 集成)，而CMM则是Compability Maturity Model的缩写，就是众所周知的软件能力成熟度模型了。要深入了解CMMI，还是得从CMM的历史说起。1991年，卡内基梅隆大学软件工程研究院(CMU-SEI)为了评估软件企业的成熟度创造了CMM，版本为1.0。而在1992年4月，SEI举行了一个CMM的研讨会，在广泛听取了众多软件工程专家的意见之后，又于1993年推出CMM 1.1版，这也是目前世界上比较流行和通用的CMM版本。就在CMM1.1发布到SEI于2003年不再更新CMM和支持CMM这10年间，全球成千上万的软件公司纷纷以CMM马首是瞻，依照CMM制订软件开发流程，并且对CMM认证趋之若骛。那么，为什么CMM会有如此大的魅力呢？我们都知道在一个软件项目中，有三个要素：人、技术和过程。很明显，前两个要素是不稳定的，人自然是首当其冲：对于项目组来说，在一段时间内，人员可能会发生变动。再关注到某一个组员，其工作状态也会出现起伏。技术的不稳定性也是明显的，相同技术的版本变迁，不同技术的推陈出新都突显了这种不稳定性，尤其是在当今技术发展迅速的年代，技术的不稳定性则更为突出了。三个因素当中就剩下了过程，它呈现出来的稳定性使它成为项目管理者的救命稻草。于是乎，软件领域的目光都集中到了过程，相应的，CMM中所谓的软件能力成熟度实质上就是软件过程的成熟度了。说到这里，您是否跟我一样，心中又多了几个大大的问号呢：过程跟能力真的可以划上等号吗？将软件过程进行了良好的定义是否就意味着拥有了无坚不摧的能力呢？
        在SEI的网站上，我们可以找到两个有关CMM的权威文档，其中之一就是Capability Maturity Model for Software (Version 1.1)。文档对CMM做了全面概括的介绍，自然也包含了我们所熟知的CMM五个等级的相关信息。文档中2.2节Understanding the Maturity Levels是相当有意思的，它讲述了应该如何理解Maturity Level，同时细化到了如何分别理解五个等级的定义。这一节开篇的时候提到了CMM对成熟度不同的过程做了足够抽象的定义，同时并没有限制每个组织应该采取怎样的方式去实现与某个成熟度相对应的过程。既然是如此之抽象的定义，软件公司又根据什么进行自己的过程定义呢？CMM评估组织又根据什么标准对软件公司进行能力评定呢？该文档的第三和第四章给出这两个问题的粗略答案，有兴趣的朋友可以参阅该文档。
        在浏览SEI网站上有关CMM的内容时，随处可见Sunset of the Software CMM的链接。确实如前面提到的一样，CMM在SEI的眼里已经是昨日黄花了，CMMI才是SEI时下主推的标准。确实，CMM的成功经验都来源于上世纪八十年代，而在近二十年间，软件的发展又如此之神速，新标准的提出自然是大势所趋了。从字面上看，CMMI比CMM多了一个I(Integration)，这是我们最容易发现的差异所在。而事实上，CMMI标准的提出也是在集成了多个CMM标准的基础上的。对于CMMI的介绍，也就不多说了，有兴趣的朋友，可以参阅What is CMMI一文。
        对于CMM和CMMI这两个Key words的介绍就到这里了，大家是不是觉得很闷了呢？ 是的，我写得也快疯掉了，因为我找不到源自思考的文字，数十页的文档包含着数以百计的概念、目标以及标准，即使是所谓的实践性介绍，我都找不到丝毫的感觉。也许是自己的层次没有那么high level吧，看着CMM和CMMI的介绍，我一如两年前那样迷惘。因为从这些长篇累牍的文字中，我找不到自己的角色，也找不到自己的方向，对于它们的理解，我仍然停留在 CMM = 一大堆文档的认知层面上。不过，这样的痛苦历程还是让我了解不少有关软件过程定义的知识。我知道自己从内心排斥这种把人的因素摆在一边的标准，但是我也不禁要给自己的排斥多问几个为什么，同时我也清楚只有充分理解了CMM及CMMI才能够让自己的排斥来得更加理性而有说服力，而不是停留在厌恶繁多的文档的层面上。
        然而，我知道自己的排斥是有充分的理由的。根据CMM和CMMI所涵盖的范围来看，它们关注的仅仅是过程，也就是说人的因素并没有包含其中，这就意味着这两个标准的本意并非是轻视人的因素，只是没有论述而已。事实上，一个良好而规范的过程确实是必须的，一旦工作陷入无序，拥有再厉害的人物，使用再强大的技术，也是无济于事的。但是，对于过程的强调是不是有些过分了呢？而在过程的定义当中，我看到了更多的是performance和commitment，却鲜见individual。我想，一个良好的过程不应该只讨好客户和项目管理者，还要顾及奋战在第一线的开发人员的感受。在过程中增加提高开发人员能力的步骤，让开发人员在项目开发过程中逐渐成长，这不是一个很不错的想法吗？然而，在我上training的过程中，我还是无法发现这个步骤的踪影，这不免让我有些失望。
        在接下来的日子里，公司会依据CMMI的规范采取更多的措施，会把开发过程制定得越来越规范，至于效果，现在还不得而知，唯有拭目以待了。总之，过程的定义与规范是重要的，但是无视个人因素的教条化定义则令人反感。