写点什么

讨论:敏捷不是什么?

2007 年 12 月 11 日

在 InfoQ 中文站前不久的文章“敏捷与产品开发”和“一个敏捷教练中止越轨列车的故事”中,读者展开了热烈的讨论。有趣的是,这些讨论的主题很大程度上围绕着“敏捷不是什么”展开。正如读者“小刀”在评论中所说的:

“敏捷开发中很重要的一个环节是发现问题,从根源上解决这个问题”,但是,难道不使用敏捷开发的软件开发流程,“发现问题解决问题”就不是它们的重要环节了么?当韩非子说“千丈之堤毁于蚁穴”的时候,敏捷在哪里?

一种理论适用的范围越狭窄,它对实际工作的指导意义就越明确;相反,放诸四海而皆准的理论通常没有实际的指导意义。但随着“敏捷”这个词逐渐成为热门词汇,越来越多的人开始往其中揉进越来越多的意义,也让敏捷的真正内涵变得越来越模糊。就像 Ivar Jacobson 在“敏捷究竟是什么”一文中所说的:

我们曾经处于一种极端——做一切事情都必须使用 UML,并象大多数人一样坚信它能够规范软件工程过程。同时,我们又倒向了另一个称为敏捷的极端。……现在,每一个人都是敏捷的。这当然啦,敏捷之外的其他事情都是愚蠢的。

当每个人都说自己坚持软件工程时,我们看到了很多对软件工程的误解和误用。那么这一次敏捷是在重蹈覆辙吗?和以往流行的东西一样,有人认为“敏捷其实更强调一种包容与和谐的文化”。事实是这样吗?从 Ivar Jacobson 的描述中似乎看不出敏捷是如此强调“文化”:

敏捷是关于以下三件事情的:敏捷是一门社会工程学。敏捷是轻量级的。敏捷提供技术实践。
我们必须用新的观念来看待实践。我们不再谈论过程,实践已经取而代之,成为一等公民。过程仅仅是实践的组合。

看起来 Ivar Jacobson 更愿意把敏捷看作一组最佳实践的组合。毕竟正如 ThoughtWorks 中国公司总经理郭晓所说,“敏捷的目标是消除浪费”。而把它无限拔高成为一种“文化”对于企业消除浪费有什么实际的帮助呢?另一种对敏捷的置疑之声是关于实施敏捷的效果的:

我们经常看到一些号称 Agile 的国内项目,按照菜谱、操作指南和教父语录的提示,采用了许多花哨的技巧和实践(做法),是啊,表面上确实 Agile 了,那么结果呢?项目还是不能按时完成,甚至严重超支和超时,这能叫“敏捷”吗?

可以看出,一些对敏捷缺乏了解的同行和甲方代表又把这个时髦的新词汇当作了万灵药:按照他们的逻辑,如果做好了敏捷,项目就一定能够按时完成,预算也不会超支的。首先,不难看出这是一个无法兑现的承诺:开发团队是有其能力极限的,超出他们能力极限的项目无论如何也无法按时按预算完成,不管用不用敏捷。如果把敏捷当作一种宗教信仰来看待,认为项目不成功就一定是没有做好敏捷的话,就可能让真正的问题从眼前滑过。另一方面,“按时按预算完成”是衡量项目成功的唯一标准吗?Martin Fowler 在 2006 年接受赛迪网采访时曾讲过一个真实的故事:

这个项目是给一家公司做在线贸易系统,有一个功能是从各种各样的来源采集数据。在项目刚开始不久,我们就展示给客户看我们能采集到哪些数据。客户看到了这些数据以后,表示希望做一些查询;但是开发团队发现用户界面上没法做这个查询。经过几分钟讨论之后,用户意识到他们并不需要 UI 来做这个事情,只要把查询的结果发到他的信箱就可以了。于是我们这样做了,一周后用户就可以得到查询的信息,而仅仅这个查询功能就已经值得整个项目迄今为止所有的投入。

如果只把眼光放在“按时按预算完成项目”上,这个振奋人心的故事或许就不会发生了。作为一种软件开发方法学,敏捷不仅改变了程序员们开发软件的手段和方式,客户看待项目的方式也需要随之改变。正如“敏捷中国”讨论组的创始人李默在“客户协作 over 合同谈判”一文中所说:

