QCon全球软件开发大会9折优惠倒计时,了解详情 了解详情
写点什么

20 年起义,敏捷已死,敏捷万岁

2021 年 8 月 31 日

20年起义,敏捷已死,敏捷万岁

开发者,你们真的享受到敏捷开发的好处了吗?


敏捷宣言(Agile Manifesto,敏捷软件开发)诞生至今刚好 20 年,有两个事实似乎不言自明。


  1. 作为一个标签,敏捷是胜利者;没有人希望被称为“非敏捷”。

  2. 但敏捷在实践上和创始人的革命性思想相去甚远。


我们是怎么走到这一步的?大家都说自己敏捷,但是很少有人真的敏捷。

宣言从何而来


2001 年 2 月,由 17 名软件专家组成的小组在数天的的讨论和辩论后,共同撰写了《敏捷软件开发宣言》(Agile Software Development Manifesto)。


首先要强调的是,这些人是实践者,并非项目经理、首席技术官或工程副总裁。他们是开发者、程序员、科学家和工程师。他们仍然在一线编写代码,并与他们的利益相关者合作,共同解决问题。这非常重要。


笔者注:我并不了解每一个签署人的个人历史,但是在我认识的人当中,他们要么还在编写代码,要么写代码写了很长时间。


还有一点是,《敏捷宣言》并不是凭空产生的。很多人已经有了他们自己创造的方法论,并且正在宣传。也许我的记忆有些偏离,但是我想所有这些方法在“敏捷”之前就已经存在了。极限编程(Extreme Programming,XP)、Scrum、DSDM、自适应软件开发、Crystal、特征驱动开发(Feature-Driven Development,FDD)、实用主义编程。Schwaber 和 Sutherland 曾在 1995 年公开讨论过 Scrum;我印象中 Beck 和 Jeffries 在 1996 年就开始谈论极限编程了。


这个小组中的每个人都有编写软件的丰富经验,他们都在寻求一种方法来代替重量级的文档驱动开发过程。宣言的核心有四项价值陈述:


我们身体力行同时帮助他人来探索开发软件的更佳方式,进而认可下列价值:


  • 个体和互动高于过程和工具。(Individuals and interactions over processes and tools.)


  • 可工作的软件高于详尽的文档。(Working software over comprehensive documentation.)


  • 客户合作高于合同谈判。(Customer collaboration over contract negotiation.)


  • 响应变化高于遵循计划。(Responding to change over following a plan.)


曙光乍现


站在 2021 年往回看,我们可以轻易地认为现代软件开发的许多实践是理所当然的,但是在 2001 年,这些想法都非常激进


你说你要在收集所有需求并评估每一个特征之前就开始开发软件?你绝对是疯了。


实际上,敏捷从一开始就公开且激进地反对项目管理。举例来说,Ken Schwaber 就曾直言不讳地表示,他的目标是解雇所有的项目经理——不只是让这些人离开他的项目,而是要将这个职业从行业中铲除。


敏捷性与 PMI


我们发现,在复杂的创造性工作中,项目经理角色会起反作用。作为项目计划的代表,项目经理的思维会将项目中其他人的创造力和智慧限制在计划范围内,而不是调动每个人的智慧去最好地解决这些问题。


——Ken Schwaber,宣言签署人和 Scrum 共同创始人


Scrum Master 在这个问题上没有什么权威,也没有投票权。他们是仆人型的领导者,帮助保护和疏通团队,但不能管理团队。极限编程也是如此。假如我没记错的话,极限编程最初有跟踪者和教练,它们的气氛很像,都是大家互相鼓励和支持。


Alistair Cockburn(敏捷宣言签署人,水晶方法论 Crystal methodology 和六边形架构 Hexagonal architecture 创始人)最近对这一问题提出了非凡而深刻的见解,包括这一观点(转述):


Scrum 在充满敌意的领域中达成了一桩伟大的交易:


