CMMI证书背后的6大怪相

CMMI认证进入我国软件领域的这十多年来，对我国软件产业的健康发展作出了巨大贡献。但一些软件企业只是以获得证书为根本目的，而忘记CMMI认证的出发点是改进软件生产过程。
这致使我国一些通过CMMI5级的企业的项目平均延期率依然在25％以上，并且数据并不稳定。尤为不幸的是，目前没有任何公开数据表明我国通过CMMI高级别认证的企业，提高了生产效率，降低了成本，提高了产品质量。
CMM/CMMI在中国的过程改进领域到底是一个伟大的经典还是一个因水土不服而失败的理论？CMMI后的软件过程改进又将如何演绎？
CMMI（Capability Maturity Model Integration,即能力成熟度模型集成模型）自20世纪90年代中期传入中国以来，有些软件企业只是一味地追求高级别CMMI认证，以为拿到更高级CMMI证书就获得了进入外包市场的国际通行证，而忽视了对软件生产过程真正持续的改进。从而导致CMMI认证在中国出现一些令人担忧的现象。

怪相一：证书摆桌面体系放一边
2006年笔者曾到某软件园进行调查，对通过CMMI评估的8家企业进行走访，发现有5家企业在通过评估后基本上放弃了。CMMI评估的证书高高挂在墙上，做过程改进的人员已经不见踪影，企业也不再按照原来的体系执行了。其实这5家企业本就没想真正去改进过程。那为什么还要去做CMMI评估呢？因为企业有补助。
2000年有关部门鼓励软件企业做CMMI评估。不少地方鼓励企业实施过程改进，并陆续出台资助政策。当企业通过评估后，可从不同部门获得资助。有些企业为拿到资助，突击通过CMMI的评估，于是便出现了“证书摆桌面，体系放一边”的现象。
其实企业失算了。企业获得的资助大都给了咨询公司。企业要编制体系文件和项目的直接与间接证据，要安排人员接受访谈。这都要耗费巨大的人力和物力，其成本可能超出资助金额，所以企业的实际投入也很大。那些一心想要补助的企业得到了什么呢？对他们有用的估计就剩下一个证书了。
                              ·                ·                      ·                ·                      ·                ·                 
怪相二：证书拿到手体系大调修
笔者曾接触过两家企业，在通过CMM或CMMI评估后，在很短的时间内就对过程体系进行了大幅度的裁剪。其中一家公司的负责人讲：“原来定的体系太烦琐，为了通过评估，我们原来忍了，现在必须裁剪！”难道只有烦琐才能通过CMMI的评估吗？难道简约就不可能通过CMMI的评估吗？
这是对CMMI的误解！
在CMMI的各种构件中，只有目标是必需的，实践是期望的，子实践是解释说明的。所以首先要满足模型中每个目标的要求，目标的达成是根据实践的执行情况来判断的，模型中给出的实践是可以替换的。只要能达成目标，采用什么实践都是可以的。
CMMI评估要求主任评估师必须具有10年以上的软件工程经验，评估组的成员必须平均具有6年以上工程经验，评估组累计不少于25年工程经验，每个生命周期阶段要有两个人具有实践经验，至少要有一个成员有6年以上的管理经验，评估组累计要有10年以上管理经验。这些要求其实是为了更好地进行专业判断，避免机械照搬。
CMMI要求企业建立裁剪指南。在实践中，裁剪指南往往比体系本身更重要。僵化的体系是不可能真正在组织里推行下去的，要保持体系的灵活与敏捷，就必须定义详细的、实际的裁剪指南，并在实践中逐步完善。
简约与烦琐都可能达到模型的要求，关键取决于起草体系的人员对模型的理解。企业在开始导入CMMI时，一般是请咨询顾问介入，而目前国内的CMMI咨询公司、咨询顾问鱼龙混杂，客户难以在短时间内做出正确的评价，往往依赖某些网站或协会之类的独立组织的推荐，根据网民投票所选出的“咨询公司排名榜”按图索骥。如果咨询顾问对模型的理解不深刻，自身的过程改进成员又欠缺经验，或者咨询顾问参与的工作量很少，则难免怪相横生。

怪相三：工期依然拖缺陷照常多
某企业实施CMMI到一定阶段后，EPG抱怨领导意识有问题，领导在言谈举止中对过程改进的支持力度不够。而领导却说该授权的也授权了，该奖励的也奖励了，该惩罚的也惩罚了，但是项目依然拖期，仍然存在质量问题，就认为EPG没有解决核心问题。
问题究竟出在什么地方呢？
过程改进的目的可以概括为“多、快、好、省”：多，即项目组能满足客户的需求越多越好，企业能承接的项目越多越好；快，即能够提高企业的估算能力、应变能力，使项目能够按期完工，减少拖期现象；好，即提高交付的产品质量，减少售后维护的工作量；省，即降低项目的开发成本，提高企业的赢利能力。
对于不同企业而言，在上述4个目的中可能侧重点有所不同。当实施过程改进时，一定要紧紧围绕企业的改进目标做工作，针对企业领导关注的问题、企业最薄弱的环节实施改进，这样才能事半功倍，快速见效，否则见不到实际效果，任何管理方法都不会长久，任何领导也不会持续投资。
很多情况下，企业在过程改进时，找到了病根，却没有找到有效的解决方案。比如单元测试和代码走查是提高软件质量的有效措施，已经在工程界得到了充分认可，但是在软件生产企业中推广时，往往会遇到开发人员的阻挠。开发人员会认为做单元测试与代码走查浪费了大量的时间，不如直接做黑盒的功能测试更简单。业内认可的最佳实践在企业中未必推行得下去。这就需要EPG成员采取各种各样的手段，努力使这些业内的最佳实践变成企业的最佳实践。上面提到的EPG与企业领导之间的互相抱怨问题，很大程度上归因于此。

