LeSS敏捷框架高效生产力实践

每个团队可能都有一套适合自己的敏捷方法,本文介绍了ResponseTap工程团队通过采用LeSS框架、引入准备周,从而提升迭代冲刺研发效能的实践。原文: LeSS Agile, More Productive — Part 1: Pain[1], LeSS Agile, More Productive — Part 2: Promise, LeSS Agile, More Productive — Part 3: Productivity

我们在ResponseTap一直使用基于Scrum的敏捷方法论(Agile Scrum Methodology) ,但却逐渐演变成我们自己的敏捷风格,这真的让人很痛苦。

接下来我们会讲述ResponseTap工程团队如何采用LeSS框架[2]重新为混乱的流程带来秩序的故事。

alt

我们的痛点:

  • 多年不断发展的软件开发流程
  • 每个人都有不同的想法
  • 马上就做(JFDI, Just Focus and Do It)

我们的敏捷

记不清有多少次听到这样的对话了。

这个新功能很紧急,能不能跳过测试,更快发布?

或者...

我们不能让流程成为阻碍,如果不修复这个错误,"客户A"就会取消订单!

还有其他一千种表达方式: 我想让你做的事情太重要了,不能因为"流程"而放慢速度。 这些对话通常以某人说出下面这句貌似正确的话结束:

好吧,这看起来一点都不敏捷!

这就是问题所在,对于团队中的许多人来说,敏捷意味着无论何时我们都应该去做我们认为应该做的事情。这听起来很敏捷,但一段时间后就变成了混乱,这当然不是敏捷方法论。

我们过去经常这么处理: 这个流程很尴尬,无法处理X情况,所以我们会改变流程。当过了一个迭代周期后,遇到了类似情况,我们就再次改变流程。

不出意外的话,不久之后,流程就会变得复杂、矛盾,而且很难帮助我们交付软件。对快速交付、快速行动和适应变化的热情蒙蔽了我们的判断,使我们陷入困境。

争论越来越多...

alt

我们无意中营造了一个没有确定性的环境,即使相似的的问题曾经出现过,也必须重新解决每个问题,因为我们没有确定可靠的模式。

没人喜欢这样。

我们只是例行公事的改变流程,试图为每个场合和每种可能性制定一个规则,从而迷失在复杂性中,并对支离破碎的流程失去了信心。

可以猜到后面会发生什么。我们都是充满激情的人,都想把工作做好,都想做出令人惊叹的产品。对于如何解决这个问题,我们都有自己的看法。

经常会发生同样的争论:

  • 预估的意义是什么?(我们的预估太不一致了!)
  • 是否应该在同一个迭代冲刺(sprint)中进行缺陷调查和修复?
  • 在一个sprint中能容纳多少东西?
  • 什么是用户故事(User Story)?

大家真的非常沮丧,甚至有一些人离开了团队。

JFDI共和国

alt

人人喜欢JFDI[3],不是吗?现在就做这件事,不要问问题。

对于缺陷,对于特性请求,甚至对于大型项目,我们都有JFDI……想象一下这种场景……

但是,为什么?

那时候我们经常问这个问题,为什么要把所有的时间都花在突然从天而降的工作上?这个问题在当时很难回答,但事后看来,答案很简单:

待办列表(Backlog) —— 我们没有一个健康的待办列表。尽管我们在待办列表中有项目,但缺乏客观的预估方法,这意味着我们无法确定优先级。对于新的工作,也没有可靠方法来理解它相对于待办列表中其他项目的优先级。

依据门槛(Threshold of Evidence) —— 对于被认为非常重要,需要立即启动的项目,只有很少的支持依据,如果某位公司高层说这件事很重要,那就足够了。有时候,在初创公司这是可以接受的,尤其是如果领导层有良好的直觉。但对于成长型企业来说,可能具有难以置信的破坏性。

现在回想起来,这显然是管理工程团队的愚蠢方式。但是,这很难抗拒,因为我们没有办法证明JFDI对生产力有多大的影响。

无法证明JFDI如何影响工作速度,我们没有数据。


alt

放松一下,再试一次

