「ArchSummit·深圳」人工智能如何促进工业和制造领域的智能化转型? >>> 了解详情
写点什么

2020 年敏捷开发人员生存指南

  • 2020-12-07
  • 本文字数:3932 字

    阅读完需:约 13 分钟

2020年敏捷开发人员生存指南

正确执行敏捷并非易事,如果能遵循本文的建议,相信它可以帮助你更容易地做到。


本文最初发表于 medium.com(《The Agile Developer’s Survival Guide for 2020》),由 InfoQ 翻译并分享。


我想说,敏捷就像是青少年的性行为,他们口口声声说做过,但却没人真正知道它到底是什么。


不过,更严重的是,我们的行业(即软件开发行业)通常都会走敏捷的路线,这意味着开发团队通常采用诸如SCRUM之类的方法,在此过程中,他们会花费很少的时间来尝试交付微小但又很简洁的代码,简化对特定项目的改进。


一些团队通过遵循认证人员的建议来实现这一点,而另一些团队则只是从书中获取他们认为有用的内容,并希望这能有所帮助。在我看来,无论哪种方式,都是好的,只要你不是盲目地遵循一套规则而没有真正理解它们的目的,它仍然比瀑布(顺便说一句,它在某些行业仍有一席之地)之类的其他替代方案要好得多。


作为这种方法论的一部分,需要遵循一些仪式(即会议,尤其是现在的会议,通常是虚拟会议),需要使用工具,一般来说,你并不是一个人在工作,这意味着还需要遵循一些团队合作的礼节,这一点并不是每个人都能真正意识到的。


因此,为了给你(敏捷开发人员)一个在敏捷丛林中健康生存的机会,如果你愿意接受的话,特别是现在 COVID-19 肆虐,虚拟网络正在兴起,我将向你展示我的建议清单(绝对不是由于多年来与不遵循这些原则的人打交道而产生的挫折!),作为敏捷开发团队的一员,这些建议可以指导你如何进行敏捷开发。

为了不影响生活,请不要使用团队“站立”通话


团队站立通话(stand-up calls)通常持续不了 15 分钟,具体取决于团队的情况,这个数字可能会有所不同,但是请考虑一下:通话被称为“站立”通话是有原因的,开发人员应该在站着的时候完成通话,这样每个人都会抓紧时间尽快完成他们的部分。


这些会议常用的脚本流程是依次发言(是的,团队中的每个人都应该发言),说出你前一天做了什么,今天打算做什么,如果有的话,提出你遇到的任何阻碍因素。在这里,你影响了同事们的生活。这不是在讲笑话,而且最重要的是,即使在你项目的范围内,也不能离题地谈论你所遇到的特定问题。


仅在必要时才使用这种方法召开会议,即使这样,会议也需要快速进行,并且不要使团队偏离他们应该做的事情。因此,如果你发现每天的站立会议慢慢地从 30 分钟变成了 1 小时,那么就可以打电话给负责的人,并请他们将自己问题转到另一个更有针对性的电话会议上讨论。

参加 Sprint 计划会议

Sprint 是团队集中精力去达成某个(通常)小目标的一小段时间。因此,当你在为这段时间以及你和你的团队将要做的工作类型做计划时,确保整个团队都致力于实现这一目标是很重要的。


这就是为什么通常鼓励整个团队都参加这些会议的原因。通过让每个人都审查要完成的工作,可能会出现一些有趣的问题,而这些问题反过来可能会彻底改变正在审查的工作。但是,这只有在相关人员都关注这一点的情况下才能实现,即使你不是将要实施该工作的人,甚至你的角色不适合来处理该工作,也可能会从不同的角度提出问题,从而解开障碍,因为这些障碍并不是每个人都能看到的,有些人可能对这项任务已经存在偏见了。


这与争论开发人员是否应该负责测试他们自己的工作(请注意,他们不应该这样做)一样。拥有局外人的视角是审查和测试某个特性的关键,这同样也适用于规划未来的工作。


因此,当你和你的团队正在审查未来的工作时,在没有提到你时,请不要关闭你的大脑。当别人正在说时,请不要在另一个标签上开始浏览互联网。在场、到场并努力去理解正在审查的任务,可能十次中有九次,你不会提出任何相关的问题,但有一次,你提出的问题可能会改变用户故事的一切。

