sigma.js案例 软件研发的6sigma案例解析



软件研发的6sigma案例解析

作/转载者:茹海燕 发布时间:2004-6-7 浏览量:53

一边是某咨询公司在项目管理培训中宣讲:“CMM2级企业不适合实施6sigma,应该等到CMM4级之后,度量体系比较完善时再进行。”一边是2004年世界软件工程大会上,各国专家达成共识:“CMM/CMMI与6sigma能够结合,互相促进”。我们怎么办?我以前主张:争执暂放一边,抓紧时间边实践边改进,否则结果就很可能是:“我们在进步,但是我们与竞争对手相比更加落后。”有些同事接受了我的看法,于是又有一问:“你有没有在软件中实施6sigma的成功案例?”6个月前我还没有,但是现在我有了几个典型案例,它们各具特色,让我们在此一一分享。

一、6sigma能帮助解决软件技术问题吗?

第一个项目是在去年年末,参加一个事业部的6sigma优秀项目发布会看到的。项目名称是《XX网管系统提高告警吞吐率》,问题是在大量告警上报时,UNIX服务器的告警处理吞吐率仅为8条/秒,同时占用CPU达90%,导致其它模块的操作基本上不能进行。用户对此非常不满,要求我公司尽快解决此问题,提高吞吐率到至少48条/秒,而系统成本不能有较大幅度增加。如何解决这个问题?一个解决方案是提高硬件的配置,从而提高处理性能,但是这样做会大大增加采购成本,而性能并不会有极大的提升,实际上降低了产品的可销性,这样的投入收益比极不合算,此方案被拒绝。项目组在花了大量时间和精力,仍然寻找不到合适的解决办法之后,想到了6sigma。大家知道,6sigma项目的选择就是那些“难度大、影响力大”的问题,于是这个项目组的成员将此问题立项,期待6sigma能在黑暗中带来曙光。

除去定义与测量阶段,此项目的分析思路是这样的:首先是头脑风暴鱼骨图,罗列所有大家能想到的可能原因;然后将这些原因按照告警的逻辑处理流程组织成FMEA,进行RPN分析,筛选出RPN值大于100的少数因素,作为潜在的关键因子;之后对这些潜在因子逐一试验,进行确认。整个项目的突破就出现在第一个因子的试验中,其试验数据如图1所示,横坐标表示输入的告警流量,纵坐标表示告警处理延时。图中的曲线显示有周期性的拐点,而在拐点之后,告警流量增加,服务器的处理延时反而有较大的降低。这个现象如果没有针对此原因的试验,没有这些数据是无法看到的。分析这个现象的原因,难不到我们的软件工程师,很快就得出了结论:TCP协议参数设置不当。修改此参数后,重新做同样的试验,得到数据如图2所示,可见其告警吞吐率基本上与输入流量呈线性关系增长,瓶颈已经消除。这不仅仅是确认了此因子是关键因子,同时也验证了改进措施的有效性。另外几个因子也是类似的,通过针对每一种可疑因子的试验,或确认此因子为关键因子,或筛选影响不大的因子;然后针对每个关键因子寻找技术上的解决办法,就更不在话下了。此项目的成功为公司创造了每年166万的收益。

回顾这个项目,又应验了一句老话:“解决难题经常是99%的努力在于寻找关键原因所在,而修改只需要1%的努力。”6sigma本身并不提供技术解决方案,但是它的思路引导我们向着正确的方向迈进,而数据是保障我们方向正确的重要依据。此项目虽然是软件项目,但是问题本身Y是可以清晰度量的,这也是它能够适应6sigma特色,得以成功的一个原因。

图1 某项目针对关键因子一的告警处理流量试验数据图

图2 某项目修改了协议参数后的告警处理吞吐率图

二、主观判断的结果有说服力吗?

这个案例是黑带项目《降低异常代码故障率》,它从CQ分析的主要故障类型之一:异常代码故障率居高不下而来,这体现出负责人主动从失误中学习和进步的精神,也给很多仍然为找不到合适项目的同事一个启示:CQ库是一个很方便的项目宝库。