很明显,我们需要停一下,寻找解决方案。

Nexus

我们首先尝试的是Nexus[4],一种Scrum扩展方法,但几个月后,我们的问题依然没有解决。不是说这种方法不好,如果多给它点时间,Nexus很可能已经解决了我们的问题。然而,我们觉得这种方法对我们的团队并不自然,因此我们继续寻找。

LeSS框架

2018年夏天,我们发现了LeSS框架。LeSS在我们团队取得了巨大成功,使我们的生产效率更高、更可靠、交付速度更快。最重要的是,我们更快乐了:)


alt

开始之前

我们曾经尝试修复被破坏的流程,但收效甚微。这次我们下定决心一定要成功。

我们制定了计划。

彻底改变

最初的困难在于如何逐步引入新框架,逐步采用新方法是件很困难的事情,我们需要彻底改变。

我们设置了改变的日期: 2018年9月17日

逐步推进

在sprint中反复出现的一个问题是没有足够时间完成优化,只是致力于解决那些没有被正确理解的工单,因此造成如下后果:

  • 处理工单花费的时间比预期要么更多,要么更少
  • Sprint要么时间太紧,要么不饱和

如果不解决这个问题,那注定要失败。所以,我们做了一些极端的事情,引入了准备周(Walk Weeks) 的概念。

alt

在每3周的sprint之前,进行1周的准备,在此期间,我们会做任何需要做的事,为即将到来的sprint做准备。

准备被认为是一种临时措施,一种达到目的的手段。通过给自己这个准备时间,我们相信可以构建一个良好的待办列表。这确实有点违反直觉,放慢速度,从而帮助我们加快速度。

这并非一帆风顺,但是非常成功。我们能够利用准备时间调整好状态,事实上我们只实践了4次准备周,就觉得可以不需要准备周了。

教育,教育,教育

如果不相信所做的事情,就不可能取得成功。我们需要对这个框架抱有信心,需要理解相关流程。

作为一个团队,我们在一起研究框架,学习涉及到的原则,沟通每个人以及各自团队的期望。

坚定的决心

在努力保持一致(坚定遵循流程)和做出明智务实决定(被动反应)之间,是一条很难走的羊肠小道。

alt

我们之前做出了错误的选择,反应太过积极,因此所做的任何事情都缺乏一致性。

尽管我们想要避免再次掉入这个陷阱,但对于古板的始终遵循流程的态度也非常谨慎。

因此我们制定了一些规则,试图做到两者兼顾:

  • 没有什么是神圣不可侵犯的,但同样也不应该因为一时兴起而做出改变。 改变需要证据来支持(例如,为什么这种改变会让事情变得更好?)不能仅仅因为你不同意或不喜欢某件事而改变,你需要付出努力来证明改变会如何带来改善。
  • 在Sprint中不进行改变。 拍脑袋的改变很少是好主意。通过将变更推迟到sprint结束(在回顾会议中讨论),给自己更多时间来详细考虑相关影响。

基线(Baseline)

预估是我们最大的问题和争论之一,其本身就是一个主题,所以现在不深入讨论。但是,我们预估的单位是点,而不是时间。

预估最有用的东西之一是基线[5]。如果没有某种框架或系统来帮助进行预估,那么很可能只能拍脑袋,我们也有类似问题,因此我们的预估和盲猜差不多。

alt

我们回顾了一些旧工单,挑出了一些典型案例,通过将它们按相对大小排列,能够建立一组基线示例工单。所以当我们下次收到一张工单,感觉看起来像5,就可以回头看看基线,决定是不是5,还是因为今天感觉有点乐观。

我们定期检查基线,以确保仍然相关性,并添加新的示例。

测量

如果不去测量,怎么知道有没有进步呢?怎么判断什么是好的什么是坏的?

有没有曾经听到或读到有人说:

测量所有东西(Measure everything)!

额,如果什么测量都没有(就像我们一样),怎么能理解这句话呢?

我不会这么说。当然,这可以作为一种愿望,但不是一个有用的实际起点。

