软件业已经有了CMM，还需要6sigma吗——“和我一起学6sigma”之二（茹海燕）

关键字：6sigma —— 一种基于统计的管理法
CMM —— 软件成熟度模型
DMAIC —— 6sigma的主要模式之一，五个字母分别表示定义、测量、分析、改进和控制

在6sigma绿带的培训过程中，不绝于耳的是软件从业人员的一个困惑：“软件业已经实施了CMM，我们还需要6sigma吗？”

这个消息对于不论是CMM推进组，还是6sigma推进组，确实是个好消息，这证明软件部门终于接受了CMM。两年前，CMM对于我们来说还是个 “洋物事”，当时没有人相信可以在我们的企业中成功推行，深入人心。而在今天，它已经溶入我们的日常工作，证明了企业推广CMM的成就不容置疑。同样，6sigma对于现在的我们还是个有些陌生的事情，但是有CMM的成功推进经验在先，我们有信心让6sigma成为企业持续经营发展的思想方法、实践方式和企业文化。

即使这样，我们还是首先要解释：软件为什么需要6sigma？有两个原因，其一，软件行业的目标与6sigma的核心思想完全一致：以客户为中心，追求卓越。其二，软件行业在产业划分中，属于服务行业的一部分，6sigma已经在服务行业大获成功，因此有理由相信它也能够帮助软件行业得到大幅度的发展。

例如，一个软件项目遇到这样的问题：远程客户端和服务器同步所有数据总是花费时间很长；而且在此期间，客户端不对用户的任何操作做响应，用户感觉就是客户端死机。可是，如果不理它，过了半个小时之后，它自动返回消息，说同步成功了。你认为这是一个好的软件吗？不，实时性差，交互信息少，用户的反馈很不好。项目组收到用户抱怨之后，就开始定位原因，发现是服务器端的处理方式有问题，同步数据操作完全是串行操作，而且全部数据量又很大，导致这个操作的完成时间长达37、38分钟。这个问题在调试过程中就已经发现，测试组也在测试报告中特别指出其实时性差，但是在发布版本中为什么没有解决呢？因为在项目划分中，客户端的开发是一个项目，而服务器的开发是借用另一个项目的人员。对于这个操作耗时太长的问题，尽管客户端开发人员早就提出不满足用户的要求，但是服务器端的人员认为完成功能就可以了，实时性并不重要。双方的沟通没有效果，就造成问题一直摆到了用户的面前。
为了解决这个问题，相关的软件部门成立了一个6sigma项目，抽专人寻找原因。在大家的协同工作下，一周之后，就将同步时间降为1.5分钟。这是个不对原有系统伤筋动骨的最好结果，如果希望进一步减少同步时间，只有调整系统架构。由此引发的风险和成本太大，在经过项目组和6sigma黑带的权衡后，同意此项目到此成功结束。

这是个成功地应用DMAIC来解决问题的软件项目，从中体现了6sigma的几个主题：对客户的真正关注；由数据和事实驱动的管理；跨越组织的无界限合作；对完美的渴望。

在这个案例中，没有CMM的介入，单纯利用6sigma的方法解决了软件的问题。有人会讲：“这只是证明了6sigma确实可以应用于软件行业，但是我们的软件行业已经有了CMM， 也能取得成功，又何必花费这么多资源推广6sigma呢？”

我们另外举一个案例，网络管理系统项目组发现，一年以来系统发布的时间总是推迟，而这个项目已经实施CMM一年有余，而且其实施方法中关于高效召开CCB会议还受到了表扬，其他的同行评审、设计先行等都是做得比较好的。那么问题出在哪里呢？在成立了一个绿带项目之后，统计一年以来的计划数据和测试故障数据发现，每当设备系统升级，从而引发的网元管理模块升级，与系统平台本身的升级同时进行的时候，网元管理模块出的故障占到了66.6%；而由于这些故障，测试由平常的两次，增加到平均7.25次，因此系统发布时间平均延误29天。在分析数据和项目现状之后，大家提出了两条措施：一是将系统平台的升级与网元管理模块的升级错开，系统版本发布以平台的升级为主；而为了解决网元管理模块的故障太多的问题，大家继续研究其解决方案。

在与许多开发人员和一线经理的讨论后，大家一致认为是由于自测不够充分造成的。按照CMM流程，这家企业要求软件项目在提交系统测试之前，需要提供功能清单和相应的自测报告。这个项目的自测报告每次都提供，它的一个片断是这样的形式：

这有什么问题呢？自测的粒度难以控制，每个功能给出一个“功能正常”的结论，但是达到什么样的标准可以给出这个结论呢？大家的看法并不一致，有的开发人员认为功能很重要，只要设备管理功能正常就可以了；有的认为，性能也很重要，要看操作的响应时间是否在用户需求的规格范围之内；还有的人说，语言的本地化也很重要，因此这个系统提供的几种语言都需要自测；相反其他的人认为其他语言的环境很难搭建，算了，还是让测试部去查吧。

这些情况反映出以下问题：
1． 在设计中没有明确用户需求规格，大家不清楚这些需求中哪些是基本需求，一定要满足的，哪些是可以可变需求，或者潜在需求，作为锦上添花可以选择满足的；
2． 在最后的质量把关自测过程中，没有流程来检验测试版本是否满足这些规格要求。

