思步网

查看: 17265|回复: 38
打印 上一主题 下一主题

全员过程改进

  [复制链接]
我们要做全员过程改进,那什么是全员过程改进呢?
让我们看看通过Google搜索“全员过程改进”的结果吧。

排名第一的:建立自优化流程框架, 推动全员过程改进.pdf
此文章为华为业软EPG Leader周代兵在2007年苏州SEPG大会的演讲胶片。胶片讲解了如何建立自动化流程框架,推动全员过程改进。
实际上此文的思想来自IBM的RPM,开源版本为EPFC(Eclipse Process Framework Composer,过程框架组合器)。我们知道敏捷方法学有很多种,他们有一个共同点就是都有最佳实践构成,比如XP的结对编程、测试先行,Scrum的Backlog、燃烧图等等。Jim Highsmith,敏捷联盟的发起人,自适应软件开发的作者,成立了敏捷联盟研究如何融合各种敏捷方法学,简称敏捷生态系统。他试图从各种方法学背后反应的价值观来融合敏捷,比如交付有用产品、依赖于人、鼓励协作等,实际上他也是站在自己的自适应角度进行的融合。所以,在那几年敏捷流行时流传的一句话就很好理解:方法学家和恐怖分子的区别是什么?答:恐怖分子可以谈判。
06年的时候我偶然发现IBM的RPM,觉得功能还是蛮强大、也蛮复杂,又偶然的在国外最大的开源基地SF上发现了EPFC:http://www.eclipse.org/epf/ 才知道这就是RPM的开源版本。经过一些研究后,才发现他是吸取了RUP的Discipline思想,将敏捷实践进行分类,然后按照实际的过程进行组合。
2006年参加苏州第一届SEPG大会时,我曾经和周总聊过这个想法,不知道他创作的这个自优化流程框架是不是也源于我的提示:)

[ 本帖最后由 Scott 于 2008-4-9 17:47 编辑 ]


上一篇:CMMI思想结合RMC实践之——“需求开发”流程定制
下一篇:居德华:从过程成熟度到人力资源成熟度

建立自优化流程框架,推动全员过程改进.pdf

 

建立自优化流程框架,推动全员过程改进.pdf

467.03 KB, 下载次数: 652, 下载积分: 金币 -10 (金)

评分

参与人数 1金币 +4 收起 理由
huiwh + 4

查看全部评分

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持1 反对反对
回复 论坛版权

使用道具 举报

现代质量管理方法的应用思考和实践

排名第二的便是来自华为的“现代质量管理方法的应用思考和实践”
http://www.huawei.com/cn/publica ... cid=5499&pid=87  (网页无法COPY和SAVE,大家通过链接看吧)

这篇文章是华为中央平台质量部写的一篇文章,从这篇文章中,可以看到整个华为的质量工作。也可以让大家理解互动栏目的分类原因,文化、过程、工程方法、工具都是我们全员过程改进人员应该关注的。其实这篇文章中也融合了很多质量管理领域的先进思想,比如文化上吸取Crosby的质量免费思想以及四个基本原则: 质量就是符合要求;预防的系统产生质量;质量的工作准则是零缺陷;必须用质量代价(金钱)来衡量质量表现。第2点注重上游客户实际上是TQM的核心;改进方法采用QCC;工程方法采用6西格玛;同时注重知识库和工具的建设。

这才是真正的质量管理!

[ 本帖最后由 Scott 于 2008-4-9 17:36 编辑 ]

(原)建立自优化流程框架,推动全员过程改进

原文地址:http://blog.csdn.net/dbzhou2008/archive/2008/01/09/2032628.aspx

摘要:      
    在企业实施过程改进,常见的是形成工作小组,少部分人参与,甚至只是质量人员参与,      
改进时很难找到关键问题点、改进后带来结果只是使得流程更"完善"和"累赘",但实际      
上并没有给企业/项目带来效益,企业也由此逐步陷入流程的焦油坑,变得笨重不堪。      
    然而,随着软件业的竞争加剧,软件产品的客户在继续要求高质量交付的同时,也要求      
"响应快速化、需求定制化",要求研发交付也要能敏捷、快速,也就要求软件开发流程要      
不断适应产品所面临新的交付环境。企业所开展的过程改进能否不再是细化和增加活动、要      
求,能否使得流程能与时俱进,及时适应交付模式改变?      
    面对这样的难题,根据华为技术有限公司内推行多年的过程改进实践经验 ,本文提出建      
立具有自优化功能的流程框架,并在此框架指导下激发所有研发人员的激情和潜能 ,使得研      
发流程保持有效、适用,使得流程能成为软件开发的切实指导。      
关键词:过程改进  流程框架      
      
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)
不错,好好学习一下,谢谢!!!
看了楼主的文章,觉得受益非浅,看来在这条路上我还有好多的东西要补充,要学习~
现在搜索“全员过程改进”,思步就是第一了:)希望大家能在思步上好好学习全员改进--不仅仅是过程改进
刚去华为的网站上去看了下,还是有挺多好东东可以学习的嘛;看样子以后要多关注一些大企业的动态.:lol
step365:victory: :lol
:) :victory:
好好学习一下,:lol
好资料,支持

顶了再下,从小养成好习惯
看了楼主的文章,觉得受益非浅
不错啊,不错。呵呵。
谢谢楼主,学习先~
谢谢楼主分享
您需要登录后才可以回帖 登录 | 注册

本版积分规则



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 2007 思步网 浙ICP备10212573号-4(首次备案号:浙ICP备07035264号)|邮箱:service#step365.com(将#换成@)|服务热线:0571-28827450
在线培训课程|求职招聘|思步文库|官方微信|手机APP|思步问答|微博平台|官方QQ群|交流论坛|软件工程透析|关于我们|申请友链|
点击这里给我发消息     点击这里给我发消息
思步 step365 过程改进 CMMI中文 质量保证 质量管理 流程体系 需求跟踪矩阵 敏捷开发 Scrum 软件度量 项目评审 全员改进 流程管理 人力资源 6sigma 信息安全 ISO27001认证 IT服务管理 ISO20000认证 ISO9000认证 软件测试 SQA 配置管理 IPD 软件工程 PMP认证 PMP试题 PMBOK中文 精益研发 agile 顾问式管理培训
返回顶部