我们的经验是,需要弄清楚什么是重要的,并进行测量。在这个过程中,我们在理解产出方面遇到了问题,无法定义交付了多少工作、能否改进,以及有没有变得更糟。

你怎么想的?

当我们谈论交付时,真正关心的是交付的点数。所以我们测量点数: 每次sprint承诺的点数和实际完成的点数。但我们知道,并不是所有sprint都一样(圣诞节对我们来说就是个低效的时间段)。因此,我们也记录每个sprint有多少人日。

例如,我们交付了100个点,每人每天交付2个点。

小心

大多数人不喜欢打卡,甚至有些人对此非常反感,因此我们不计时。基本上如果没有生病或者度假,就都算作1个人天。

魔法数字

每人每天的点数

这个指标可以解决请假、大工单、中断等问题。通过记录一次sprint完成的点数和人天,可以展示实际效率,从而可以客观看到是否在总体上有所提高。

另一个重要因素是在哪个级别定义度量。我们实际上是在团队层面收集这些数据(因为这样更容易),但我们并不关心每个团队的指标,只在部门层面关心总体上每人每天的点数。

不是全部

有太多对话都是从一个话题开始,又以另一个话题结束。我们一直不善于解决特定问题,因为我们总是被一堆其他相关问题分散注意力。

举例来说,如果sprint完成的点数较少,我们会认为不好。这跟我们不擅长预估有关,但将关注点转移到其他事情上并不能帮助我们从不好的sprint中吸取教训。

我们尽量避免这些问题。我们承认问题可能存在,也应该正视问题,但它们会分散我们对眼前问题的注意力。

例如,我们可能在预估时有问题,但并不意味着可以错过sprint目标。这是一件简单的事情,但它需要纪律来保持注意力。

各就各位

就这样,我们准备好开始新的冒险了!它将把我们带到哪里?成功了吗?下面会找到答案。


alt

Sprint 1: 开始

在sprint之前,我们进行为期一周的调整,完善待办事项列表,以确保即将到来的3周sprint的工单处于良好状态,我们不希望一开始就被定义不清的工单所困扰。

第一次sprint很难避免拍脑袋,我们显然不知道团队速度会是多少,所以在sprint阶段只添加自认为可以交付的工单。

因为我们有171个人日,因此承诺了105个点。3周后,交付了92个点。

0.54

在Sprint 1期间,每人每天能完成0.54个点,好还是不够好?由于没有可供比较的东西,因此无法确定。

我们所知道的是,第一个sprint总是很棘手,我们需要学会窍门并习惯这个过程。我们还进行了回顾会议,在回顾中发现总体上大家对新流程抱有积极的态度。

我们怀着乐观的心情进入下一次迭代。

Sprint 2,3,4: 一致性

alt

每次sprint前都有一周的准备。事实证明,这种方法真的很有帮助,让我们有足够时间进行适当的准备,并建立一个健康的待办事项列表。

在每一次sprint之前,我们分别承诺要完成148点、137点和114点,并且实现了100%的交付。

有趣的是,每次的人日都不一样: 155、143和113。尽管如此,指标出奇的一致。在这些sprint中,每人每天完成了0.97、0.97和1.02分,表现出了明显的一致性。

连续3次实现sprint目标让我们怀疑是不是对自己太放松了,没有尽可能督促自己。然而,我们坚持自己的模式,决定不做任何草率的改变。我们做得很好,然而即将迎来第一个真正的挑战……

Sprint 5: 减速带

alt

准备周变得越来越容易了,我们打算认真考虑是不是可以不需要准备周了。

第5个准备周正好赶上圣诞节假期,因此第5个Sprint开始于圣诞节后的第一周。

我们决定把准备周留到圣诞节,因为大多数团队成员都休假了,反正也做不了什么。当所有人都回到办公室时,我们直接进入sprint阶段。

紧张

第一周很艰难,很明显我们在圣诞准备周时没有为sprint做好准备。事后看来,我们不应该按时开始sprint,因为根本没有准备好。

第二周开始,sprint变得更加困难。团队之间存在交叉依赖,意味着他们会互相牵制,这给跨团队沟通带来了很大压力,这很糟糕,不可避免的引发了相当大的紧张状态。

