原本准备把自己的想法总结一下，由于时间关系，先转载几篇CMM的文稿，希望给大家提供参考。


────────
我是老罗
我现在就付诸行动
E-mail：max656798@21cn.com

CMM/CMMI不是软件企业唯一的选项

CMM/CMMI目前在国内似乎很热，大大小小的公司都争先恐后申请CMM评估并争取政府在财力、人力和物力上的支持，有个别公司只用了2年的时间就通过了CMMI 5级！
这是喜讯，还是噩耗？
这不是喜讯！
CMM/CMMI来到中国已经变质。只要花钱，只要招待，你就可能拿到一张证书。虽然拿到了这个证书，但是软件企业并没有得到什么实惠。举例说来，软件企业的效率、过程的能力仍然是跟以前一样，因为CMM/CMMI在做的同时，他们仍然在按照原来的方法在做，原来的体制在运行。这就造成了几张皮的现象，一边按照CMM/CMMI做各种需要的文档，一边还在按照老传统做什么调研、方案设计、调试，跟CMM/CMMI并不合拍。这是问题之一。
CMM/CMMI是一个评估的依据，也是一个过程改进的框架，并不是一个标准。但是国内却把它用来做标准。例如，信息产业部标准SJ/T 11235和一些军用标准。把CMMI作为一个标准本身就有问题，更不用说用这个标准来评估企业能力成熟度，给他们发证书。况且，这种证书并不一定为国际上承认。关于这方面的问题，可以参见《中国软件企业遭遇CMM认证陷阱 CMMI、行标搅局 》一文。http://www.e-works.net.cn/ewkArt ... 14/Article14098.htm ——这是问题之二。
CMM/CMMI来到中国水土不服。CMM/CMMI体现了西方的“三权分力”的思想。SEPG相当于立法机构，而软件项目组相当于行政机构，SQA人员相当于司法机构。三者相互制约。SEPG所出的规范需要得到软件项目组的认可，规范在执行过程中需要进一步与项目组的实际结合从而进行改进；而SQA人员则是需要监督软件过程是否按照规范来执行，从而决定是否开出不符合项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或者更多的过程改进框架，免得给自己上套，花了钱不算，束缚自己的手脚。

CMM的“六要六不要”