怪相四：文档一篇篇不见有人看
有一家已经通过CMMI3级评估的软件生产企业，完成一个项目需要项目组填写接近90份文档。当笔者去做CMMI的差距分析时，发现在那些文档中有大量显而易见的错误。而这些文档还要给项目经理、QA人员及高层主管等多个角色去看，却没有人发现这些很明显的错误。其实这些人根本就没有去看这些文档！既然没有人去读，何必要写呢？
CMMI评估需要企业提供3种证据：直接证据、间接证据和人证。每条实践都必须有直接证据。直接证据包括了产出的文档、使用的工具等等。由于直接证据是必须的，于是，为了满足评估的需要，很多企业做了上百个文档来满足模型的要求，其实这是不对的。模型是强调直接证据，但是并非文档越多越好。文档只是用来证明某个实践你做到了，只要达到了这个目的就可以了。而且一个文档可以满足多条实践的要求，可以作为多条实践的证据，这是最经济的做法。只要内容有了，也并非在乎文档的多少与格式。
实施CMMI之前，项目组往往不写文档或者很少写文档；实施CMMI之后，写的文档又可能太多—这是两个极端，需要平衡。

怪相五：流程很优秀效果不见有
有一家专门从事软件外包的公司，通过CMMI3级，流程定义得很简洁、实用，企业的执行力也很强，但是项目的实际效果却不好。为什么呢？经过笔者仔细审查项目组的需求、设计、测试用例、源代码等文档，发现需求的描述有遗漏，有错误；设计文档没有满足基本的设计原则；测试用例不完备，覆盖率比较低；源代码中需要重构的地方比比皆是。在调查中，我们还发现项目组的成员都比较年轻，工程经验大都少于两年。尽管企业也进行了需求工程、设计模式等技术培训，但经验不是靠培训就能解决的。因此，即使有好的流程，仍然有可能开发不出好的软件系统。
另外一家公司，没有通过CMMI的评估，公司内有3个部门，其中一个部门积累了一个基于.NET的可复用的MIS软件框架，该框架已由少数精英开发了4年，积累了4年，发布了多个版本。实现一个新需求时，只要定制界面，编写存储过程就可以了。当一个新员工进入该部门后，基于该框架，大概花费1周的时间就可以编写出能够交付给客户执行的代码，该部门的开发效率很高。其实对于该企业来讲，引入CMMI并非当务之急，打破部门之间的壁垒，将该软件框架推广到其他两个部门可能投入、产出比会更高。
人、过程、技术三者都不可偏废。企业要分析人、技术与过程，哪个因素是企业的瓶颈问题。优先解决瓶颈问题才能事半功倍，最大限度地提高生产效率。
硬件生产企业的生产线是由各种各样的设备组成的，而软件企业的生产线主要是由水平各异的人员构成的。在软件开发中，人是最基本的生产要素，要想提高生产率，必须优先提高人员的能力。在一家大型的软件公司中，老板的文化就是：“让员工一半时间工作，一半时间学习提高。”如果做到这个程度，企业想不进步都难—水涨船高啊。而另外一家大型软件公司经过统计后发现公司员工的平均司龄为两年，因此拒绝导入PSP等针对员工个人的改进模型，理由是：“人培养出来了，呆不长就走了！”如此一来，很可能形成恶性循环。

怪相六：大家要业绩快速过五级
很多企业在通过了CMMI3级的正式评估后，急于通过CMMI的5级评估。为什么呢？一是企业从市场竞争方面想把竞争对手甩在后面，便于争取更多订单；二是政府有巨资资助，企业通过高级别CMMI认证对当地的政府来讲有业绩；三是对于咨询公司来讲，企业通过高级别CMMI认证可以扩大对外宣传，增强客户对自己的信任。几种因素综合在一起，企业不由自主地就开始了向高成熟度组织的迈进之路。
据统计，在中国，2006年一年内通过CMMI5级评估的软件公司就超过了10家。也很不幸，在中国进行CMMI5级评估的主任评估师有的受到SEI（美国卡内基·梅隆大学软件工程研究所）的处分。自2007年始，SEI开始对CMMI高成熟度组织的评估师进行重新考试。并非所有的主任评估师都可以做4～5级的正式评估。在全球，SEI加大了对4～5级评估的审计工作，尤其是对东方的软件大国。
在实施4～5级认证之前，需要慎重考虑：你的企业真的需要通过CMMI4、5级的评估吗？
CMMI的4级强调的是过程稳定性与项目量化管理，5级强调的是根本原因分析与持续改进。很多企业可能在CMMI3级时，就已经做到了在项目组内定义量化的质量目标，并实现了该量化目标，因此在3级时可能就已部分做到4级的要求。有的企业在3级时就做到交付软件的缺陷密度低于0.3个/Kloc，比SEI统计的通过CMMI5级评估的企业的平均质量还要好。客户的水平决定了供应商的水平，对于客户要求高和生产高可靠性软件的公司通过CMMI4～5级的评估是很有必要的。否则，真正达到