为何敏捷将成为主流

公司里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%。不论在美国还是中国，它都将成为主流。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友