为什么Scrum正在变得不重要我们中的许多人都去了健身房，最初获得了良好的效果。一旦你的身体适应了，同样的程序可能会帮助

我们中的许多人都去了健身房，最初获得了良好的效果。一旦你的身体适应了，同样的程序可能会帮助你保持，但你不会看到任何进一步的收获，你甚至可能开始倒退。

我觉得Scrum作为一种交付软件项目的方法论，也存在着同样的问题。Scrum循环，或者说实践Scrum的方式，要么是过于从字面上理解，要么是过于死板地遵守。

Scrum的目的是什么？

Scrum应该是为两周内定义一个可实现的冲刺目标。Scrum应该鼓励团队从经验中学习，在处理问题时进行自我组织，并对他们的得失进行反思以不断改进。

根据我的经验，不幸的是，Scrum最终破坏了敏捷的核心原则，即人高于过程。这在很大程度上归因于糟糕的管理和认证的Scrum大师的兴起。

每天的Scrum应该是一个15分钟的、有时间限制的活动，供开发团队计划未来24小时的工作。不幸的是，Standups已经成为一个固定在JIRA票据上移动的媒介。

在一组泳道上移动票据，有点像计算代码行数作为成功的衡量标准。一个开发者可以仅仅因为他们移动票据的速度而显得很有成效。从另一个角度看，专注于板块可以减少优秀的开发人员在挑战性问题上的工作，看起来很普通。

如果做得好的话，Scrum鼓励团队从经验中学习，在处理问题时自我组织，并反思他们的得失以不断改进。

在臭名昭著的scrum master所倡导的scrum中，你需要清理票据，此外，没有对工作质量的实际检查，这往往是由非技术性的项目负责人决定的。这就激励了人们进入空虚的状态，专注于输出代码。

故事点是一种测量单位，用于表达对完全实现产品积压项目所需的整体努力的估计。或者说，至少它们应该是这样。

根据我的经验，故事点可以鼓励团队对系统进行游戏。在几个冲刺阶段没有达到目标之后，精明的项目经理会变得害怕在冲刺阶段带入太多东西。

对失败的恐惧导致了小规模的故事冲刺，在这种冲刺中，只有次要的项目被带入，以确保其完成。大局变得无关紧要，而专注于小事情最终会使项目脱离正轨。

我曾在一个项目中亲眼目睹了这一点，每个故事都必须有一个自动化测试。这些测试有很高的维护预算，而这个项目的自动化测试使开发速度几乎停滞不前。当自动化测试成为重点时，将开发和维护过程纳入两周的窗口，使持续集成构建时间上升到两个小时。管线停滞不前，变革被迫进行。

把太少的东西带进冲刺阶段的反面是把太多的东西带进冲刺阶段。开发人员和测试人员偷工减料，同时积累了技术债务。债务永远不会被偿还，旋转的盘子最终会撞到地上，导致大规模的、昂贵的重新思考。

我们不应该依赖故事点，而应该追踪已完成的工作，而不是我们所估计的。我发现这一点令人咋舌。如果我想知道一件类似的工作花了多长时间，我想知道实际时间，而不是估计的时间。如果你所有的故事都足够小，那么你就不需要估算。

回顾的目的就是：反思。我们看看哪些工作成功了，哪些没有成功，以及我们想尝试什么样的实验。

不幸的是，它归结为把 "良好的团队合作 "和 "过多的会议 "等相同的便利贴与 "什么地方做得好"、"什么地方做错了 "以及 "我们将如何做得更好 "放在同一泳道上。

第一次复古之后，就很无聊了。经过认证的SCRUM大师缺乏想象力是其中巨大的一部分，但我觉得现在的复古是一种疲惫和沉闷的浪费时间。

黑客马拉松和实践活动可能比尝试新模式的复古更好。协作在黑客马拉松中是隐含的，而成功的唯一途径是良好的团队合作。在一个有趣的问题上工作，并有一个强加的期限，可以确保学习。

复盘迫使人们每周两次带着 "让我们现在就进行复盘 "的心态进入一个房间。这将变得重复和无聊，而且没有活力。团队需要新的刺激，而不是相同的多余的两周土拨鼠冲刺。

Scrum通常是生产力的敌人，在遥远的、后COVID世界中，它更没有意义。

Scrum的前提不应该是一个cookie cutter适合地球上的每个开发团队。很多团队只是照本宣科地做事，其有效性的证据为零。一个不断重复的噩梦，即拼接、冲刺梳理、冲刺计划和回顾，只能导致僵化。SCRUM并不提倡新的和新鲜的工作方式，相反，它提倡重复性。

让优秀的开发团队根据他们的情况进行自我组织。追踪被运送到生产中的东西，加上事后花费的时间（以天为单位！），并追踪它。

专注于现实，而不是一些模糊的可理解的进度表。自动化所有你能做的，并有一个超平滑的管道。消除所有的浪费。在你了解更多的时候，不断地重新估算。当你在工作开始时知道的最少的时候，你就在估算并坚持你的神话故事点，这种想法是站不住脚的。

成年人玩计划扑克就像它听起来一样可笑。