艰难的决定

这次sprint只能兑现其承诺的一小部分。让团队在这种紧张状态下再呆两周是没有意义的,所以我们做出了一个艰难的决定,取消了sprint。

所有未完成的工单被放回待办列表中,将Sprint 5的第二周改为准备周。我们要求自己在这周结束前把待办列表恢复到健康状态,这样就可以在下一周开始新的sprint。

我们做了回顾,尽管经历了噩梦般的一周,仍然很乐观。我们意识到,问题在于未能妥善解决圣诞节假期的中断问题,事实上整个流程仍在正常运行。

Sprint 6: Run, Forrest! Run!

alt

Sprint 5回顾中的另一个讨论点是准备周。尽管Sprint 5很痛苦,但我们相信在Sprint 6开始时,状态已经足够好了,可以放弃准备周。就这么定了,从现在开始,我们要冲刺,冲刺,再冲刺。

我们承诺要在Sprint 6中完成99点,结果完成了98点。然而,我们的神奇数字已经下降到每人每天0.85点。

我们在回顾会上讨论了效率的变化。因为放弃了准备周,所以必须在sprint期间找到时间来细化我们的待办列表。在Sprint 6中,我们会抽空做这件事,事后来看,这相当具有破坏性。

分配细化时间

我们决定试着解决这个问题。Scrum告诉我们,应该能够通过分配大约10%的sprint时间来管理待办事项的细化,因此我们决定为每个sprint设置3个3小时会议来完成细化,希望这将为交付工单留出足够时间。

Sprint 7, 8, 9 and 10: 完全有效!

alt

这些sprint覆盖了12周的时间,在这段时间里,我们效率非常高!尽管员工人数有所波动,但这些sprint实现了1.6、1.37、1.26和1.41的平均人效,不仅表现一致,而且还更有效率!

用于待办列表细化的时间分配系统工作得非常好。在回顾会上得到一些反馈后,我们决定如果把细化会议改成4个稍短一点的2小时会议,而不是原来的3个3小时会议,那就更好了。

健康的待办列表

理论上并不影响我们的sprint效率(正面或负面),但实际上确实有影响。真是个好主意!我们的待办列表一直徘徊在150-200点左右。这还不错,但我们想要足够2-3个sprint的待办列表,而150点只够一个sprint的。

变更为4个2小时的细化时间可能不会影响sprint效率,但会让健康的待办列表不断增加,到Sprint 10结束时,达到了300点。

Sprint 11: 别指望了!

alt

到Sprint 10结束时,我们感觉很好,沾沾自喜,冒险已经进行了8个月,并且取得了成功。

但软件开发是残酷的,当你自认为已经掌控全局时,某些习惯会将你绊倒!

在Sprint 11,我们的研效跌到了每人每天只有0.63个点。哎哟!

坚持到底

我们非常沮丧。在结束之前,我们就知道sprint并不顺利。尽管如此,我们现在有强烈信念,相信所做的是正确的,所以没有恐慌。

我们发现,两支团队最终都完成了比通常在sprint中完成的大得多的工单,我们是有意这么做的,分割工单意味着很强的依赖性,这正是在Sprint 5中伤害到团队的东西。

我们意识到这个问题只是由一个小错误引起,因此没有做任何改变。工单之间可以有强烈的依赖关系,这比大量工单要好。需要做的改变是,确保有强烈依赖的工单只被放入一个团队的sprint中。

成长!

这是一个简单问题的简单解决方案,但这个场景确实证明了我们在这段时间内的成长。如果没有这次冒险,我们肯定会有一些冗长痛苦的讨论,从用户故事的定义,到团队专业化,再到如果我们做错了,为什么要费心预估,以及中间的一堆其他争论。在这方面我们有了明显进步。

继续前进!