1. 管理层每年有 12 次机会,在每次 sprint 结束后,以他们希望的方式改变方向。


2. 团队有一整个月的安静时间,没有任何干扰或者方向的改变,可以进行大量的思考和工作。


3. 在没有管理层干预的情况下,团队必须宣布他们在本月能做什么,不能做什么。没有哪位高管能得到比这更好的交易。没有哪个开发团队能得到更好的交易。


作为一名认证的 Scrum Master,我在敏捷团队里工作超过 15 年,我阅读过该领域的许多流行书籍。在这方面,我从来没有见过任何人能够如此清楚、简明扼要地阐述这一观点(再次引用 Cockburn):


Scrum 的发明是为了在恶劣的环境下工作。它是一个强硬的管理者与开发者之间的契约,需要时间思考和探索。


反击战


从某种意义上说,敏捷是一场源自基层的劳工运动,从基层工作者开始,然后被推到管理层。为什么会成功呢?


部分原因是因为开发者的数量以及他们对公司的价值不断增加,从而获得了影响力。我认为最大的因素是,传统的瀑布开发方法并不可行。由于软件变得越来越复杂,业务变更的速度更快,用户的复杂性更高,预先计划每件事情都变得不可能。采用迭代式开发更合乎逻辑,尽管对习惯于计划所有事务的管理者来说有些可怕。


在 2000 年代中期的会议上,你能看到管理层并不买账,但是他们已经没有更好的主意了。


接着,令他们吃惊的是,敏捷开始慢慢奏效了。团队需要奋斗一段时间,然后慢慢成长,找出哪种模式更适合自己,并获得发展的动力。经过几次 sprint 之后,你会发现在优先考虑工作软件、协作、花时间检查、适应以及其他所有方面的真正力量。


敏捷花了 5 年左右的时间,从一种你听说过但可能从未使用过的的方法变成了每个人都在做的事情。在 2005 年,我换了工作,我还记得我当时只是对敏捷略有了解,而 TDD 才是真正的不同。2010 年,人们认为现代的软件团队都在进行某种形式的敏捷开发。


我们做到了!我们赢了!恭喜各位!


我非常希望故事到此结束。你可以关闭浏览器的标签页了。


赢很轻松,年轻人,治国才更艰辛。(Winning was easy, young man. Governing’s harder.)


——百老汇音乐剧《汉密尔顿》(Hamilton)中乔治·华盛顿的歌词


遗憾的是,像许多革命一样,敏捷并不像创始人预想的那样发展。


  • 事实证明,优先考虑个体和互动是一个很难推广的概念。销售过程和工具要容易得多。

  • 事实证明,比起不切实际的计划和堆积如山的文件,工作中的软件更难生产。

  • 事实证明,与客户合作需要信任和脆弱性,而这在业务环境中并不总是如此。

  • 事实证明,对于那些想要控制局面、同时又需要为自己的业务制定长期计划的高管来说,应对变化往往显得不够重要。


事实证明,敏捷做得不好,就会让人感觉很混乱。


但这并不意味着这四种价值观都错了。这只意味着整个事情需要更多努力才能做好,也需要一些勇气去接受软件有时候本来就混乱无序的。你必须了解并相信,如果你一直在学习、适应、改进和提升,你最终将达到一个更好的境界,这比使用瀑布方法更诚实、更现实、更富有成效。


敏捷运动并不反对方法论,事实上,我们很多人都想要恢复方法论这一术语的可信度。我们想要恢复一种平衡。我们支持建模,但不是为了将一些图表存档到尘封的公司仓库中。我们支持文档,而不是几百页从来没有维护、很少使用的“大部头”。我们制定计划,但也承认在不稳定环境下计划的局限性。有些人把极限编程、SCRUM 或者任何其他敏捷方法的拥护者当做黑客来对待,他们根本不知道这些方法和“黑客”的最初定义。


——《历史:敏捷宣言》(History: The Agile Manifesto),Jim Highsmith


