忘记敏捷

标签: 忘记 敏捷 | 发表时间:2011-09-19 01:05 | 作者:baiyuzhong Guan
出处:http://ucdchina.com/rss/all

瓦沙奇山下那段著名的敏捷宣言,至今已近十年。似乎在不经意之间,敏捷已经被视为 CMM 之后又一次软件开发领域的浪潮,不论业界报道或者坊间传闻,都不约而同地将敏捷视为一个时代的开始,与之同存的是那些未尝或浅尝敏捷者的各种质疑和争论。

当敏捷在介于自发与非自发中间演变成为一种近乎“革命”的运动,围绕在它身边的躁动就不曾停歇,对于细节的争执,对于方法的固执,让我们更多地为敏捷的未来忧心忡忡。我们担心的是,如果敏捷只被认为是实践和方法集合,那么必然有一天在它某次失效或者迫于压力无法延续的情况下,便会被开发团队自然而然地抛弃,他们要做的也只是耐心等待下一次所谓的“革命”。

这时往往被忽略的是第一个要问的问题——为何敏捷。作为从汽车产业精益制造理念衍生出来的敏捷,到底为何产生?敏捷的萌芽和发展与精益理念的传播过程有何共同之处?敏捷将如何发展?当敏捷风潮过后留下什么?只有当这些问题一一被深刻解答和理解,才能让敏捷实践忘记敏捷,真正的敏捷基因才会被持久留存。

精益启示

在这个充满隐喻的软件世界中,各种软件开发方法的思潮都来自于其他某个成熟行业成功经验的映射。理解敏捷的核心,应该从精益制造的灵魂开始。精益的萌芽发展变化在某种程度上契合并预测着敏捷的今生来世。

敏捷之前工业制造世界的基础都建立在“遵循计划”的模型上——在执行之前,需要完成的是计划,这个被设计的计划中规定了资源分配、详细工序、时间线、技能要求等,被认为如果按照计划严格地执行,便可达到预期的成功。那么,当计划在一个可预期的成功之上被设计时,理所当然遵循计划的结果便是这个可预期的成功。

基于这个模型,在 1908~1927 年的 19 年间,福特制造了T型车的神话——在福特设计的流水线上,生产计划被严格地执行,所有的产出物都达到“可预期的成功”。在这 19 年里,福特认为“无论你需要什么颜色的汽车,福特只有黑色”—— 拒绝任何改变,并坚持把计划中可预期的成功作为经营成功的唯一标准。因为市场需求的单一,以及价格的低廉,计划的成功执行与市场经营成功在某种意义上,画上了等号。

而福特T型车的迅速衰落正是在于,当市场需求最终占据了主动时、当企业生产和销售的天平慢慢倾向于销售一方时,计划中“可预期的成功”瞬间变得次要。原因很简单,企业的价值不以生产计划的完成为基础,取而代之的是销售计划的完成。换句话说,如果最终目标是“在一定时间线上用合理的成本生产出产品”,作为企业来说,这样的目标不足以成为企业价值的衡量基准,而真正体现企业价值的是“在一定时间内用合理的成本生产出产品,并让这些产品成功地被用户使用”。

当成功地让用户使用产品变得越来越有风险(用户的需求越来越趋于多样性和变化),使得传统制造工业的从业者无以适从——完成预测的生产计划可以通过内部的管理手段实现,但当生产计划无法完美契合用户需要时,传统生产方式的低效和浪费便暴露无遗。也许关张的不一定都是那些没有在“在一定时间内用合理的成本生产出产品”的企业,但那些没有“让这些产品成功地被用户使用”的企业一定关张。

这样的危机感使得更拥抱变化的精益制造理论得到了迅速发展——如果那些没有被用户使用的产品就是不产生价值的东西,那么更应该关注的不是生产计划的完成,而是生产线那头的东西是不是可以被市场买单。

精益的产生和发展完全契合着汽车消费市场的变革——越来越趋向于关注用户多变和多元的需求。换句话说,一个消费需求变化风险越大的消费市场,必然产生一种对“降低消费需求变化风险”越依赖的生产模式,这个生产模式就是精益。

敏捷非革命

相对汽车行业近 135 年的历史,软件产业仅仅经历了不到 50 年的时间。在软件产业初端将近一半的时间里,就像福特T型车流行的 20 世纪 20 年代,软件并没有足够庞大且多元化的消费市场,世界对于软件的应用多限于工业控制、数据分析、科学研究等领域,以及那些服务于并没有形成足够成熟消费市场的配套软件。“遵循计划”的瀑布式生产模式在很长一段时间里成为软件工程的准则——“在规定的时间和规定的资金投入内,完成规定软件规格的应用”。

