《术以载道——软件过程改进实践指南》—第1章1.3节如何实施CMMI

本节书摘来自异步社区《术以载道——软件过程改进实践指南》一书中的第1章1.3节如何实施CMMI，作者任甲林,更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.3 如何实施CMMI
1.3.1 实施CMMI时必须解决的7个认识问题
在基于CMMI实施软件过程改进时，有些根本的思想认识问题解决不了，往往会导致实施过程改进的周期变长，效果不佳，甚至终止或失败。软件企业的高层领导、企业的过程改进主管、销售人员、项目经理及一般的开发人员都需要对这些问题统一认识，在此基础上才能消除各方面的阻力，把握好过程改进的方向，控制好过程改进的进度。在实施CMMI时必须解决如下几个思想认识问题。

（1） CMMI不是万能的，需要技术、人员、过程三个要素一起改善

在软件工程发展的历史进程中，人们为了解决软件危机，尝试采用了诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案，但是效果并不那么显著。美国卡内基梅隆大学软件工程研究所提出的软件过程能力成熟度模型是基于过程的角度来应对软件危机。那么是否实施了CMMI，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。企业要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，因为人员、技术和过程是支撑软件开发的三条腿，少了哪一条都不行，如图1-8所示。在管理学中，有所谓的“木桶原理”，即一个木桶可存水的最大容量是由最短的那根木头决定的。在企业的开发能力中，过程，技术（含工具、方法），人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，很可能事倍功半。

在开始实施CMMI时，最容易犯的一个错误就是“唯管理论”或孤立地只抓过程改进，忽略了开发技术与人员的提高，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改进就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、ROSE等开发工具，但是仅仅是形似，没有做到真正的面向对象方法，没有得到面向对象方法的精髓，这种问题仅仅依靠过程改进是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMMI无法解决的。

案例：人员培养的瓶颈问题

2007年，我曾经为江苏一家软件外包企业做咨询。该公司2003年时就通过了CMM 3级的评估，经过多年的持续改进，企业的过程体系简洁而高效。但是该公司的开发人员基本上没有超过3年工作经验，尽管过程定义得简洁高效，项目组成员也能按标准与规范执行，但是项目组成员编写的需求文档、设计文档、代码与测试用例的质量比较差。我每次去运行检查都要首先作为同行专家去发现这些文档的bug，帮助项目组成员去发现工作产品中的内在的质量问题。在这家公司，过程就并非最突出的问题，而人员问题才是瓶颈，迫切需要解决的是人员培养问题。
案例：技术复用的威力

2007年底，我曾经到深圳一家软件公司做售前。该公司有3个做类似软件的开发部门，其中一个部门花了4年的时间积累了一套可复用的框架，当有新的员工加入该部门时，只要花1周的时间学习该框架，就可以开发出可以交付最终用户使用的应用系统，具有很高的开发效率，但是，其他两个部门却没有复用该框架。当完成一天的初步差距分析后，我告诉该公司老板：“只要将该框架推广到其他两个部门，获得的效益要超过实施CMMI的投入产出比！对这家公司而言，目前迫切需要解决的是打破3个部门之间的“墙”，复用其中一个部门的框架，将该框架演变为组织级的框架，就可以在短期内提高整个公司的生产效率。
（2） 过程改进的效果不是立竿见影的

在实施CMMI时，企业的管理层在开始时往往会对过程改进的期望值太高，希望在短时间内达到显著效果，但管理的改善是符合J曲线的。如图1-9所示，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，但是度过了这段时间就会看到过程改进的效果。所以在改善的初期大家要有这个思想准备，要有耐心。

案例：建立老板对过程改进的承诺

2005年，我为北京一家公司咨询CMMI 3级，在差距分析的报告会上，针对企业的突出问题（比如研发人员的考核办法、配置管理等）老板做出了如下承诺。

在平均提高开发人员10%工资的前提下建立研发人员的考核办法；

可以购买不超过40万元的设备与软件工具用以提高管理水平；

在过程改进启动3个月之内，所有的反对意见暂时搁置；

……

上述的承诺写入会议纪要，并由公司老板亲自修改了会议纪要作为其对过程改进的承诺。在上述承诺中的第3条，其实就是对J曲线的认可。
（3） 坚持活学活用，以我为主

很多国内的软件企业都是从作坊式的软件组织逐步发展过来的，没有标准、规范，企业里真正超过10年软件工程经验的人员比较少，有经验的人员又不愿意从事质量管理与过程管理。因此很多企业的EPG成员欠缺工程经验，又没有真正的有实践经验的专家进行指导，所以对CMMI的理解就不可能深刻，于是就不敢裁剪CMMI，容易机械照搬CMMI条文。其实这恰恰违背了CMMI的精神，CMMI是软件工程经验的集大成，是从实践中总结出来的，CMMI本身也在更新版本，不断完善。

每个企业都有自己的特点，也都有自己的经验教训总结，就像微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结。有些内容是CMMI中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地尝试。

在推行CMMI时，所遇到的阻力，很大程度上是由于照搬CMMI的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁就有发言权。所以在制定质量体系时，尤其是在制定大家都要执行的操作规程、模板时，一定要得到执行者的认同，否则就容易成为执行和沟通的障碍。凭借公司的行政制度硬性推行质量体系，表面上看来似乎大伙也照规程做了，其实是表面文章，对改善没有实际帮助，导致过程改进工作受阻。

