“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

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

  • 2021-08-31
  • 本文字数:4042 字

    阅读完需:约 13 分钟

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-08-31 08:104901

评论 6 条评论

发布
用户头像
敏捷说到底是一种价值观和行为准则,而大家常用的scrum是个管理框架。思想归思想,框架归框架,scrum这种框架本来就只应用于几个小团队,体量一旦大了,就需要需要引入大规模敏捷比如less这种框架,否则就是场灾难,管理人员会发现不如走走老瀑布;而业务一旦不是单纯的开发交付了,那就光靠scrum等框架来管理更不够了,肯定还是要结合诸多传统的项目管理手段适应性的融合起来去管理和补齐开发外的一系列事务;
最后,最关键的一点,敏捷对团队自身的要求真的很高,管理成本其实没有降低,只是从集权制的管理成本分散到了优秀的敏捷团队每个人头上进行自管理了。所以至少在目前的中国,想真的全公司落地敏捷的真的很难,几个项目还能搞搞,多了真的只取敏捷,而放弃命令与控制,真的没法管,得乱套.....
2022-08-15 16:58 · 上海
回复
用户头像
理想的敏捷有诸多前置要求: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
回复
没有更多了
发现更多内容

面试题:JVM在Java堆中对对象的创建、内存结构、访问方式

java小李

java 14 sping

DeFi智能合约DAPP开发|DeFi项目源码

Geek_23f0c3

DeFi去中心化系统开发 DAPP智能合约交易系统开发

幸福的人在当下就活出了幸福的样子|靠谱点评

无量靠谱

stack overflow 问题分类

毛显新

tensorflow

对象存储手把手教三 | 数据分段上传

QingStor分布式存储

对象存储 分布式存储 数据传输

聊聊百度搜索背后的故事

程序员鱼皮

Java 搜索引擎 数据结构 算法 后端

速来围观!大佬把Java基础核心知识整理成了PDF版

java小李

Java开发手册 Java 开发

基于 Java Spring Security 的关注微信公众号即登录的设计与实现ya

哈德韦

spring security 微信公众号 Apache Pulsar SSO

TensorFlow 2 quickstart for experts

毛显新

tensorflow

根据译文片段预测翻译作者

毛显新

tensorflow

深度融合,云管理平台助推政府实现“最多跑一次”改革

BoCloud博云

云计算 云管理平台 云管理

FBI 警告称,网络犯罪分子可能以 2021 年东京奥运会为目标!

郑州埃文科技

Vue进阶(九十四):自定义组件

No Silver Bullet

Vue 自定义组件 7月日更

向大佬学习!「mybatis查询匹配机制」,手动点赞

java小李

java 14 Mybati

DAPP智能合约开发|智能合约搭建

Geek_23f0c3

区块链 智能合约 DAPP智能合约交易系统开发 DAPP系统开发

架构实战营-模块三

Cingk

携生态伙伴展示AI计算盒参考设计最新成果 英特尔点亮智能边缘广阔机遇

E科讯

被转载10W次的:Java小白系统资料和职业规划路线

java小李

java基础

如何借用第三方APM工具, 为移动应用保驾护航

APM

拨云开雾!阿里面试官力荐Java开发必看的操作系统底层原理PDF

Java架构追梦

Java 阿里巴巴 架构 面试 操作系统

淘宝一面:说一下 Spring Boot 自动装配原理呗?

java小李

面试 java 14 sping

大学四年Java学习路线规划,所有私藏资料我都贡献出来了

java小李

spring Java web

GitHub标星139K的:“嵌入式Linux系统开发教程”

白亦杨

汽车燃料效率预测

毛显新

tensorflow

行云创新完成B轮融资,阿里云独家投资

行云创新

阿里云 云原生 投资

LeetCode题解:456. 132 模式,n平方暴力,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

被面试官问的Android问题难倒了,深度集成!

欢喜学安卓

android 程序员 面试 移动开发

机器学习- 吴恩达Andrew Ng Coursera学习总结合集 John 易筋 ARTS 打卡 Week 57

John(易筋)

ARTS 打卡计划

华为助力高校释放能量,加速中国从开源使用大国向贡献大国转变

科技热闻

Recommending movies: retrieval

毛显新

tensorflow 推荐系统

请谈下Android消息机制,成功拿下大厂offer

欢喜学安卓

android 程序员 面试 移动开发

20年起义,敏捷已死,敏捷万岁_架构_AI Tenhundeld_InfoQ精选文章