接下来,随着个人电脑以及各种消费类电子和通信产品的普及,人类对于信息的需求上升到前所未有的高度。软件终究是连接使用者和信息的接口,当对于信息的需求不仅限于大型制造商、军方、科研人员,而突然趋向于成为普通消费者日常生活的必需品,对软件的需求必然呈现级数增长。于是,软件行业在过去 20 年里的发展趋势是“让更多的人享受到信息服务”,而曾经的高端专业软件市场正在慢慢被信息消费类软件所挤压。

可以这样理解,当一个市场的消费门槛越来越低时,这个市场越有可能变成买方市场,这个市场的消费者层次就越来越丰富,这个市场可能出现的需求变化就越来越频繁,预测这个市场需求变化的难度就越来越高。

这便可以解释为什么越来越多的软件从业者,开始体会到如同汽车普及化运动对汽车行业的影响类似的困惑——单单“在规定的时间和规定的资金投入内,完成规定软件规格的应用”已经不够,必须在后面加上一个“并让这些产品成功地被用户使用”。这种市场需求带来的内部驱动使得人们开始思考一种更加适应市场需求变化的生产模式,像大野耐一的天才创新一样,软件行业也开始像汽车行业一样开始向追逐最终消费者使用价值的方向发展,敏捷方法的诞生正是基于此。

一个行业的成熟,必然经历一个消费市场剧烈分化膨胀的阶段——随着工艺和技术的提高,以及生产成本的降低带来了消费门槛的降低和更多多元化需求,这必然使得涉足其中企业的核心竞争力完成从“按时按量按质生产”到“按时按量按质适应市场生产”的转变。在这个转变的背景之下,必然出现一种生产模式的转变,保证“按时按量按质生产”之外还能保证“这些产品成功地被用户使用”。

汽车消费市场变革发生在汽车行业发展 75 年后的 20 世纪中叶,丰田的精益制造模式成为适应汽车消费市场剧烈变革的主角——快速推向市场,迅速对市场变化作出调整,丰富汽车品种满足多元化需要的丰田在一段时间内成为汽车行业发展的标杆。

同样,在软件行业的发展经历 50 年之后,也开始迎来一次软件消费市场疯狂膨胀剧烈变化的阶段,这个行业的参与者,不得不到殚精竭虑于生产的产品是否能够真正适应市场的需求,把成功交付的标准改变成“在规定的时间和规定的资金投入内,完成规定软件规格的应用,并让这些产品成功地被用户使用”。

而传统的软件开发方法已经无法支持对快速变化的市场变化作出快速反应,换言之,传统的“计划+执行”的模式在当前的市场特质中行不通,在这样存在“巨大需求变化风险”的市场中,不可避免地需要一种能够降低这个风险的生产模式,这个生产模式,就是快速响应变化的敏捷开发方法(见图1)。

图1 汽车消费市场的变革产生了精益制造;软件消费市场的变革产生了敏捷开发

从这个意义上来说,敏捷本身并不是“革命”,真正发生巨大变革的是市场,敏捷只是被市场选中。实践敏捷是软件消费市场变革的结果,驱动敏捷背后的力量是市场。如果敏捷是市场变革背景一次必然的风潮,那么在风潮过后,如果这个市场依然充满变化且专注每一位消费者的价值,那么能够被市场所留存的必是这个充满变革的市场在一开始最需要的东西。

风潮过后

对敏捷的经典误读之一:从“敏捷”的字面出发,认为敏捷是一种快速和高效的开发方式,通过各种实践达到交付能力提升,使交付速度变快。事实上,“敏捷”真正的含义里,“灵活”远大于“高速”,或者说敏捷绝不是提升效率的方法,敏捷是降低变化风险的艺术,即是“拥抱变化”的艺术。换言之,敏捷的精髓在于“拥抱变化”,而正因为这个特质,才使得敏捷越来越被这个越来越充满变化风险的软件消费市场所需要。那么,应该如何理解敏捷的精髓?

灵活应对变化风险的实质在于当需求发生变化时,应对变化的成本最小,而这个成本的组成包括舍弃在这个需求上的已投成本、修改其他关联需求的修改成本和额外投入的新成本。我们不难看出,额外投入的新成本基本由需求本身决定,为固定成本,而舍弃的已投成本和关联的修改成本是可以通过某些手段降低的可变成本。这便是敏捷“拥抱变化”的两个核心之所在(见图2)。