案例：EPG与开发人员建流程的对比

2011年我咨询了一家软件公司，在这家公司内建立体系时，项目管理类的体系是由一个EPG成员参考其他公司的流程建立的，工程类的体系是由开发部门的资深人员建立的。2013年当我回访此公司时，质量人员反馈工程类的体系这2年执行的很好，而管理类的流程执行的不好，项目组成员总是找借口不执行或事后补文档。
（4） 要改良不要革命

以革命的方式来实施CMMI，期望通过一场运动来解决过程能力的问题，一种可能是不懂CMMI，不晓得管理的改进是循序渐进的，另一种可能是明知故犯，期望在短期内通过CMMI评估，单纯追求市场上的轰动效应。有的企业在短时间内虽然通过了CMMI评估，但是由于没有实效而得不到大家的认同，所以难以将这种“水平”持续下去。过程改进就像减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复。

我曾经尝试以革命的方式与改良的方式进行过程改进，效果差异很大，改良的效果比较扎实，所以应该让大家在“小步快跑”中接受变革，这样风险最小，效果最好。

案例：Genersoft公司的过程改进

Genersoft是我工作了8年的软件公司。1998年10月Genersoft开始启动了基于CMM的过程改进，2001年10月通过CMM 2级的正式评估，历时3年。在这3年里，Genersoft成立了独立的测试部门，购买了测试工具、配置管理工具，对开发人员实现了量化考核，在考核中纳入了工作量、质量、过程符合性等指标。所有的上述改进都不是一朝一夕完成的，要建立企业的质量文化就必须扎扎实实地做。
（5）CMMI与企业的创新文化是不矛盾的

软件企业必须形成创新的文化。管理与创新是软件企业发展的两个轮子，管理确保企业能够平稳地发展，创新能够实现企业的跳跃式发展，只抓管理不抓创新，可能导致企业的发展速度太慢，最终形成“快鱼吃慢鱼”的现象，只抓创新不抓管理，则可能导致创新无法转化为生产力。当然有的企业是以出售企业为目的，将整个公司作为一个产品销售出去，此时又另当别论。一个成功的企业，应该同时具备两个基本的条件，一是规模大，二是百年老店。中国有很多老字号，比如“**剪刀”之类的，虽然这个品牌存活了上百年，但是一直手工作坊，没有规模，也就没有太大的影响力。而当年的巨人集团虽然企业的规模可以快速膨胀起来，但是垮得也很快。这两类企业都不是成功的企业。

软件企业的有些管理人员，也包括一些开发人员，往往认为严格的管理会束缚他们的创新，他们认为 CMMI提倡的是一种按部就班的文化，什么活动都要做计划、按规程标准来做，对企业的创新文化会起到负面作用。在我遇到的开发人员中，技术钻研越深的人持这种观点的越多。形成这种观点主要有两个原因：一是企业在推行CMMI时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。比如在分析与设计阶段，需要开发人员能够发挥创意的成分更大一些，如果要求他们一定按统一的文档标准来写文档，甚至字号大小、缩进格式一点也不能差，这的确很难做到，可能需要项目组配备文档支持人员来做这些完善工作，降低分析与设计人员的工作量。二是这类人员缺少真正的软件工程经验，做大项目的经验太少，经历的失败太少。CMMI 是工程经验与教训的大集合，我们无需再去重复那些失败。

技术创新必须通过管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。管理的改进优化到一定程度就会遭遇“天花板”现象，此时就必须借助技术的创新或管理的创新才能突破屋顶，达到另外一个境界。

（6）要勇于实践，也要允许犯错误

CMMI就是软件工程经验与教训的总结。在实施CMMI的过程中，肯定会走弯路，甚至犯错误，因此许多人会议论纷纷，一直会反应到高层经理。这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，要“摸着石头过河”，不下水，是没有办法过河的，临渊羡鱼不如退而结网。要少说不，少说难，多实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、EPG等人员有偏见，要以积极的心态面对改进。

（7）管理过程改进是组织内所有人的事情，而并非仅仅是EPG的事情

按照CMMI专家的建议，在一个组织内专职从事软件过程改进的人数应为组织总人数的29～39%，这些人称为工程过程组（EPG），EPG成员专职负责企业的软件过程改进工作。另外企业根据需要还会配备一些兼职的技术任务组（TWG），他们会兼职参与质量体系的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题。

EPG成了最忙的人，TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由EPG成员替代TWG做工作。
企业的非开发人员没有明确地感受到过程改进的效果，有的甚至认为由于加了这些新的活动可能使项目拖期会更严重，于是他们可能就会将这些抱怨反馈给企业的高层经理。在推行过程中我经常会听到：这个项目时间太紧，当前不适合使用CMMI。
高层经理迫于市场的压力，甚至可能会提出不合实际的项目工期等。
推行CMMI不仅仅是管理人员的事情，每个人都要积极参与。要改变原来的一些做法： EPG在使劲地推进CMMI的工作，而不是大家自觉自愿地来实施CMMI。从EPG的角度来看，要做好培训的工作，首先要解决大家的思想认识问题，这还是比较难的，有些人的思想比较顽固。