注意 Sprint 的剩余时间


通常, Sprint 的时长是 2 周,尽管有些团队可能会稍微调整这个数字。这里的重点是,你应该始终确切地知道你还剩多少天可以交付你在计划会议上承诺的工作。


反过来说,你不能在 Sprint 的最后一天完成任务,这是不理想的。你说这不是你的责任,甚至说你的经理应该能预见到这一点,而且他应该采取一些措施来缓解这个问题。


作为一个管理者,让我来告诉你,这并不完全正确。是的,在某些情况下,需要对团队进行微观管理,即使在某些情况下,仅与几个团队成员一起进行管理可能会对所有人和整个团队都是有益的。但是,有足够经验的团队应该能在没有任何人执行微观管理的情况下进行工作(这需要双方花费大量时间和精力),并且能够按时交付承诺的工作。


而且,如果遇到困难或挫折(当然,在现实世界的项目中总会遇到这种情况),你应该了解得更多,并在出现问题时举手(也就是说点什么)。不要等到 Sprint 结束时才把这些问题提出来,然后为自己辩解说你认为自己可以解决这些问题。把这些问题提出来,让你的经理知道,然后一起决定如何最好地进行下去。


这不是一个与敏捷相关的问题,更像是一个软件开发的问题,但是考虑到 Sprint 所涉及的时间窗口很小,因此在这种情况下这样做会产生更大的影响,因为这样犯错的余地很小。

你并不是一个人在工作中


考虑如下情形:


Sprint 最后一天的开发者:准备好了!我今天已经完成了所有任务,呜呜,我以为我会让团队失望呢。 


QA 团队成员在等着测试你的功能:我对你来说是个笑话吗?!


 在单个 Sprint 中,你通常需要完成其他人需要的工作,无论是前端开发人员需要与之交互的后端代码,还是 QA 团队成员需要验证的 UI,你需要把你的工作看作是更大背景的一部分。


换句话说,在 Sprint 的最后一天交付你的工作已经太迟了,因为有可能,你已经完成了任务,但是你正在处理的整个用户故事(即你尝试添加的功能)需要其他人与你的代码进行交互,现在就没有时间了。

 

因此,下次你在做某件事情的时候,想想还有谁需要它:是否需要进行 QA 流程?需要多长时间?我的代码是否阻碍了其他任务的开发?其他任务需要多长时间才能完成?


你并不是一个人在工作,你当然也不是在一个真空环境中工作,在这个环境中你可能遇到的任何延迟或问题都不会影响到其他人。实际上,任何你可能造成的延迟,都会耽误你团队中的其他人。因此,当你提前计划工作或问题开始堆积的时候,一定要把这两个因素都考虑进去。


不要再仅仅考虑你自己的工作,而要考虑你团队的目标,这应该可以帮助你牢记团队的其他成员。

每个人都讨厌任务跟踪,但它很重要

无论你使用的是JIRATrello,还是市场上的其他任何任务跟踪工具,你都会讨厌它。仅仅是因为开发人员在编写代码,所以几乎没有时间登录那些(通常))繁琐的工具并更新状态来作为日常会议的一部分。


所以,为什么要找麻烦呢?对吧? !


错了,事实上,这就是原因。


除了让你的生活变得痛苦之外,任务跟踪工具还可以让你一目了然地了解一个项目的当前状态,以及对团队能否按计划交付他们承诺的里程碑进行合理的猜测。


站在经理的角度考虑一下,考虑他们的职责,以及利益相关方每天是如何询问他们项目能否按计划进行的。你是否愿意他们依次询问开发人员、设计人员、QA 和其他团队成员,他们的生活会怎样?还是你认为鸟瞰项目可能会有帮助?


我认为没有人会真正选择第一项,所以如果要选择第二项,就需要有人更新每个任务的进展情况。这就是你要做的,只需每天简单地更新下你任务的状态,就能为你的经理提供很多价值。请注意,我并不是要你记录每个任务的工作时间,我只是说,将任务标记为“待处理”、“进行中”、“已阻塞”或“已完成”就能提供很大的价值了。如果你想多做一点,比如留下评论解释为什么它被阻塞了,那么你可能就很了不起了,值得奖励一块饼干,所以继续,拿着它,一边享受一边继续阅读。