这说明大家实施CMM还在一个“套路”当中，只有CMM的壳，而没有把握“追求卓越”的核心。CMM要求有用户需求说明书和软件需求说明书，于是项目提供了；CMM要求有系统设计、详细设计和相应的同行评审，项目组都做了；CMM要求测试之前有自测报告，项目组也提供了……项目流程是清晰了，可是质量并没有显著提高。原因就在于大家僵化在CMM的流程框架中，没有活力和创造性了。而6sigma的魅力就在于它是事实驱动的，它的每一个项目都是瞄准了一个问题，从只知道问题到搜集数据、分析原因，制定解决方案并试验、修正，直至最后确定有效方案，并控制其实施。这就是创造的过程。

如上面的项目，应该怎样改进呢？这里用到了几个6sigma的统计学定义，缺陷机会和缺陷率。经常有人说这些词汇都是用在生产行业的，软件行业没有法子用，我们就在这里试一下。以最简单的“系统信息配置”功能为例，它实现了SNMP中系统组的信息查询和配置功能，一共有六个参数：系统名称，系统位置，系统联系人，系统描述，系统标识，系统时间，全是字符串类型的变量。其中前三个是可读可写的，也就是用户可以修改的，后三个是只读的，就是用户只能看不能改的。我们按照“黑盒测试”的思想，只看其交互界面，这个界面设计起来很简单，六个参数从上之下，排列整齐，每个参数有一个名称控件，一个内容控件；加上一个标题，和三个按钮，一共有16个控件，如图1 所示。

图1 系统信息配置功能界面

什么叫做缺陷机会？假设这个系统支持中文和英文两种语言，并且要求所有的界面都需要一个标题。那么这个标题，在中文环境下，它有两钟情况会被用户认为是不正确的：一是如果没有显示出来标题，或者由于控件位置调整不正确，显示不全，就是错了；二是中文字写错了，即“系统信息配置”这几个字拼写有误。加上英文环境的两种情况，它一共有四次机会成为一个让用户不满意的功能，所以这个标题的缺陷机会是4；而每一个缺陷机会都可能让这个“系统信息配置”功能不合格，所以缺陷机会数永远是大于不合格品数的。而缺陷率就是实际发生的缺陷数量，除以总的缺陷机会的比率。如这个界面的标题，在中文时显示正确，但是在英文环境中，由于长度所限，没有显示完整，但是拼写看起来正确，那么它的缺陷率就是1÷4＝25％。

依此类推，这个最简单的界面上究竟有多少个缺陷机会呢？如果这个系统支持Windows和Unix两种操作系统，和3种类型的数据库，那么它又有多少缺陷机会呢？不说不知道，一说吓一跳，一个这么简单的功能，缺陷机会就有几十种，开发人员看到这个结果都不说话了。在如此详尽地列出这些缺陷机会之前，每个人自测的过程中能够覆盖的缺陷机会有多少呢？在“功能正常”这四个字的结论中，有多少内容和可信度呢？

那么这样讲，是不是CMM就没有用了呢？不是的，CMM既然是为软件量身定做的，就有它的用途。

为了回答这个问题，我们来分析一下软件行业的特点，这与服务行业类似：有看不见的工作流程；不断演变的工作流程； 缺少事实和数据；缺少良好的开端。

CMM作为一种衡量软件行业成熟度的模型，在以上四点都有所作为。它致力于将软件制造由无序变有序，将流程由粗犷变细致；不同的企业可以根据自身情况，选择不同的起点，不断升级；而CMM对于数据也是情有独钟，从二级开始不断加大数据的积累的统计分析，寻找可以递增改进的过程。CMM以其已经比较完善的过程指导软件企业迅速找对位置，固定流程，获得了基本的有形系统；而这些也为软件实施6sigma奠定了基础。反过来6sigma又为软件行业在CMM等级上的提升提供突破机会。

仅从上面的这个案例来讲，在DMAIC的控制阶段，在原有的CMM流程中做出这样的调整：详细设计阶段在提供详细设计文档的同时，提供自测规程，列出每个功能的缺陷机会；而在提交测试之前，要提供自测报告，按照自测规程对每一个缺陷机会都涉及到，由于特殊原因没有涉及到的，要给出充分理由并经过经理的同意。这不是又回到CMM了吗？

因此，CMM与6sigma是相辅相成的。

一些有经验的6sigma黑带提醒我们：“实现6SIGMA管理法标准最好的办法是那些能够适应你的组织的办法。”“选择一个模式并坚持使用这个模式，是使公司业务发挥6sigma管理法威力的途径。”正如上文所讲，6sigma也需要创造，在我们的组织中寻找CMM与6sigma互相促进、互相完善的模式，并且坚持这个模式， 不仅仅能够实现6sigma管理法的初级目标：问题解决，也完全可以实现它的高级目标：战略改进和业务转型。

参考资料：
《6sigma管理法——追求卓越的阶梯》，机械工业出版社，2001

本文由作者向AMT提供
作者联系方式：ru.haiyan@zte.com.cn

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友