过程改进首先要解决的就是思想认识问题，然后才是实施方法问题。不但在主观上要建立整体的思想认识，在客观上也要有切实可行的改进措施。光说不练是不行的，光练不说也是要否定的。任何变革都会涉及企业内部权力的再分配，不要忽视企业政治，这是客观存在的，所以一定要预防那些光说不练者。

案例：动口不动手的改进者

2008年，有一家软件公司启动了过程改进，从上到下都表示要积极参与，但是雷声大，雨点小，所有兼职的EPG成员都以项目的工期紧、人手少为理由，并没有真正地投入时间编写质量体系，而是直接借鉴咨询顾问提供的样例或拷贝国家、国际标准。没有真正理解CMMI模型，没有结合本公司的实践，体系的起草者们自己都无法解释清楚体系中定义的活动及文档模板的含义，这样建立的体系怎么可能推广起来呢？

1.3.2 软件过程改进的11条成功策略
基于CMMI的软件过程改进已经被越来越多的软件企业所接受，据不完全统计，2012年在中国有 400 多家软件公司通过了 CMMI 评估。但是，通过评估不是企业的最终目的，提高企业的管理水平才是实施过程改进的根本目标。CMMI 是一个过程改进的框架，并没有给出实施过程改进的具体策略，基于我自身过程改进及咨询的经验，概括出如下的11条策略供参考。

策略一：由底向上，主动改进

在进行软件过程改进的时候，通常有两种做法，称为自顶向下与由底向上。在自顶向下的做法中，企业成立一个推进小组，一般称为EPG（工程过程组），他们是企业里“开发大法”制定的组织者。EPG组织一些专家成立各种任务小组，由这些任务小组参照过程改进的标准编写各种各样的企业标准与规范，经过一系列的评审、培训，然后发布、执行。在执行过程中最常见的阻力是来自于开发人员，他们往往会抱怨制定的企业开发规范不符合企业的实际情况，不实用，无法达到。这种做法，费时费力不讨好，大家的意见都比较大，标准可能定得比较完美，但执行时难以贯彻下去。在1998年、1999年我在企业里做过程改进时采用过这种方式，收效甚微。后来我切换为由底向上的办法，即由EPG访谈开发人员、项目经理，让他们自我发现问题：你有什么缺点？你将如何改进？在开发人员、项目管理人员确定好自己的改进措施后，EPG将其文档化，QA监督这些措施的执行。在这种办法中，不需要管理人员花费太多的精力进行标准的制定、改进的推动，这些工作都是由开发人员去做，管理人员仅仅起到监督的作用，只要开发人员自己说到做到就可以了。再做下一个项目时，管理人员同样会问这2个问题：你有什么缺点？你将如何改进？然后管理人员监督开发人员说到做到。如此循环提升、逐步完善，形成标准与规范。

可以从几个方面对上述两种策略进行比较，参见表1-7。

融合上述的两种策略也是一种解决方案。

策略二：循序渐进，由易到难，由粗到细，由松到严

CMMI的一个核心思想是分级改进，采用渐变的方式而不是突变的方式进行过程改进。比如对于2级的每个过程域，可能你先启动一部分活动，支持部分目标，待制度化了，再实施另外一部分活动，直至支持全部目标。在实施CMMI的过程中一定要根据企业的实际情况量力而行，千万不要把期望值定得太高，要一步一步来，先定出最基本的改进方案，要把握分级改进的思想然后逐步提高。

做到循序渐进，首先要对企业现状有一个明确清醒的认识。在按照CMMI的评估标准分析现状时，下面的四个问题必须要解答。

当前我们存在哪些问题和弱项？
哪些问题和弱项是我们迫切需要解决的？
哪些问题和弱项是我们目前能够解决的？
哪些问题和弱项是我们当前无法解决，需要打好基础后才可以解决的？
接下来要对照标准，提出解决方案。按照“既要突出重点，又要力所能及，有所提高”的原则对问题排出优先级。

以PP、PMC这2个过程域为例，以下就是一种循序渐进的方案：

第一次循环：

（1）要求每个项目组都要用MS Project做项目计划，该项目计划要满足一定的条件，如：任务的颗粒度不能太大；任务负载要均衡；任务尽可能并行等。

（2）对每个项目组，按计划进度进行跟踪，在计划执行过程中及时发现问题，解决问题。

（3）总结本次循环执行过程中存在的问题。如，项目计划中任务识别不全；计划的任务工作量估算不准；在项目进行过程中，发现问题后采取措施不及时等。

第二次循环：增加完整的生命周期模型定义。

生命周期模型是项目管理的主线，定义一个好的生命周期模型是推行CMMI 2级的一个最关键的基础工作。

（1）要求每个项目组首先要定义自己的生命周期模型，做出项目计划模板。

（2）要求每个项目组按照项目计划模板做项目计划。

（3）进行项目计划跟踪。

第三次循环：增加规模、工作量等的估算，进行更深入的计划管理，确保计划的合理性。

（1）要对项目的规模、工作量进行正式估计。

（2）按计划模板做项目计划。

（3）进行项目计划跟踪。

第四次循环：增加风险分析。

项目的风险管理是一个难点，所以建议将风险管理放在较后的循环中进行改进。

第五次循环：体系化，制度化。

每个企业应该根据企业的实际现状确定改进的图线，逐步提高管理水平。

策略三：先敏捷再规范