为了提高企业竞争力，不少软件企业为通过ISO或CMM（I）资质认证付出了巨大的代价，但有为数不少的企业却很少或没有看到这些资质认证给公司软件质量改进带来的明显效果，原因何在？
有些人说是ISO或CMM（I）等质量体系不适合中国国情，有些人说是中国的软件企业太急功近利。原因究竟是什么？
　　以下总结作者数年来从事软件质量改进工作的经验和教训，归纳成软件质量改进的“六要六不要”，一方面作为对上述问题的解答，另一方面也期望能给广大正在和将要从事软件质量改进的同仁提供参考。
（一） 要重视效果，不要徒有虚名
　　国内有一些软件企业，认证动机不纯，有些企业为竞标资质而认证，有些企业为获得政府资助而认证，不一而足。这样的企业，为认证而认证，徒有虚名，工作没有实际做到位，一旦拿到证书，则万事大吉，因此注定享受不到认证带来的真正价值。
　　其实这种做法也许能“灵念”一时，但最终无疑是害了自己，因为徒有虚名而没有实际功底的企业是一定不会得到客户长期“青睐”的，而失去客户则意味着失去一切。
　　软件质量改进，一定要关注效果，过分追求认证无异于缘木求鱼。因此，我们说，进行软件质量改进的企业务必“头脑清醒”，一定“要重视效果，不要徒有虚名”。
（二） 要循序渐进，不要急于求成
　　有些企业，一年（甚至更短时间）通过一个级别的认证，咋一看软件质量改进成绩斐然，其实实际情况并非如此。
　　因为软件质量改进是一个长期的过程，不可能一朝一夕，那些每年（甚至更短时间）拿到一个CMM（I）级别认证的企业，我敢说绝大部分是名不副实的（因为通过认证是一回事，实际能力是另一回事）。我亲眼见过一些通过CMM（I）4级甚至是5级的企业，项目管理的实际能力甚至还达不到3级的要求。
　　其实软件质量改进是有其客观规律的，违背了客观规律而一味追求高级别的认证往往欲速则不达。
　　另外，有些企业虽然没有在证书上一味追求高级别，但往往过分要求软件质量改进的实际效果在短时间内上新台阶而不是按实际可行的计划循序渐进地练“内功”，这种做法也是极具危害性的。因为这种做不但会导致大家疲于奔命，而且往往达不到所要求的结果而使大家心灰意冷，进而形成恶性循环。
　　因此，理性地对待资质认证和质量改进工作是非常重要的，特别是对于一些内部管理基础差或以工程项目为主营业务（因为这样的企业软件质量的改进不但受公司内部因素的影响，而且还在较大程度上受客户因素的影响）的企业更应如此。
（三） 要注重现实，不要“拿来主义”
　　有些企业，不考虑自己公司的实际情况，为节约成本或追求“速度”，在没有认真“诊断”的情况下就照搬在别的企业已经取得成果的管理制度和流程，还美名其曰是“经验借鉴”，最后落于失败。
　　其实，由于企业的实际情况和文化背景不同，别的企业的成功做法在自己企业往往不会“奏效”，因此需要我们花必要的时间和精力认真分析自己企业的实际情况并建立适合自己企业的管理制度和流程方能产生效果。照搬别人的做法，是错误的开始，只会导致错误的结束。
（四） 要把握重点，不要遍地开花
　　对大多数的国内软件企业来说，我们都是在求生存中求发展，因此，企业很难在人力、物力和财力上有足够的投入来进行“革命性”的质量改进。有些企业没有注意到这一点，什么都想改进，结果由于投入不足，什么都没有改进好。
　　因此，我们需要结合本企业的实际情况和可能的投入，确定每阶段质量改进的重点并“各个击破”，这样不但可以在较短的时间内收到明显的效果，而且不会让公司投入过大而对后续工作改进“供血不足”，有利于形成良性循环。
（五） 要注重过程，不要只重结果
　　无疑，过程改进的目的是为了取得良好的结果，但如果一味追求结果而忽视对过程的改进和控制，则必然收效甚微。
　　我们知道CMM的核心思想是通过科学、严格的过程执行保证结果的质量，但我们有一些企业却没有清晰地意识到这一点，“唯结果论”的观点让他们将视线和精力都投入到“结果”上来，结果是“头痛医头、脚痛医脚，到处救火”，到头来得不偿失。
　　因此，我们一定要清醒地认识到，没有严格的过程执行，就不会有我们所期望的结果，即使出现了，那也是由于个别能人的努力而出现的个别现象，决不会产生公司所期望的普遍现象。因此，只重结果是“短视”的，惟有注重过程，才可能出现好结果。
（六） 要自我修炼和客户引导并举，不要一味“埋头苦干”
　　在进行软件质量改进的前期往往会增加项目的投入或延长项目成果的交付时间，如果我们不去引导客户，不去让客户明白我们如此做的主要目的是为了给客户提供更好的产品以及在将来的项目上缩短项目工期，则工作往往会很被动。
　　因此，我们在进行质量改进时，除了进行自我修炼外，一定要不失时机地去引导客户，让客户建立起质量意识进而得到客户的理解和支持。如果我们一味“埋头苦干”而不去追寻客户的理解和支持，则我们将会非常难受，甚至美好的质量改进计划不得不由于客户要求的进度压力而大打折扣甚至“夭折”。
　　我们需要知道，客户的支持是我们质量改进的最大后盾。因此，在我们“埋头苦改”的同时，一定要去引导客户配合我们的质量改进工作，“双管齐下”，方能“成就卓越”。
以上是作者在软件质量改进方面的一些体会，期望对正在和将要从事软件质量/过程改进的同仁带来一些过往者的经验借鉴。
主要参考文献：
　　[1] 《软件过程管理》 [美] 瓦茨•S•汉弗莱（Watts S. Humphrey） 著 清华大学出版社
　　[2] 《能力成熟度模型：软件过程改进指南》 卡内基•梅隆大学软件工程研究所  电子工业出版社