这并不是冒险的结束,生活还在继续,流程还在改进,但这个小故事即将结束了。我想给大家分享一些帮助我们扭转交付流程的经验:

  • 坚定不移: 如果有些东西被破坏了,就做出一些改变,但不要变得太多、太快。
  • 保持耐心: 冰冻三尺,非一日之寒。需要时间来证明自己,要有耐心。
  • 目标明确: 做出改变是因为你对会发生什么有深思熟虑的假设,无论如何要避免一时兴起或因为某人投入了感情而做出改变。
  • 使用回顾: 确保将讨论推迟到回顾阶段,在可能的情况下,避免持续争论。要在合适的时间和地点做事后诸葛亮!
  • 要有勇气: 做出决定需要勇气,必须向别人证明这些决定是正确的。这很难,但值得。

你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。
微信公众号:DeepNoMind

参考资料

[1]

LeSS Agile, More Productive — Part 1: Pain: https://medium.com/responsetap-engineering/less-agile-more-productive-part-1-bd9f354837f8

[2]

LeSS框架: https://less.works

[3]

JFDI: https://www.urbandictionary.com/define.php?term=JFDI

[4]

Nexus: https://www.scrum.org/resources/scaling-scrum

[5]

How to Estimate without Losing Your Mind: https://medium.com/responsetap-engineering/do-estimate-dont-guess-90d206c74799

- END -

本文由 mdnice 多平台发布

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/202350.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

2023亚太杯数学建模APMCM竞赛C题思路讲解:基于ARIMA与机理模型进行预测

本文针对6大问题,从多角度分析了我国新能源电动汽车发展形势与前景。文中针对不同问题,采用了层次分析法、时间序列模型、机理模型、回归模型等数学方法。并结合实例数据,对相关模型进行求解,以量化预测了新能源电动汽车在政策驱动、市场竞争、温室气体减排等多个方面的潜在贡献…

mongo DB -- aggregate分组查询后字段展示

一、分组查询 在mongoDB中可以使用aggregate中的$group操作对集合中的文档进行分组,但是查询后的数据不显示其他字段,只显示分组字段 aggregate进行分组示例 db.collection.aggregate([{$group: {_id: "$field"}},]) 查询后显示 展开只显示两个字段 二、显示所有字段…

找JPG格式图片的地址(持续更新中)

问题描述:找JPG格式图片的地址 解决办法: 第一个 谷歌的images 第二个,搜狗图片和百度图片 不过下载是WEBP格式,可以使用一个在线WEBP格式转JPG格式的在线网站即可。 转换的网址为: https://ezgif.com/webp-to-j…

linux通过串口传输文件

简介 在嵌入式调试过程中,我们经常会使用调试串口来查看Log或者执行指令,其实,调试串口还有另一种功能,就是传输文件,本文说明使用MobaXterm串口工具来传输文件。 环境要求 嵌入式系统需要安装lsz和lrz,…

【深度学习】卷积神经网络(CNN)

一、引子————边界检测 我们来看一个最简单的例子:“边界检测(edge detection)”,假设我们有这样的一张图片,大小88: 图片中的数字代表该位置的像素值,我们知道,像素值越大&#…

STM32-SPI协议详解及CubeMX+HAL函数配置分析

1 SPI协议 SPI(Serial Peripheral interface)串行外围设备接口是同步全双工的通信总线,在芯片的管脚上只占用四根线。 1.1 物理层 SS/NSS/CS:从设备选择信号线(片选信号线)。由主设备控制,选择指定的从设备。 当主机要选择从设备时,把该从设备的SS信号线设置为低电平…

软件测试岗位与职业发展

一、软件测试岗位有哪些? 在企业中,软件测试领域的几个典型的职位有:功能测试工程师(也叫手工测试)、自动化测试工程师、性能测试工程师、测试开发等。 1、功能测试(手工测试)工程师 主要工作内…

C++算法入门练习——相同的二叉查找树

将第一组n​个互不相同的正整数先后插入到一棵空的二叉查找树中,得到二叉查找树T1​;再将第二组n个互不相同的正整数先后插入到一棵空的二叉查找树中,得到二叉查找树T2​。判断T1​和T2​​是否是同一棵二叉查找树。 二叉查找(搜索)树定义&am…

2023.11.22 IDEA Spring Boot 项目热部署

