你在使用哪种编程语言?快来投票,亲手选出你心目中的编程语言之王 了解详情
写点什么

开发人员应该放弃敏捷

2020 年 10 月 10 日

开发人员应该放弃敏捷

“敏捷”已然成为一门“大生意”。以 Scrum 联盟认证 Scrum Master 为首,我们看到了成千上万所谓的“敏捷“教练和培训师,以及很多相互竞争的框架和方法,比如“敏捷”领导力培训、“敏捷”项目管理,等等。


或许这些不算是坏事,至少对于企业来说。想要进步的企业通常会进步,即使“敏捷”思想没有得到充分应用,付出的努力也不会白白浪费。至少,企业知道这当中都发生了什么,即使是最不开明的领导层,也会因此知道该怎么做出更好的决策。从这方面来说,事情是好的,我完全赞同。


但对于开发者来说,就不是这么一回事了。当“敏捷”思想没有得到充分应用,只会给开发者带来更多的干扰和更大的压力,消耗他们的时间,让他们感觉像是被鞭子抽着往前赶。这对开发者来说不是好事,而最终也会对企业不利,因为糟糕的“敏捷”实践只会造成更多的缺陷和更缓慢的进展。好的开发者通常会因为这个而离开企业,而对于企业来说,“敏捷”比“不敏捷”更加糟糕。


我的想法来自 Kent Beck 十多年前说过的话——我希望这个世界对于开发者来说是安全的。我骨子里是个开发者,尽管做了多年的管理、咨询和写作工作。我几乎每周都会写代码。看到“敏捷宣言”里所宣扬的想法并没有让开发者的生活变得更好,而是更糟糕,我感到很伤心。企业也没能从“敏捷”中得到应得的好处,我也感到很悲哀,不过我最关心的还是那些参与敏捷实践的人。


多年来,我听到很多开发者吐槽“敏捷”。我试着让他们明白,其实是他们所在的企业没有做好“敏捷”,他们没有按照“敏捷宣言”作者和敏捷软件开发专家说的那样去做。我希望和我有同样想法的人能够救救自己,救救所在的企业,真正理解“敏捷宣言”背后的想法,远离那些到处可见的伪敏捷和暗黑敏捷。


但事与愿违,一些“高级”的敏捷培训和认证以及来自领导力方面的努力或许可以开花结果,但进展缓慢,而且可能永远都触及不到真正的开发者。


是时候尝试一些新的东西了。


开发者应该放弃“敏捷”

开发者会继续在敏捷环境或使用 SAFe 框架的企业里工作。有些人甚至会遭遇隐晦的“敏捷”方法,比如 DAO。或者如果足够幸运的话,他们会遇上更加开明的方法,比如“现代敏捷”或“敏捷之心”,有一些还可能从事极限编程。


话虽如此,我认为开发者应该抛弃任何与“敏捷”方法论相关的想法,而是把注意力放在那些在“敏捷”方法论之下行之有效的软件开发方法上。这些开发方法包括了极限编程,当然,不仅限于此。开发者的工作应该遵循敏捷软件开发的基本原则,正如我们在撰写敏捷宣言时所想的那样。我将这些想法总结如下:


无论管理层认为他们在应用什么样的框架或方法,都要按以下这些方式展开:


  • 每一两周都要交付经过测试的可运行软件。锻炼你的技能,直到可以每天一次、每天两次甚至是每天多次发布可运行的版本。

  • 保持整洁的软件设计。随着规模的增长,软件的架构设计会趋于复杂。有意识地抵制并扭转这种趋势,通过持续小步快跑式的重构来尽可能保持稳定和一致的进度。

  • 将软件的当前增量部分作为与产品领导层对话的基础,告诉他们哪些事情已经就绪,并询问他们希望你接下来要做什么。


对于开发团队来说,这是他们最有可能过上理想生活的方式。让软件保持就绪状态,我们就能够以尽可能最好的结果应对任何一个截止日期。“今天就是截止日期了?我们已经准备好了,可以交付了”。


随着越来越接近截止日期,当我们在商讨接下来要做什么时,我们会将谈话的重点放在接下来要做的最重要的事情上,而不是他们脑子里几乎无穷无尽的想法。从“把所有东西都做出来”到“接下来要做这个”的思维转变有点困难,但这是让开发人员过上美好生活最佳时机。当我们以协作的方式与领导者共事,而不是完全听命于他们,就很有可能把这种焦点转变过来。


被强制推行的敏捷

通常,团队所使用的“敏捷”方法是被强加的。大规模“敏捷”方法实际上就是建议强加流程,包括所谓的“SAFe”、可伸缩 Scrum,等等。这些都是针对企业的,要求企业去“推行”它们。