先敏捷再规范这个策略源于实践。其本意是先做到再写到，先短期利益再长远利益，先实效再完备。因为一步到位直接采用规范的方法，阻力比较大，效果难以持久，很可能事倍功半。敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易被开发人员接受，所以可以先敏捷再规范，将敏捷作为通向规范的一个阶段。

芸芸众生，大都是凡人，凡人都是注重短期利益的。只有那些领袖、那些思想家才是目光如炬，站得高看得远。过程改进要从凡人做起，凡人是体系的执行者，所以首先要满足凡人的需求，让凡人看到好处。否则，群众的力量是无穷的，这力量可以是建设的力量也可以是破坏的力量。

敏捷方法是适应变化的一种方法。因时、因势、因事调整计划，它可以处理近期内即将发生或已经发生的变化，它不赞成为未来的不确定的变化花费太多的时间，变化会导致近期计划的调整，也使长期的计划难以预期。

采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。敏捷方法在落实其规矩时与重量级的方法有所不同。

（1） 敏捷方法减少了中间结果的记录，减少了管理与支持类的文档

敏捷方法减少了管理与支持文档的工作量，但并不意味着没有做管理，只是做得少、文档也少。比如敏捷方法也要做计划，也要估算项目的工作量，也要和项目组的成员沟通计划的可行性，也要获得项目组成员的承诺，只是这些管理活动可能只有最终的计划书，而没有中间结果的记录。在敏捷方法中很少看到关于质量保证活动、度量分析活动的系统要求。

（2）敏捷方法强调通过面对面的口头交流，减少书面的文字交流

文档是沟通的一种方式，口头交流也是一种沟通的方式。在重量级的管理方法中强调了文档的重要性，而敏捷方法并非没有文档，只是它认为口头交流更重要，口头交流效率更高，因此可以编写简单的设计文档，设计思想可以通过口头交流进行评审，用口头交流弥补文档简化的不足。因为文档简单，将来的变化也就少，维护的工作量也相应减少。但是口头交流在传递的过程中，很容易由于传递者个人的观点而对信息进行增删改，比如一些神话故事，各有各的版本。

（3）敏捷方法强调最终的交付物而忽略了中间产物

关注最终交付物的质量而不是中间结果的质量，采用诸如单元测试、结对编程、代码重构、持续集成、代码规范等手段确保源程序的质量。采用迭代的方法尽早进入编程，在过程中通过沟通进行设计的实时评审、代码的实时评审，以便于尽早发现交付代码的缺陷，尽早修复缺陷。作为开发过程的中间产物，需求与设计等文档则进行了简化。代码是必须交付的，所以要采用一切手段规范之，既然要交付，就要保证其质量。而需求与设计文档并非是必须交付的，需求和设计也是经常变化的，既然不交付，既然始终变化，干脆就不花时间去写。

（4）敏捷方法认为高效的人比规范的过程更重要

敏捷方法中最常见的是3种角色：教练、客户、开发人员。教练起到了项目经理和过程指导者的作用，客户实时执行确认与验证的动作，开发人员去实现产品。一群精英如果能默契地合作，则不需要去监督他们是否按照标准规范去执行了，这个团队是自我管理的，大家有着共同的价值观，彼此能快速协同，互补合作，最终走向成功。是英雄创造了历史，还是人民群众创造了历史？结论不言而喻，但是如果没有英雄呢？如果各位都是英雄呢？

以上种种思想，反映了敏捷方法的实用主义哲学。如果一家企业的项目大都在10人以下，开发团队完全可以从敏捷方法开始着手进行过程改进。但是，软件开发存在非规模经济的现象，随着团队规模的增加，上述的手段可能很快就失效，还要回到重量级方法上来。

策略四：先下游再上游

先改进生命周期下游的流程，再改进生命周期上游的流程。

系统的维护阶段是用户方与开发方交流沟通最多最直接的一个阶段，开发方在此阶段的错误可以被用户方直接捕获，用户对开发方的管理水平、服务水平、开发水平的体会最直接最深刻。开发方应该首先改进与客户直接交互的流程，确保高质量的产品能得到有效的部署与维护。在维护阶段发现的问题，应该进行根本原因的分析，分析这些问题的产生根源，以提供客观的证据证明在生命周期上游存在的问题，便于从生命周期的上游开始改进。

采用此策略易于解决目前客户反应最强烈的问题，易于发现目前的瓶颈问题进行改进，能够在短期内取得良好的改进效果，制定的改进点易于为开发人员所接受，是一种典型的由表及里的改进路线。

策略五：测试先行

在管理基础薄弱的软件企业里，通过加强软件测试，可以直观地发现很多问题，事实胜于雄辩，从而使大家认识到质量的重要性，认识到进行过程改进的重要性；另一方面也减少了用户发现错误的概率。

设立专职的测试，让他们在开发过程中参与测试，可以发现项目开发过程中的很多问题。

项目组提交给测试人员的文档太简单，测试人员无法看懂；
项目组提交的文档与实际做出来的软件不一致，测试人员无法测试；
项目修改了需求与设计，没有及时通知相关人员，测试人员按旧的设计测试，有的开发人员按新设计开发，有的开发人员按旧的设计开发；
不同的模块界面风格差别很大，没有统一的界面标准；
测试人员测试的版本与开发人员开发的版本不统一；
项目组成员的分工不合理，有的开发人员任务重，他开发的软件缺陷就特别多；有的模块缺陷特别多，可能设计人员的能力比较弱；
项目组没有按计划提交测试，项目拖期；
软件运行速度很慢，怀疑系统的设计有问题。
通过对错误原因的分析，可以发现大量的管理问题、需求的问题与设计的问题，这些实际的问题对我们找出最关键的改进点，说服反对派，教育软件工程师，加快推进过程改进是一个有力的武器。

