为何敏捷将成为主流

 

公司里80后的同事和我聊天时戏称,你们那个时代是20年一个代沟,我们现在4年就一个代沟了。这些年国内各方面的进步实在是在令人目不暇接,在硬件上很多已超过欧美了,在软件和思想上则急起直追。在1978年之前非国营企业的工作是非法的,之后有了小私营企业,但雇用人员在8人以上则被认为是资本主义的剥削。(对于剥削的这个定义,你现在是否觉得不可思议?)根据全国工商联主编的民营经济蓝皮书数据显示,到了2010年,中国私营企业数量占全国企业总数的比例将达到70%以上;全部民营经济占全国GDP比重将达到3/4左右。管理的思想更是产生了翻天覆地的变化,从中枢控制式到分布式,从教导式到启发式。人心思潮会在各个看似不相关的层面都表现出来。软件研发管理则属于其中很小一部分,但也蕴含了很多文化的因素在里面。我个人以为,在未来几年中,敏捷方法将会超越其他几类软件研发方法而成为主流。以下我从四个方向来论证我的推测。

越来越讲求性价比高的商业作风,务实成为主流 - 传统的瀑布研发模式是基于一个理想的假设:需求不会经常变动。在二三十年前,由于硬件太贵,一般软件的大小不及现今软件的百分之一,软件的需求较简单,也不会经常变动,因此瀑布研发模式相当吻合。但现在,需求不会经常变更的软件系统已越来越少了。当使用瀑布方法开发一个庞大复杂的软件时,若因任何原因(如经费不足)没法全部完成,则最终得到的结果可能是每个模块都不太完整或缺陷很多,没法给顾客使用。这导致整个系统都可能被废弃,人力及财力的损失都非常的大。但使用敏捷方法则不然。它在开始时并不需要完整的需求,它的每个迭代都是做最核心(或最常被使用的)的功能,在每个迭代完成时都产生一个可执行的版本。到最后,若因任何原因没法全部完成,所得到的可执行的版本很可能还是个能让大多数人使用的软件,因为在大多时候人们使用的就是那几个核心功能。投资软件开发的风险很高,使用敏捷方法开发软件,即便最后未取得百分之百的成功,总是能得点什么,而不是全盘皆输。

越来越普遍的自下而上的管理模式传统的管理是自上而下的,或者说是中枢控制的。它主要强调的是,高层制定制度,底层照着制度操作。封建社会以及军队的管理就是典型的代表。中枢控制的系统是高效的,但她的中枢一旦出问题整个系统就全崩溃。大多数的电脑软硬件系统都有个中枢,但全球网络已完全不是中枢控制的了。在一般的情况,自上而下的操作可以满足例行的需求。但当需求复杂或特例发生时,问题就来了。詹·卡尔森在他所写的《关键时刻》里讲道,北欧航空公司的服务人员照着制度操作,但这并无法让客户满意,因为只要客户的要求不是在例行的服务范围内,服务人员便拒绝服务。自下而上的管理模式以达到客户满意为目的,授权给一线人员自主的能力,让他们更有创意地去服务顾客,并将问题回馈给上层。詹·卡尔森在试用了这新模式后一年内就让北欧航空公司转亏为盈。同样地,为让员工人尽其才并提高其参与度,越来越多的现在企业已采取了这种管理模式。她们的管理人员更像是其下属的意见收集者及工作协调者,而非发号司令者。敏捷团队里的Scrum Master做的就是意见收集及工作协调,这两种管理者非常相近。为防有的团员的意见被别人左右,敏捷方法里更提供了敏捷扑克,当在估算某个任务所需的工作天数时,每个组员都以敏捷扑克的数目来代表他的估算值。每个人想定个数目后,先将扑克盖住,然后同时翻开。这种对个体意见的尊重,让每个成员都觉得他非常重要的管理方式,不也是社会的一个趋势吗?

越来越多的系统自序列(Sequential)转为并行(Concurrent - 当你去做全身身体检查时,如果该单位规定你一定要做了第一项,才能做第二,然后第三等等,那你一定发现很多的检查站排满了人,而另外也有检查站是没有人的。倘如这次序可以打破,每个人可以随意做他尚未做的检查,那排长队的现象就可以减少,并且所有服务及被服务的人的时间都可以省下来。在工程系统及软件设计上,这种序列和并行的情况也常发生。一旦一个系统可以从序列转为并行,它的效率马上能提高几倍。在研发方法论上,瀑布模式是个典型的序列式,而敏捷则为并行。

急速扩张的个人表现能力和表现欲望有了Web2.0之后,网络博客成了网民表达自我思想的最佳途径。二十年前当人们在唱KTV时,许多人是被逼上去唱的,并且唱得荒腔走板;而现在,麦霸出现了,而且年轻人模仿原唱逼真到令人咂舌的地步。敏捷方法让每个团员都有很充分的表现的机会。不仅他们天天沟通,甚至,有的团队还让其团员从任务列表中自行选择他认为合适的任务去做。但许多的中国软件开发及测试人员都比较内向,这种表现的机会对他们来说未必是件乐事。“尊重权威”及跟风也是比较常见的。或许,由于这些原因,目前敏捷方法未能很快地在国内扩散开来。但我相信,随着个人表现能力的增强,情况很快就会变。

为了证实这推测正确,我查证了美国知名研究机构Forrester Research2009年对100位资深经理问卷调查所发布的数据。该数据显示,30%的被访者说,他们主要的软件开发模式是敏捷方法,38%说他们使用迭代(iterative)方法,另有32%使用瀑布式之类的序列(sequential)方法。相比之下,在2年前的问卷调查中发现仅有8~10%的被访者说他们主要的软件开发模式是敏捷方法。

敏捷团队对个人的能力(如编程、测试及表达等)的要求相对都较高。许多人认为进入圈内的软件团队会很多,但失败的也会很多。是的,我也相信如此,并且失败的多半会调整并再尝试。我相信使用敏捷方法的企业会不断增加,其百分比在未来几年将不断地提高,并会超过50%。不论在美国还是中国,它都将成为主流。

作者为TechExcel中国区总经理 蔡培堃

原文链接:

http://www.techexcel.com.cn/newsevents/relatedarticles/20100312.html

 

 

  • 0
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 6
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值