针对软件研发过程改进,目前存在两种非常流行的改进方式:6sigma和CMMI。这两种方法到底谁更优呢,我们该选用哪种方法进行软件研发过程的改进呢?作为对6sigma和CMMI都比较熟悉的人,我从以下两个方面简单分析一下对这两种改进方式的认识。
一、 针对于组织处于CMMI3级以下的企业进行分析:
1、6sigma与CMMI的相同之处在于
进行研发过程改进首先要做的是策划,识别改进机会,确定改进的方向。从组织的高级流程,到一个一个研发过程域;从组织的高级管理单位,按照组织结构逐级分解任务和目标,直至个人。
这个过程可以用6sigma在定义阶段的方法来做:关注提高客户满意度,关注提高企业绩效,分析关键流程,找出薄弱环节,确定关键质量特性,明确现状与目标。也可以按照CMMI
OPF过程域的要求来做:建立组织的过程需求,评估组织过程能力,识别改进机会,制定过程计划、实施这些改进措施,并发布改进效果。
这两种改进策划,同样执行了从高端、全局出发,识别出改进的机会,之后有改进行动的具体计划和实施。
2、6sigma与CMMI的不同之处在于:
6sigma强调从最终客户出发,强调改进活动投资收益比,所以用数据说话,有财务收益可以衡量。
CMMI的改进方式,组织处于4级以下,一般来讲数据基础是比较薄弱的,用数据辅助决策改进方向,也还做不到。
从以上分析,尤其是两种改进方式的不同可以看出,研发过程改进如果采用CMMI的方式,必定会比强调量化和逻辑严谨的6sigma方式松散一些。这是优势还是劣势呢?这就需要看我们的研发过程现状,因为衡量一种做事方式是否有效的唯一标准,是它是否“适合”现状,能够达到改进目标。如果我们的研发过程数据收集不够、过程改进的财务衡量方法不健全的,要求严格的数据和逻辑,要求严格计算财务的投资收益比,以及6sigma的理论和工具使用技巧,
势必会提高了参与改进的门槛。许多本来有热情做过程改进的研发人员被阻隔在这个门槛之外,使得研发过程改进更加困难。与之相比,采用CMMI的方式,显然启动更容易,对于研发人员也更容易接受。同样做了改进活动,CMMI的最佳实践与6sigma项目相比,同样优化了流程,然而无需为此新建严格的度量机制,而且只关注于做自己最熟悉和擅长的本职工作,
总结文档也不需要为了满足认证的要求而穷心竭力,只要简单地说明问题来源、解决思路、特点与推广建议即可。如此的轻装上阵确实有吸引力,同时也鼓励了更多的研发人员参与到过程改进中来。
二、 针对于组织处于CMMI的4级或者5级的企业进行分析:
如果组织的过程成熟度在CMMI的4级或者5级,6sigma和CMMI的不同就不存在了。在成熟度等4级上组织建立了关于产品质量、服务质量以及过程性能的定量目标,运用统计技术和其他定量管理的技术对选定的过程进行控制,并把这些定量目标作为判断过程管理成功与否的标准。各个过程域应满足如下目标:
1、对于CMMI4级:
组织过程性能(OPP)的特定目标为:
建立并维护用于表征组织标准过程集合的过程性能的基线和模型。
定量项目管理(OPM)的特定目标有:
运用质量和过程性能目标对项目进行定量管理;
对项目已定义过程中所选择的子过程的性能实施统计管理;
2、对于CMMI5级:
组织革新与部署(OID)的特定目标为:
选择那些有助于满足质量和过程性能目标的各种过程和技术改进措施;
针对本组织的过程和技术系统持续地部署可度量的改进措施;
原因分析与决定(CAR)的特定目标为:
系统性地确定缺陷和其他问题的根本原因;
系统性地处理缺陷和其他问题的根本原因防止它们以后再次发生;
6sigma 的DMAIC各个阶段与CMMI4级和5级中的特定目标与特定实践的对应关系如下图:
DMAIC各阶段 CMMI中4级和5级中的特定目标、特定实践
D 定义阶段 组织过程性能-OPP
sp1.1选择过程
组织革新和部署-OID
SP1.1收集和分析改进建议
SP1.2识别和分析革新
M 度量阶段 组织过程性能-OPP
sp1.2建立过程性能度量值
sp1.3建立质量和过程性能目标
sp1.4建立性能基线
sp1.5建立性能模型
A 分析阶段 原因分析和决定-CAR
sp1.1选择缺陷数据进行分析
p2.1实施行动建议
sp2.2评估变更效果
sp2.3记录数据
I 改进阶段 组织革新和部署-OID
sp1.3试点改进措施
sp1.4选择改进措施以便部署
C 控制阶段 定量项目管理-QPM
sp1.3选择将予以管理的子过程
sp1.4管理项目性能
sp2.1选择度量和分析技术
sp2.2应用统计方法了解变异
sp2.3监控所选择子过程的性能
组织革新和部署-OID
sp2.1策划部署
sp2.2管理部署
sp2.3度量改进效果
不管是DMAIC还是IDEAL都是基于 PDCA循环的持续改进方法论。CMMI4级和5级强调了需要具备统计学的思维和数据量化管理,必须要用到相关的统计学理论和相关工具。6Sigma的DMAIC方法论系统的整合这些理论、工具和技术。所以如果组织为了达成高成熟度利用6Sigma和CMMI方法都是可以的。
经过前面的详细介绍,相信大家对两种改进方法都有一定的了解。到底哪种方法更优一些呢?
目前,CMMI采用项目管理的方式进行过程改进,避免了以前存在的两方面的不足:一是减少了EPG承受的很多项目组的抱怨,以前项目组认为制定的规程和流程繁复,缺乏可操作性,脱离了项目的实际;二是
EPG的改进活动项目运作一样的弊病也得到了减轻,进度得以控制,人员职责更加清晰,任务目标更加明确,需求变化得以控制等。整个EPG按照一个项目运作,每个过程域的工作小组,类似于项目的开发组。于是在这个与项目一样的两层结构中,同样设定了满足SMART要求的项目目标,按照CMMI的要求进行计划、跟踪、审核等活动。即使是组织内部对于过程改进的需求变更请求和审核不合格项,也与项目一样走变更流程,由EPG的
CCB来定期处理。由于EPG的成员对于自己制定的规程很熟悉,对于推荐的各种工具、方法也很熟悉,这种工作方式的转变进行得很快,改善效果也非常明显,一切看起来都在有条不紊地进行。这算不算是神奇呢?这就是CMMI的价值体现,它毕竟是软件行业多年来经验与智慧的结晶,而且现在的应用已经突破了软件行业的限制。
随着我对CMMI理解越深,就越相信它在研发领域是很好的方法。然而为什么我们的研发企业发现在研发过程改进中还是进展缓慢呢?我想有两个原因:一是在面对多种独自有效的工作思路时,既没有能力将之有效结合,使工作高效进展,也不敢决断地舍弃一些,坚持一些。二是即使在决策之后,组织的执行力跟不上。如果我们明确了在研发过程的改进中以CMMI为主的工作思路,在实际执行中,按照CMMI对于项目管理的规范进行,各阶段目标明确,责任清晰,跟踪及时,照此下去,我坚信一定会达到我们既定的目标。
在我们明确了以CMMI为主的工作思路后,6sigma也能在更加细节的地方,为研发过程改进添加助力。如CMMI在流程改进的财务收益衡量上的欠缺,不仅这些,6sigma对于完美的渴望,客户的关注,团队的沟通,以及传播这些知识和理念的定期培训,都在潜移默化地改变着组织的氛围,提高组织成员的素质。这一切都是在默默地推动着研发过程的改进,而结果也必定使组织在CMMI的成熟度级别评估中,越走越高。
|