此项目对于故障分类的测量系统分析,是离散数据做测量系统分析的典型。在研发过程中,我们经常遇到“只可意会不可言传”的情形,大家都是主观判断“拍脑袋”,这样的分析如何具有说服力?主观判断不等于拍脑袋,这个项目可以作为参考,感觉上的东西通过制定一定的准则,能够将大家的主观判断达到基本一致和准确的标准。以下摘自此项目负责人的总结文章:

在确定了故障的分类规则后,对于故障进行分类,对于同一个故障不同的研发人员分类可能出现不同的结果。出现这种问题可能是有两个原因:(1)故障分类的标准还不够明确,参加故障分类的研发人员对于故障理解不同。(2)参加故障分类的研发人员没有能力按分类标准对故障进行分类。解决的办法是在故障分类前进行测量系统分析,确认故障分类标准是否已经明确,参加分类故障的研发人员是否具备了故障分类能力。

对于故障分类进行的测量系统分析可采用离散测量系统分析。进行离散测量系统分析的基本步骤为:

1、 在需要分析的故障中随机抽取30个故障。

 软件研发的6sigma案例解析

2、 多个开发经理按故障分类标准共同确定每个故障的分类结果。(作为“真值”——本文作者)

3、 让参加故障分类的研发人员按故障分类标准进行分类。(作为“测量值”——本文作者)

4、 一周后,让参加故障分类的研发人员重新按故障分类。

5、 进行离散测量系统分析,确定故障分类的准确性、重复性和再现性。

如果通过测量系统分析,发现故障分类的重复性有问题,同一个研发人员对于同一个故障的判定结果不相同,则一般是研发人员自身素质的问题,采取的措施是需要加强对分类标准的学习。如果不同研发人员之间的再现性有问题,则一般是由于分类标准不明确造成,需要进一步明确分类标准。若重复性、再现性都符合要求通过,基本可以保证故障分类的标准定义是明确的,参加故障分类的研发人员的技能已经符合要求。

实际上这种测量系统分析的方法并非第一次使用,去年我们研究所的一个绿带项目做法极其类似,其原理如图3所示。

图3 某绿带项目的测量系统分析原理图示

这是一种典型的离散数据MSA的案例,在展示时,不少研发人员很吃惊:“原来MSA是可以这样做的”,或者“原来是可以这样得到量化数据的”。有很多人总是说研发过程中的数据量化不足,所以不适合做6sigma项目。其实不是6sigma不能用于研发领域,而是很多时候是我们没有找到正确的方法而已。所以多思考、多动手,这个从小老师就教我们的话,在工作中一样适用。

三、如何提高执行力?

记得前不久一位领导说:“我们公司从来不缺好的策划,我们缺的是好的执行。”软件中的问题有些就是执行的问题,如规范的执行不严格,流程不合理等等。有人会问:“如果解决方案就是执行的问题,可以依据其影响力选择合理化建议,或者团队项目来解决,并不适合做6sigma项目。”实际上,一来6sigma项目在开始时并不知道关键因子是什么,二来执行也不简单,知道和做到是两码事,正如一个黑带所言:“听到你会忘记,看到你会记住,做到你才会明白。”

言归正传,这个案例是另一个黑带项目《提高功能测试仪的软件研发效率》,研发效率的定义为单位软件的软件开发和维护人力成本。这个项目的特点首先是非常细致,每一个步骤都按照6sigma的思路、方法完整、清晰地描述,可以作为初学者的样板指导。然而对我而言,它更加重要的特点是它强大的执行力。在分析阶段,已经确认了三个关键因子:

1. 模块化程度不高;

2. 接口文档不规范;

3. 系统部、软件部、硬件部沟通机制不健全;

为了解决第一个问题,此项目提出建立10个模块的目标,而目前它只有3个模块;为了解决第二个问题,需要建立接口文档的模板,但是更重要的是得到使用者的认可和操作;而第三个问题更是需要三个部门的最高长官——部长来亲自沟通协调解决。以上这些,这个项目都做到了!怎么做到的?看看他的团队成员,有研究所的所长,一个产品总经理,三个相关部门的部长,还有相关的所有科长、开发经理,以及部分开发人员,这样的团队架构,还担心解决方案得不到执行吗?

