UML软件工程组织

 

 

要过程改善,不要CMMI模型
 
2008-05-29 作者: 蔡志旻 来源: 网络
 

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上来学习这些理论,学习这些模板,然后再照猫画虎地传授给企业。这让我感觉到咨询业的通病:外行人教内行人。

当然,我们也不必妄自菲薄,似乎全世界的咨询公司都是这样的。

3.CMMI不是中印软件差距的根源;抓住自身优势,进行开发实践积累和内在的全面改善是企业的致胜之策

印度导入了CMM模型,并且在世界上占据了最多的CMM5的企业。随即在国务院的首先倡导下,中国各级开始了大力支持企业导入CMM/CMMI模型进行过程改善,并提供高额的资金补助。

可是,按照CMMI模型的设想,导入CMMI进行过程改善,是可以提高品质降低成本的,是有受益的。既然有受益,为什么企业还需要政府的资助?这几年看来,基本上,市场的敲门砖成为一些中等以上公司的需求,赚政府补贴是一些小公司的需求,追求品质是很少一部分公司的需求。

政府谈软件必谈软件外包,接着就是中国软件不如印度。那我们就来仔细对比一下中印的软件差距。首先,中国的软件产业并不比印度差。中国国内的软件市场要远远大于印度市场,唯一差的是软件外包出口。可是,软件外包出口差的首要原因不是品质和过程不行,而是起步早,语言好,经验多。

首先,印度软件起步早。印度的软件起步是在90年代初期,特别是在解决“千年虫问题”上,印度人为全世界做出了贡献。千年虫问题的解决方法现在想想其实很简单,相当于是reverse Engineering,阅读代码,寻找出与时间定义相关的代码,并修改定义;然后进行全面的回归测试。软件业的一个不可思议但是很普遍的现象是:软件开发的文档实际上是不完备或者与实际代码不一致。因此很多时候所谓的reverse engineering就是靠直接看代码来找bug。这可是无聊的活,美国人不愿意干,全部交给印度人干了。印度人兢兢业业地看代码,修改,测试,也就开始了印度和美国软件业合作的起源。

而当时中国在干什么?我记得非常清楚的是,中国的媒体一方面在使用非常浅显的词汇来让大家理解千年虫的含义,一方面在展开各种奇妙的想象,万一发生千年虫问题,世界会变成什么样。可是,没有一个媒体在问:我们该怎么办。当然在同时,中国开始了世界历史上最大规模的纺织业等初级制造业的外包转移,成为世界工厂。

因此,印度的软件产业起步领先中国十年,并因此积累了开发经验和市场渠道。随着经验的积累,品质和过程的改善和标准化会自然成为内在的动力。经验是要靠时间的,品质改善是靠内在需求的,而不是靠CMMI。

就如同人的成长需要时间,拔苗助长,贴成人标签是没有用的。中国现在的CMMI已经是世界第二多,但是软件行业和印度的差距仍然是那么多。我们需要的是时间和经验,不是CMMI资格。

其次,印度人语言好。我们在说软件外包的时候,通常都以为是在说软件开发,实际上软件外包涵盖的概念太广泛了,远远不局限于软件开发,包括了整个IT软件和服务的各个环节。

我们来看看印度面向北美的IT软件和服务产业。

比如呼叫中心(Call Center)负责解决客户投诉和技术支持的。美国有一些大公司为了节省成本,将呼叫中心转移到印度,培训一下当地技术人员的英语口音,尽量像一些北美的通用口音,就可以接电话了,而北美的消费者完全不知道接电话的人实际上人在遥远的印度。

在上海的微软全球技术支持中心,在某种意义上就是这样的呼叫中心,却因为高薪(相对于美国就成了毫无趣味的低薪工作)戏剧化地吸引了中国很多很有天分的软件工程师。

再比如BPO(Business Process Outsourcing),将业务流程的某个环节外包。比如印度某著名IT公司帮助美国高盛公司进行数据维护,将每天美国交易的数据在后台进行统计,分类,计算,备份等处理,这样美国人就需要每天晚上紧张地处理数据,并在天亮之前提供报表给第二天的交易员了。

最近的例子是,英国中小学期末考试,英国人居然也外包给印度人去批改,统计,排序,汇总,实在是做到了极至。

这里面很多工作是存在语言的壁垒的,是和CMMI的级别没有关系的。中国无论怎么努力,无论过程多么完美,都无法赶上印度的。中国人的英语后天再努力,我估计也很难达到为能北美人解决售后问题的程度;同样英国人也不会放心把中小学生的作文题交给中国人批改的。

相反,由于东亚语言的相近,现在中国出现了很多面向日本的呼叫中心和BPO业务,因为同样的理由,中日的语言太相近,文化也太相近了。

印度的公司说他们很多的工作实际上是“Body Shopping”,即基本上是代替了美国的一些低薪的IT服务业工作。由于互联网的存在,使得全世界成为一个平坦的村落(The World Is Flat),使得很多工作可以通过互联网传递到世界的任何角落去完成。

十年的不同道路的发展,印度人占据了IT软件和服务业的领先地位,中国人占据了服装和鞋帽等初级制造业的领先地位。中国到今天也没有产生世界级的服装设计和品牌一样,印度到今天也没有产生世界级的独立软件产品(Packaged Software)。

印度公司在90年代为了“吹嘘”自己的实力,比美国更早更积极地导入CMM模型,使得通过CMM5的公司比美国还多。可是,这意味这印度的软件实力超过了美国了么?当然不是。中国现在大干快上,浑水摸鱼地搞CMMI,很快CMMI5的数量就要超过印度了,可是我们之间的差距很快就没有了么?当然不是。

