CMM/CMMI目前在国内似乎很热，大大小小的公司都争先恐后申请CMM评估并争取政府在财力、人力和物力上的支持，有个别公司只用了2年的时间就通过了CMMI 5级！
这是喜讯，还是噩耗？
这不是喜讯！
CMM/CMMI来到中国已经变质。只要花钱，只要招待，你就可能拿到一张证书。虽然拿到了这个证书，但是软件企业并没有得到什么实惠。举例说来，软件企业的效率、过程的能力仍然是跟以前一样，因为CMM/CMMI在做的同时，他们仍然在按照原来的方法在做，原来的体制在运行。这就造成了几张皮的现象，一边按照CMM/CMMI做各种需要的文档，一边还在按照老传统做什么调研、方案设计、调试，跟CMM/CMMI并不合拍。这是问题之一。
CMM/CMMI是一个评估的依据，也是一个过程改进的框架，并不是一个标准。但是国内却把它用来做标准。例如，信息产业部标准SJ/T 11235和一些军用标准。把CMMI作为一个标准本身就有问题，更不用说用这个标准来评估企业能力成熟度，给他们发证书。况且，这种证书并不一定为国际上承认。关于这方面的问题，可以参见《中国软件企业遭遇CMM认证陷阱 CMMI、行标搅局 》一文。ewkArticles/Category114/Article14098.htm ——这是问题之二。
CMM/CMMI来到中国水土不服。CMM/CMMI体现了西方的“三权分力”的思想。SEPG相当于立法机构，而软件项目组相当于行政机构，SQA人员相当于司法机构。三者相互制约。SEPG所出的规范需要得到软件项目组的认可，规对谥葱泄?讨行枰 徊接胂钅孔榈氖导式岷洗佣 懈慕?欢鳶QA人员则是需要监督软件过程是否按照规范来执行，从而决定是否开出不符合项NCI。另外，系统测试人员也需要具有相当的独立性，不能处于项目开发人员的控制之下。所有这些，在一个以技术能力决定一切的公司里头根本就不可能做到。例如，软件项目经理兼有需求分析、设计、编码和测试的职责，对于项目计划、进度、跟踪的工作则是能做到什么程度就做到什么程度。这种软件项目经理和技术主管职位不分、职责不明的做法怎么能够做好CMMI? 这是问题之三。
CMM/CMMI不是为软件研究性项目设计的，而是为产品项目设计的。对于那些研究性的项目，搞上CMM，等于把自己打进了死牢。研究性的项目需要创新的思想，需要更多的实验与思维，给与研究人员更多的创新空间，而不是能够在短时间内出产品的，不是需要更多的文档和过程。所以，需要搞清楚你的项目是研究性的，还是产品性的，不要盲从CMM/CMMI。这是问题之四。
CMM/CMMI不可以以强权方式实施。按照正常的步骤，软件企业做CMM/CMMI先从二级做起，先是各个项目按照自己的实际形成项目的过程，因此，在二级不同的项目的过程可能“五花八门”。到了三级，才开始将不同项目的过程分析总结，并形成一个组织的过程标准。所以，笔者认为二级不能少，不能越级做CMM/CMMI，也不能以做三级的方法来做二级的过程，即先做一个企业的CMM2级规范，然后强行向项目组推动，这显然违反CMM/CMMI过程改进的原则。因此，需要收集不同项目的过程实践经验，体现一种“民主”的思想，经总结分析才能形成组织的过程。用相反的方法来推动CMM/CMMI的实施，只能得到失败的结果。现在很多企业在做CMM/CMMI总是先成立一个SEPG组，首先制定一套企业的过程规范，强行向软件项目团队推动；有时候，还直接越级评估，直接上三级、四级，操之过急，令人怀疑其实施CMM/CMMI的动机：到底是为了改进，还是为了拿证。这是问题之五。
综合以上的问题，笔者认为，不要对CMM/CMMI热过了头。软件企业可以选择CMM/CMMI，也可以选择6Sigma，也可以选择ISO9001。小公司也不要急着上CMM/CMMI或者更多的过程改进框架，免得给自己上套，花了钱不算，束缚自己的手脚。

但是CMMI用好了还是比较好的，小企业可以先上CMMI2的过程域，或者直接就不做评估，只是用CMMI的理论来规范化软件开发过程，选择适合自己的过程域；如果勉强上的话，呵呵，可能反而会成为企业的包袱

但是一般的软件外包公司都会过的呀！

要顶要顶

同意，不错