思步网

查看: 88823|回复: 49
打印 上一主题 下一主题

为何敏捷将成为主流

  [复制链接]
公司里80后的同事和我聊天时戏称,你们那个时代是20年一个代沟,我们现在4年就一个代沟了。这些年国内各方面的进步实在是在令人目不暇接,在硬件上很多已超过欧美了,在软件和思想上则急起直追。在1978年之前非国营企业的工作是非法的,之后有了小私营企业,但雇用人员在8人以上则被认为是资本主义的剥削。(对于剥削的这个定义,你现在是否觉得不可思议?)根据全国工商联主编的民营经济蓝皮书数据显示,到了2010年,中国私营企业数量占全国企业总数的比例将达到70%以上;全部民营经济占全国GDP比重将达到3/4左右。管理的思想更是产生了翻天覆地的变化,从中枢控制式到分布式,从教导式到启发式。人心思潮会在各个看似不相关的层面都表现出来。软件研发管理则属于其中很小一部分,但也蕴含了很多文化的因素在里面。我个人以为,在未来几年中,敏捷方法将会超越其他几类软件研发方法而成为主流。以下我从四个方向来论证我的推测。
越来越讲求性价比高的商业作风,务实成为主流 - 传统的瀑布研发模式是基于一个理想的假设:需求不会经常变动。在二三十年前,由于硬件太贵,一般软件的大小不及现今软件的百分之一,软件的需求较简单,也不会经常变动,因此瀑布研发模式相当吻合。但现在,需求不会经常变更的软件系统已越来越少了。当使用瀑布方法开发一个庞大复杂的软件时,若因任何原因(如经费不足)没法全部完成,则最终得到的结果可能是每个模块都不太完整或缺陷很多,没法给顾客使用。这导致整个系统都可能被废弃,人力及财力的损失都非常的大。但使用敏捷方法则不然。它在开始时并不需要完整的需求,它的每个迭代都是做最核心(或最常被使用的)的功能,在每个迭代完成时都产生一个可执行的版本。到最后,若因任何原因没法全部完成,所得到的可执行的版本很可能还是个能让大多数人使用的软件,因为在大多时候人们使用的就是那几个核心功能。投资软件开发的风险很高,使用敏捷方法开发软件,即便最后未取得百分之百的成功,总是能得点什么,而不是全盘皆输。
越来越普遍的自下而上的管理模式– 传统的管理是自上而下的,或者说是中枢控制的。它主要强调的是,高层制定制度,底层照着制度操作。封建社会以及军队的管理就是典型的代表。中枢控制的系统是高效的,但她的中枢一旦出问题整个系统就全崩溃。大多数的电脑软硬件系统都有个中枢,但全球网络已完全不是中枢控制的了。在一般的情况,自上而下的操作可以满足例行的需求。但当需求复杂或特例发生时,问题就来了。詹·卡尔森在他所写的《关键时刻》里讲道,北欧航空公司的服务人员照着制度操作,但这并无法让客户满意,因为只要客户的要求不是在例行的服务范围内,服务人员便拒绝服务。自下而上的管理模式以达到客户满意为目的,授权给一线人员自主的能力,让他们更有创意地去服务顾客,并将问题回馈给上层。詹·卡尔森在试用了这新模式后一年内就让北欧航空公司转亏为盈。同样地,为让员工人尽其才并提高其参与度,越来越多的现在企业已采取了这种管理模式。她们的管理人员更像是其下属的意见收集者及工作协调者,而非发号司令者。敏捷团队里的Scrum Master做的就是意见收集及工作协调,这两种管理者非常相近。为防有的团员的意见被别人左右,敏捷方法里更提供了敏捷扑克,当在估算某个任务所需的工作天数时,每个组员都以敏捷扑克的数目来代表他的估算值。每个人想定个数目后,先将扑克盖住,然后同时翻开。这种对个体意见的尊重,让每个成员都觉得他非常重要的管理方式,不也是社会的一个趋势吗?
越来越多的系统自序列(Sequential)转为并行(Concurrent) - 当你去做全身身体检查时,如果该单位规定你一定要做了第一项,才能做第二,然后第三等等,那你一定发现很多的检查站排满了人,而另外也有检查站是没有人的。倘如这次序可以打破,每个人可以随意做他尚未做的检查,那排长队的现象就可以减少,并且所有服务及被服务的人的时间都可以省下来。在工程系统及软件设计上,这种序列和并行的情况也常发生。一旦一个系统可以从序列转为并行,它的效率马上能提高几倍。在研发方法论上,瀑布模式是个典型的序列式,而敏捷则为并行。

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

为了证实这推测正确,我查证了美国知名研究机构Forrester Research在2009年对100位资深经理问卷调查所发布的数据。该数据显示,30%的被访者说,他们主要的软件开发模式是敏捷方法,38%说他们使用迭代(iterative)方法,另有32%使用瀑布式之类的序列(sequential)方法。相比之下,在2年前的问卷调查中发现仅有8~10%的被访者说他们主要的软件开发模式是敏捷方法。
敏捷团队对个人的能力(如编程、测试及表达等)的要求相对都较高。许多人认为进入圈内的软件团队会很多,但失败的也会很多。是的,我也相信如此,并且失败的多半会调整并再尝试。我相信使用敏捷方法的企业会不断增加,其百分比在未来几年将不断地提高,并会超过50%。不论在美国还是中国,它都将成为主流。

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



上一篇:QC七工具之排列图
下一篇:六西格玛管理培训心得体会
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
回复 论坛版权

使用道具 举报

是啊,这是一个趋势!
支持,赞一个
沙发???
鼎力支持!!
好帖是需要鼓励的~
很有见地的探讨,先收藏着~
众里寻他千百度,蓦然回首在这里!
路过 帮顶 嘿嘿
没人回帖。。。我来个吧!
支持,赞一个
看起来好像不错的样子
众里寻他千百度,蓦然回首在这里!
支持,赞一个
很有见地的探讨,先收藏着~
您需要登录后才可以回帖 登录 | 注册

本版积分规则



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 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 顾问式管理培训
返回顶部