作为一名开发人员,你可以肯定这种方式不会得到顺利推行,也不会实现真正的敏捷。你可能接受不到培训,在工作上也获取不到必要的帮助。你的领导可能会接受培训,一培训就是一两周,他们为这些即将给产品和软件开发带来彻底改变的东西做足了准备。但这条路可能有点难走。


不过,如果你能够稳定地在每一个 Sprint 里把工作做好,把系统打包,运行、测试、集成,然后等待发布,就有可能获得最好的结果。


如果你做不到,我建议你还是在每一个 Sprint 里少做一些事情,直到可以把这一阶段内的东西都做好。但这也很难!因为人们会催促你,要你尽全力往前赶。顶着压力超负荷运作,还不如每次只完成一两件事情,等把它们都做好了,再去做其他的,那么在 Sprint 结束的时候,你才有已经完成的东西拿出手。坦然接受因为未能完成所有事情而遭受的指责,试着让计划和期望更接近现实情况,而不是那些你永远都没有机会去做的东西。


事情不会那么完美,而且在一段时间内,也不会那么有趣,但这是我所知道的最好的生存契机。完成可运行的产品片段是扭转局势最好的方式。如果情况不妙,我们所能做的就是尽我们所能,让事情尽可能好起来。


很显然,在一家开明或者有持续学习意愿的企业,很多东西都会对真正的敏捷持开放态度。生活会更美好,我也希望如此。


我经历过这些,我知道最好的方式是把工作做好,保持软件的可见性,让它运行起来,进行测试和集成,并帮助人们认清现实。


选择你的敏捷方法

敏捷宣言呼吁团队的“自我组织”能力,在最好的情况下,就是指团队可以选择自己的流程。如果我自己创办一家公司,我会让团队自己选择他们想要的流程。


当然,还是有一些限制的,但这种限制不在乎他们的工作方式,而在乎我需要看到什么。我会告诉他们,最多每两周我需要评审一下他们完成的产品片段。他们需要向我展示他们的计划以及已经完成的东西。产品片段必须是可运行的,并且包含我能够看到和理解的功能。我们会讨论下一阶段需要做哪些事情。我还会告诉他们,如果一周可以完成,就不要做两周,如果一天可以完成,就不要做一周。


我会给他们提供帮助,让对产品需求很了解的人帮助他们决定后续的工作。我会给他们提供培训和支持,帮助他们更好地完成工作。我会确保他们有能力去完成我所要求的事情。


当然,我之所以这么做,是因为我心里很清楚这些事情。你可能也会很幸运地遇到类似的情况,至少,你可以选择自己的流程。


如果你有机会做出选择,我建议从极限编程开始。极限编程提供了必要的计划和反馈闭环,还提供了一些基本的技术实践,这些技术实践是你完成目标所必需的。


另外,我建议你时刻对你的需要的东西保持警惕。在我看来,“ATDD、TDD 和重构”这些东西正是你需要的。当然,除了这些,你还需要其他很多东西。保持警惕,当它们出现时,抓住它们。


追求卓越的软件开发是一项终生的活动,即使是极限编程也只触及到表面而已。是否能够走向卓越,这取决于你的团队。


总结

除了极限编程(我们可以把它看成是一种思想而不是方法),我认为开发人员不要拘泥于任何一种“敏捷”方法。正如这些方法在实际当中所体现的那样,它们通常是开发者的敌人,而不是朋友。


不过,敏捷宣言的价值和原则仍然是用来指导软件开发的好方法。从我长久以来的经验来看,无论企业使用了哪一种方法,我都会遵循敏捷宣言的价值和原则。


我把这些作为建议提出来,如果你觉得适合你,可以尝试一下。


原文链接

Developers Should Abandon Agile


2020 年 10 月 10 日 17:056127
用户头像
小智 前 InfoQ 主编

发布了 402 篇内容, 共 324.1 次阅读, 收获喜欢 1782 次。

关注

评论 6 条评论

发布
用户头像
论点比较认同,但文章没有实质内容,老外也喜欢搞这种口号式文章。

敏捷应该是公司文化上的敏捷,如果只是其中一个部门或一部分敏捷,所以就会出现怪异,因为敏捷宣言是开发者提出来的文化,而这部分大部分都是在CTO以及以下岗位,所以文化中一定会出现文化的不匹配,那么这种不匹配在哪个环节被纠正和梳理,就是一个很要命的问题。而往往这要命的问题,大家都留给了程序员,所以敏捷不但没有减轻负担,反而让程序员无形中背了很多锅。


