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

软件研发的 6sigma 案例解析 一边是某咨询公司在项目管理培训中宣讲：“CMM2 级企业不适合实施 6sigma，应该等到 CMM4 级之后，度量体系比较完善时再进行。”一边是 2004 年世界软件工程大会上，各国专家达成共识：“CMM/CMMI 与 6sigma 能够 结合，互相促进” 。我们怎么办？我以前主张：争执暂放一边，抓紧时间边 实践边改进，否则结果就很可能是：“我们在进步，但是我们与竞争对手相 比更加落后。”有些同事接受了我的看法，于是又有一问：“你有没有在软件 中实施 6sigma 的成功案例？”6 个月前我还没有，但是现在我有了几个典型 案例，它们各具特色，让我们在此一一分享。 一、6sigma 能帮助解决软件技术问题吗？ 第一个项目是在去年年末，参加一个事业部的 6sigma 优秀项目发布会看到 的。项目名称是《XX 网管系统提高告警吞吐率》，问题是在大量告警上报 时，UNIX 服务器的告警处理吞吐率仅为 8 条/秒，同时占用 CPU 达 90 ％， 导致其它模块的操作基本上不能进行。用户对此非常不满，要求我公司尽快 解决此问题，提高吞吐率到至少 48 条/秒，而系统成本不能有较大幅度增加。 1 如何解决这个问题？一个解决方案是提高硬件的配置，从而提高处理性能， 但是这样做会大大增加采购成本，而性能并不会有极大的提升，实际上降低 了产品的可销性，这样的投入收益比极不合算，此方案被拒绝。项目组在花 了大量时间和精力，仍然寻找不到合适的解决办法之后，想到了 6sigma 。大 家知道，6sigma 项目的选择就是那些“难度大、影响力大” 的问题，于是这个 项目组的成员将此问题立项，期待 6sigma 能在黑暗中带来曙光。 除去定义与测量阶段，此项目的分析思路是这样的：首先是头脑风暴鱼骨图， 罗列所有大家能想到的可能原因；然后将这些原因按照告警的逻辑处理流程 组织成 FMEA ，进行RPN 分析，筛选出 RPN 值大于 100 的少数因素，作为 潜在的关键因子；之后对这些潜在因子逐一试验，进行确认。整个项目的突 破就出现在第一个因子的试验中，其试验数据如图 1 所示，横坐标表示输入 的告警流量，纵坐标表示告警处理延时。图中的曲线显示有周期性的拐点， 而在拐点之后，告警流量增加，服务器的处理延时反而有较大的降低。这个 现象如果没有针对此原因的试验，没有这些数据是无法看到的。分析这个现 象的原因，难不到我们的软件工程师，很快就得出了结论：TCP 协议参数设 置不当。修改此参数后，重新做同样的试验，得到数据如图 2 所示，可见其 告警吞吐率基本上与输入流量呈线性关系增长，瓶颈已经消除。这不仅仅是 确认了此因子是关键因子，同时也验证了改进措施的有效性。另外几个因子 也是类似的，通过针对每一种可疑因子的试验，或确认此因子为关键因子， 2 或筛选影响不大的因子；然后针对每个关键因子寻找技术上的解决办法，就 更不在话下了。此项目的成功为公司创造了每年 166 万的收益。 回顾这个项目，又应验了一句老话：“解决难题经常是 99 ％的努力在于寻找 关键原因所在，而修改只需要 1％的努力。”6sigma 本身并不提供技术解决 方案，但是它的思路引导我们向着正确的方向迈进，而数据是保障我们方向 正确的重要依据。此项目虽然是软件项目，但是问题本身 Y 是可以清晰度量 的，这也是它能够适应 6sigma 特色，得以成功的一个原因。 图 1 某项目针对关键因子一的告警处理流量试验数据图 图2 某项目修改了协议参数后的告警处理吞吐率图 二、主观判断的结果有说服力吗？ 这个案例是黑带项目《降低异常代码故障率》，它从 CQ 分析的主要故障类 型之一：异常代码故障率居高不下而来，这体现出负责人主动从失误中学习 和进步的精神，也给很多仍然为找不到合适项目的同事一个启示：CQ 库是 一个很方便的项目宝库。 此项目对于故障分类的测量系统分析，是离散数据做测量系统分析的典型。 在研发过程中，我们经常遇到“只可意会不可言传” 的情形，大家都是主观判 断“拍脑袋”，这样的分析如何具有说服力？主观判断不等于拍脑袋，这个项