在企业实施过程改进，常见的是形成工作小组，少部分人参与，甚至只是质量人员参与，
改进时很难找到关键问题点、改进后带来结果只是使得流程更"完善"和"累赘"，但实际
上并没有给企业/项目带来效益，企业也由此逐步陷入流程的焦油坑，变得笨重不堪。
然而，随着软件业的竞争加剧，软件产品的客户在继续要求高质量交付的同时，也要求
"响应快速化、需求定制化"，要求研发交付也要能敏捷、快速，也就要求软件开发流程要
不断适应产品所面临新的交付环境。企业所开展的过程改进能否不再是细化和增加活动、要
求，能否使得流程能与时俱进，及时适应交付模式改变？
面对这样的难题，根据华为技术有限公司内推行多年的过程改进实践经验 ，本文提出建
立具有自优化功能的流程框架，并在此框架指导下激发所有研发人员的激情和潜能 ，使得研
发流程保持有效、适用，使得流程能成为软件开发的切实指导。
关键词：过程改进 流程框架
1. 引言
许多公司都有这样的经历，在最初混乱的项目控制情况下，引入相关的软件开发流程或
者制定相关的规则、约束，极大地解决了项目进度无休止延期、不停救火式的解决问题、交
付质量低下等恶梦，使得项目的质量、成本和进度都有所改善，效率有所提高。通常，还会
由此建立起一套改进机制，不断地引入要求来规范和约束开发活动，希望能够全面的避免和
防止犯错误。
然而，软件开发并没有简单到仅用一些约束和限制就能够可靠地防止错误的地步。当
我们避免了某一个方面的错误时，又发现在另一个方面存在犯错的可能。在改进机制的驱动
下，不停地优化和完善， 流程中增加了更多的约束和交付件来防止以后犯另一方面的错误。
经过多年的发展后，项目使用的流程越来越"完善"，过程改进活动永远是在做"加法"。完
成软件项目需要开展的活动、相关的要求、需要完成的交付件已经实在太多了。在避免犯错
机会的同时，我们又从另外一个角度引入了问题：流程笨重，效率低下。
在软件业竞争日益加剧的今天，客户对软件产品的交付要求越来越快，庞大的开发过
程降低了团队的响应能力，使得我们又开始陷入新的"不能如期交付"恶梦中，引入的开发
流程好像成为了软件开发中的绊脚石。
软件开发的过程本身是应该为项目团队服务，为了确保能交付"满足客户需求"的产
品，那么，在多年的过程改进活动中，我们究竟犯了什么错误？
2. 几种传统的过程改进模式
常见的软件过程改进模型是 IDEAL 模型，以过程改进环的形式表示，如下图所示，IDEAL
模型将软件过程改进的整个过程分为五个阶段：准备（Initiating）、诊断（Diagnosing）、建
立（Establishing）、行动（Acting）、调整（Learning）。IDEAL 取自于五个字母的缩写。
初始阶段(Initiating) 为 IDEAL 模型的起点，识别改进的商业需求，建立相关过程改进运
作机制和基础性工作，并正式启动。
诊断阶段(Diagnosing) 是根据企业远景目标和当前的软件过程能力 ，识别当前状态，确
定希望达到的目标，开发达成业务需要的初步计划。
建立阶段(Establishing) 设定活动优先级，制定整体详细行动计划，用于指导过程改进
的活动；此阶段的任务是制定可度量的目标、定义度量标准、分配必要的资源。
行动阶段(Acting)的任务是按照前面阶段制定好的计划寻找解决方案、试点、验证。
学习改进阶段(Learning)的任务是通过实践收集有用数据、完善度量和评价本次改进过
程中使用的策略、方法和构架是否合理、完善。为 IDEAL 模型的下一次循环奠定良好的基础。
CMM(I) 也是当前一个主流、有效的软件过程改进指导模型，它指导一个软件组织如何
摆脱杂乱无章的、不成熟的软件过程，形成一个成熟的、有纪律的软件过程所必经的改进、
提高的途径。它不仅为组织软件过程的改进提出了一个循序渐进 的、稳步发展的模式，更有
意义的是，它列出了为要达到每一个成熟度等级所必须关注 的软件过程过程域 PA，以及要
做好 PA 必须需要的关键实践.。实践证明，CMMI 的级别及每一级所包含的 PA 的划分是很
科学的，CMMI 的五个等级标志着组织的逐渐提高的软件开发能力的成熟度的级别 ，随着
组织所达到的成熟度等级提高，组织不仅具备了本级的能力，而且还具备前面各个级别的能
力，致使组织的软件过程能力成熟度不断地增长。
CMMI 模型推荐使用 IDEAL 模型来进行软件过程改进。当然，也还有其他比如 ISO9000,SPICE,ISO15504 等过程改进/评估模型，也都能为达成
改进目的而提供支撑。
传统的过程改进模式理论体系非常完善，但是多数实施时候却碰到了难题。按照这样
IDEAL 改进模式实施了多年：强调评估现状，根据业务目标找出差距，成立改进项目组，改
进，总结。但是，却发觉这样的改进方式，依赖于如下两个条件：
(1) 精准且合适的目标。一个公司每年成立的改进团队不可能很多，所以，选取的目标
也不会很多，精准且合适的目标似乎就成了一个关键因素，要求能命中靶心。实际
工作中的改进中，往往要么是改进成果并不是项目实际所急需 （没命中靶心），要
么是目标太大很难达成。
(2) 专题小组成员的高技能。即使确定好了目标，能实施，但是改进也往往是这个团队
的几个到十几个人员在想办法，只能寄希望他们能够专研透里面的所有内容，或依
赖某些具有特别技能的专家，找到合适的解决办法。实际上，由于专题小组人员不
一定是最一线的开发员工，很可能是 SEPG 成员或其他过程专家，解决的办法也常
常过于理想化而不具有实用性，最终结果并没有实质性的解决问题，反倒可能是引
入了另外一些活动的杂质。
每个项目情况千差万别，每个项目所面临的情况都不尽相同，要解决问题的方法应该
各不相同，由此，多年的过程改进，结果软件开发过程能力仍然是在原地徘徊。
回顾起来其实是犯了一个大忌：脱离了真正的改进对象（项目开发人员）。实施越长，
最终体现的软件开发过程就越脱离实际情况 ，真正的软件开发人员越来越觉得流程是
公司的流程，不是项目需要的流程。
那么，有没有一种方法能够引入广大开发者主动加入到改进中来 ，寻找最佳的解决问
题方法实践，并引入到实施流程中来呢？本文提出一种基于最佳实践的自优化流程框
架，通过实践可极好的解决这个问题。
3. 自优化的流程框架
自优化的流程分层框架，顾名思义，就是一种具有自我改进、自我完善的流程框架体
系。
自优化的流程分层框架，把整个流程体系分为三个层次：
第一层，关键活动和要求，包含业务决策、关键活动的要求和标准。组织级通过对关
键活动上要求明确，了解项目进展的建康状况，为业务决策提供支撑，简单称为"业务决策
层"。其中，关键活动，按照"需求、设计、实现、验证、管理"五个维度划分，并给予明
确的要求。
第三层，关键实践层，针对每类具体的软件开发关键活动，都有可能积累多种方法。
比如进行软件需求分析，有采用面向对象 UseCase 的方法，有采用传统特性分析方法，也可
能有其他的一些方法。这些方法更多是来自以前项目的经验积累。综合这些经验，聚合成一
个关键实践库。
关键实践，是针对具有独立输入和输出，有明确责任人，没有必要再进行细分的软件
开发活动。每个关键活动存在固有属性，包含有活动名、活动要求、操作指导等。
第二层，项目使能层。由每个项目使用流程的时候，针对具体项目情况，根据组织级
对关键活动要求，细分组合一系列关键实践活动，来实施项目。比如，在设计阶段，根据项
目复杂度和分层设计的需要，可能会选取架构设计、系统设计、软件设计、各类评审这些关
键实践来完成；也可能系统设计还会细分成一些更具体的关键实践来完成，但也有可能只需
要一个软件设计和同行评审活动就完成。这些的选择都是根据项目实际情况，由项目组选择
决定。
三层框架组合如下图所示：
每个软件开发项目在启动的时候，看起来象是拿到了一个空的流程筐子 。项目组成员
一起分析项目的实际需要，选择需要哪些关键实践来完成这个项目，并填充成项目的流程。
就如同到超市里面去买各种生活必须品（比如牙膏、牙刷、毛巾等等）一样，每种必须品都
有一些品牌可选，每个人选择这些生活品的目的都可能有所不同：喜欢尝试某个新牌子，习
惯某个牌子，想要提高生活品质选高档点，经济紧张要选便宜点的。。。当然，不管怎么选，
都能保证能刷牙，能洗脸，都能满足基本生活需要。
由此，软件开发项目的流程就变得如同到超市买东西这样简单了 ："按需选择"。实际
上，这也类似传统的通过 PHB 选择项目生命周期过程模型，不同的是这里不仅是选择了项
目生命周期过程，还选择了生命周期各阶段的活动组合。
仅仅是多了一些可选择机会，为什么会被称为自优化的流程框架？如何引入广大项目
成员进行改进呢？
首先，需要从流程框架中各层的责任人说起。分层的思想基于"谁的孩子谁抱走"原
则。谁是这个层次的使用者，谁将对这部分的发展和完善负有责任，也只有这个层的人员才
有切身的感受，知道当前的问题在哪里，关键点或阵痛点是什么。
在第一层，也就是业务决策层中，由组织级根据业务目标制定其要求和标准 （可能有
多种类别的要求和目标）。代表组织级的业务需求和导向，即这个层次的流程，解决做与不
做的问题。业务决策层关心要在哪些地方关注，关注哪些内容，使得这个项目能够不偏离要
求达成业务目标，流程给管理者是否提供了足够的可视性。这个层的使用者是管理者，所以
第一层的使用人和责任人都是是管理者。
第一层的活动只是为了这些决策和管理使用 ，其交付件应该是尽量的少，关注点本着
"够用即可"的原则来实施。
在第二层，也就是项目使能层，是具体项目的操作流程，这个层面的用户主要是项目
经理和开发者。改进循环按照如下顺序运作：
A、每个项目启动时，项目根据具体的特点，结合第一层的要求，从"货架"上
选择关键实践，把完成项目交付需要的关键活动转化成完成一系列的关键实
践，如果没有选择到最满意的实践，还可以自定义更好的操作方法。每个项
目都自我完成一个量身定做的流程。
B、在项目结束时，提炼是否产生了更好的关键实践（标准化），如果有了更好的
关键实践，提出由改进关注组审核，是否纳入关键实践库。同时，项目结束
时候，也对使用的关键实践是否有效做出评价，给后来项目提供参考，或者
给选用过的关键实践进一步改进的建议。
C、改进关注组评估可以共享给其他项目团队的关键实践 ，则纳入库中，后续项
目选用。改进关注组还应该定期的对实践进行清理，剔除那些长期没有项目
使用，或者使用效果不好的实践，大力推广那些广泛使用且效果突出的实践。
D、由此形成关键实践的提炼循环，越运行持久，组织级的实践越丰富。如下图
所示： 
第三层，聚合众多的有效关键实践，如同超市货架上的物品，供项目选择。积累越多，
选择机会越多。
每个项目都在验证如何操作更有效，不断的丰富和验证关键实践库。由此，使得流程
持续不断的自我优化满足项目的需要。具有了"自优化"功能。
关键实践提炼循环一旦运行起来，每个项目都在进一步寻找如何做得更好，并把这些
实践不断的加入到流程体系中，那么，就是全员都一起参与过程改进，形成良好的改进氛围。
4. 自优化流程框架的几个关键点
自优化流程框架的实施，建立起"全员参与过程改进，流程自动优化"的的氛围，实
际实施的时候有几个关键点需要把握：
(1) 流程框架上要能支撑引入关键实践
如果流程框架体制上不支撑引入关键实践，即使有了很多实践，都无法让项目组使用到，
更别说项目验证后有效实践的引入了。不能引入关键实践到流程中，则永远只能停留在
当前水平。
(2) 关键实践提炼循环要能驱动运行起来
如果所有团队成员都能参与到应用和产生关键实践中来 ，就有非常好的效果。也由此成
立了相应的 IFG 团队（改进关注组）来提炼各级关键实践。
（ 1）每个产品，建立 IFG，识别和提炼本产品内的所有关键实践。如果值得推广的实
践，继续上升到产品族的 IFG。QA 成员是产品/产品族的 IFG 支撑人员。
（2）组织级建立 IFG，关注组织级共享的实践提炼、新开发模式/生命周期模型引入。
（3）EPG 团队，是组织级 IFG 的支撑团队，负责流程架构日常维护、体系支撑、关
键实践提炼循环的运作驱动等。
如下是我们建立的改进关注组组织结构图：
当然，同时，还需要建立一定的激励机制，奖励所有能提供有效关键实践的团队、奖励
应用效果成效良好的实践。
(3) 团队成员都有一颗"超越"的心
每个项目团队，都希望能够做得更好，都需要一颗"超越现状、超越自我"的心。如
果缺少了主动的改进和创造，则少了改进的动力。组织级管理者和 EPG 团队，所做的
工作是如何时刻保持大家有一个超越的心，使得过程改进建立起广大的群众基础。
只要关键实践改进循环运行起来，加上一定的激励机制，很自然就会形成一种改进的
氛围，激发团队成员寻求如何能够做得更好。
5. 小结
流程，为了达到特定的目的，将一系列相互关联的活动组合形成一个有序集合。过程
改进目的是使得流程更有效。相信有了持续的把广大开发中有效实践引入 ，使得流程保持
"活"的状态，那么软件开发过程将是最有效、最实用的流程！
记住一个理念："改善就是改自己"，营造了全员都参与改进的氛围，软件过程改进将
是一件非常容易而富有乐趣的事情！
参考文献
[1] 能力成熟度模型（CMM）：软件过程改进指南 （美）卡耐基梅隆大学软件工程研究所 电子工业出版社 2001
[2] 软件过程改进实践 北京 SPIN 编著 电子工业出版社 2004
[3] CMMI® Distilled: A Practical Introduction to Integrated Process Improvement, Second Edition
By Dennis M. Ahern, Aaron Clouse, Richard Turner Addison Wesley 2003
[4] The IDEAL Model Carnegie Mellon SEI (WebPage)
470
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
