实施CMMI时必须解决的认识问题

 

在基于 CMMI 实施软件过程改善时，有些根本的思想认识问题解决不了，往往会使实施的周期比较长，效果不好，甚至导致过程改善的失败或中止。软件企业的高层领导、企业的过程改进主管、项目经理及一般的开发人员都需要对这些问题统一认识，在此基础上才能消除各方面的阻力，把握好过程改善的方向，控制好过程改善的进度。 CMMI 不是万能的，只有 CMMI 是不行的，还要技术 ( 开发方法、工具 ) 、人员二个要素一起改善。

在软件工程发展的历史进程中，人们为了解决软件危机，尝试了采用诸如形式化描述语言、结构化开发方法、 CASE 工具、构件化开发方法等等各种解决方案，但是效果并不那么显著， SEI 提出了软件过程能力成熟度模型集成（ CMMI ）基于过程的角度来解决软件 / 系统危机。那么是否实施了 CMMI ，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。 如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，才能保证带来经济效益，因为人员、技术和过程是支撑软件开发平台的三条腿，少了那一条都不行。大家也都知道木桶原理，一个木桶可存储水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术 ( 含工具、方法 ) 、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。

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

1.          管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心。

在实施 CMMI 时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显著，正如上面所述，效果显著与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。

任何的管理的改善都是符合 J 曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备，要有耐心。

2.          坚持活学活用，以我为主

机械照搬 CMMI 的条文是在实施 CMMI 时常犯的错误。在国内的软件企业中，都是从作坊式的软件组织逐步发展过来的，也没有经过系统工程化阶段，甚至也没有什么标准、规范。真正超过 10 年软件 / 系统工程经验的人员更是比较少的，加上大家不愿从事管理，因而有的企业所组建 EPG 的人员中可能在工程经验方面是有欠缺的，又没有真正的有实践经验的专家进行指导，所以对 CMMI 的理解就不可能一下就很深刻，不敢裁剪 CMMI ，容易机械照搬 CMMI 条文，其实这恰恰违背了 CMMI 的精神， CMMI 是系统工程经验的集大成，是从实践中总结出来，用以指导实践的， CMMI 本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的 MSF ，那是微软自己内部的管理过程标准，是微软的产品开发经验总结，有些内容是 CMMI 中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。

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

3.          要改良式不要革命式

以革命的方式来实施 CMMI ，期望通过一场运动来解决过程能力的问题，一种可能是不懂 CMMI ，不晓得管理的改进是循序渐进的，一种可能是明知故犯，期望在短期内通过 CMMI 评估，单纯追求市场上的轰动效应。有的企业在短时间内虽通过了 CMMI 几级评估，我想恐怕由于没有实效而得不到大家的认同而难以将这种 " 水平 " 持续下去。一个企业引入 CMMI 之后会从本质上影响企业的文化，改变大家的思想与做事方法。有人曾形象得将过程改进比喻为减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复到原来，我认为这个比喻是十分形象的。

4.          CMMI 与企业的创新文化是不矛盾的

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

软件企业必须形成创新的文化，事实 CMMI 本身也一种系统工程管理的创新，而技术创新是必须进行管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。

5.          要勇于实践，也要允许犯错误

CMMI 就是系统工程经验与教训的总结。在实施 CMMI 的过程中，肯定会走些弯路，甚至于要犯错误，由此许多人会议论纷纷，一直会反映到高层经理处，这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，现在大家都是 " 摸着石头过河 " ，不下水，是没有办法过河的，临渊慕鱼不如退而结网。要少说不，少说难，勇于实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、 SEPG 等人员有偏见，要提倡这种文化。

 

6.          管理过程改进是组织内所有人的事情，而并非仅仅是 SEPG 的事情

按照 CMMI 专家的建议，在一个组织内专职从事软件过程改善的人数应为组织总人数的 2-3% ，根据这一建议，企业内一开始就配备专职的工程过程组（ EPG ），这些员工专职负责企业的软件过程改善工作，另外我们根据需要组织一些技术任务组（ TWG ），他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题：

SEPG 成了最忙的人， TWG 的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由 SEPG 的成员替代 TWG 做工作；

企业的非开发人员对管理过程改进的效果一下没有明确地感受到，甚至看到由于加了些新的活动可能使项目拖期可能会更严重，于是他们可能就会将这些抱怨反馈到企业的高层经理，在推行过程中经常会听到：我这个项目时间太紧，当前不适合使用 CMMI ；

7.          高层经理迫于市场的压力，甚至可能会提出不合实际的项目工期等等。

推行 CMMI 不仅仅是管理人员的事情，每个人都要积极参与。要改变原来的一些做法：即 EPG 是在使劲的推进 CMMI 的工作，而不是大家自觉自愿的来实施 CMMI 。从 EPG 的角度来看，要做好培训的工作，首先要解决的大家的思想认识问题，这还是比较难的，有些人的思想还是比较顽固的。

管理首先要解决的是思想认识上的问题，不但在主观上要解决，在客观上也要有措施，光说不练是不行的，光练不说也是要否定的。曾经遇到过类似的问题，有的开发人员或者项目经理在口头上是可以接受变革的，会配合工作的，但是在具体操作，很可能又会遇到事实上的否定，这时作为 CMMI 的推广人员要尽快提出实施的具体措施，尽快落实。任何变革都要涉及到企业内的权利的再分配，不要忽视企业政治，这是客观存在的，所以一定要预防那些光说不练者。