CMM/CMMI
不适合在当前软件开发当中应用的原因
1. CMM/CMMI 淡化了软件项目的独特性
1.1 不是所有的项目都是外包项目
CMM/CMMI
的一个主要问题是它淡化了软件项目的独特性,让人产生一种错觉:软件是有严
格规格的工业产品,在标准流程下,从一端输入原材料,在另一端获取软件产品。然而,在市场
压力下,这种软件的标准化、规格化变得越来越不可能存在。
这也许和 CMM/CMMI 提出的背
景和目的有关:CMM
是美国国防部在
1984
年因当时该机构软件标案委外承作时,无法评估软
件公司对软件标案的承接及执行能力,故委托美国卡内基美隆大学的软件工程学院所进行的一
项研究成果,其目的是用来评估及改善软件发展公司的软件开发过程及软件开发能力,并且协助
软件开发者持续改善软件流程成熟架构及软件品质,进而提升软件开发项目及软件发展公司的
软件开发管理能力,达成软件发展的功能正确、缩短开发时程、降低成本及确保品质等目标。
[1]
可以看出,CMM/CMMI 实际是为评估软件公司对软件标案的承接及执行能力而产生的,它更
像是安抚买家的安慰剂与赢得合同的催化剂,对于外包公司,当甲方项目需求类似(如某乙方公
司只做财务类系统),CMM/CMMI 或许是有效的。然 而 ,有很多公司不是外包公司而且有越来
越多的公司成立自己的研发部门,这 些 公 司 只 研 发 自 己 的 产 品 、开发自己的需求,在 市 场 压 力 下 ,
这些需求场景越来越多样化、这些挑战越来越大,当他们应对这些场景与挑战时,CMM 还会是
有效的吗?不会,而且当公司 CMM/CMMI 等级越来越高,在这种规范指导下,需要面对新场
景与挑战的开发团队将会在组织的笼罩下将寸步难行。
1.2 过度渴望一致性
CMM/CMMI
渴望一致性或者说保持稳定而平庸。这就像音频压缩算法,可以除去峰值,但是
音乐中也就没有了高音与低音的美妙。
一方面,从项目产品的角度来看,稳定而平庸的公司很难
有非连续性创新,其终将会被互联网的浪潮淘汰,因为这样的公司太多,用户有太多选择。另一
方面,从工程师角度来看,在组织层级上要求 A+等级的团队与 C 等级的团队保持一致,这对
A+等级的团队或个人是极不公平的,这只表现出色、才华横溢的团队并没有受到表彰与推崇,
反而为了流程受到排斥与限制,他们会对这种管理反感或许他们也会变得平庸。
2.CMM/CMMI 与敏捷方法冲突
众所周知,
CMM/CMMI
与敏捷是完全不同层面的东西,但它们实施起来仍然会在某些方面有
冲突。近十几年来,敏捷方法在业界一直占据软件开发的主导地位,然而
CMM/CMMI
却与敏
捷方法有着大量的冲突。人是敏捷开发的核心,敏捷开发总是以人为中心建立开发的过程和机
制,而非把过程和机制强加给人,而
CMM/CMMI
恰恰相反。
我们相信 CMMI 是在敏捷环境中改进流程的一种方法,通过检查敏捷方法对过程领域的覆盖,
可以发现敏捷方法中的缺陷,从而改进敏捷方法。然 而 ,使 用 CMMI 的过程改进只能在一定程
度上进行,因为有几个过程领域与敏捷原则相冲突,如果不牺牲一些敏捷的基础,第 3 级和第
评论0