全文共3518字，预计学习时长9分钟
大多数使用Scrum的公司都会花很多时间讨论速度，并设计提高速度的方法。开发速度变成了一个不可思议的、几乎是神话般的数字，开发人员在每个Sprint中都必须追求这个数字。
在速度被打破的公司里充斥着这样的评论：
· 为什么我们这个Sprint的速度低于上一个Sprint? 你能提供一个合理的解释吗?
· 速度停止增加。也许该雇佣一个新的Scrum管理员了?如果一个Scrum Master不能提高速度，那还有什么意义呢?
· 我们并没有在Sprint中完成所有的故事。怎样才能保证下次能全部完成呢?
对更快速度的竞争是许多开发人员讨厌使用Scrum的首要原因。你永远没有足够的时间来喘口气，停下来反思一下工作，大家变得痛苦不堪。程序员感觉自己像流水线上的工人一样被对待，他们需要尽快完成罚单。在任何时候放慢速度，很快就会受到惩罚。
速度崇拜被认为是必要的，开发人员是昂贵和稀缺的资源，我们需要榨干他们的价值，速度是执行这种对金钱思考的最大作用的完美工具，高速度一定意味着我们从宝贵的资源中获得了物有所值的价值。
不幸的是，事实并非如此。
速度统治一切
速度成为了统治它们的唯一数字。每一次冲刺，数字看起来都很棒。但是，这种数字上的美丽带来了高昂的代价——团队中的每个人都很痛苦。团队意识到让人们满意的唯一方法是速度遵从宇宙的法则：不断膨胀。他们知道这不是能够永远保持下去的东西。
被速度崇拜洗脑的公司不会尊重软件工艺，也不会尊重价值的交付。所有的人关心的是这个愚蠢的数字，以及什么时候他们可以期望自己的特性能够实现。技术债务拖累你了吗？停止抱怨，这是一个假想的朋友，阻止我们提供更多的功能。
开发人员是流水线上的工人吗?开发人员是否需要定期进行速度测试，以确保他们能够不断地推出新特性?提供更多的功能总是更好吗?我相信所有这些问题的答案都是一个响亮的“不”。
过于关注Scrum团队的速度表明公司对Scrum的目的一无所知，事实上，速度崇拜毫无意义
1.输出的结果比输出更重要
Scrum的目的是帮助你交付可能具有最高价值的产品。使用速度来度量开发人员的输出很容易，但这并不重要。更多的功能并不意味着更多的价值或更好的产品。
请允许我用一个日常的例子来说明。我可能会花8个小时写一篇只有100次浏览量的文章，有时我在火车上一小时内写一篇文章，浏览量超过1万次。在最好的情况下，努力和价值之间的关系是模糊的。
读者不知道我在一篇文章上花了多少时间。他们只关心作品带给他们的价值。客户也一样——他们不会关心开发人员在构建一个特性上花费了多少精力。
停止优化开发团队花费的工作量，开始优化特性对客户的影响。交付价值是一件棘手的事情。交付价值需要实验、尝试和错误，以及反思的空间。通过推动团队优化功能交付，你扼杀了创造一个对客户重要的产品所必需的创新和学习。
团队是否为客户和企业创造了有价值的结果?如果他们能通过减少交付来做到这一点，那就是一种胜利。
2.速度被有意地排除在Scrum之外
速度不是Scrum的一部分，它是可选的和补充的实践。Scrum团队可以决定采用或拒绝开发速度。自组织Scrum团队可以自由地停止进行计划扑克游戏，不再报告他们的开发速度。
速度被视为Scrum的同义词，这是一种谬误。Scrum让你决定如何处理评估和吞吐量。你有无数可行的选择：#不估计、t恤尺寸、理想的日子、能力驱动的冲刺计划，等等。如果速度拖着你往下走，请抛弃它，只有Scrum团队才能决定如何评估和预测。
3. Sprint的Backlog除了开发团队之外，没有人关心
Sprint通常被视为压制开发人员的一种方式。它被视为一种工具，用来迫使团队尽可能多地完成工作。这种想法是错误的，只有开发团队被允许在Sprint期间进行更改。以下是Scrum指南中的措辞：
· Scrum Guide, 2017年11月：只有开发团队可以在Sprint期间更改其Sprint Backlog。
· Scrum Guide, 2017年11月："短跑进行时"。那么冲刺什么时候开始，什么时候结束呢?一个新的Sprint在前一个Sprint结束后立即开始。
因为Sprint是所有Scrum事件的容器，所以第一次Sprint从第一个事件开始：Sprint计划。第二个Sprint和后面的任何Sprint都在Sprint的时间盒到期时开始——基本上，你总是在冲刺。
简而言之，只有开发团队可以更改Sprint中的内容，即使是在Sprint计划期间。认为Sprint存在的目的是向开发人员施加压力的观点是没有根据的。只有开发团队自己施加压力，开发人员才会在Sprint中感受到压力。完成了多少工作，最终会产生速度，这完全由开发团队决定。
4.每一次冲刺所做的唯一承诺就是目标
想象一下，即使团队在Sprint中增加了太多的工作，他们也不会承诺完成添加到Sprint Backlog中的所有工作。开发团队承诺在每个Sprint中只完成一件事：Sprint目标。
这对开发团队意味着什么?只要开发团队没有将Sprint目标置于风险之中，Sprint Backlog就是完全灵活的。与Sprint目标不相关的Sprint待办项可以被带到下一个Sprint，没有任何损失。实现Sprint目标所需的计划和工作可以在任何时候进行讨论和修改。
实现目标比按照计划或完成特定的工作更重要。没有对速度的承诺，只有对范围可变的目标的承诺。
5. Scrum已经为交付创造了足够的紧迫感
Scrum已经包含了足够多的设备，这些设备给开发团队带来了健康的压力，让他们在每个Sprint都交付一个工作产品。“冲刺”、“冲刺计划”、“每日Scrum”和“冲刺评审”都是为了这个目的。即使是Sprint回顾也是为了了解你可以做得更好，以便下次交付产品增量。
它们的存在使得对速度施加额外的压力是不必要的，甚至是有害的。在每日的Scrum中，每个工作日的紧迫性都被灌输以满足Sprint的目标。做好Scrum需要纪律和专注，给你的团队施加太多的速度压力只会埋葬你的团队，让他们走向失败。
公司应该对他们的开发者表现出更多的信任和尊重
迷恋速度是特征工厂思维模式的一个明显标志，对速度的关注表明该公司相信提供更多的功能总是更好的。不幸的是，更多的特性并不意味着交付更多的价值。为了创造价值，你需要时间去试验、创新和反思。通过在建筑上施加太多的压力，你就剥夺了创造和弄清楚什么才是真正会产生影响的必要的喘息空间。
不要过分关注开发速度，这个问题事关尊重：我们是否相信开发人员是有能力的，并且相信他们能够在没有开发速度之剑的情况下交付产品？Scrum已经包含了足够多的工具，可以在每个Sprint中灌输一种紧迫感来交付有价值的东西。
Scrum给予开发者的权力比大多数人想象的要大得多。不要让对Scrum自私错误的解释把你放在一个想象的盒子里，打破这个框框，使用Scrum为你服务，不要被公司的速度废话所愚弄。
Scrum通过设计给了开发人员很多权力。通过设计，Scrum希望授权从事这项工作的人创建他们自己的规则。使用这种力量以可持续的速度工作，并在你认为合适的情况下处理技术债务。
如果你在一家餐馆当厨师，你做饭时打扫厨房不需要得到许可。为什么开发人员需要获得许可来清理他们的代码?如果是有必要做的工作，你不需要征求任何人的同意。
只要你能像承诺的那样交付Sprint目标，任何人都会被你为了让产品给客户和业务带来价值而做的其他事情所困扰。没有人应该关心你完成了多少待办事项，只要你交付了一个满足Sprint目标的产品增量。
不要让自己被速度所吓倒，把自己放回到属于你的驾驶座位上，不要让那些不知道你在做什么的人来决定你做了多少工作。作为一名专业人士，你很清楚自己应该得到公司的尊重和信任。
留言点赞关注
我们一起分享AI学习与发展的干货
如转载，请后台留言，遵守转载规范
如若转载，请注明出处：https://www.ozabc.com/keji/8236.html