策略六：从经验教训中学习

每次去客户现场进行差距分析或者运行检查，我总是习惯于找他们的缺点，但是每次也总能发现他们的优点，时间久了。慢慢地对缺陷麻木了，审丑疲劳了，只有发现他们的优点时，我才会精神一振，心情愉快。

我始终坚信，通过每个开发人员、每个项目组、每个角色自我总结自己的经验教训，吸取这些经验教训，可以扎实地提高组织的过程能力，如果再加上参考某个模型，效果可能更好。而现实是，很多企业把眼睛盯在外部的参考模型上，而忽略了自身的经验教训，没有挖掘自身的价值，实在是让我痛惜。

曾子曰：“吾日三省其身！”，圣贤的话是很有道理的。

向自己的历史学习，针对性强、见效快、效果好！

灯，需要有人去点燃！点燃的灯，往往灯下黑！

案例：看看你的表，告诉你几点了

2007年1～2月份期间我去给一个客户做运行检查，整理完发现报告后，我查阅了6个项目组的阶段总结报告与项目总结报告中的经验教训部分，我发现的60%的缺陷他们自己也感觉到了，只是没有人去提取，去系统地归纳整理、去落实。他们老板的一句话马上浮现在我的脑海里：“咨询顾问就是当你问他时间时，他拿过你的手腕，看看你的表，然后告诉你几点了，再向你收费！”。他们没有想到看自己的手表，我就充当了那个看手表的顾问，我比他们更知道手表的价值。
策略七：因材施教，各个击破

在一个企业内可能有多个开发项目组或者开发部门，不同的组与部门有不同的管理水平，在我们推行CMMI时，不要一刀切，不要希望每个队伍同时达到CMMI2级或更高的级别，应该区别对待。比如说产品研发的部门，经常进行大大小小的各种各样的升级，产品的版本比较多，他们对版本管理认识得很深刻，在工作中积累了一套行之有效的版本管理方法，对于这样的部门可以实施配置管理PA的要求，进一步提高管理水平，而对于其他做系统集成的部门这方面的工作可能就差一些，没有很好的版本管理的基础。因此，如果一刀切，要求大家都在3个月内都达到CMMI 2级的要求，这个目标对系统集成的部门就定得太高了。所以在进行改进时应针对不同的项目组、不同的部门定出不同的改进计划，如可以采用表1-8的方式来定义不同项目组、不同PA的阶段计划。

策略八：教育与培训并重

教育主要是改变思想观念，培训主要是传授具体的方法，二者互补，以使员工能够知其然，知其所以然，能够在主观上认可，客观上执行。

进行教育与培训有各种方式，需要配合起来使用。

（1）观摩学习。看看其他的标杆企业是如何做的？和其他企业的管理人员多沟通交流。这种方式是企业的高层管理人员经常采用的。

（2）请外面的专家来讲。俗语讲得好“外来的和尚好念经”，这句话屡试不爽。企业内的人说多遍可能效果甚微，外面的专家讲一句，一下就点透了，对方就接受了。

（3）自我反省。开发人员进行自我分析找出自己的不足，并提出改进意见，大家互相沟通交流这些经验教训，自己教育自己。

（4）培训。培训可以分成多种：技术型培训与管理型培训，这是最基本的工作，思想工作做通了，培训起来效果就会比较好。

过程改进不能仅仅定义为开发部门的工作，需要整个企业的所有人员的参与和重视，因此教育与培训的对象比较多，不要有遗漏，如：

a）高层管理人员：为什么要进行过程改进？所支持的经营目标是什么？企业能提供哪些支持？在过程中会出现什么问题？对公司有哪些正面与负面的影响？需要领导配合做哪些工作？要认识到工作的艰巨性。

b）开发管理人员：技术与管理知识，CMMI的理念、作用。

c）开发人员：技术与管理知识，CMMI的理念，企业的政策、规程。

d）市场人员：要认识到SPI过程改进的重要性、SPI对市场的影响，在此过程中如何配合？

e）客户：对于一个项目而言，需要提出合理的进度、质量与投入的要求，并把握需求的范围。

案例：富士康科技集团的教育训练

自2006年6月起，我便为FOXCONN集团提供CMMI的咨询服务，接触了多个事业群。在我接触到的所有企业中，FOXCONN集团是教育训练做得最优秀的。平均每位员工接受训练要达到288工时/年，师四及以上级别的工程师每年对内部员工必须做两次教育训练，如果无法达到这个考核指标，则影响员工的晋级。

在给FOXCONN SIDC部门咨询时，楼道的墙壁上贴满了本月的培训课程，内容很丰富。这些课程有些是FOXCONN集团评定的内部教员讲授，有些是外部讲师的讲授，有些是以前历史培训的录像。

有一位事业群的老总讲过一句话让我记忆深刻：“我要让我的员工一半时间挣钱，一半时间提高！”
策略九：充分利用管理工具