CMM“六步曲”--CMM实施技术问题分析
对大多数国内软件企业来说，CMM的实施还处于起步阶段，准备实施CMM2级的企业占绝大多数，因此，分析CMM2级实施过程中的问题，将有助于这些企业尽快找到适合本企业的实施方式。
一些正在实施CMM2级的企业发现有大量的重复性工作要做，原因何在？没有做好需求开发是产生这一问题的主要原因！
1、 需求管理与需求工程
需求开发和需求管理是需求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出现重复性的工作。导致需求开发欠佳的主要原因有以下几点：
◆ 缺乏良好的需求规格说明编写模板
分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。
◆ 较严重地忽略了非功能性需求
目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐成熟，软件客户对软件的非功能性需求也会越来越高，这就对软件开发商提出了更高的要求。不做好非功能性需求的规格说明编写工作，同样会陷入大量重复工作的包围之中。
如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中期才被发现，这将导致大量的文档和产品需要更改，由此带来严重的工程和管理难题。改进的方法之一是调用有相当软件调试和维护背景的资深人员参与需求规格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面存在的不足。
◆ 缺乏对需求文档的配置管理
采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看，一份留给软件开发小组内部使用，前者的目标是让客户较容易理解，后者则更加专业化。在这种情况下，两个需求规格说明都应纳入配置管理的范畴以便从管理的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前者到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能严谨的规则将大大缩小转化过程中人为自由发挥的空间。需要注意的是，这套规则的建立应从一个项目开始，从基础做起，逐渐完善。例如，首先确定项目的基本名词和动词集合，并规定语句书写规则。
◆ 需求规格说明缺乏可测性
在需求说明应具备的几个特性里，为什么单单挑出可测性呢？在需求说明编写阶段，主观性对其他特性的影响较大，而一个独立且有经验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的。从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视的问题。
◆ 缺乏较好的需求规格说明转化规范
需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的中间形式，这一转化过程也被称为“软件建模”。一般来说，建模可以使需求说明的某些方面更形式化一些，并使设计更加清晰地保持需求继承。通常，不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求说明丢失，从而增加后续管理工作的难度。
需求管理的根本目的是为其后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性，因此需求工程完成得好坏对需求管理实施的工作量有很大影响。
2 配置管理与工作产品的转化
软件配置管理的目的是保证项目生成的产品在软件生命周期中的完整性，它需要一个较好的工具，当找不到较好的商用软件工具覆盖该关键域的实践时，许多国外软件企业会自行开发一些工具来弥补不足，并且取得了很好的效果。国内软件企业在实施该关键域时也会使用一些工具，但存在的典型问题是：有太多的SCCB（软件配置控制委员会）活动。
配置管理是在软件生命周期中建立和标识软件工作产品并控制基线的更改，这将保证软件工作产品的完整性和一致性。但是，作为配置项/单元标识的软件工作产品通常为典型的软件生命周期中的工作产品，这些产品具有一个共同特点：一个产品通常是由另一个产品转化而来。从一些企业配置管理下的工作产品来看，存在的主要问题是缺乏较好的可转化性。在这里，“较好的可转化性”是指把一个产品转化为另一个产品时有较规范的转化规则可循，其目的是最大程度地保证一种工作产品能被忠实地转化为另一种工作产品形式，从而最大限度地降低最初的软件需求在转化过程中出现遗漏和被错误解释的可能性。企业在实施这个关键过程域时，应由SCCB记录工作产品的更改以及引发这些更改的原因，这些数据能很好地帮助企业找出问题的症结。一般来说，引发类似问题的原因主要有以下3点：

　　需求规格说明书编写不好或不全；
工作产品模板定义不好；
工作产品之间转化缺乏规范定义。

