研发过程改进之6sigma与CMMI

研发过程改进之6sigma与CMMI

2009-8-25     作者：佚名        编辑：李湘琪   点击进入论坛

关键词：CMMI  6sigma

　　首先要做的是策划，识别改进机会，确定改进的方向。从组织的高级流程，到一个一个研发过程域;从组织的高级管理单位，按照组织结构逐级分解任务 和目标，直至个人。这个过程可以用6sigma在定义阶段的方法来做：关注提高客户满意度，关注提高企业绩效，分析关键流程，找出薄弱环节，从Y到y，确 定关键质量特性，明确现状与目标。也可以按照CMMI的OPF来做：建立组织的过程需求，评估组织过程能力，识别改进机会，计划、实施这些改进措施，并发 布改进效果。

　　我们现在的做法基本上是按照OPF来做的：应用CMMI的SCAMPI评估法，对组织的CMMI过程域的满足程度进行度量。每个过程域经过查阅 组织资产库、过程数据库，以及访谈，给出满足CMMI的符合程度：FI——完全实施，LI——大部分实施，PI——部分实施，NI——未实施。每个过程域 的特定实践和通用实践均可以用此评价，一般FI与LI的评价含义是合格，PI与NI是不合格。那么如果将每个实践作为一个缺陷机会，被评价为PI与NI的 实践是一个缺陷，就可以度量出此组织符合CMMI的某个成熟度等级的缺陷率。组织追求CMMI的某个成熟度等级的达标就可以此为起点，降低过程域的缺陷率 到SCAMPI的通过标准，识别出需要改进的过程域和实践，逐个制定改进计划、分派职责、落实与跟踪。

　　两种改进策划，同样执行了从高端、全局出发，识别出改进的机会，之后有改进行动的具体计划和实施。不同的在于，6sigma强调从最终客户出 发，强调改进活动投资收益比，所以用数据说话，有财务收益可以衡量。而过程改进的财务收益衡量，更依赖于此组织已经建立的财务收益衡量方法，如一个过程的 收益如何计算?过程指标改进的程度，如何衡量其收益?这方面我们的方式还不够健全，所以在过程改进策划时，没有考虑到投资收益比。而CMMI的改进方式， 如果组织处于4级以下，一般来讲数据基础是比较薄弱的，用数据辅助决策改进方向，也还做不到。也有人认为，组织的高级管理层，下达追求CMMI的某个成熟 度等级的达标就是已经高层决策好的改进方向，我们只要想办法做到就可以了，不必追究其来源。但是黑带的责任是帮助组织思考，要敢于发问：“为什么要这样 做?”如果方向错了，越好的执行带来的组织损失越差。

　　两种改进方式的差异，已经决定，研发过程改进如果采用CMMI的方式，必定会比强调量化和逻辑严谨的6sigma方式松散一些。这是好还是不 好?需要看我们的研发过程现状，因为衡量一种做事方式是否有效的唯一标准，是它是否“适合”现状，能够达到改进目标。在我们的研发过程数据不严格、过程改 进的财务衡量方法不健全的现在，如果要求严格的数据和逻辑，要求严格计算财务的投资收益比，以及6sigma的理论和工具使用技巧，势必会提高了参与改进 的门槛。许多本来有热情做过程改进的研发人员被阻隔在这个门槛之外，把过程改进的工作又丢回给EPG自己承担，造成EPG与客户的隔离，使得研发过程改进 更加困难。与之相比，采用CMMI的方式，显然启动更容易，对于研发人员也更容易接受，最近的最佳实践评比活动证实了这一点。同样做了改进活动，最佳实践 与6sigma项目相比，同样解决了产品顽疾或者流程优化，然而无需为此新建度量机制，而且只关注于做自己最熟悉和擅长的本职工作，总结文档也不需要为了 满足认证的要求而穷心竭力，只要简单地说明问题来源、解决思路、特点与推广建议即可。如此的轻装上阵确实有吸引力，每个月层出不穷的案例提交到评审委员的 案头等待审核，而且无论质量和数量，都在逐步提高，真是一片繁荣景象。当然，这种自下而上的改进行为更加需要引导和规范，目前的高效率与低成本在组织的管 理要求和财务核算更加严格后，也会逐渐丧失其优越性，但是至少目前还是可行的，因为需要鼓励更多的研发人员参与到过程改进中来。

　　如果组织的过程成熟度在CMMI的4级或者5级，这个矛盾就不存在了，因为4级的OPP本身就是对过程性能的量化，而5级的OID是基于OPP，在量化管理组织过程的基础上，进行过程的革新策划的。

　　在具体的改进活动的执行中，6sigma与CMMI的最大相似点就是：采用项目管理的方式运作。6sigma采用项目方式运作不稀奇，而 CMMI的过程改进也采用这种方式，则是近来的事情。原因有两个：一是EPG承受了很多项目组的抱怨，认为制定的规程和流程繁复，缺乏可操作性，脱离了项 目的实际;二是EPG的改进活动，在审核中暴露出与项目运作一样的弊病：进度严重延误，人员职责不清，任务目标不明确，需求变化不可控等等。这些促使 EPG改进了工作方式：整个EPG按照一个项目运作，每个过程域的工作小组，类似于项目的开发组。于是在这个与项目一样的两层结构中，同样设定了满足 SMART要求的项目目标，按照CMMI的要求进行计划、跟踪、审核等等活动。即使是组织内部对于过程改进的需求变更请求，和审核不合格项，也与项目一样 走变更流程，由EPG的CCB来定期处理。由于EPG的成员对于自己制定的规程很熟悉，对于推荐的各种工具、方法也很熟悉，这种工作方式的转变进行得很 快，改善效果也非常明显，一切看起来都在有条不紊地进行。这算不算是神奇呢?这就是CMMI的价值体现，它毕竟是软件行业多年来经验与智慧的结晶，而且现 在的应用已经突破了软件行业的限制。

　　我自信对于6sigma已经理解比较深入;然而当我越深入理解CMMI，就越相信它在研发领域是很好的方法。然而为什么我们在研发过程改进中还 是进展缓慢呢?我想有两个原因：一是在面对多种都独自有效的工作思路时，既没有能力将之有效结合，使工作高效进展，也不敢决断地舍弃一些，坚持一些。二 是，即使在决策之后，组织的执行力跟不上。以我们目前的改进来说，终于明确了在研发过程的改进中以CMMI为主，这是工作思路的明确;在实际执行中，按照 CMMI对于项目管理的规范进行，各阶段目标明确，责任清晰，跟踪及时，所以成果凸现。照此下去，我对于达到既定的目标毫不怀疑。