求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
敏捷活动中的系统思考
 

发布于2013-7-29

 

1 引言

近期,我所在的组织(软件研发单位)开始了轰轰烈烈的由传统的管理方式向敏捷转型工作。我们希望通过敏捷,提高研发效率和产品质量。但是,随着时间的推移,发现敏捷并非良药,上上下下对敏捷的热情逐渐消退,敏捷正逐渐走向“灭亡”。

是敏捷对提高效率没有帮助吗?是敏捷在传统企业里面水土不服吗?怎样才能在做好敏捷呢?

本文试图从实际出发,结合系统思考,来反思我们的敏捷。希望这个反思过程,能够给准备进入敏捷,或者正在敏捷中纠结的团队提供参考。

2 敏捷之初——增强环路

图1 敏捷之初——增强环路

敏捷开始之初,领导热情高涨,敏捷推行风风火火,是一个典型的增强环路。(该模型的具体信息,可以参考《第五项修炼》)。

敏捷试点,培训,敏捷推广——敏捷活动“全面”铺开。

开发和测试不打架了,沟通效率明显提升,里程碑的压力被迭代活动稀释了——团队自组织程度提高明显。

需要特别强调的是,在敏捷活动中,管理实践和技术实践会有很多具体的问题。这些问题会制约敏捷活动的进行,不在本环路中体现,后续有机会再开帖子讨论。

3 敏捷之中——成长上限

虽然敏捷有诸多好处,但是,我需要很遗憾的告诉大家,跟所有的增强环路一样,一定有一个平衡环路制约增强环路的成长空间。如图2所示。在敏捷到一定程度时。团队自组织程度提高,工作过程中诸如详细设计、同行评审、内部故障等等表现形式和传统的软件管理大相径庭。对传统管理带来了威胁:

1) 基层组织自我管理——管理层架空了;

2) 敏捷详细设计等研发过程不能在传统的系统中登记——管理过程对象隐形了。

和大多数公司一样,作者所在的组织的管理层,对传统管理持保守态度。他们希望管理可控,他们希望管理架构不要做大的变化;他们也希望敏捷做的越来越好,甚至希望能在冬天里燃气一把火——这在某种程度上加速了敏捷活动在组织中的消亡。因为成长上限模型决定了这一结果:当平衡环路发挥较强作用时,加速推动增强环路,不但不会取得很好的效果,甚至有可能引起增强环路反转。

图2 敏捷之中——成长上限

现实的系统往往是很复杂的。作者所在的组织。在敏捷推行到一定程度时,平衡环路发挥作用,同时内部力量继续猛烈的推动增强环路。敏捷活动中出现了三种情况:

1) 有追求型——想尽一切办法,延缓甚至解除平衡环路对团队自组织程度的制约

2) 因势利导型——一方面降低对传统管理的威胁,一方面推动敏捷,稳打稳扎

3) 放弃型——不搞敏捷了,爱咋咋地

下面我们用三个小节详细展开。

4 有追求型

图3 有追求型

有追求型的敏捷团队这样的特点:

有一个强势的团队领导者,拥抱敏捷,对敏捷理解很深,可以跟管理层叫板。

通过强势的敏捷团队领导者的操作,传统管理层的威胁对团队自组织程度的影响大大延迟。敏捷活动这个增强环路可以在相当长一段时间,获得成长空间。

在有追求型的团队里面。还有一些要素需要注意

1) 需要优秀的敏捷实践指导。这样可以及时解决敏捷实践中的管理和技术问题(例如TDD),提高团队的敏捷积极性。

2) 一个合适的项目。那种工期紧,现场问题多就算了。合适项目最好是只用一种编程语言,没有太大工期和现场压力的技术型项目。

3) 几个技术骨干。如果全部是技术骨干,对其他项目会有较大影响。如果全部是新手,肯定也是玩不转的。

4) 对敏捷中的实际问题,不回避。敏捷是一种能力,需要通过实践,踏踏实实做出来,敏捷来不得半点忽悠。

很可惜,作者所在的团队不是有追求型团队。对于有幸在传统自组织中,进入到有追求型团队的兄弟,希望好好把握,在不久的将来,能够得到敏捷的精髓,进而诞生推动更多有追求的敏捷团队诞生。

5 因势利导型

在因势利导型的团队中,没有一个强势领导。换言之,就是对敏捷活动的支持力度跟上面是一致的。如果自组织团队程度影响到传统管理,他会毫不犹豫的和传统管理站在一起。

在因势利导型团队里面,一般会有两种手段来推进敏捷。

方式1:做好传统管理要求的事情

方式2:延迟传统管理对团队自组织程度的影响

上图:

图4 因势利导型

在方式一中,我们把传统管理要求的平时、设计做好,使得管理层可以“看到”传统管理的对象,从而降低对传统管理的威胁,给敏捷活动创作空间。

在方式二中,我们将传统管理的威胁,通过多层管理过滤和旁路模式(分给其他团队)的方式,延迟传统管理的威胁。这种方式,和有追求型的敏捷团队最大的区别在于延迟的力度或者时间。在本类型中,这个延迟相对来说,是比较“脆弱”的。

6 放弃型

放弃型团队是这样一种状况:管理层驱动,团队在没有做好准备的时候“被敏捷”;团队领导和团队成员缺乏对敏捷的深入理解和认同。当敏捷活动遇到困难或者团队自组织程度收到传统管理的威胁时,团队敏捷积极性急剧下降,最后就是不了了之。

在这样的团队,基本上就是浪费时间,唯一的收获可能就是对敏捷的“恶感”。

7 杠杆解

从成长上限模型可知,通过杠杆解发力,可以事半功倍的解决问题。在敏捷活动中,杠杆解即“管理层的目标”,如图5所示。

图5杠杆解

需要说明的是,所谓的杠杆解对应的管理层,一般不是公司老总,而是能够对敏捷的组织形式,资源分配,考核等有决策权的管理者。

当然,不是说敏捷跟公司老总没有关系。实际上,敏捷跟公司老总有关系,关系在哪儿呢?在于企业文化。我个人认为,敏捷是有适合的企业文化的。传统的指令型(老大绝对正确性)企业,搞敏捷是有很大风险的。如果敏捷决策管理者对敏捷理解正确,那么,一切可能会朝着OK的方向进行。否则,就有很大可能产生巨大的浪费,甚至造成公司挂掉。

因此,在一个组织里面,要搞好敏捷,首先要搞定管理者。

我们假设大部分企业都是指令型企业(这可能是中国软件研发的普遍状况)。那么在敏捷开始之初,一定要仔细考评敏捷管理决策者对敏捷的理解。如何考评呢:

1) 读过《人件》,《人月神话》

2) 理解敏捷宣言,敏捷的原则

3) 理解敏捷实践,包括实践的普遍性和特殊性。敏捷的技术实践,在特殊性方面表现的尤为突出。如果一个组织有多重技术架构,那么,就会需要对应的技术实践。甚至,有些产品可能压根就做不了某些技术实践,比如TDD。

4) 理解敏捷的组织,评价

5) 理解敏捷适应的环境(高级要求)。不是每一个产品都适合敏捷。

8 结语

关于敏捷,网上有很多前辈做了很多精彩的论述。本文仅从系统思考的角度对敏捷做了一些简单的思考。希望对大家有一点点帮助。总之,就我个人参与敏捷的过程而言,敏捷整体而言是个好东西,但是需要合适的整体环境,才能很好的成长。否则,极有可能得不偿失。

 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证
 
分享到
 
 

相关文章
由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   

相关培训课程
统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行

成功案例
某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...