基于CMM的软件过程改进已经被越来越多中国的软件企业所接受，目前，在中国已经掀起了一个CMM评估的小高潮， 但是，通过评估不是企业的最终目的，对软件企业而言其根本的利益是通过实施软件过程改进，提高企业的治理水平。CMM作为美国军方评价软件过程能力的一个模型，他是在研究了美国的一些较大的治理基础较好的软件企业提出来，针对中国软件企业的实际需要灵活裁剪，而且，在CMM中也没有告诉企业如何按照此标准进行企业的过程改善。笔者从98起开始主持一个企业的软件过程改善项目，在这3年的时间里，积累了大量的经验教训，现概括出6条策略，供正在或预备实施CMM的软件企业参考。
策略一：自低向上，主动改进
在进行软件过程改善的时候，通常有两种做法，我称之为自顶下与自低向上。在自顶向下的做法中，企业成立一个推进小组，一般称为SEPG（软件工程过程组），他们是企业里"开发大法"制定的组织者。SEPG组织一些开发人员成立各种任务小组，由这些任务小组根据进行过程改善参照的标准编写各种各样的企业的标准与规范，经过一系列的评审、培训，然后让开发人员去执行。在执行过程中最常见的阻力是来自于开发人员，他们往往会抱怨制定的企业开发规范不符合企业的实际情况，标准太高，无法达到。 这一种做法，费时费力不讨好，大家的意见都比较大，标准定的比较完美，而且在评审时还要大家表面上都要认可，制定标准的人花费了很大的精力，对标准的评审浪费了大家的很多的时间，执行时还难以贯彻下去。这种方式98年、99年上半年我在企业里采用过，收效甚微。后来我们降低了要求，抛弃了各种标准与规范，采用了一种简单易行的策略，自低向上的办法，即由SEPG找开发人员、项目经理让他们自我发现问题：你有什么缺点？你将如何改进？好，在开发人员、项目治理人员讲自己的改进措施后，让他们确保能做到。在这种办法中，不需要治理人员花费太多的精力进行标准的制定，改进的推动，这些工作都是由开发人员自己去做的，治理人员仅仅是起到了监督的作用，只要开发人员自己说到做到就可以了。再做下一个项目时，治理人员同样会问这2个问题：你有什么缺点？你将如何改进？然后治理人员监督开发人员说到做到。在这个过程中逐步完善形成标准与规范。
在上面的两中方法中，我们可以从几个方面进行比较：
当然采用第2种方法时，你一定要目标明确，你是要改进过程，而不是为了在短时间内通过评估。策略二：循序渐进，由易到难，由粗到细，由松到严
CMM的一个核心思想是分级改进，在CMM模型中将软件企业的过程能力分成了5级，有很多企业很可能违反了分级改进的思想，搞了一场革命，期望短时间内提高治理水平，那显然是不现实的，我们要需要的是改良而不是革命。分级改进实际上就是要循序渐进，你能一步做到2级吗？不可能的，对于2级的每个KPA，可能你先实现了每个KPA的一部分活动，稳定了，再实施另外一部分活动，假如你现在1级，想一下子将2级的所有的KPA的所有活动都满足是不现实的。在实施CMM的过程中一定要根据企业的实际情况量力而行，千万不要期望值太高，要一步一步来。先定出最基本的改进方案，然后逐步提高，要把握分级改进的思想。
要做到循序渐进，首先要对企业现状有一个明确清醒的熟悉，在分析现状时，下面的四个问题是必须要解答的：
当前我们存在哪些问题（当然，问题可能很多）？
哪些问题是我们迫切需要解决的？
哪些问题是我们目前能够解决的？
哪些问题是我们当前无法解决，需要打好基础后才可以解决的？
接下来要对照标准，提出解决方案。按照"力所能及，有所提?quot;的原则对问题排出优先级。
以SPP、SPTO这2个KPA来说，你可能可以采取5次循环达到CMM2级的要求：
第一次循环：从无到有，使项目组成员熟悉做计划的过程，熟悉项目计划跟踪的重要性。
第一步：要求每个项目组都要用PROJECT 2000做项目计划，该项目计划要满足一定的条件，如：
任务的颗粒度不能太大；
任务负载要均衡；
任务尽可能并行；
等等。
第二步：对每个项目组，按计划进度进行跟踪，在计划执行过程中及时发现问题，解决问题。
第三步：总结本次循环执行过程中存在的问题，如：
项目计划中任务识别不全；
计划的任务工作量估算不准；
在项目进行过程中，发现问题后采取措施不及时等等。
第二次循环：增加完整的生命周期模型定义
生命周期模型是项目治理的治理的主线，定义一个好的生命周期是推行CMM2级的一个最要害的基础工作。
第一步：要求每个项目组首先要定义出自己的生命周期模型，做出项目计划模版
第二步：要求每个项目组按照项目计划模版进行做项目计划
第三步：进行项目计划跟踪
第三次循环：增加规模、工作量等的度量
第一步：要对项目的规模、工作量进行正式的估计
第二步：按计划摸版做项目计划
第三步：进行项目计划跟踪
第四次循环：增加风险分析
项目的风险治理对于国内的软件公司而言，一般都是一个难点，可能风险很多，风险可以预见，但是没有很好的规避措施。所以建议将风险治理放在较后的循环中来改进。
第五次循环：体系化，制度化
开始时要求不要太严，对文档的要求要粗一些，要把握住实质而不是皮毛。
策略三：教育与培训并重
任何一种标准的推广总会将培训放在一个很高的位置上，我不太喜欢用培训这个词，我更喜欢用教育这个词，我们的一个要害目的不是告诉他技能，而是要改变他们的思想，因此，首先要做的工作是教育。要让各个方面的人都能够接受这些先进的思想，以便于主观上认可，客观上配合。进行教育有各种方式，需要配合起来使用：
观摩学习：看看别的做的好的企业是如何做的？和别的企业的治理人员多沟通交流。尤其是对企业的高层治理人员这点很要害。
请外面的专家来讲：俗语讲的好"外来的和尚好念经"，这句话屡试不爽，企业内的人说多遍可能效果甚微，外面的专家讲一句，一下就点透了，接受了。
自我反省：开发人员进行自我分析找出自己的不足，并提出改进意见，大家互相沟通交流这些经验教训，自己教育自己。
补上"教"：我们的很多软件工程师、项目经理的经验并不是很充分，也可能比较固执，不撞南墙不回头，没关系，答应他犯错误，但是要有人帮他记录他的错误，提醒他熟悉自己的不足，加深他的印象。
培训：培训可以分成多种：技术型培训与治理型培训，这是最基本的工作，思想工作做通了，培训起来效果就会比较好。 SPI不能仅仅定义为开发部门的工作，需要整个企业的所有人员的参与和重视，因此教育与培训的对象比较多，不要有遗漏，如：
高层治理人员：为什么要进行SPI？在过程中会出现什么问题？对公司有哪些正面与负面的影响？需要领导配合做哪些工作？要熟悉到工作的艰巨性。
开发治理人员：技术与治理知识
开发人员：技术与治理知识
市场人员：要熟悉到SPI的重要性，对市场的影响，在此过程中如何配合？
客户：对于一个项目而言，需要提出合理的进度、质量与投入的要求，并把握好需求的范围。策略四：测试先行
尽管测试在CMM中没有作为一个单独的KPA存在，但是，加强测试却是我们实施CMM的一个很好的策略。在治理基础薄弱的软件企业里面，通过加强软件测试，可以直观地发现很多问题，从而使大家熟悉到质量的重要性，熟悉到进行过程改进的重要性，事实胜于雄辩；另一方面也减少了用户发现错误的概率。在很多软件企业里面并没有专职的测试人员，测试一般是有项目组自己进行，而且往往也是在项目结束时才进行测试，在项目进行过程中很少进行测试，这就是现状。
设立专职的测试，让他们在开发过程中参与测试，可以发现项目开发过程中的很多问题，如：
项目组提交给测试人员的文档太简单，测试人员无法看懂；
项目组提交的文档与实际做出来的软件不一致，测试人员无法测试；
项目修改了需求与设计，没有及时通知相关人员，测试人员按旧的设计测试，有的开发人员按新设计开发，有的开发人员按旧的设计开发；
不同的模块界面风格差别很大，没有统一的界面标准；
测试人员测试的版本与开发人员开发的版本不统一；
项目组成员的分工不合理。有的开发人员任务重，而他开发的软件缺陷非凡多，有的模块缺陷就非凡多，可能设计人员的能力比较弱；
项目组没有按计划提交测试，项目拖期；
软件运行速度很慢，怀疑系统的设计有问题；
……… 通过对错误原因的分析，可以发现大量的治理问题、需求的问题、与设计的问题没，这些实在的统计数字对我们找出最要害的改进点、说服反对派、教育软件工程师、加快SPI的推进是一个有力的武器。
策略五："因材施教，各个击破"
在一个企业内可能有个开发项目组或者开发部门，不同的组与部门原来就有不同的治理水平，在我们推行CMM时，不要一刀切，不要希望每个队伍同时达到CMM2级或更高的级别，应该区分对待。比如说做产品的部门，经常进行大大小小的各种各样的升级，产品的版本比较多，他们对版本治理的工作熟悉的很深刻，在工作中积累了一套行之有效的版本治理的方法，版本治理比较正规，对于这样的部门可以实施配置治理KPA的要求，进一步提高治理水平，而对于其他做系统集成的部门这方面的工作可能就差一些，没有很好的版本治理的基础。因此，假如一刀切，要求大家都在3个月内达到CMM2级的要求，这个目标对系统集成的部门讲，就定的太高了。当然通过一场运动来提高治理水平是可以尝试的，但往往是不能持久的。
所以在进行改进时应针对不同的项目组、不同的部门定出不同的改进计划，如可以采用下表的方式来定义不同项目组、不同KPA的阶段计划：
策略六：充分利用治理工具
治理工具可以做为思想、方法的载体，他可以将治理有形化、客观化，降低劳动强度，解决手工无法解决的问题，易于为开发人员、治理人员所接受。充分利用治理工具来推行SPI的一个很好的策略。
很早我们就引进了MKS SI配置治理工具，Poject 98计划工具，SQA 测试工具以及QA monitor等其他的一些治理工具。开始引入的时候是有些难度，究竟是对工作方法产生了改变，一旦熟练了，就习惯了，目前它们已经成了大家在工作中必不可少的工具。
对工具的选择与购买需要把握好"够用既可"的原则。软件开发治理工具一般比较昂贵，假如一次性投资购买了比较昂贵的软件，可能软件的80%的功能用不上，等企业的治理提高到工具软件可以支持的较高的治理水平，已经是2年以后的事情了，而2年以后的版本也需要升级更新了，所以，没有必要为用不到的80%的功能提前投资。