管理工具可以作为思想、方法的载体，它可以将管理可视化、客观化，降低劳动强度，解决手工无法解决的问题，易于为开发人员、管理人员所接受。充分利用管理工具来推行过程改进是一个很好的策略。

1998年我在做过程改进时引进了MKS SI配置管理工具、Project 98计划工具、SQA 测试工具、以及QA monitor等其他的一些管理工具。开始引入的时候是有些难度，毕竟是对工作方法产生了改变，一旦熟练了，就习惯了。

对工具的选择与购买需要把握好“够用即可”的原则。软件开发管理工具一般比较昂贵，如果一次性投资购买了比较昂贵的软件，可能软件的80%的功能用不上，待企业的管理提高到工具软件可以支持的较高的管理水平时，已经是2年以后的事情了，而2年以后的版本也需要升级更新。所以，没有必要为用不到的80%的功能提前投资。而现在各种各样的开源工具比较多，功能可以满足需求，又便于进行客户化，因此，充分利用开源工具是一个不错的选择。

策略十：内外结合，以内为主

目前很多软件公司，为达到在较短的时间内通过CMMI的评估，签订咨询合同，寻求咨询公司的帮助，我认为这也是一个可行的方式。原因有以下几个方面。

（1）咨询公司熟悉CMMI框架，并提供相应的培训，可使公司的EPG抓住重点，少走弯路，与完全依靠组织自身的EPG相比，可缩短实施的周期。

（2）咨询公司的培训往往比公司内部的培训效果要好，正是所谓外来的和尚好念经，公司内的认可程度较高。

（3）咨询公司对组织资源的建议，比较易于获得企业高层的采纳，引起组织的重视。

但同时也需要注意，不要过分依赖咨询公司，尤其不值得提倡的是，有些公司直接从咨询公司处得到标准、规程，囫囵吞枣，直接照搬照抄，真正是为了评估而评估。企业的标准规范必须与本企业紧密结合，这些标准规范在CMMI中被称之为企业财富，只有符合企业实际情况的标准规范才是最有价值的。

咨询公司虽然可以提供帮助通过评估，但企业的过程改进还是要以内部为主。软件的过程改进实际上是企业文化的转变，而企业文化的转变归根结底是人的观念、思想、认识、做事方式的转变，是个人能力的提高，这种提高是通过组织中的EPG、项目经理、工程技术人员、管理人员整体素质的提高得以实现的，这种实现的途径是通过学习、实践获得的。因此，软件企业要真正注重实效的改进，就要尽可能多的与咨询公司进行交流，不仅要知其然还要知其所以然，打破沙锅问到底，才能真正促进企业过程的改进，同时也能丰富咨询公司的工程实践经验，获得双赢的效果。

策略十一：由外而内的过程改进策略

何谓“外”？外，是相对而言的。

对于一个公司而言，供应商、客户为“外”。

对于一个开发部门而言，供应商，客户，其他部门（比如市场部门、运维部门等）为“外”。

对于一个项目组而言，供应商、客户、其他部门、其他项目组、其他支持组为“外”。

对于一个项目组内的小组而言，其他小组、其他项目组为“外”。

对于一个项目阶段而言，其上游阶段、下游阶段为“外”。

对于一个人而言，其他人为“外”。

在定义过程体系时，采用由外而内的策略，则意味着，可以采用如下的优先级定义和规范公司的管理。

1．先定义和客户、供应商的沟通协同规范，再定义公司内部的规范，如：

需求获取、用户确认、验收测试、试运行、用户验收、运行维护的流程。

……

2．定义公司内部各部门之间的接口标准、沟通协同规范，如：

市场转开发、开发转测试、测试转运行维护的接口标准、规范。

……

3．定义项目组和其他组之间的接口标准、沟通协同规范，如：

领导下达、验收任务的流程、标准；

项目组之间互相支持的流程、标准；

质量保证组、测试组以及其他支持组和项目协同的流程和标准。

……

4．定义各个项目小组之间的接口标准、沟通协同规范，如：

问题处理的流程、标准；

承诺、确认的流程、标准；

……

5．定义阶段之间的接口标准，如：

从需求阶段进入设计阶段的标准是什么？

从设计阶段进入编码阶段的标准是什么？

从编码转测试的标准是什么？

测试结束的准则是什么？

……

6．定义每个人的行为准则，如：

如何对项目经理承诺，如何给项目经理报告工作？

如何配合其他人完成开发任务？

……

说白了，此策略就是优先进行管理接口的设计，只不过接口有大有小，是“攘外必先安内”的反其道而行之！

1.3.3 CMMI实施的4个重大失误
很多公司在做CMMI时在重复这种错误：“证书优先，机械照搬，文档泛滥，宁严勿宽”！

（1）“证书优先”

CMMI的证书成了一个敲门砖，没有这个证书是无法承担国外的项目，没有CMMI的证书就无法在国内一些项目的竞标中获胜，也无法获得政府的补助，于是很多公司都选择了要在短时间内获得CMMI证书。证书只是过程改进的附属物，而过程改进的实效才是其真正的价值。为了尽快拿到证书，企业往往忽略了实效，从形式上满足了模型的要求，但是从实质上却差的很远。

