写点什么

开发人员应该放弃敏捷

  • 2020-10-10
  • 本文字数:2973 字

    阅读完需:约 10 分钟

开发人员应该放弃敏捷

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


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


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


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


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


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


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

开发者应该放弃“敏捷”

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


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


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


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

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

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


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


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

被强制推行的敏捷

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


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


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


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


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


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


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

选择你的敏捷方法

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


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


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


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


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


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


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

总结

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


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


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

原文链接

Developers Should Abandon Agile


2020-10-10 17:058609
用户头像
小智 让所有人认同的文字称不上表达

发布了 408 篇内容, 共 385.3 次阅读, 收获喜欢 1977 次。

关注

评论 7 条评论

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

敏捷应该是公司文化上的敏捷,如果只是其中一个部门或一部分敏捷,所以就会出现怪异,因为敏捷宣言是开发者提出来的文化,而这部分大部分都是在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
回复
没有加班费的996都是耍流氓
2023-05-02 11:38 · 广东
回复
没有更多了
发现更多内容

Java之Spring基础与IOC,java实用教程第五版答案第四章

Java 程序员 后端

Java之StringUtils的常用方法,java整体项目架构图

Java 程序员 后端

Java内存问题 及 LeakCanary 原理分析,mybatis架构设计层次

Java 程序员 后端

Java几种常用JSON库性能比较,java接口开发面试

Java 程序员 后端

Java学习路线和方法推荐,拿下我人生中第7个Offer

Java 程序员 后端

Java实现图的存储和创建,linux编程基础课后答案第二章

Java 程序员 后端

Java中高级核心知识全面解析——Dubbo,java语言入门自学书

Java 程序员 后端

Java基础总结三(泛型、异常,阿里java面试题及答案

Java 程序员 后端

Java基础面试题整理,java数组排序sort原理

Java 程序员 后端

Java多态大乱炖,mysql基础教程视频

Java 程序员 后端

Java反射的深入浅出,mongodb优化面试

Java 程序员 后端

架构实战营模块二学习总结

吴霏

「架构实战营」

Java基础09 面向对象~类和对象,阿里面试官必问

Java 程序员 后端

Java基础27~使用JDBC+连接池,这篇文章可以满足你80%日常工作

Java 程序员 后端

Java中的泛型,java程序执行过程与编译原理

Java 后端

Java初学01:学习路线,java基础入门清华大学出版社

Java 程序员 后端

Java基础面试题——IO流,springboot实战项目百度云

Java 程序员 后端

第二模块作业

River Tree

架构实战营

Java多线程 高频面试题,java架构师工作内容

Java 程序员 后端

JAVA代码审计之Shiro反序列化漏洞分析,浦发银行Java开发笔试题

Java 程序员 后端

Java基础 - 多态,抽象类,接口,linux源码学习

Java 程序员 后端

Java学习笔记——正则表达式,平安金服java面试题

Java 程序员 后端

Spring是如何自动注入多类型的?

编号94530

spring bean @Autowired 自动注入

Java基础25~XML和JSON解析,springbootoauth2教程

Java 程序员 后端

Java基础 - 单例(饿汉、懒汉),Runtime类,java教程推荐学客巴巴

Java 程序员 后端

Java中高级核心知识全面解析——常用框架(Spring常用注解

Java 程序员 后端

架构实战模块二作业

吴霏

「架构实战营」

Java如何支持函数式编程?,大专生面试阿里P7居然过了

Java 程序员 后端

Java实现RPC(源码),java常见面试题

Java 程序员 后端

自由职业者靠什么赚钱?

石云升

职场经验 10月月更

Java中高级核心知识全面解析-容器(ArrayList)

Java 程序员 后端

开发人员应该放弃敏捷_文化 & 方法_Ron Jeffries_InfoQ精选文章