故事点不是你附加到用户故事的随机数


我知道,对于用户故事来说,给出没有任何实际意义的随机数是没有意义的。但是相信我,这只是在开始的时候,一旦你看到了它们的意义(顺便说一句双关语),它们就变成了必备品。


让我问你一个问题:如果你要领导当前的项目,那么在计划未来的工作时,你如何决定在一个 Sprint 中要投入的工作量呢?我知道,作为一名开发人员,在很长的一段时间里,我从来都没有真正考虑过这个问题。我必须完成的任务被分配给了我,我要在两周内完成。就是这样。


这就是我当上经理之前的情况。我怎么知道我团队的魔力数字是多少呢?有多少用户故事就足够了呢?多少又太多了呢?这只是一个反复试验的问题吗?我能用这些故事点做些有用的事吗?


但是考虑一下更大的计划,如果我不能可靠地知道我的团队在短短的两周内可以完成多少工作,我又怎么知道我是否能够按时完成项目呢?


这就是故事点发挥作用的地方。如果你始终根据同一比例来挑选故事(哦,是的,你需要设置一个比例,以便每个人都能以 1 或 8 来理解同一件事),那么经过几次 Sprint 之后,你便开始了解多少个故事点你可以在 Sprint 期间完成。这就是所谓的“速度”(Velocity),这就是你计划未来 Sprint 时要使用的。


所以,请记住,下次当你必须挑选故事时,有一个非常好的理由!

总而言之


作为一名优秀的敏捷开发人员,并不是要快速地编写代码,而是要采用所选的方法,考虑项目和团队,而不仅仅是任务和自己。并记住:


  • 把你每天的更新保持在最低限度,把其他的事情都放在一个更集中的会议上。

  • 计划会议是非常重要的,出席并为会议作出贡献。

  • Sprint 是一个非常明确的时间窗口,请记住这一点,并考虑其他人可能正在等待你的工作。

  • 任务跟踪很重要,它可以帮助其他人了解整个团队的工作方式,因此这样做吧。

  • 故事点很重要,不要忽略它们,也不要在用户故事上随机抛数字。


从本质上说,和你的团队好好相处,你就会享受这个过程,只考虑自己,敏捷方法论就会把项目变成一场噩梦。


你在过去的项目中见过类似的行为吗?我有没有漏掉你认为很重要的建议?请在下方留言,让大家知道你的经历!


原文链接:

https://medium.com/agileinsider/the-agile-developers-survival-guide-for-2020-be6621560188

2020-12-07 08:003892

评论 6 条评论

发布
用户头像
这篇文章在对敏捷知识没有一定了解的情况下,读起来还是有些难度的。
敏捷定义:一种开发流程
敏捷方法:XP(极限编程),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)具体可先搜索一下,
敏捷中的角色定义:拿scrum举例:PO:产品负责人,SM:团队领导,TEAM:研发所有成员
Sprint:迭代周期,一般是两周一个迭代,可调整
主要会议:站会:每天工作开始前,迭代计划会,迭代复盘会都是每个迭代结束时做。其中还会夹杂一些总结鼓励,感谢,等激励团队的环节。
工具:带有泳道的看板工具,工时排期工具等

总之,敏捷是提供了一套协作流程方法,具体怎么用,怎么调整,用到什么程度,就跟公司的整体氛围关系很大,而且即便用的很好,这个收益恐怕也是很难评估

展开
2021-04-17 17:41
回复
用户头像
对于如何在敏捷环境下生存下来我有一个简单建议:加入一家敏捷跑得好得公司/团队,如果不是在做咨询,别浪费时间在假敏捷上
2020-12-17 11:29
回复
用户头像
敏捷提了多少年了,然而并没有多少公司真正尝到它的甜头。都是为了敏捷而敏捷,它需要文化和流程的配合,以及自上而下的主观意愿。往往很难自底向上推动,工作这么多年,凡是说自己公司实施敏捷带来收益的几乎为0,借助敏捷来吹牛逼到处都是。作为一线开发,敏捷个毛线,不如XP来的直接高效。微服务时代,XP才是最佳辅助
2020-12-07 10:46
回复
个人认为敏捷做不好其实不是敏捷本身的锅,是文化不同导致的水土不服…其实公司管理也是,很多西方国家用得好的管理体系,放到国内就水土不服了。所以我觉得不用非得敏捷不可,能顺畅跑起来才重要
2020-12-07 16:01
回复
XP 也是众多敏捷流派中的一种,偏向工程敏捷的技术流派。如果你的团队能够接受XP,并能很好地应用它我相信你们已经尝到敏捷的甜头了。
很赞同你说的企业文化很重要。要上下齐动。