展开
2020 年 11 月 10 日 09:51
回复
比较同意,敏捷应是公司上下的敏捷,没有组织架构及流程的保障其实更加事倍功半。
2020 年 11 月 16 日 16:54
回复
用户头像
敏捷有些时候有些地方有一定意义,但是绝对不能泛敏捷化,要拿捏好情景场合。如果不理解其方法论,最好不要乱试。
2020 年 11 月 03 日 17:17
回复
用户头像
敏捷最大的问题就是不够事实求是, 做的不好就说你的 假的敏捷,黑暗敏捷。明明是理论有问题,不去修复理论,而指责实践有问题
2020 年 10 月 23 日 13:45
回复
用户头像
非常赞同,现在的敏捷第一是新鲜事物,大家都赶时髦。另外敏捷就是偷工减料,很多东西都没想明白,东一榔头,西一榔头;原子弹怎么不搞敏捷开发?理论基础、可行性分析还是很有必要的。一切的根源都是浮夸,急功近利。以为单靠996这种低效率的加班和工作能一两年赶超欧美了?静下心来,从基础做起,脚踏实地吧。真得蛮佩服以前老一辈的科研工作者。
2020 年 10 月 19 日 10:36
回复
敏捷不等于996。 在我的观念里面只有两种的996: 1.公司战略需要,公司上下一心,这种996,应该是提倡的,毕竟商业社会就如同打仗。2.公司战略缺失,公司管理者心理不平衡,为了自我欺骗,自我安慰,鼓励大家无效加班。 现在动不动就996 ,很大一部分就是 第二种情况。和 敏捷没有任何关系
2020 年 11 月 10 日 09:54
回复
没有更多了
发现更多内容

APICloud Avm.js前端框架的优势

APICloud

小程序 前端框架 移动开发· 跨端开发 多端开发

Semaphore实战

叫练

CountDownLatch CyclicBarrier Semaphore 线程协作

区块链产业革命:解决融资租赁之谜

CECBC区块链专委会

区块链

9.hooks源码(想知道Function Component是怎样保存状态的嘛)

全栈潇晨

源码分析 React React Hooks

迎战大厂!“金三银四”和春招通过率达95%的Java面试要点集锦

云流

Java 程序员 架构 面试

一桶食用油的数字化

吴俊宇

数字化转型 鲁花

10.scheduler&lane模型(来看看react是暂停、继续和插队的)

全栈潇晨

源码分析 React React Hooks

【科创人】Testin云测总裁徐琨:创业必须要创造出肉眼可见的价值

科创人

一场关于代码注释的争执,引发的三点思考

架构精进之路

编码 经验分享 七日更 3月日更

12.手写迷你react(短小精悍就是我)

全栈潇晨

源码分析 React React Hooks

通俗易懂!看了不会忘的网络面试知识点

云流

编程 架构 面试

【回溯算法】经典题:求目标和的组合方案 ...

宫水三叶的刷题日记

LeetCode 数据结构与算法 面试数据结构与算法

Wireshark数据包分析学习笔记Day1

穿过生命散发芬芳

Wireshark 数据包分析 3月日更

怎样在自己的 Web 中加入强大的日志系统?slf4j 的日志插件必须要知道!

老王说编程

slf4j java 日志 日志管理 日志框架

5 分钟部署一个 OAuth2 服务并对接 Shibboleth-IdP 3.4.6

冯骐

golang 运维 开发 OAuth2 Shibboleth

程序员之禅(二)

每天读本书

读书笔记 每天读本书

区块链电子合同--电子合同区块链签约平台

13530558032

git 教程 --git cherry-pick 命令

生之欢愉,时间同行

git 程序员 git cherry-pick

Mysql安装

Sakura

11.react concurrent mode(并发模式是什么样的)

全栈潇晨

React React Hooks

科学的互联网思想 指引我国网络强国建设稳步前行

CECBC区块链专委会

网络安全

beego + nginx 实现反向代理统一认证

冯骐

golang nginx 开发 ldap auth_request

Shibboleth-IdP 的 OAuth2 对接方案详解

冯骐

OAuth2 SAML Shibboleth CARSI

Promise原理及常用操作

花明

世界经济论坛:四大区块链趋势将在今年绽放异彩

CECBC区块链专委会

区块链

Python学习心得

张鹤羽粑粑

28天写作 3月日更

园区网中 IPv6 地址的终端 mac 地址追溯

冯骐

Python 运维 日志 网络 ipv6

15 分钟部署一个 CAS 服务并对接 Shibboleth-IdP 3.4.6

冯骐

CAS 认证 Shibboleth 统一身份认证

智慧党建平台解决方案--高效开展党建工作

13530558032

白话Go内存模型&Happen-Before

Gopher指北

go

Docker的三言两语-基础篇

一个大红包

Docker 28天挑战 3月日更

云原生场景下企业API 网关选型及落地实践

云原生场景下企业API 网关选型及落地实践

开发人员应该放弃敏捷-InfoQ