根据SEI的报告，自1992年以来，从CMMI等级1到等级2的达到时间的中间值为19个月，从2级到3级的中间值为19个月，从3级到4级的中间值为24个月，从4级到5级的中间值为13个月。在中国根据调查，从1级到2级的平均时间为14个月，从1级到3级的平均时间为18个月，到4级的平均时间为32.6个月，到5级的平均时间为34个月。

CMMI的基本精神是循序渐进，循序渐进就是要逐步改进，逐步改进就要立足实际，就需要时间，而非一蹴而就。

（2）“机械照搬”

企业在实施CMMI的时候，为了满足模型的要求，在描述自己的过程时，习惯于照搬模型的描述。最典型的例子是PMC过程域，该PA中包含了10条实践。

SP1.1 监督项目的计划参数

SP1.2 监督承诺

SP1.3 监督风险

SP1.4 监督数据管理

SP1.5 监督项目相关人员的参与

SP1.6 执行进展评审

SP1.7 执行里程碑评审

SP2.1 分析问题

SP2.2 采取纠正行动

SP2.3 管理纠正行动

于是有的企业就照搬上面的10个活动定义了自己的项目监督与控制过程，其实项目的监督与控制活动主要是：

（1）每天检查项目组成员的工作情况：进度，质量等。

（2）周例会。

（3）阶段审查与里程碑评审。

（4）事件触发的跟踪与管理。

这4个活动已经包含了模型中要求的10条实践，按照企业的实践来描述这个过程是最自然的，是项目经理最容易理解的，而不需要机械地按照模型的实践去描述。

机械照搬的根源在于缺乏软件工程的经验，不能真正理解模型的要求。在模型的构件中，只有目标是必需的，实践是期望的，子实践是解释说明的。所以首先要满足模型里每个目标的要求，目标的达成是根据实践的执行情况来判断的，模型里给出的实践是可以替换的。只要能达成目标，采用什么实践都是可以的。CMMI采用SCAMPI评估方法，评估组的成员根据专家判断给出是否达成目标的判断，是依赖于专家经验的，所以在评估方法中对评估组成员的工程经验有明确要求。对于企业来讲，只要能达成目标，就没有必要一定照搬模型。

CMMI最初的实践来源基于为美国国防部供货的软件厂商，这些软件厂商的企业规模比较大，软件项目组的人数也比较多。对于规模比较小、管理基础比较差的公司，有些实践并非一次改进就可以达成的，可能需要循序渐进地完成。

ISO组织在借鉴CMM模型起草ISO15504标准时，将软件企业的成熟度划分为了6个等级而非5个等级，实际上就是规避了CMM门槛太高的问题。CMMI本身也在逐渐更新，从CMM 1.0、CMM 1.1、CMMI 1.1、CMMI 1.2到CMMI1.3。新的成功的软件工程实践也在不断地总结出来，比如每日构建等实践，这些实践都可以充分地吸收到企业的实践里面来。

其实判断哪些实践是否适合本企业，关键在于从事过程改进工作的人，他们是否有足够的软件工程实践，能够对比较好的实践很敏感。

（3）“文档泛滥”

文档与口头交流是两种沟通的方式，文档可以减少二义性，可以永久存储，可以方便检索，可以经济地存档，可以多人共享。而口头交流具有时效性，这个时刻说的话，如果不录音，第二天就无法重现了，而且往往讲话时所处的场景信息、讲话者的语气、神态等都是对语言的含义起到了辅助作用，这些都是不可重现的。因此文档作为一种沟通的工具远比口头交流更加有效。但是任何文档都不能将所有的信息包含在里面，文档不能解决所有的沟通问题，需要辅助以口头交流，二者是互补的，文字不能替代语言，语言也不能替代文字，在软件开发的过程中尤其是这样。

SCAMPI评估方法需要企业提供两种证据：物证和人证。每条实践必须要有物证来覆盖，物证包括了产出的文档、使用的工具等；人证是在评估时通过访谈来获得的。由于物证是必需的，于是为了满足评估的需要，很多企业做了上百个文档来满足模型的要求，其实这是不对的。模型是强调证据，但是并非文档越多越好，文档只是用来证明某个实践你做到了，只要达到了这个目的就可以了，而且一个文档可以满足多条实践的要求，可以作为多条实践的证据，其实这是最经济的做法。只要内容有了，也并不一定在乎文档的多少与格式。

需要注意的是，企业的成熟度不同、软件类型不同、客户群不同，同样是CMMI 2级的企业或者同样是CMMI 3级的企业，管理的严格与细致程度差别还是很大的。CMMI的等级只是一个基本台阶，是基本要求。CMMI对证据中包括哪些内容有基本的要求，但是并没有对文档的多少进行要求，文档的多少实际上与企业管理的细致程度紧密相关。

（4）“宁严勿宽”

把握好尺度，既能满足模型的要求，又能符合企业的实践是相当有难度的。放宽底线，是一种错误；同样超出模型要求并脱离了企业实践的要求，也是错误的，都忽略了CMMI的真正的精神。究竟什么该宽，什么该严呢？其实该严的是过程改进的实际效果，而非形式效果！首先就应该从企业做过程改进的时间上严格，不能鼓励那种短期行为！SEI建议的过程改进的模型是IDEAL模型，螺旋上升式地逐步改进企业的过程。有的企业一个循环没有做完，企业的过程体系没有经过多个项目的检验就通过CMMI 3级的评估，这显然违背了客观规律，这些都应该从严处理！严，应该是内容上的严，实践上的严，而不是形式上的严。为了达到模型的要求，让企业去补一些文档，表面上是严了，实际上却违背了CMMI的精神，浪费了人力与时间！