图2 拥抱变化的实质

1. 在需求发生变化前,不在或者尽可能少地在这些发生变化的需求上投入任何工作量;

2. 当需要发生变化时,不在或者尽可能少地在可能影响的其他功能上产生任何工作量;

而敏捷几乎所有实践活动的实质都围绕在这两个核心上。让我们从敏捷中几个经典实践出发看它们是如何体现这两个核心的,它们是:用户故事、迭代交付、重构和持续集成。

1. 用户故事:将客户的需求拆分成不同的用户故事,每一个用户故事代表一个独立的业务价值,对于未来不确定的潜在特性(变化风险最大),用用户故事的方式占位(Placeholder),当需求发生变化时,尽量只影响其中的一个用户故事(最好的情况是之前预估过风险还未进入开发),而不影响其他用户故事的业务价值;

2. 迭代交付:将需求放在不同迭代进行交付,每个迭代都给予客户对下个迭代需求进行变化的机会,当需求变化真正产生变化时,还没有实质的开发工作量产生;

3. 重构:鼓励持续地对系统架构进行优化和重构,降低系统的耦合程度,让一个需求的变化不会或尽可能少的对现有的其他功能产生额外的工作量;

4. 持续集成:大量使用自动化测试和构建持续基础环境,让可能产生于每次提交的缺陷(对现有功能的影响)及时暴露,越早发现,越减少可能产生在被影响的其他功能上返工工作量。

市场的变革是敏捷方法风潮背后的推手,如果市场真正需要的是一种适应消费需求充满变化的生产模式,那么很有可能,敏捷作为一种方法论,有天也会被某种更新的理念替代。但是能够肯定的是,软件消费市场将会在更长的时间内趋向于满足日益多元化的消费群体充满变化的需求,因为敏捷“拥抱变化”的基因,这场市场的变革选择了敏捷,如同汽车消费市场选择了精益,那么当风潮有天退去时,“拥抱变化”的基因必然被留存,无论冠以敏捷之名或是其他。

同时应该指出的是,软件消费市场仍然存有部分消费需求变动较小的市场,包括稳定的工业自动控制、数据分析和科研研究等领域。在这一市场里,对于市场变化的风险控制成本较小,以敏捷所包含的“拥抱变化”的基因,并没有足够优势完全替代传统“计划+执行”的开发方式。因此,在可预见的未来,敏捷或任何一种可能出现的“拥抱变化”的开发方法会在一定时期内与传统开发方法共存。

不可否认,敏捷正在风行,绝大部分敏捷实践者的关注点自然都在敏捷本身,而我们往往陷于的误区是——因为它是敏捷的东西,所以我们要实践。那么,当敏捷风潮退去或者对敏捷的效果产生疑问,我们的反应往往会变成——敏捷已经不流行或者敏捷已经证明不适合我们,那么我们没有理由继续实践敏捷的东西。如果仅仅把敏捷当成一种风潮之下的流行物,最有可能发生的事情在于,现在如火如荼实践的敏捷方法的任何一种,都有可能突然在某天被团队所抛弃而不能延续。

图3 实践敏捷的根本不在于敏捷本身,而在于理解敏捷背后拥抱变化的基因

当我们深刻理解敏捷背后,“拥抱变化”被这个充满变化的市场所需要的基因,明白我们做的每一件事都是让我们在面对变化时从容不迫,让我们制造的产品能够满足更多消费者的需求,创造更加多元化的需求。而不是因为,某个深不可测的大师或是高屋建瓴的咨询师不遗余力地鼓吹敏捷的神奇。只有这样,我们的实践才能够真正为我们的交付产生实效性的价值,并能在更长的时间内坚持,哪怕有天没有人谈起敏捷,那个藏在敏捷最里面的基因一直可以留存。实践敏捷,请忘记敏捷(见图3)

源地址:http://www.programmer.com.cn/8240/

相关 [忘记 敏捷] 推荐:

忘记敏捷

- Guan - 所有文章 - UCD大社区
瓦沙奇山下那段著名的敏捷宣言,至今已近十年. 似乎在不经意之间,敏捷已经被视为 CMM 之后又一次软件开发领域的浪潮,不论业界报道或者坊间传闻,都不约而同地将敏捷视为一个时代的开始,与之同存的是那些未尝或浅尝敏捷者的各种质疑和争论. 当敏捷在介于自发与非自发中间演变成为一种近乎“革命”的运动,围绕在它身边的躁动就不曾停歇,对于细节的争执,对于方法的固执,让我们更多地为敏捷的未来忧心忡忡.