案就是这么简单,每个项目负责人都需要慎重选择您的团队成员,力争让每个人各尽所长。团队中需要各种人员:首先是各方客户代表,然后是善于分析者,善于操作者,善于协调者,以及流程主管或组织负责人等等。记得以前有个项目,成员基本上都是项目经理,这样的团队沟通倒是通畅了,可是说到做具体的事情,大家都没有时间做,项目怎么进展呢?最后只有取消。想想有多少项目在到达终点之前倒下去,少有找不到解决办法的,但是做出来的方案无法兜售给使用方,从而不能达到项目目标,这倒是常见。为什么?多数是因为团队中没有使用方的代表,强加的东西谁都不喜欢。

也许有人会讲,其实说到执行,就是要把领导拉进来,搞定了领导,让领导出面推进执行和追踪,就一切OK了。这话不对,因为我们不可能把领导搞定的,只会是领导把我们搞定:选择项目一定要把握领导最关心的问题;即使不是最关心的,也要是在他的问题列表中位于前列的问题。如果你要做的就是领导非常想解决的问题,那么邀请他加入项目团队,请他做一些追踪工作自然顺理成章;然而如果选择的课题,在领导问题列表中远没有排在前列,让他分散精力,同时消耗他的资源来做事,他自然不肯。这就是目前我们强调自上而下产生项目的原因。目前,我们公司在一定程度上还是人治的社会,承认这个现实,并且主动调整我们的做法适应现状,才是做事的明智之举。

以上是我近期收集到比较典型和成功的软件6sigma项目。然而我不得不承认,在公司已经完成的上千个项目中,软件项目仍然是占非常少的比例。如果是因为没有成功的案例,影响到大家的信心,或者不知道怎么入手来做,希望本文能够为大家提供一些参考。CMM/CMMI与6sigma的结合和互相促进,在双方领域内都是新课题,还有很大的拓展空间。目前我们公司也有不少黑带身处EPG,选择的项目正是这个新课题。一年之后,我们再来回顾,希望能有更大的突破,让我们也在6sigma的历史上留下光彩的一笔。

参考资料:

《让失败成为成功的母亲》,徐金炉,2004-3。

  

爱华网本文地址 » http://www.413yy.cn/a/9101032201/489340.html

更多阅读

如何破解文件夹加密软件加密的文件夹 文件夹加密破解

????? 利用软件给文件夹加密很多人都在用,只不过很多的此类软件都是纸老虎,高手喝着咖啡就搞定了。我们把此类软件称为伪文件夹加密软件。此类软件的特点是:1、加密时间很短,几乎瞬间完成。一个文件夹要复制还需要一定时间的吧,它的加密

91手机助手安装软件失败的原因 91助手上传视频失败

91手机助手安装软件失败的原因——简介很多朋友的苹果手机已经越狱了,但是91手机助手安装东西总是失败, 安装任何东西都提示安装失败, 到底是什么原因呢?下面小编为你解答几个原因,希望可以帮助到你。91手机助手安装软件失败的原因—

转载 用友软件研发支出财务分析 研发支出加计扣除

原文地址:用友软件研发支出财务分析作者:51kuaiji用友软件研发支出财务分析在传统的财务分析和会计报表披露将研发支出进行了很细线条的披露。特别是研发支出在我国的会计处理中对大多数进行了费用化的处理,在上市公司的相关年报中披

并购经典案例解析 经典并购案例

并购经典案例解析主讲人:王 林引言:今天上午我们交流话题是“中国企业并购之路”,也就是“并购经典案例解析”。今天这个话题主要是从宏观角度给大家一个理念,并购对企业的发展、对中国未来产业的发展会产生什么作用以及中国企业在并

博盈投资并购重组案例解析 并购重组案例

博主初步研讨博盈投资并购重组案例,如果有错误,大家不吝指出赐教。博盈投资并购重组案例解析博主叉叉前言几个月的时间,一系列精巧的并购重组设计方案,成功的使得一家名不见传的钢构企业入主一家上市公司,控制权悄然发生变更的同时,又

声明:《sigma.js案例 软件研发的6sigma案例解析》为网友奋发向上分享!如侵犯到您的合法权益请联系我们删除