1.3.4 CMMI成功的根本原因是什么
曾经和一位朋友沟通关于在公司内实施过程改进的心得，我介绍了几个成功案例后，她突然问了一句话：“他们成功的最重要的原因什么呢？”，我第一反应是：原因很多啊！随即，在林林总总的原因中，我找到了自认为最重要的原因：“企业文化”！随着讨论的深入，越来越意识到这个结论的正确性。

企业文化也许是一种说不清道不明的东西，但是你却能切实地感受到。有的企业从员工到领导重视质量：系统没有经过严格测试不可以发布，文档没有经过评审不能正式发布；无论是小BUG还是大BUG，在公司内都会记录并跟踪至问题的关闭；测试与评审的任务都会在计划中明确识别出来等等。而有的企业对于质量的投入能省则省，领导不会过问质量问题，即使出了质量事故也只是就事论事地批评责任人，没有从根本上找原因，企业的管理体系无法落实下去。有的企业员工勇于承担责任，勇于实践，勇于吸收，采取有价值的管理改进与技术改进。有的企业员工则推诿责任，所有的好想法都停留于口头上，领导不推，自己不动。凡此种种，这些都是企业文化的体现。

仔细回顾我的成功案例，真的是：整个企业建立了重视质量的文化，企业具有强有力的执行力，这样的企业才真的将过程改进落实到实处。

企业文化是由人建立的，企业文化是由老板建立的，老板的文化代表了企业的文化，在我看到的软件企业中大都如此。

案例：富士康科技集团的文化

富士康集团自20世纪90年代初进入大陆设厂以来，已经发展成为了全球最大的代工厂。我在给富士康集团SIDC部门咨询时，每次讲课，培训教室座无虚席，因为座位有限，EPG给每个部门分配听课的名额，每个部门的部门经理都会努力争取多要名额，有时每个部门都会多派人员参与培训，即使是站在教室的后边听课。每次做运行检查，当访谈一位员工时，部门的其他同仁如果没有紧急的事情需要处理，都会旁听，以期能够从别人的经验教训那里汲取营养。有一次有位部门主管返台度假，我无法进行当面访谈，结果该主管要求一定电话访谈，为什么呢？他希望能够帮他找到工作中的不足，能够帮他提高。从普通员工到高层主管，都用他们的言行给我传达了一个强烈的信号：“我要提高，我要改进”！我想这可能也是富士康能够快速发展的原因之一吧。

而其他一些客户表现出来的改进的热情却远远没有那么高。我曾经到深圳的一家私营企业做培训，只有寥寥数人听课，还都带了笔记本电脑不知在忙什么，现场的提问与沟通效果也很差，让我很是痛心。因为对方毕竟是花了高价请我来讲课，公司提供了帮助大家提高的机会，为什么不珍惜呢？

这便是文化的差异，文化的差异决定了企业未来的竞争实力。一个没有建立良好文化的企业不可能长久。

1.3.5 Infosys公司过程改进的18条经验
Infosys公司是印度最大的软件外包企业之一，是CMMI 5级的软件企业，其质量管理水平全球闻名。Pankaj Jalote是印度理工大学计算机科学与工程系的教授和系主任。曾经是马里兰大学计算机科学系的副教授，担任过印度班加罗尔的Infosys技术有限公司质量部门的副总裁，在Infosys公司任职期间，他是推动Infosys向CMM高成熟度等级发展的主要设计师之一。他写了2本书介绍Infosys的过程改进与项目管理的经验：《CMM实践应用（Infosys公司的软件项目执行过程）》与《软件项目管理实践》。

我基于这两本书，提取了Infosys公司进行过程改进的18条经验。

（1）设定明确的过程改进目标，每次改进的周期不宜太长。

（2）保持过程定义的简单性，使过程定义易于为项目经理、开发人员所接受。

（3）尽可能减少过程定义的变更次数。

（4）基于企业的实践定义过程，使过程易于接受，并减少培训、部署的工作量。

（5）过程改进视同为一个项目，有明确的项目计划。

（6）为每个项目组配备质量顾问，质量顾问为EPG成员，负责手把手指导项目组按体系执行。

（7）每次改进在3个月内完成体系修改与试点工作。

（8）在新项目中部署新的体系变更，正在进行中的项目采用旧的体系。

（9）对项目经理和开发人员培训公司定义的过程体系而不是CMM模型。

（10）建立EPG与项目组成员沟通的WEB网站。

（11）进行质量和CMM的周测验，给获胜者以奖励。

（12）成立管理指导组（MSG），MSG由CEO领导，高层管理人员参与，MSG每月定期开会，检查过程改进的进展情况。

（13）CEO对从事过程改进的优秀者加薪、提升和股票奖励。

（14）对高层管理者进行关于CMM的高级培训。

（15）在MSG的例会上讨论过程改进项目的风险。

（16）聘用有经验的CMM咨询顾问判断公司的实践是否符合CMM的要求。

（17）EPG负责组织定义过程，但很少由EPG本身去制定过程定义。

（18）EPG每月向其上级汇报过程改进的进展情况，每季度向公司管理委员会提交度量分析报告。