目录 引言 操作步骤 1. 在 pom.xml 中添加热部署框架支持 2. Setting 开启项目自动编译 3. 以后创建的新项目进行同步配置 4. 重复 配置 步骤2 的内容 5. 开启运行中的热部署 引言 Spring Boot 的热部署是一种在项目正在运行的时候修改代码,却不需要重新启动…

算法复杂度分析

文章目录 有数据范围反推算法复杂度以及算法内容一般方法递归 有数据范围反推算法复杂度以及算法内容 c一秒可以算 1 0 7 10^7 107~ 1 0 8 10^8 108次 一般方法 看循环 有几层循环就可以初步分析O( n i n^i ni) 双指针算法除外O(n) 递归 公式法 根据公式的形式&#xff0…

基于STM32外设 -- 超详细ADC(模数转换器)内部流程及解析

前言 本次我们学习一下STM32的一个基本外设 --- ADC(模数转换器),全程参考手册讲解,讲述ADC的工作模式和作用,转换过程和转换方式。本篇博客大部分是自己收集和整理,借鉴了很多大佬的图片和知识点整理,如有侵权请联系我…

小猪优版的前世今生:从籍籍无名到行业瞩目,再到骤变的风暴中心

1. 前世:籍籍无名到行业新星的崛起 小猪优版在初创时期,并不被大众所知。然而,它凭借对短视频行业的深度洞察,以及独特的商业模式,开始在这个领域崭露头角。它提供了一个平台,不仅助力内容创作者更好地展现…

Vue3 配置全局 scss 变量

variables.scss $color: #0c8ce9;vite.config.ts // 全局css变量css: {preprocessorOptions: {scss: {additionalData: import "/styles/variables.scss";,},},},.vue 文件使用

在springboot中实现WebSocket协议通信

前面介绍了使用netty实现websocket通信,有些时候,如果我们的服务并不复杂或者连接数并不高,单独搭建一个websocket服务端有些浪费资源,这时候我们就可以在web服务内提供简单的websocket连接支持。其实springboot已经支持了websock…

python -opencv形态学操作

python -opencv形态学操作 1.服饰和膨胀 2.开运算和闭运算 3.礼帽运算和黑帽运算 1.服饰和膨胀 opencv 腐蚀通过cv2.erode实现,膨胀通过cv2.dilate实现,看一下下面代码: from ctypes.wintypes import SIZE from multiprocessing.pool i…

技术细分|推荐系统——推荐系统中的数据去偏方法

本篇的主要脉络同样依据中科大何向南教授、合工大汪萌教授联合在 TKDE 上的一篇综述文章展开:Bias and Debias in Recommender System: A Survey and Future Directions。 下面按照前导文章中介绍的数据偏差 Selection Bias、Conformity Bias、Exposure Bias、Posit…

跨境电商包装的可持续性:EPR的视角

跨境电商的崛起已经改变了我们购物的方式,使我们能够轻松购买来自世界各地的产品。然而,这种便捷也伴随着一个不容忽视的问题:包装和废物管理。 跨境电商平台通常需要在全球范围内运送产品,这意味着大量的包装材料和废弃物。在这…

【计算机网络学习之路】TCP socket编程

文章目录 前言一. 服务器1. 初始化服务器2. 启动服务器 二. 客户端三. 多进程服务器结束语 前言 本系列文章是计算机网络学习的笔记,欢迎大佬们阅读,纠错,分享相关知识。希望可以与你共同进步。 本篇博客基于UDP socket基础,介绍…

企业建数仓的第一步是选择一个好用的ETL工具

当企业决定建立数据仓库(Data Warehouse),第一步就是选择一款优秀的ETL(Extract, Transform, Load)工具。数据仓库是企业数据管理的核心,它存储、整合并管理各种数据,为商业决策和数据分析提供支…

模电知识点总结(二)二极管

系列文章目录 文章目录 系列文章目录二极管二极管电路分析方法理想模型恒压降模型折线模型小信号模型高频/开关 二极管应用整流限幅/钳位开关齐纳二极管变容二极管肖特基二极管光电器件光电二极管发光二极管激光二极管太阳能电池 二极管 硅二极管:死区电压&#xf…