这些都很重要。对于敏捷,我们仍然需要计划和文档,并且具有严谨性。这涉及平衡。但是,如果你的组织在敏捷转型中挣扎,陷入混乱之中,那么当有人以认证、过程和工具的形式为你提供“救生艇”时,你就可以一跃而上。管理层对于过程和工具的理解要比对自组织团队更了解。


起义失败


不幸的是,我没有看到勇敢的反叛者在这一幕中卷土重来,至少在敏捷这个大方向下是如此。


工具供应商、过程顾问和专家们所作的承诺永远不能实现,这种情况已经泛滥成灾。因此,这就是我们最终采用 SAFe 和 Scaled Scrum 以及所有其他企业敏捷风格的原因。这些框架并非出于恶意而创建,它们甚至在正确的情况下具有一定的价值。但是我不认为它们是敏捷。尝试拓展一种注重个体和互动的方法论,会不可避免地带来问题,并侵蚀其方法论的原始价值。


我们正是这样结束了 Ron Jeffries 作为宣言签署人和极限编程的共同创始人在 2018 年发表的著名文章。

开发者应该放弃敏捷


如果不恰当地运用“敏捷”的理念,它们往往会导致开发人员更容易被干扰,缩短工作时间,增加压力,并且要求“更快地开展工作”。这样做不利于开发者,并最终影响到企业,因为不能很好地应用敏捷,通常会导致更多的缺陷和进展缓慢。优秀的开发者经常会离开这样的组织,导致企业的效率比安装“敏捷”之前要低。


我们正是这样结束了 Dave Thomas 作为宣言签署人和实用主义编程的共同创始人在 2014 年发表的著名文章。

敏捷已死(敏捷万岁)


“敏捷” 这个词已经被颠覆了,实际上已经毫无意义,而所谓的敏捷社区似乎主要是顾问和供应商兜售服务和产品的舞台……一旦《宣言》流行起来,“敏捷”一词就会吸引任何有观点支持、有时间收费、有产品销售的人。这已成为一个行销术语。


因此,我认为是时候让“敏捷”这个词退休了。


反思


看着年轻的开发者们诋毁敏捷,把它看成是管理层压榨不现实的承诺、迫使开发团队疯狂工作的一种方法,我感觉非常悲哀。好吧。他们唯一知道的敏捷是强加给他们的控制机制,而非一种他们乐于接受的自我授权工具。但是我希望,一些围绕着历史和最初设想的讨论能够帮助我想起来这件事本应如何演变。


《敏捷宣言》的原则在今天和 20 年前一样明智且有意义,甚至像 Jeffries 和 Thomas 这样的所谓反叛者也仍然这样认为。


Jeffries 在上面提到文章中说,“《敏捷软件开发宣言》的价值观和原则 仍然是我所知道的构建软件的最佳方式,基于我这么长时间的各种经验,无论大型组织采用什么方法,我都将遵循这些价值观和原则。”


我深以为然。


如今讨论敏捷既不时髦也不酷。敏捷很无聊。每个人都在做敏捷,对吧?现在是反思过去 20 年的最佳时机,问自己一些问题:


  • 哪些地方做对了?

  • 哪些地方出错了?

  • 下次我们想做些什么不同的事情?


一些 Simple Thread 的员工正在经历这场革命,他们计划在未来几个月里重新思考最初的 12 条敏捷原则中的每一条,对其原始含义进行背景分析,并考虑它们在当前软件开发环境中的价值。


我希望我们能通过研究创始原则,从过去的经验中学到一些东西。用 Dave Thomas 的话说,即使我们选择放弃“敏捷”,我们也能保持敏捷。


原文链接:


https://www.simplethread.com/agile-at-20-the-failed-rebellion/


2021 年 8 月 31 日 08:103529

评论 5 条评论

