实施CMMI必须解决的3个问题

在软件工程发展的历史进程中,人们为了解决软件危机,尝试了采用诸如形式化描述语言､结构化开发方法､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之后会从本质上影响企业的文化,改变大家的思想与做事方法｡有人曾形象得将过程改进比喻为减肥,你是可以依靠减肥药在短时间内减轻体重,但如果不从根本上改善饮食､生活､运动的习惯,那么体重将会在短时间内恢复到原来,我认为这个比喻是十分形象的｡