　　3 项目计划与数据收集和分析
项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域，它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前，项目计划的实践总是处于需要改动的状态。
一般来说，期望在CMM实施之初就有一个可靠的项目计划是不现实的，因为这需要经历若干项目的实施才能获得有效数据并据此制定未来项目的计划。我们知道，配置管理可以保证项目生成的产品在软件生命周期中的完整性，因此，为了更好地实施项目计划，我们可以把用于项目计划的大部分数据放在对应的工作产品配置管理之下，必要时，还可将工作产品进一步细化，以保证对应的项目计划数据的准确性。项目完成后，我们还应该对项目计划的数据进行收集和分析，在此基础上制定下一个项目计划时，准确性就能大大提高。通过对若干项目进行同样的实践，项目经理就有了比较可靠的数据用于制定未来的项目计划。通常，项目跟踪和监督实施不好的原因很大程度上是由于项目计划的频繁更动，同时缺乏良好的项目跟踪工具，使项目管理人员逐渐失去跟踪项目的兴趣。
4 质量保证与实践反馈
实践反馈是质量保证体系得以有效运作的驱动力，企业应该为所有项目建立一条从SQA到项目经理以及更高层经理的反馈渠道。实践反馈是SQA组与高层经理相互沟通的过程，SQA组定期向高层经理汇报SQA的活动，并及时与项目组沟通，使项目组能尽早改进工作；当沟通不畅、发现项目组运作不力或发现组间协调困难时，应及时报告高层经理，通过高层经理的协调及时进行修正。
有些项目经理认为自己心里有一套计划，只要按计划进行就可以按时保质完成项目，但事实并非如此，在项目组之间的协调问题上，高层经理的作用是非常明显的。如果仅仅为满足CMM的要求而虚设高层经理，这种做法是不可取的，因为如此一来，实践反馈是不完全的。
SQA组在CMM实践中犹如一个司法机构，但这还不够，它还应该为改进过程管理提供资源。SQA组不一定完全由专职人员组成，也可调配一些擅长软件开发方法和软件过程管理的人员参与主要的SQA活动。
5 同行评审
从理论上讲，同行评审这个关键域的实施并不难，但实际上大多数企业都掌握得不够好，主要表现在以下方面：
◆ 评审时组间争论过多或过少
这一问题在不同企业的表现也不同。调查表明，争论较多的情况是工作产品的输入/输出不清楚，组间缺乏沟通的公共平台，因此组间只有通过较多的讨论甚至争论才能弄清其他组的需求。遗憾的是，事后大家并没有坐下来认真讨论如何改进原工作产品的模板形式或表现形式，因而也就无法从根本上解决问题。另一种较极端的情况是，评审一个组的工作产品时，其他组很少发表意见，尽管有些问题是十分明显的。通过调研发现，这实际上是企业文化的问题。一种普遍的想法是“等我们实际做的时侯自然就清楚了”，但实际情况往往事与愿违，这使企业的工作效率大打折扣，但又不易被管理层意识到。无论是哪种情况，最终的原因是：“项目甚至企业缺乏持续改进过程管理的意识。”
◆ 缺乏心理训练
做好同行评审的最大挑战是克服心理障碍。简单地说，同行评审就是被别人挑错或挑别人的错。因此，评审会就像是答辩会，必须做好充分的准备。当角色互换，自己成了挑错方时，则应该把被评审的工作产品看成是自己在较早前完成的，现在再做一次修改，且修改完成后，自己要拿它去参加评审答辩。经历几次这种心理角色换位，就会逐渐适应。如果大家都这么做，同行评审就会形成良好的氛围，这对形成健康的企业文化将起促进作用。
◆ 竞争与合作意识不充分
从另一个角度看，同行评审又是竞争与合作的最佳表现场所和形式，凡在这种场合讲话有理且意见中肯的人逐渐会成为团队的核心人物。在这种竞争的环境中，合作是基础，同行评审的目的就是在合作的前提下尽早且有效地排除工作产品中的缺陷。把握好竞争与合作的尺度，将有益于企业文化的发展，否则有可能出现恶性循环。如何把握呢？从大量的案例看，多数消化少数是较好的方法，因为文化是不可创造的。
◆ 考虑不全面
同行评审存在的另一个问题是评审时仅注意工作产品内容本身，大家面对面地弄清内容后，却忽略了如何改进工作产品的表现形式，使新表现形式下的工作产品可更好地用书面形式表示，进而可减少面对面沟通的需求。当然，面对面的沟通并不是不好，但如果一个工作产品需要太多的口头表达才能被理解，则原因只有两个：书写不清楚或模板定义不好，如果是后者则情况更糟。
6 缺陷预防与度量
缺陷预防的目的是为了识别产生缺陷的原因并防止其再次发生。一些实施低级别CMM的企业通常都采用一些度量（metrics）来预防缺陷，包括软件大小、软件设计错误、编码错误、测试错误、设计评审覆盖、编码评审覆盖、产生测试覆盖、与过程原因相关的缺陷、与项目原因相关的缺陷等。
个别企业选用了一些难度更大的度量。大多数情况下，这些企业并非要达到更高级别的CMM，而是从产品需求的特性出发，对工作产品进行缺陷分析和预防。其过程通常是：获取数据、数据整理、度量、发现原因并确定过程的改进措施，其典型例子包括设计复杂性与测试覆盖及测试深度、模块复杂性与测试覆盖及测试深度等。这类企业的软件产品一般具有以下特点：软件产品规模较大，通常在软件产品交付给用户后，通过相当长时间的不断维护，稳定性才能达到满意程度。如果在早期对可能产生较多错误的软件模块进行识别，加强对这些模块的早期关注和测试，就可较早地使系统达到稳定。这种方法常常用在大型软件开发中，但真正用好的并不多，主要原因有以下几点：
◆ 忽略了使用度量的环境
大多数工作产品的度量都是为某一种特定的设计方法或编程语言设计的，忽略了这个因素，度量就容易失去准确性。此外，软件产品不同的行业特性往往也是造成度量产生偏差的原因。
◆ 忽略了对度量参数的修改
一些度量参数是在原来的实践环境下确定的，当在新环境下使用时，其中的参数很可能需要进行修改，才能使度量的准确性得到保证。
◆ 忽略了对相关性的研究
使用的度量与缺陷在本地的相关性越高，度量的价值就越大。获取这种相关性的方法一般是对本地的历史数据进行相关性研究，企业只有在确认满意的相关性后才可将度量用于缺陷预防。

认证和能力提升在中国通常是两码事，过程能力提升任重道远啊。

不错，好文， 学习乐 ，谢谢搂住