发布
用户头像
理想的敏捷有诸多前置要求:1 高度自主权, 2. 团队平均素质高 3.团队不同角色利益一致。屁股决定脑袋,在大公司里,不同角色的汇报线都不一样
2021 年 09 月 02 日 08:51
回复
用户头像
敏捷本身作为一种思想是优秀的,优秀的思想会让软件开发更快捷。但是如果“敏捷”成为了“快”的背书就错了。
2021 年 09 月 01 日 11:58
回复
用户头像
本质上,“敏捷的终局”发下的宏愿是巨大的,试图要去解决“一般性管理问题”,这是无法实现的。但敏捷带来的灵活应对的思路、工作方法,是非常成功的
2021 年 08 月 31 日 15:31
回复
用户头像
自顶向下规划+自下向上应对,应该是两头都要才能大河有水小河满,才能让地上的土壤去载物、让外部价值流入。多大的颗粒交由战略和规划,多大的颗粒交由灵活的应对是需要看情况的,无法用一种绝对的方法论来解决。
2021 年 08 月 31 日 15:29
回复
用户头像
翻译得诘屈聱牙
2021 年 08 月 31 日 10:43
回复
没有更多了
发现更多内容

面试大揭秘!从技术面被“虐”到征服CTO,全凭这份强到离谱的pdf

Java架构之路

Java 程序员 架构 面试 编程语言

芯片破壁者(二十五):从全球贸易网络看芯片博弈

脑极体

Activemq Jms 简单示例

Java 消息队列 JMS Activemq

架构师第 6 课作业及学习总结

小诗

「架构师训练营第 1 期」

大作业 1

郎哲

追寻人生的意义

三只猫

28天写作

独角兽余额宝(Java现场面试48题):性能调优+索引+Mysql+缓存+HashMap+GC

Java架构之路

Java 程序员 架构 面试 编程语言

MySQL慢查询(中):正确的处理姿势,你get到了吗?

架构精进之路

MySQL MySQL优化 MySQL架构 28天写作

架构师训练营 第十二周作业

文江

「学习笔记」深入理解ThreadLocal

Java架构师迁哥

面向垂直领域的OpenIE图谱构建技术

DataFunTalk

Spring Cloud Gateway (七)处理流程解析

Java 网关 SpringGateway

爱奇艺SOAR探索与实践

爱奇艺技术产品团队

安全

移动开发属于哪个领域!2021年Android春招面试经历,详细的Android学习指南

欢喜学安卓

android 程序员 面试 移动开发

学习安卓开发!View的这些基础知识你必须要知道,Android岗

欢喜学安卓

android 程序员 面试 移动开发

网卡分身技术,你 Get 了吗

Linux云计算网络

网络

OOP: DIP与LSP

Iris

面向对象 架构训练营

用 flomo 管理自己的奇思妙想瀑布流

Guanngxu

多熟悉一门编程语言看法

superman

精选算法面试-链表(判断环)

李孟

算法 链表 28天写作

Go的声明语法为什么是这样

Rayjun

Go

美团P4推出的Java程序性能优化手抄本,让你的Java程序更快更稳定

Crud的程序员

Java 程序员 架构 性能调优

架构师训练营第十二周作业

丁乐洪

案例研究之聊聊 QLExpress 源码 (一)

小诚信驿站

聊聊架构 规则引擎 28天写作 QLExpress源码 聊聊源码

2021 十大技术趋势扑面而来,你准备好了吗?

李忠良

区块链 人工智能 云计算 大数据 架构

洞察

JiangX

创业 投资 认知 28天写作 洞察

推荐系统解构

DataFunTalk

大数据

消失的同事

石君

时代发展 28天写作

面向对象设计总结

Iris

面向对象

链上数据存储,区块链底层技术落地

t13823115967

区块链落地

智慧警务,大数据分析决策平台建设方案

t13823115967

智慧警务大数据系统开发

数据库运维技术发展与展望

数据库运维技术发展与展望

20年起义,敏捷已死,敏捷万岁-InfoQ