如果签订固定价格合同,客户会倾向于在这个价格内挤入更多的需求,而开发公司会希望在这里面减少成本。最终两方博弈的结果就是项目出了问题。这种情况下,更好的办法是单价合同,或者具体说,就是确定阶段时间内的开发力量,但不确定开发范围的收费方式。按照客户需求的优先级来开发,双方合作,尽最大的努力,频繁交付。这种做法的好处是,客户可以控制项目的长短。可以不停的做下去,也可以立即随时终止。由于双方的协作,开发公司也会按照自己的能力,尽最大可能来保证质量和进度。

不难想象,在这种合作模式下,“按时按预算完成项目”已经不再是一个有效的衡量标准,因为项目的时间和预算都是动态调整的。在敏捷项目中,衡量项目成败的标准是:在合作的时间里,乙方能给甲方创造多大的价值。而这也是甲方真正在乎的。最后(但绝不是最不要紧的),敏捷是否就意味着“做得快”?Jim Highsmith 在他的《敏捷项目管理》一书中这样写道:

敏捷是指在动荡的业务环境中,适应变化并创造变化,从而获得价值的一种能力。同时敏捷是平衡灵活性和稳定性的一种能力。

由此可见,望文生义地把“敏捷”理解为“做得快”也颇可商榷:如果缺乏有效的实施指导、忽视严格的敏捷实践,单凭着高层面的理解甚至“文化”就开始盲目前行,往往会因为缺乏对质量的有力保障而失去平衡,最终欲速则不达。作为总结:敏捷不是放诸四海而皆准的通用理论;敏捷不是玄而又玄的文化;敏捷不是在传统项目合作模式下包治百病的金丹;敏捷不是抛开纪律盲目求快。除了这些,敏捷还不是什么?

2007 年 12 月 11 日 03:20560

评论

发布
暂无评论
发现更多内容

架构师训练营第一期第十一周总结

Leo乐

极客大学架构师训练营

极客时间架构 1 期:第 11 周 安全稳定 - 命题作业

Null

Week7 性能优化学习总结

evildracula

学习 架构

第十一周作业

Meow

LeetCode题解:55. 跳跃游戏,贪心,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

Week7 作业

evildracula

学习 架构

架构师训练营第十一周总结

月殇

极客大学架构师训练营

极客时间架构 1 期:第 11 周 安全稳定 - 学习总结

Null

安全稳定

wing

极客大学架构师训练营

nodejs事件和事件循环简介

程序那些事

事件驱动 nodejs 事件循环 异步编程 程序那些事

架构师训练营第一期第十一周作业

Leo乐

极客大学架构师训练营

一文彻底搞懂前端监控

执鸢者

前端 前端监控

架构师训练营第七周小结

韩儿

架构师训练营第2期 第7周命题作业

月下独酌

极客大学架构师训练营

架构词典:逻辑

lidaobing

架构 逻辑

架构师训练营第七周作业一

韩儿

架构师第二期 第7周总结

月下独酌

极客大学架构师训练营

【第十一周】课后作业

云龙

架构师 01 期,第十一周课后作业

子文

第 7 周 系统架构总结

心在那片海

架构师训练营第 1 期 week11

张建亮

极客大学架构师训练营

第 11 周 怎么又翻车了???

Pyr0man1ac

第 7 周 系统架构作业

心在那片海

架构师训练营 - 第 11 周课后作业(1 期)

阿甘

架构师训练营第七周作业

李日盛

性能测试

第十一周 架构方法学习总结 —— 安全稳定

兵长

安全架构 高可用架构

冰河开源了全网首个完全开源的分布式全局有序序列号(分布式ID)框架!

冰河

分布式架构 雪花算法 分布式ID 全局序列号 全局唯一ID

架构师训练营第 7 周学习总结

菜青虫

极客大学架构师训练营

第十一周学习总结

Meow

架构师训练营第十一周课程笔记及心得

Airs

11 安全稳定课后作业

ABS

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

讨论:敏捷不是什么?-InfoQ