2020-12-11 14:57
回复
用户头像
沙发
2020-12-07 09:22
回复
没有更多了
发现更多内容

[极致用户体验] 一行简单的样式,让网页有「高级感」

HullQin

CSS JavaScript html 前端 8月月更

《亲密关系》:如何保持良好的亲密关系?

郭明

读书笔记

DBPack 数据库限流熔断功能发布说明

峨嵋闲散人

分布式事务 云原生 分库分表 dbmesh Database Mesh

为什么不做APP而要做小程序

源字节1号

小程序开发

SSM框架整合(Spring+SpringMVC+Mybatis)

开源 SSM框架 8月月更

如果让我设计一套,TPS百万级API网关!

小傅哥

Java 微服务 小傅哥 分布式架构 网关

一对一直播系统源码——多人语音聊天室

开源直播系统源码

直播系统源码 语音直播系统 一对一直播视频源码 一对一语音直播

最常见的 10种网络安全攻击类型

郑州埃文科技

网络安全 IP地址 网络攻击

35岁程序员危机,有何破解之法?

博文视点Broadview

属实不赖!Alibaba开源GitHub星标114K微服务架构全彩进阶手册

冉然学Java

Java 阿里巴巴 开源 微服务 微服务架构

【源码解析】MyBatis整体架构与源码解析

小明Java问道之路

mybatis mybatis源码 源码解读 8月月更 架构解析

云原生(十八) | Kubernetes篇之Kubernetes(k8s)工作负载

Lansonli

云原生 k8s 8月月更

Java 泛型 T,E,K,V,,傻傻分不清?

TimeFriends

8月月更

寻找OpenHarmony「锦鲤」|万元豪礼+技术干货全是你的!

OpenHarmony开发者

OpenHarmony

RabbitMQ高可用架构总结

知识浅谈

RabbitMQ 8月月更

STM32入门开发 制作红外线遥控器(智能居家-万能遥控器)

DS小龙哥

8月月更

干货!这份阿里P8大佬纯手打总结Kafka学习笔记,真是yyds

了不起的程序猿

Java kafka java程序员 消息中间件 Java 开发

DAPP和APP有哪些区别?多链跨链NFT铸造挖矿dapp系统开发技术原理分析

开发微hkkf5566

【源码解析】MyBatis工作原理源码深度解析

小明Java问道之路

深度解析 mybatis 源码解析 源码解读 8月月更

“新DeFi”生态的构建,流支付协议Zebec或厚积薄发

鳄鱼视界

Kotlin协程解析系列(上):协程调度与挂起

vivo互联网技术

kotlin 协程

为什么电商云产品需要 Assisted Service Module (ASM) 模块的支持

Jerry Wang

typescript 电商 SAP 8月月更 Storefront

部署Spark2.2集群(on Yarn模式)

程序员欣宸

大数据 spark 8月月更

增强分析在百度统计的实践

百度Geek说

数据库

人手一套的K8S命令集合,它来了!

wljslmz

云计算 Kubernetes 容器 8月月更

多原则等于无原则,微服务识别方法究竟该怎么选?

老坛架构

架构 微服务

less的基本语法

Java学术趴

8月月更

【云原生】Docker 进阶 -- 构建自定义镜像实战

Bug终结者

Docker 阿里云 服务器 8月月更

聊聊客户档案模型的设计与管理

Java 架构 CRM CDP

测试开发【Mock 平台】09 开发:项目管理(五)搜索、删除和Table优化

MegaQi

测试平台开发教程 8月月更

SpringBoot 日志的各种使用姿势,你真的用对了吗?

程序知音

Java spring 程序员 springboot 后端技术

2020年敏捷开发人员生存指南_语言 & 开发_Fernando Doglio_InfoQ精选文章