要过程改善，不要CMMI模型(2)

过程改善不只是ＣＭＭＩ

形式上通过CMMI对于复杂而且须持续进行的过程改善没有什么实质性意义。

笔者觉得最须澄清的是：软件过程改善只是软件方法学的一个领域。除过程改善之外，软件方法学还有很多其他重要领域，比如系统工程、质量工程等。在过程改善领域，CMMI模型只是众多模型中的一个，除了CMMI模型之外，软件过程改善还有很多其他模型，比如Basili教授的GQM模型、SPICE模型、EFQM和TickIT等。

软件方法学包含很多领域，在每个领域中都包含大量的经验、Knowhow以及为之奋斗的专家：比如在估算领域中最先提出COCOMO模型的Barry，在同行评审领域最先提出实证数据的Fagan，在度量领域的实践者Capers Jones，活跃在思想界的Weinberg，最先提出螺旋式开发过程模式的Boehm，永远热情洋溢的真正的咨询师Tom Glib。

这些依然活跃在世界各地的明星在不同领域奠定了软件方法学的基础，为软件方法学的完善而分享和贡献自己的思想和实践。

但很不幸的是，很多企业现在都倾向于将软件方法学等价于过程改善，将过程改善等价于CMMI，将CMMI等价于Humphrey。

实际上Humphrey与CMMI毫无关系。CMMI只是众多模型中的一个而已。CMMI是Humphrey的知识汇集，主要是IBM的知识汇集。全世界通过CMMI5的公司很多，并不是每个企业都能提供优秀产品，都是市场领先者。相反，全世界优秀的公司很多，几乎没有几家是通过CMMI5的。

CMMI模型被批判的最大不足之处是忽视了市场交付压力和竞争对手的压力。CMMI模型原本是美国国防部在外包军事软件时，对承接单位能力的评判体系，然后逐步推广到民间企业中来。很显然，国防部的软件交付日期是不会经常变动的，而且需求是稳定的，因而这些企业自然不需要考虑市场交付压力，不需要考虑市场需求的变化，不需要考虑竞争对手突然提前推出产品等因素。

而在实际的竞争环境中，这些都是不得不考虑的问题。很多时候，用户需要的不是最高品质的产品，而是最快交付的、有吸引力的、质量尚可的产品。

CMMI只说明了What to do，没有说明How to do，更没有说明Why should we do？也就是说，CMMI本身并不包含具体的软件方法学，不能帮助企业理解各个具体的方法学。如果不是为了CMMI的虚名，企业不如根据自身的实际情况进行方法论的学习，扎实地改善过程，不一定非要按照CMMI模型设定的内容进行改善。比如，难道我们非要建立了管理过程之后，才需要考虑组织统一的培训吗？难道我们非要建立标准的组织过程之后，才能导入定量管理吗？难道我们非要定量管理之后，才能进行根本原因分析和组织创新吗？

软件企业与其刻板地按照CMMI的要求来改善，不如秉承拿来主义，挑选自己认为有价值的内容进行改善。这就涉及到人员能力的培养，要培养优秀的过程改进人员，要培养过程改进人员的软件方法学的理论和知识，要培养软件过程改进人员的分析和判断能力。

形式上通过CMMI不难，因为CMMI提供了很多案例，照猫画虎，再加上咨询公司提供的模板集合，就可以在纸面上通过各级评估。但是企业要想理解CMMI中的Knowhow和根植这些Knowhow是需要时间的。