最后,因为经验积累多了,为了进一步的竞争力,印度人在经历了上述价值链低端的工作后,开始向高端前进,比如直接为最终客户提供开发大型的应用系统,构建自己独立的软件产品和解决方案等。就如同,中国的纺织业从单纯代工开始过渡到了面料设计,样式设计,品牌经营的阶段一样。

中国的华为等公司已经是在价值链高端占据了一席之地的优秀企业了,又为何一定要将中国的软件前途等同于印度的IT服务呢?华为的5万员工创造的销售额要好几倍于Infosys的5万员工。我们为何对此视而不见呢?

与其用我们的弱点去和别人的强项竞争,不如换一条道路,多多发挥我们的强项。比如,我们可以着力于产品开发,这个是对语言依赖最低的工作内容。

软件外包就不是软件行业的唯一领域,软件外包也无法支撑起中国信息业发展的脊梁。研发外包是分享不到商业利润的。就如同制造业外包给中国一样。与其多一个infosys,还不如多一个huawei。

对于面向市场进行真刀真枪竞争的技术型公司而言,基本的项目管理(二级)是最重要的,其次是三级,四级和五级依次递减。这也是非常符合通常的边界效益递减的原则。

过于强调过程,会使得过程刻板化,将创造性的软件开发工程庸俗化为机械性的事务性工作。理论上,建筑工人对建筑规则和过程的遵守似乎是远远高于软件行业的软件工程师的。如果过程真的那么神奇的话,何不让建筑工人来从事软件开发,或许更能胜任呢?

与过程相比,优秀的人才是更加重要的要素。二级的过程加上五级的人才肯定会战胜五级的过程和二级的人才。Humphrey搞了CMM之后,发现人的重要性,又搞起了People CMM,后来自己一个人搞PSP和TSP,也就是说如果不把执行过程的人训练好,再好的过程也是无法实施的。

有些人说中国的工程师喜欢用指针等技术高但是容易错的功能,印度的工程师用数组这样技术低不容易错的功能。很可惜,在我的工作经历中,没有发现这样的差别。即使有一些使用方法的差别,与其说是CMM的结果,不如说是经验和习惯的结果。而这是所有行业都面临的。

十年前中国和印度在不同的方向上开始起步。到了今天,中国可以有一万人的纺织工场,印度无法有这样的工场;同样,印度可以有一万人的软件工场,而中国无法有这样的软件工场。

中国和印度的软件出口差距不是能力而是经验和时间。再过十年,印度会有一万人的纺织工场,中国也会有一万人的软件工场。在十年前中国遍地都是几十个人的软件工场,中国数千人的软件工场已经开始出现了。这不是主要因为CMM,而是因为经验的积累。CMM作为一个外在因素,起到了一定的促进作用,但不是决定因素。

4,第一轮的热潮之后

所谓历史都是相似的。印度在90年代同样产生了CMM的热潮,大家纷纷将CMM作为竞争手段。很快大家都是CMM5级了,竞争什么呢?于是再找模型,比如People-CMM,ITIL,six sigma等等。

从2000年开始的CMM和CMMI热潮,在政府补助金的推波助澜之下,第一轮的CMMI热潮迅速沸腾起来。

第一轮的热潮的价值并不会真正带来软件过程的改善和软件品质的提高,而是普及了软件方法学的知识,让人们普遍达成共识:品质很重要,并且品质是可以通过过程来改善的。

改善品质的动力来自何处?

商品短缺的时代,商家和市场首先考虑的是商品是否充足,不是品质;只有进入商品过剩时代,品质才可能成为商家和市场首先考虑的课题之一。

没有实际问题的发生,人们是不会重视品质的。

Crosby说Quality Is Free,这是说由于低质导致的损失超过了强化品质的成本,因此要“第一次就把事情做对”(Do Things Right The First Time)。可是,如果低质并没有损失呢?如果客户不关心品质,而关心交付日期,功能创新呢?

因为食品问题死了人,毒害死了世界人民的猫狗,在地球村里丢了人,没人买我们的食品了,所以我们才会真正重视食品的品质。因为饺子吃了发现有毒,却找不到下毒的环节,人们才开始重视过程。

由于品质问题的产生,中国很多制造行业开始进入了品质竞争的时代。

那么,中国的软件产业真正进入了需要以品质为前提进行竞争的时代了么?在某些关键行业,比如电信,电力,银行,证券等,由于软件系统支撑着人们的日常生活的每个环节,品质成为了不可忽视的要素;但是在其他行业,比如在线服务,在线游戏等,或许还要等等。

大家意识到品质确实很重要之后,然后开始挽起袖子,真正地开始改善品质。大家会重新翻开CMMI的书籍,审视软件工程方法学的各个具体领域,摒弃那些表面无用的模板和规章,制定真正适合自己的开发流程和控制手段。

品质就像走钢丝,要时刻小心;可是,有时即使很小心了,也会掉下来。按照Cusumano的结论,日本企业的品质是世界级别的,是美国的十倍。可是即使这么小心,在2006年的时候,东京证券交易系统还是意外死机了。

CMMI是软件工程知识的整理。软件工程课程是大学计算机系的主要课程,大学没有认真学,现在再来重新学习一遍,就认真了么?郑人杰老师在80年代就翻译了Myers的《软件测试技术》,每本只卖2角钱。可是那个时候我们连什么是软件都不知道,更不要说在实际工作中进行软件测试了。

我们缺的不是知识,缺的是实践。

去他的,什么CMMI模型,什么CMMI级别。

让我们开始真正的软件过程改善吧。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号