敏捷

- - 人月神话的BLOG
对于敏捷开发,我前面其实已经有很多文章提到了,再次强调下敏捷的核心思想个人理解为三个重要的方面. 其一是需求的条目化并以需求点进行的全程追踪和跟踪;其二是短周期迭代;其三是基于持续集成思想的进度和质量可视化. 对于敏捷开发本身,对于很多内容我仍然坚持自己的观点,具体如下:. 对于大型全新系统的开发,如果是以底层数据为核心的业务系统,则不能单纯的应用敏捷开发.

在敏捷

- - 崔凯
这是在 www.scrum.org 网站上轮播的一张图,网站上 SCRUM GUIDES 一栏,详尽的介绍了敏捷开发的方式和方法,有兴趣的可以看一下. 这里仅谈一下 Scrum 怎么玩更舒服. 回到那张图,想玩的舒服,一起聊聊很重要. Scrum 不是定死的一种模式,每个团队有每个团队的玩法. 通过不断的磨合、反思、改进,形成最适合自己团队的模式.

敏捷个人和敏捷开发

- beralee - 博客园-首页原创精华区
    自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开发的一种主流方法. 没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来新的问题. 我在今年6月份上海举办的ScrumGathering中进行了一场敏捷个人话题的分享,我说到,想要Doing敏捷并不难,只要花上几天功夫学习敏捷知识之后就可以在小范围团队中去实践了,而要做到真正的Being敏捷则并不容易,而导致并不是真正敏捷的原因中,人是一个主要问题之一,这也是为什么现在敏捷社区中对人开始越来越关注的原因.

敏捷中国2011

- Ben - 梦想风暴
果然是按照个人规律来的,我又参加了单数年的Agile China. 其实,真正仔细听的只有两个人的session,吴军和Fred George. 至于其它关于敏捷的讨论,好吧,我承认,我不是很感兴趣. 刚看完吴军的《浪潮之巅》,于是,很敢兴趣他关于工程师的说法. 在《浪潮之巅》里,他提到了五级工程师的说法,但是,书中并没有详述何为五级工程师,在敏捷中国上,他给出了答案:.

敏捷开发——Programmers(27)

- plidezus - 西乔的九卦
载于《程序员》杂志2011年第7期. 从这一期起,开始在杂志上登出整P的大幅漫画,需要看大图的同学们,讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件.

漫谈敏捷开发

- scotty - ITeye论坛最新讨论
软件开发是一种非零和博弈,意思是某一方的获得不是建立在另一方的损失之上,所以软件开发必须实现双赢,帮助客户成功的同时帮助自己成功. 如:通过软件帮助客户把手上的5块钱变成50块钱,然后从客户那里拿5块钱. 通过软件帮助客户节约50块钱,然后从客户那里拿5块钱. 传统的汽车制造是以计划驱动,如根据往年的经验判断今年应该生产多少汽车,但是这样带来的问题是有可能等汽车生产出来,市场已经不需要了,而这就是一种极大的浪费.

敏捷不能当饭吃

- stern - BlogJava-首页技术区
喜欢敏捷的很多想法,喜欢它务实的态度. 我说“敏捷不能当饭吃”,当然不是说敏捷无用,相反,我倒是挺推崇敏捷的. 之前有两篇文字都涉及到一些对敏捷的看法. 一篇是 与神对话,另一篇是 对敏捷的一些想法. 只是看到很多人好像敏捷是他爷爷写的一样,龟孙子似地迷信和追捧敏捷,把工作一条一条跟书上描述的对照,一旦工作中实际操作跟书上有不一致,口诛笔伐,吐沫拳头无影腿就一齐上来了,那就太过了.

设计师谈敏捷

- xg - 所有文章 - UCD大社区
腾讯一直推广敏捷开发,也在强调敏捷开发,但你会发现,即便如此,还是会陷入以下情景. 我们如何构建一个更轻巧的开发流程,让我们更快更好的交付结果. 作为一个设计师,如何成为敏捷的一分子. 以下是一些心得方法,希望和大家分享. 作为设计师,最简单能让大家明白你的想法就是先把它画出来,不要用晦涩的语言和结构图,毕竟不是所有人都能把你的语言转化为图像.