每个团队可能都有一套适合自己的敏捷方法，本文介绍了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]^重新为混乱的流程带来秩序的故事。
我们的痛点:
- 多年不断发展的软件开发流程
- 每个人都有不同的想法
- 马上就做(JFDI, Just Focus and Do It)
我们的敏捷
记不清有多少次听到这样的对话了。
这个新功能很紧急，能不能跳过测试，更快发布?
或者...
我们不能让流程成为阻碍，如果不修复这个错误，"客户A"就会取消订单!
还有其他一千种表达方式: 我想让你做的事情太重要了，不能因为"流程"而放慢速度。 这些对话通常以某人说出下面这句貌似正确的话结束:
好吧，这看起来一点都不敏捷!
这就是问题所在，对于团队中的许多人来说，敏捷意味着无论何时我们都应该去做我们认为应该做的事情。这听起来很敏捷，但一段时间后就变成了混乱，这当然不是敏捷方法论。
我们过去经常这么处理: 这个流程很尴尬，无法处理X情况，所以我们会改变流程。当过了一个迭代周期后，遇到了类似情况，我们就再次改变流程。
不出意外的话，不久之后，流程就会变得复杂、矛盾，而且很难帮助我们交付软件。对快速交付、快速行动和适应变化的热情蒙蔽了我们的判断，使我们陷入困境。
争论越来越多...
我们无意中营造了一个没有确定性的环境，即使相似的的问题曾经出现过，也必须重新解决每个问题，因为我们没有确定可靠的模式。
没人喜欢这样。
我们只是例行公事的改变流程，试图为每个场合和每种可能性制定一个规则，从而迷失在复杂性中，并对支离破碎的流程失去了信心。
可以猜到后面会发生什么。我们都是充满激情的人，都想把工作做好，都想做出令人惊叹的产品。对于如何解决这个问题，我们都有自己的看法。
经常会发生同样的争论:
- 预估的意义是什么?(我们的预估太不一致了!)
- 是否应该在同一个迭代冲刺(sprint)中进行缺陷调查和修复?
- 在一个sprint中能容纳多少东西?
- 什么是用户故事(User Story)?
大家真的非常沮丧，甚至有一些人离开了团队。
JFDI共和国
人人喜欢JFDI^[3]^，不是吗？现在就做这件事，不要问问题。
对于缺陷，对于特性请求，甚至对于大型项目，我们都有JFDI......想象一下这种场景......
但是，为什么？
那时候我们经常问这个问题，为什么要把所有的时间都花在突然从天而降的工作上？这个问题在当时很难回答，但事后看来，答案很简单:
待办列表(Backlog) ------ 我们没有一个健康的待办列表。尽管我们在待办列表中有项目，但缺乏客观的预估方法，这意味着我们无法确定优先级。对于新的工作，也没有可靠方法来理解它相对于待办列表中其他项目的优先级。
依据门槛(Threshold of Evidence) ------ 对于被认为非常重要，需要立即启动的项目，只有很少的支持依据，如果某位公司高层说这件事很重要，那就足够了。有时候，在初创公司这是可以接受的，尤其是如果领导层有良好的直觉。但对于成长型企业来说，可能具有难以置信的破坏性。
现在回想起来，这显然是管理工程团队的愚蠢方式。但是，这很难抗拒，因为我们没有办法证明JFDI对生产力有多大的影响。
无法证明JFDI如何影响工作速度，我们没有数据。
放松一下，再试一次
很明显，我们需要停一下，寻找解决方案。
Nexus
我们首先尝试的是Nexus^[4]^，一种Scrum扩展方法，但几个月后，我们的问题依然没有解决。不是说这种方法不好，如果多给它点时间，Nexus很可能已经解决了我们的问题。然而，我们觉得这种方法对我们的团队并不自然，因此我们继续寻找。
LeSS框架
2018年夏天，我们发现了LeSS框架。LeSS在我们团队取得了巨大成功，使我们的生产效率更高、更可靠、交付速度更快。最重要的是，我们更快乐了:)
开始之前
我们曾经尝试修复被破坏的流程，但收效甚微。这次我们下定决心一定要成功。
我们制定了计划。
彻底改变
最初的困难在于如何逐步引入新框架，逐步采用新方法是件很困难的事情，我们需要彻底改变。
我们设置了改变的日期: 2018年9月17日
逐步推进
在sprint中反复出现的一个问题是没有足够时间完成优化，只是致力于解决那些没有被正确理解的工单，因此造成如下后果:
- 处理工单花费的时间比预期要么更多，要么更少
- Sprint要么时间太紧，要么不饱和
如果不解决这个问题，那注定要失败。所以，我们做了一些极端的事情，引入了准备周(Walk Weeks) 的概念。
在每3周的sprint之前，进行1周的准备，在此期间，我们会做任何需要做的事，为即将到来的sprint做准备。
准备被认为是一种临时措施，一种达到目的的手段。通过给自己这个准备时间，我们相信可以构建一个良好的待办列表。这确实有点违反直觉，放慢速度，从而帮助我们加快速度。
这并非一帆风顺，但是非常成功。我们能够利用准备时间调整好状态，事实上我们只实践了4次准备周，就觉得可以不需要准备周了。
教育，教育，教育
如果不相信所做的事情，就不可能取得成功。我们需要对这个框架抱有信心，需要理解相关流程。
作为一个团队，我们在一起研究框架，学习涉及到的原则，沟通每个人以及各自团队的期望。
坚定的决心
在努力保持一致(坚定遵循流程)和做出明智务实决定(被动反应)之间，是一条很难走的羊肠小道。
我们之前做出了错误的选择，反应太过积极，因此所做的任何事情都缺乏一致性。
尽管我们想要避免再次掉入这个陷阱，但对于古板的始终遵循流程的态度也非常谨慎。
因此我们制定了一些规则，试图做到两者兼顾:
- 没有什么是神圣不可侵犯的，但同样也不应该因为一时兴起而做出改变。 改变需要证据来支持(例如，为什么这种改变会让事情变得更好?)不能仅仅因为你不同意或不喜欢某件事而改变，你需要付出努力来证明改变会如何带来改善。
- 在Sprint中不进行改变。 拍脑袋的改变很少是好主意。通过将变更推迟到sprint结束(在回顾会议中讨论)，给自己更多时间来详细考虑相关影响。
基线(Baseline)
预估是我们最大的问题和争论之一，其本身就是一个主题，所以现在不深入讨论。但是，我们预估的单位是点，而不是时间。
预估最有用的东西之一是基线^[5]^。如果没有某种框架或系统来帮助进行预估，那么很可能只能拍脑袋，我们也有类似问题，因此我们的预估和盲猜差不多。
我们回顾了一些旧工单，挑出了一些典型案例，通过将它们按相对大小排列，能够建立一组基线示例工单。所以当我们下次收到一张工单，感觉看起来像5，就可以回头看看基线，决定是不是5，还是因为今天感觉有点乐观。
我们定期检查基线，以确保仍然相关性，并添加新的示例。
测量
如果不去测量，怎么知道有没有进步呢？怎么判断什么是好的什么是坏的？
有没有曾经听到或读到有人说:
测量所有东西(Measure everything)!
额，如果什么测量都没有(就像我们一样)，怎么能理解这句话呢？
我不会这么说。当然，这可以作为一种愿望，但不是一个有用的实际起点。
我们的经验是，需要弄清楚什么是重要的，并进行测量。在这个过程中，我们在理解产出方面遇到了问题，无法定义交付了多少工作、能否改进，以及有没有变得更糟。
你怎么想的？
当我们谈论交付时，真正关心的是交付的点数。所以我们测量点数: 每次sprint承诺的点数和实际完成的点数。但我们知道，并不是所有sprint都一样(圣诞节对我们来说就是个低效的时间段)。因此，我们也记录每个sprint有多少人日。
例如，我们交付了100个点，每人每天交付2个点。
小心
大多数人不喜欢打卡，甚至有些人对此非常反感，因此我们不计时。基本上如果没有生病或者度假，就都算作1个人天。
魔法数字
每人每天的点数
这个指标可以解决请假、大工单、中断等问题。通过记录一次sprint完成的点数和人天，可以展示实际效率，从而可以客观看到是否在总体上有所提高。
另一个重要因素是在哪个级别定义度量。我们实际上是在团队层面收集这些数据(因为这样更容易)，但我们并不关心每个团队的指标，只在部门层面关心总体上每人每天的点数。
不是全部
有太多对话都是从一个话题开始，又以另一个话题结束。我们一直不善于解决特定问题，因为我们总是被一堆其他相关问题分散注意力。
举例来说，如果sprint完成的点数较少，我们会认为不好。这跟我们不擅长预估有关，但将关注点转移到其他事情上并不能帮助我们从不好的sprint中吸取教训。
我们尽量避免这些问题。我们承认问题可能存在，也应该正视问题，但它们会分散我们对眼前问题的注意力。
例如，我们可能在预估时有问题，但并不意味着可以错过sprint目标。这是一件简单的事情，但它需要纪律来保持注意力。
各就各位
就这样，我们准备好开始新的冒险了！它将把我们带到哪里？成功了吗？下面会找到答案。
Sprint 1: 开始
在sprint之前，我们进行为期一周的调整，完善待办事项列表，以确保即将到来的3周sprint的工单处于良好状态，我们不希望一开始就被定义不清的工单所困扰。
第一次sprint很难避免拍脑袋，我们显然不知道团队速度会是多少，所以在sprint阶段只添加自认为可以交付的工单。
因为我们有171个人日，因此承诺了105个点。3周后，交付了92个点。
0.54
在Sprint 1期间，每人每天能完成0.54个点，好还是不够好？由于没有可供比较的东西，因此无法确定。
我们所知道的是，第一个sprint总是很棘手，我们需要学会窍门并习惯这个过程。我们还进行了回顾会议，在回顾中发现总体上大家对新流程抱有积极的态度。
我们怀着乐观的心情进入下一次迭代。
Sprint 2，3，4: 一致性
每次sprint前都有一周的准备。事实证明，这种方法真的很有帮助，让我们有足够时间进行适当的准备，并建立一个健康的待办事项列表。
在每一次sprint之前，我们分别承诺要完成148点、137点和114点，并且实现了100%的交付。
有趣的是，每次的人日都不一样: 155、143和113。尽管如此，指标出奇的一致。在这些sprint中，每人每天完成了0.97、0.97和1.02分，表现出了明显的一致性。
连续3次实现sprint目标让我们怀疑是不是对自己太放松了，没有尽可能督促自己。然而，我们坚持自己的模式，决定不做任何草率的改变。我们做得很好，然而即将迎来第一个真正的挑战......
Sprint 5: 减速带
准备周变得越来越容易了，我们打算认真考虑是不是可以不需要准备周了。
第5个准备周正好赶上圣诞节假期，因此第5个Sprint开始于圣诞节后的第一周。
我们决定把准备周留到圣诞节，因为大多数团队成员都休假了，反正也做不了什么。当所有人都回到办公室时，我们直接进入sprint阶段。
紧张
第一周很艰难，很明显我们在圣诞准备周时没有为sprint做好准备。事后看来，我们不应该按时开始sprint，因为根本没有准备好。
第二周开始，sprint变得更加困难。团队之间存在交叉依赖，意味着他们会互相牵制，这给跨团队沟通带来了很大压力，这很糟糕，不可避免的引发了相当大的紧张状态。
艰难的决定
这次sprint只能兑现其承诺的一小部分。让团队在这种紧张状态下再呆两周是没有意义的，所以我们做出了一个艰难的决定，取消了sprint。
所有未完成的工单被放回待办列表中，将Sprint 5的第二周改为准备周。我们要求自己在这周结束前把待办列表恢复到健康状态，这样就可以在下一周开始新的sprint。
我们做了回顾，尽管经历了噩梦般的一周，仍然很乐观。我们意识到，问题在于未能妥善解决圣诞节假期的中断问题，事实上整个流程仍在正常运行。
Sprint 6: Run, Forrest! Run!
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: 完全有效!
这些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: 别指望了!
到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多平台发布