要过程改善,不要CMMI模型.doc
要过程改善,不要 CMMI 模型 蔡志旻南京富士通南大软件技术有限公司 富士通(中国)有限公司 1,软件工业与制造业和服务业相比远远没有成熟,需要持续进行过程改进通过改善过程的品质,来改善过程的产物的品质,是二战之后的戴明主义理论和实践的基本经验,得到了工业和服务业实践的作证。 戴明主义首先在日本生根开花,使得日本的工业品质在战后 30 年一跃成为世界第一。 1990 年,美国的 NBC 访问了戴明,并发出了“ IfJapanCan, WhyCan’ twe?”的感叹。 从汽车工业和麦当劳的经验看,传统行业和服务业的过程和品质已经非常成熟,并且形成了工业工程 的方法论体系。无论是麦当劳还是汽车制造,都可以达到“一致的和可预测的”品质。 1914年,福特公司引入了工业流水线,初步建立了“一致的和可预测的”生产过程,使得著名的 T 型车的成本大大降低,不仅有钱人能够买的起车,装配线上的工人也能够买的起车了。这标志着汽车工业走向成熟。 相对而言,软件工业是非常年轻的行业,还远远没有成熟。 1968 年到 1969 的 NATO(北大西洋公约组织)的会议上,学者提出软件危机和软件工程的概念标志着软件进入了工业化时代,这也意味着软件工业到现在只有不到 50 年的历史。 在短短 50 年的历史 中,硬件平台从早期的主机( MainFrame)过渡到 UNIX 平台 ,到今天的 PC 平台;开发语言从早期的 Fortran 过渡到 COBOL, ALGOL,到今天的 C++,JAVA,并且出现了很多script 语言;开发方法从早期的结构化方法 ,到面向对象方法 ,到面向框架的方法;开发过程从早期的自顶向下结构化的瀑布式过程,到原型过程,增量式过程,敏捷过程;软件的应用范围从早期的军事工业 ,到商业计算 ,到今天渗透入社会生活的各个角落的泛用计算( UbiquitousComputing) . 可以说,软件自身技术和方法的发展是爆炸式 的,软件的应用范围的扩张也是爆炸性的,社会大众对软件的期待也是爆炸性的。正因为如此 ,对于如何开发软件的方法论到今天都还没有稳定: bestpractice 不断出现 ,还无法达成广泛的共识; stateofart 不断更新 ,不断充实进来新的内容 .IEEE 和 ACM 联合制定的软件工程的知识体系( SWEBOK,SoftwareEngineeringBodyofKnowledge)还无法获得一致的认可。 软件行业还远远没有进入稳定和成熟的阶段。正如同 CMM 模型是 TQM 模型在软件行业上的映射,软将行业必须通过过程的改善来建立“ 一致的和可预测的”软件生产过程,提高软件品质,尽快使得软件行业进入稳定和成熟的阶段。 但是,软件工业与制造业和服务业又存在明显的区别,使得软件行业的过程改善具有显著不同的特征。 软件工业与传统工业相比,最大的差异是:传统工业是围绕机器,人处于辅助位置;软件工业是围绕人,机器处于辅助位置。 在制造业中,只要建立起来机器系统,那么在必备的能源,润滑,温度控制的维护下,机器就可以 24 小时连续运转,甚至可以达到无人值守的状态。简单的说,机器是可靠的,不受时间,空间和外界环境的影响。 而在软件工业中,不同人的差别是很 大的;即使同样的人在不同的时间,空间和外在环境的影响下,会表现出完全不同的能力。同时,人不能长时间连续工作,需要休息和恢复,否则工作效率会降低;简单的说,人是不可靠的。因为人是不可靠的,必须通过团队的力量,借助流程的控制,来及时发现和弥补个人工作中的失误和错误。 在制造业中,制造流程的改进依靠机器,只需要修改一下生产线的流程,机器就自动按照新的流程执行了,是“知难行易”。而在软件行业中,过程的改进要靠人,每个具体的措施的执行也是靠人,不同人的差别是很大的,人是有独立的判断和行为方式的,期待 SEPG 制定一些新 制度的流程,然后制度就可以顺利被执行,这样的事情没有,是“知易行难”。伟大的杜鲁克说二战之后,很多工作都变为知识工作,不再直接创造具体的产物。 Humphrey 在 SEPGChina2007 上说软件工业是第一个知识工业。由于知识工业与传统工业的差别,使得知识工业通过过程改善来提高品质的努力更加困难和复杂化。 2,过程改善不只是 CMMI,形式上通过 CMMI 级别没有什么意义。 首 先 , 我 觉 得 最 需 澄 清 的 是 : 1 ) 软 件 过 程 改 善 ( SPI ,SoftwareProcessImprovement)是只是软件方法学(软件工程)的一 个领域;除了过程改善之外,软件方法学还有很多其他重要领域,比如系统工程,质量工程等(详细请看 IEEE 和 ACM 联合编写的 SWBOK)。 2)在过程改善领域, CMMI 模型只是众多过程改善模型中的一个;除了 CMMI 模型之外,软件过程改善还有很多其他模型,比如 Basili 教授的 GQM( GoalQuestionMetric)模型, SPICE 模型,EFQM, TickIT 等。 但是,很不幸的是,中国的政府和企业现在倾向于将软件方法学(软件工程)等价于过程改善,将过程改善等价于 CMMI,将 CMMI 等价于Humphrey(实 际上 Humphrey 与 CMMI 毫无关系)。 软件方法学包含很多领域,在每个领域中都包含大量的经验, knowhow, practice,以及为之奋斗的专家。比如在估算领域中最先提出 COCOMO 模型的 Barry,在同行评审领域最先提出实证数据的 Fagan,在度量领域的实践者 CapersJones,活跃在思想界的 Weinberg,最先提出螺旋式开发过程模式的 Boehm,永远热情洋溢的真正的咨询师 TomGlib。 这些耀眼的明星在不同领域奠基了软件方法学的基础,并且依然活跃在世界各地,为软件方法学的完善分享和贡献自己 的思想和实践。 由于软件方法学还没有完善,对于众多缺乏经验的企业而言,面对众多的理论和实践,无所适从,不知道如何运用这些方法学。 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 模型提供了一个普遍的方法轮,每个企业根据自己的实际情况,确定自己的目标,定位 为达到目标需要解决的问题,针对问题提出度量的方法,在此基础上进行改善。 有一句非常有名的话:所有模型都是错误的,只有部分是正确的( allmodelsarewrong,somemodelsareright)。也就是说,我们不能 100%地将自己企业的未来和命运托付给某个咨询公司和某个模型,然后就安心地等待奇迹发生。 CMMI 是 Humphrey 的知识汇集,主要是 IBM的知识汇集,特别是 IBM 大型机的知识汇集。全世界 CMMI5 级的公司很多,并不是每个企业都能提供优秀的产品,都是市场的领先者;相反全世界优秀的公司很多, 几乎没有几家是 CMMI5 的。 CMMI 模型被批判的最大不足之处,忽视了市场交付压力和竞争对手的压力。 CMMI 模型原本是美国国防部在外包军事软件的时候,对于承接单位能力的评判,然后逐步推广到民间企业中来。 很显然,国防部的软件的交付日期是不会经常变动的,国防部是没有很多竞争对手的,需求是稳定的,因而承接国防部软件开发的企业自然不需要考虑市场交付压力,不需要考虑市场需求的变化,不需要考虑竞争对手突然提前推出产品等因素。 而在实际的竞争环境中,这些都是不得不考虑的。很多时候,市场用户需要的不是最高品质的产品,而是 最快交付的,提供了有吸引力功能的“质量尚可”的产品。 马克思同样为人们提供了一个历史发展的模型,姑且不论这个模型本身是否准确。但是不同的国家在引入这个模型的时候,必须也必然会根据自身的国情进行必要的修正。比如列宁对俄国十月革命和帝国主义理论的解释,中国对中国特色革命路线和社会主义建设路线的解释等。 我们可以退一步假想,政府和企业从众多模型中选择了 CMMI 模型作为公司过程改善的模型。 CMMI 只说明了 whattodo,没有说明 howtodo,更没有说明 whyshouldwedo?即: CMMI 本身并不包含具体的软件方法学,不能帮助企业理解各个具体的方法学。 比如 CMMI 需要进行同行评审,但是并没有告诉你如何才能获得有效的评审。这就需要具体的评审方法学的知识。 CMMI 也没有告诉我们为什么同行评审很重要,这就需要我们自己去首先寻找行业的实践和数据,然后建立我们实践的方法,遵循“组织创新”的原则,逐步导入这样的方法,并进行必要的培训和效果的评估。 我觉得如果不是为了CMMI 的虚名,不如自己进行方法论的学习,根据自身的实际情况,进行扎实的过程改善。我们根据企业的实际情况,不一定需要按照 CMMI 模型的级别设定的内容进行改善 。比如:难道我们非要建立了管理过程之后,才需要考虑组织统一的培训么?难道我们非要建立标准的组织过程之后,才能导入定量管理么?难道我们非要定量管理之后,才能进行根本原因分析和组织创新么? 具体的企业有具体的开发领域,开发文化和市场背景,与其刻板地按照 CMMI 模型的要求来改善,不如秉承“拿来主义”,挑选自己认为有价值的内容进行改善。 这就涉及到人员能力的培养,要培养优秀的过程改进人员,要培养过程改进人员的软件方法学的理论和知识;要培养软件过程改进人员的分析和判断能力。 形式上通过CMMI 不是很困难的事情,因为 CMMI 中提供了很多 practice 的例子,照猫画虎,再加上咨询公司提供的模板集合,就可以在纸面上通过各级评估了;但是理解CMMI 中的 knowhow 和根植这些 knowhow 是需要时间的。 如同驾校考试一样,短期突击通过考试拿到驾照是可以的,但是如果不练习,就只是 paperdriver。不仅企业是 paperdriver,甚至指导企业的很多咨询公司都是 paperlicenser,因为咨询公司的年轻的咨询师们自身并没有足够的软件开发经验,他们也只是从CMMI 的 paper 上来学习这些理论,学习这些模板,然后再照猫画虎 地传授给企业。这让我感觉到咨询业的通病:外行人教内行人。 当然,我们也不必妄自菲薄,似乎全世界的咨询公司都是这样的。 3. CMMI 不是中印软件差距的根源;抓住自身优势,进行开发实践积累和内在的全面改善是企业的致胜之策同样,我觉得政府在谈论软件产业的时候,有两个误区: 1)政府谈软件必然软件外包; 2)中国软件不如印度,原因是我们没有“国际通行”的 CMMI 级别; 从几年前开始,政府反思中国软件业与印度的差距。很不幸的是,政府主要的结论是:印度导入了 CMM 模型,并且在世界上占据了最多的 CMM5 的企业。随即在国务 院的首先倡导下,中国各级开始了大力支持企业导入 CMM/CMMI 模型进行过程改善,并提供高额的资金补助。 可是,按照 CMMI 模型的设想,导入 CMMI 进行过程改善,是可以提高品质降低成本的,是有受益的。既然有受益,为什么企业还需要政府的资助?这几年看来,基本上,市场的敲门砖成为一些中等以上公司的需求,赚政府补贴是一些小公司的需求,追求品质是很少一部分公司的需求。 政府谈软件必谈软件外包,接着就是中国软件不如印度。那我们就来仔细对比一下中印的软件差距。首先,中国的软件产业并不比印度差。中国国内的软件市场要远远大于 印度市场,唯一差的是软件外包出口。可是,软件外包出口差的首要原因不是品质和过程不行,而是起步早,语言好,经验多。 首先,印度软件起步早。印度的软件起步是在 90 年代初期,特别是在解决“千年虫问题”上,印度人为全世界做出了贡献。千年虫问题的解决方法现在想想其实很简单,相当于是reverseEngineering,阅读代码,寻找出与时间定义相关的代码,并修改定义;然后进行全面的回归测试。软件业的一个不可思议但是很普遍的现象是:软件开发的文档实际上是不完备或者与实际代码不一致。因此很多时候所谓的reverseengineering 就是靠直接看代码来找 bug。这可是无聊的活,美国人不愿意干,全部交给印度人干了。印度人兢兢业业地看代码,修改,测试,也就开始了印度和美国软件业合作的起源。 而当时中国在干什么?我记得非常清楚的是,中国的媒体一方面在使用非常浅显的词汇来让大家理解千年虫的含义,一方面在展开各种奇妙的想象,万一发生千年虫问题,世界会变成什么样。可是,没有一个媒体在问:我们该怎么办。当然在同时,中国开始了世界历史上最大规模的纺织业等初级制造业的外包转移,成为世界工厂。 因此,印度的软件产业起步领先中国十年,并因此积 累了开发经验和市场渠道。随着经验的积累,品质和过程的改善和标准化会自然成为内在的动力。经验是要靠时间的,品质改善是靠内在需求的,而不是靠 CMMI。 就如同人的成长需要时间,拔苗助长,贴成人标签是没有用的。中国现在的 CMMI 已经是世界第二多,但是软件行业和印度的差距仍然是那么多。我们需要的是时间和经验,不是 CMMI 资格。 其次,印度人语言好。我们在说软件外包的时候,通常都以为是在说软件开发,实际上软件外包涵盖的概念太广泛了,远远不局限于软件开发,包括了整个 IT 软件和服务的各个环节。 我们来看看印度面向北美的 IT 软件和服务产业。 比如呼叫中心( CallCenter)负责解决客户投诉和技术支持的。美国有一些大公司为了节省成本,将呼叫中心转移到印度,培训一下当地技术人员的英语口音,尽量像一些北美的通用口音,就可以接电话了,而北美的消费者完全不知道接电话的人实际上人在遥远的印度。 在上海的微软全球技术支持中心,在某种意义上就是这样的呼叫中心,却因为高薪(相对于美国就成了毫无趣味的低薪工作)戏剧化地吸引了中国很多很有天分的软件工程师。 再比如 BPO( BusinessProcessOutsourcing),将业务流程的某个 环节外包。比如印度某著名 IT 公司帮助美国高盛公司进行数据维护,将每天美国交易的数据在后台进行统计,分类,计算,备份等处理,这样美国人就需要每天晚上紧张地处理数据,并在天亮之前提供报表给第二天的交易员了。 最近的例子是,英国中小学期末考试,英国人居然也外包给印度人去批改,统计,排序,汇总,实在是做到了极至。 这里面很多工作是存在语言的壁垒的,是和CMMI 的级别没有关系的。中国无论怎么努力,无论过程多么完美,都无法赶上印度的。中国人的英语后天再努力,我估计也很难达到为能北美人解决售后问题的程度;同样英国人也不会 放心把中小学生的作文题交给中国人批改的。相反,由于东亚语言的相近,现在中国出现了很多面向日本的呼叫中心和 BPO 业务,因为同样的理由,中日的语言太相近,文化也太相近了。 印度的公司说他们很多的工作实际上是“ BodyShopping”,即基本上是代替了美国的一些低薪的 IT 服务 业 工 作 。 由 于 互 联 网 的 存 在 , 使 得 全 世 界 成 为 一 个 平 坦 的 村 落( TheWorldIsFlat),使得很多工作可以通过互联网传递到世界的任何角落去完成。 十年的不同道路的发展,印度人占据了 IT 软件和服务业的领先地位,中国人占据了服装和鞋帽等初级制造业 的领先地位。中国到今天也没有产生世界级的服装设计和品牌一样,印度到今天也没有产生世界级的独立软件产品( PackagedSoftware)。 印度公司在 90 年代为了“吹嘘”自己的实力,比美国更早更积极地导入 CMM 模型,使得通过 CMM5 的公司比美国还多。可是,这意味这印度的软件实力超过了美国了么?当然不是。中国现在大干快上,浑水摸鱼地搞 CMMI,很快 CMMI5 的数量就要超过印度了,可是我们之间的差距很快就没有了么?当然不是。 最后,因为经验积累多了,为了进一步的竞争力,印度人在经历了上述价值链低端的工作后,开始 向高端前进,比如直接为最终客户提供开发大型的应用系统,构建自己独立的软件产品和解决方案等。就如同,中国的纺织业从单纯代工开始过渡到了面料设计,样式设计,品牌经营的阶段一样。 中国的华为等公司已经是在价值链高端占据了一席之地的优秀企业了,又为何一定要将中国的软件前途等同于印度的 IT 服务呢?华为的 5 万员工创造的销售额要好几倍于 Infosys 的 5 万员工。我们为何对此视而不见呢? 与其用我们的弱点去和别人的强项竞争,不如换一条道路,多多发挥我们的强项。比如,我们可以着力于产品开发,这个是对语言依赖最低的工作内容。 软件外包就不是软件行业的唯一领域,软件外包也无法支撑起中国信息业发展的脊梁。研发外包是分享不到商业利润的。就如同制造业外包给中国一样。与其多一个 infosys,还不如多一个 huawei。 对于面向市场进行真刀真枪竞争的技术型公司而言,基本的项目管理(二级)是最重要的,其次是三级,四级和五级依次递减。这也是非常符合通常的边界效益递减的原则。 过于强调过程,会使得过程刻板化,将创造性的软件开发工程庸俗化为机械性的事务性工作。理论上,建筑工人对建筑规则和过程的遵守似乎是远远高于软件行业的软件工程师的。如果过程真的 那么神奇的话,何不让建筑工人来从事软件开发,或许更能胜任呢? 与过程相比,优秀的人才是更加重要的要素。二级的过程加上五级的人才肯定会战胜五级的过程和二级的人才。 Humphrey 搞了 CMM 之后,发现人的重要性,又搞起了 PeopleCMM,后来自己一个人搞 PSP 和 TSP,也就是说如果不把执行过程的人训练好,再好的过程也是无法实施的。 有些人说中国的工程师喜欢用指针等技术高但是容易错的功能,印度的工程师用数组这样技术低不容易错的功能。很可惜,在我的工作经历中,没有发现这样的差别。即使有一些使用方法的差别,与其说是 CMM 的结果,不如说是经验和习惯的结果。而这是所有行业都面临的。 十年前中国和印度在不同的方向上开始起步。到了今天,中国可以有一万人的纺织工场,印度无法有这样的工场;同样,印度可以有一万人的软件工场,而中国无法有这样的软件工场。 中国和印度的软件出口差距不是能力而是经验和时间。再过十年,印度会有一万人的纺织工场,中国也会有一万人的软件工场。在十年前中国遍地都是几十个人的软件工场,中国数千人的软件工场已经开始出现了。这不是主要因为CMM,而是因为经验的积累。 CMM 作为一个外在因素,起到了一定的促进作用,但不是 决定因素。 4,第一轮的热潮之后 所谓历史都是相似的。印度在 90 年代同样产生了 CMM 的热潮,大家纷纷将 CMM 作为竞争手段。很快大家都是 CMM5 级了,竞争什么呢?于是再找模型,比如 People- CMM, ITIL, sixsigma 等等。从2000 年开始的 CMM 和 CMMI 热潮,在政府补助金的推波助澜之下,第一轮的 CMMI热潮迅速沸腾起来。 第一轮的热潮的价值并不会真正带来软件过程的改善和软件品质的提高,而是普及了软件方法学的知识,让人们普遍达成共识:品质很重要,并且品质是可以通过过程来改善的。 对于很多“迅速”通 过了各个级别的大小企业而言,名也有了,政府的钱也给了;然后,在热潮之后,我们开始真正静下心来反思软件品质的价值,开始检讨软件过程的改善。 改善品质的动力来自何处? 商品短缺的时代,商家和市场首先考虑的是商品是否充足,不是品质;只有进入商品过剩时代,品质才可能成为商家和市场首先考虑的课题之一。 没有实际问题的发生,人们是不会重视品质的。 Crosby 说 QualityIsFree,这是说由于低质导致的损失超过了强化品质的成本,因此要“第一次就把事情做对”( DoThingsRightTheFirstTime)。可 是,如果低质并没有损失呢?如果客户不关心品质,而关心交付日期,功能创新呢? 因为食品问题死了人,毒害死了世界人民的猫狗,在地球村里丢了人,没人买我们的食品了,所以我们才会真正重视食品的品质。因为饺子吃了发现有毒,却找不到下毒的环节,人们才开始重视过程。 由于品质问题的产生,中国很多制造行业开始进入了品质竞争的时代。 那么,中国的软件产业真正进入了需要以品质为前提进行竞争的时代了么?在某些关键行业,比如电信,电力,银行,证券等,由于软件系统支撑着人们的日常生活的每个环节,品质成为了不可忽视的要素;但是在其他行 业,比如在线服务,在线游戏等,或许还要等等。 大家意识到品质确实很重要之后,然后开始挽起袖子,真正地开始改善品质。大家会重新翻开 CMMI 的书籍,审视软件工程方法学的各个具体领域,摒弃那些表面无用的模板和规章,制定真正适合自己的开发流程和控制手段。 品质就像走钢丝,要时刻小心;可是,有时即使很小心了,也会掉下来。按照 Cusumano 的结论,日本企业的品质是世界级别的,是美国的十倍。可是即使这么小心,在 2006 年的时候,东京证券交易系统还是意外死机了。 CMMI 是软件工程知识的整理。软件工程课程是大学计算机系的 主要课程,大学没有认真学,现在再来重新学习一遍,就认真了么?郑人杰老师在 80 年代就翻译了 Myers 的《软件测试技术》,每本只卖 2 角钱。可是那个时候我们连什么是软件都不知道,更不要说在实际工作中进行软件测试了。我们缺的不是知识,缺的是实践。 去他的,什么 CMMI 模型,什么 CMMI 级别。让我们开始真正的软件过程改善吧。