要过程改善,不要CMMI模型
【IT168 技术文章】
1,软件工业与制造业和服务业相比远远没有成熟,需要持续进行过程改进通过改善过程的品质,来改善过程的产物的品质,是二战之后的戴明主义理论和实践的基本经验,得到了工业和服务业实践的作证。
戴明主义首先在日本生根开花,使得日本的工业品质在战后30年一跃成为世界靠前。1990年,美国的NBC访问了戴明,并发出了“If Japan Can, Why Can’t we?”的感叹。
从汽车工业和麦当劳的经验看,传统行业和服务业的过程和品质已经非常成熟,并且形成了工业工程的方法论体系。无论是麦当劳还是汽车制造,都可以达到“一致的和可预测的”品质
1914年,福特公司引入了工业流水线,初步建立了“一致的和可预测的”生产过程,使得著名的T型车的成本大大降低,不仅有钱人能够买的起车,装配线上的工人也能够买的起车了。这标志着汽车工业走向成熟。
相对而言,软件工业是非常年轻的行业,还远远没有成熟。
968年到1969的NATO(北大西洋公约组织)的会议上,学者提出软件危机和软件工程的概念标志着软件进入了工业化时代,这也意味着软件工业到现在只有不到50年的历史。
在短短50年的历史中,硬件平台从早期的主机(Main Frame)过渡到UNIX平台,到今天的PC平台;开发语言从早期的Fortran过渡到COBOL,ALGOL,到今天的C++,JAVA,并且出现了很多script语言;开发方法从早期的结构化方法,到面向对象方法,到面向框架的方法;开发过程从早期的自顶向下结构化的瀑布式过程,到原型过程,增量式过程,敏捷过程;软件的应用范围从早期的军事工业,到商业计算,到今天渗透入社会生活的各个角落的泛用计算(Ubiquitous Computing ).
可以说,软件自身技术和方法的发展是爆炸式的,软件的应用范围的扩张也是爆炸性的,社会大众对软件的期待也是爆炸性的。正因为如此, 对于如何开发软件的方法论到今天都还没有稳定:best practice不断出现,还无法达成广泛的共识;state of art不断更新,不断充实进来新的内容. IEEE和ACM联合制定的软件工程的知识体系(SWEBOK,Software Engineering Body of Knowledge)还无法获得一致的认可。
软件行业还远远没有进入稳定和成熟的阶段。正如同CMM模型是TQM模型在软件行业上的映射,软将行业必须通过过程的改善来建立“一致的和可预测的”软件生产过程,提高软件品质,尽快使得软件行业进入稳定和成熟的阶段。
但是,软件工业与制造业和服务业又存在明显的区别,使得软件行业的过程改善具有显著不同的特征。
软件工业与传统工业相比,最大的差异是:传统工业是围绕机器,人处于辅助位置;软件工业是围绕人,机器处于辅助位置。
在制造业中,只要建立起来机器系统,那么在必备的能源,润滑,温度控制的维护下,机器就可以24小时连续运转,甚至可以达到无人值守的状态。简单的说,机器是可靠的,不受时间,空间和外界环境的影响。
而在软件工业中,不同人的差别是很大的;即使同样的人在不同的时间,空间和外在环境的影响下,会表现出完全不同的能力。同时,人不能长时间连续工作,需要休息和恢复,否则工作效率会降低;简单的说,人是不可靠的。因为人是不可靠的,必须通过团队的力量,借助流程的控制,来及时发现和弥补个人工作中的失误和错误。
在制造业中,制造流程的改进依靠机器,只需要修改一下生产线的流程,机器就自动按照新的流程执行了,是“知难行易”。而在软件行业中,过程的改进要靠人,每个具体的措施的执行也是靠人,不同人的差别是很大的,人是有独立的判断和行为方式的,期待SEPG制定一些新制度的流程,然后制度就可以顺利被执行,这样的事情没有,是“知易行难”。
伟大的杜鲁克说二战之后,很多工作都变为知识工作,不再直接创造具体的产物。Humphrey在SEPGChina2007上说软件工业是第一个知识工业。由于知识工业与传统工业的差别,使得知识工业通过过程改善来提高品质的努力更加困难和复杂化。
2,过程改善不只是CMMI,形式上通过CMMI级别没有什么意义。
首先,我觉得最需澄清的是:
1)软件过程改善(SPI,Software Process Improvement)是只是软件方法学(软件工程)的一个领域;除了过程改善之外,软件方法学还有很多其他重要领域,比如系统工程,质量工程等(详细请看IEEE和ACM联合编写的SWBOK)。
2)在过程改善领域,CMMI模型只是众多过程改善模型中的一个;除了CMMI模型之外,软件过程改善还有很多其他模型,比如Basili教授的GQM(Goal Question Metric)模型,SPICE模型,EFQM,TickIT等。
但是,很不幸的是,中国的政府和企业现在倾向于将软件方法学(软件工程)等价于过程改善,将过程改善等价于CMMI,将CMMI等价于Humphrey(实际上Humphrey与CMMI毫无关系)。
软件方法学包含很多领域,在每个领域中都包含大量的经验,knowhow,practice,以及为之奋斗的专家。比如在估算领域中最先提出COCOMO模型的Barry,在同行评审领域最先提出实证数据的Fagan,在度量领域的实践者Capers Jones,活跃在思想界的Weinberg,最先提出螺旋式开发过程模式的Boehm,永远热情洋溢的真正的咨询师Tom Glib。
这些耀眼的明星在不同领域奠基了软件方法学的基础,并且依然活跃在世界各地,为软件方法学的完善分享和贡献自己的思想和实践。
由于软件方法学还没有完善,对于众多缺乏经验的企业而言,面对众多的理论和实践,无所适从,不知道如何运用这些方法学。CMM/CMMI模型应运而生。
CMMI的价值在于根据大量业界的实践经验,特别是以IBM为代表的传统公司的经验,向缺乏经验的软件公司提供了一个分阶段导入软件方法学理论和实践的过程改进的路线图,即从一级到五级的改善路线图。
CMMI模型期待软件企业首先建立基本的项目管理过程(CMMI二级),然后统一化为组织范围的标准过程(CMMI三级),然后进行定量化的记录和控制(CMMI四级),并再次基础上进行持续和长期的改善(CMMI五级)。这样的story对于众多迷茫的企业当然是非常有效的,无意是指明了努力的方向。
但是如果教条地听信CMMI模型,而完全放弃了自身的理解和辨别的话,同样是非常危险的事情。因为CMMI模型并没有考虑到各个企业的实际情况,提供了一个统一的路线图,事实上,我们无法想象全世界的所有软件企业都来遵循同样的过程改善流程,试图成为一个模子出来的企业。
CMMI只是众多模型中的一个而已。CMMI模型在美国远远没有在中国和印度这样流行,甚至在欧洲和日本也没有被如此追捧,那里的企业还是“因循守旧”地在搞ISO9001。
ISO9001是国际化的品质标准,同样可以运用到软件行业,特别是ISO9001:2000版本进行了适当的改善。可是鉴于ISO9001在国内的恶名,人们已经不再信任ISO9001能够提高软件品质了。可是,CMMI不正像十年前的ISO9001么?或许不久也会有同样的恶名呢?
Basili教授的GQM(Goal,Question,Metric)模型在北美是一个经常拿来与CMMI模型相比教的模型。GQM模型提供了一个普遍的方法轮,每个企业根据自己的实际情况,确定自己的目标,定位为达到目标需要解决的问题,针对问题提出度量的方法,在此基础上进行改善。
有一句非常有名的话:所有模型都是错误的,只有部分是正确的(all models are wrong, some models are right)。也就是说,我们不能100%地将自己企业的未来和命运托付给某个咨询公司和某个模型,然后就安心地等待奇迹发生。
CMMI是Humphrey的知识汇集,主要是IBM的知识汇集,特别是IBM大型机的知识汇集。全世界CMMI5级的公司很多,并不是每个企业都能提供优秀的产品,都是市场的领先者;相反全世界优秀的公司很多,几乎没有几家是CMMI5的。
CMMI模型被批判的最大不足之处,忽视了市场交付压力和竞争对手的压力。CMMI模型原本是美国国防部在外包军事软件的时候,对于承接单位能力的评判,然后逐步推广到民间企业中来。
很显然,国防部的软件的交付日期是不会经常变动的,国防部是没有很多竞争对手的,需求是稳定的,因而承接国防部软件开发的企业自然不需要考虑市场交付压力,不需要考虑市场需求的变化,不需要考虑竞争对手突然提前推出产品等因素。
而在实际的竞争环境中,这些都是不得不考虑的。很多时候,市场用户需要的不是最高品质的产品,而是最快交付的,提供了有吸引力功能的“质量尚可”的产品。
马克思同样为人们提供了一个历史发展的模型,姑且不论这个模型本身是否准确。但是不同的国家在引入这个模型的时候,必须也必然会根据自身的国情进行必要的修正。比如列宁对俄国十月革命和帝国主义理论的解释,中国对中国特色革命路线和社会主义建设路线的解释等。
我们可以退一步假想,政府和企业从众多模型中选择了CMMI模型作为公司过程改善的模型。
CMMI只说明了what to do,没有说明how to do,更没有说明why should we do?即:CMMI本身并不包含具体的软件方法学,不能帮助企业理解各个具体的方法学。
比如CMMI需要进行同行评审,但是并没有告诉你如何才能获得有效的评审。这就需要具体的评审方法学的知识。CMMI也没有告诉我们为什么同行评审很重要,这就需要我们自己去首先寻找行业的实践和数据,然后建立我们实践的方法,遵循“组织创新”的原则,逐步导入这样的方法,并进行必要的培训和效果的评估。
我觉得如果不是为了CMMI的虚名,不如自己进行方法论的学习,根据自身的实际情况,进行扎实的过程改善。我们根据企业的实际情况,不一定需要按照CMMI模型的级别设定的内容进行改善。比如:难道我们非要建立了管理过程之后,才需要考虑组织统一的培训么?难道我们非要建立标准的组织过程之后,才能导入定量管理么?难道我们非要定量管理之后,才能进行根本原因分析和组织创新么?
具体的企业有具体的开发领域,开发文化和市场背景,与其刻板地按照CMMI模型的要求来改善,不如秉承“拿来主义”,挑选自己认为有价值的内容进行改善。
这就涉及到人员能力的培养,要培养优秀的过程改进人员,要培养过程改进人员的软件方法学的理论和知识;要培养软件过程改进人员的分析和判断能力。
形式上通过CMMI不是很困难的事情,因为CMMI中提供了很多practice的例子,照猫画虎,再加上咨询公司提供的模板集合,就可以在纸面上通过各级评估了;但是理解CMMI中的knowhow和根植这些knowhow是需要时间的。
如同驾校考试一样,短期突击通过考试拿到驾照是可以的,但是如果不练习,就只是paper driver。不仅企业是paper driver,甚至指导企业的很多咨询公司都是paper licenser,因为咨询公司的年轻的咨询师们自身并没有足够的软件开发经验,他们也只是从CMMI的paper上来学习这些理论,学习这些模板,然后再照猫画虎地传授给企业。这让我感觉到咨询业的通病:外行人教内行人。
当然,我们也不必妄自菲薄,似乎全世界的咨询公司都是这样的。