把Scrum留给橄榄球
哦，你在上一个雇主的Scrum上遇到过问题吗？嗯，那不是真正的Scrum。&你的Scrum主人，他不是一个真正的苏格兰人点击推特很难批评Scrum。我脑海中的“Scrum”概念可能与您所熟悉的截然不同。这是故意的，也是承认的。在官方的Scrum指南中，我们可以找到Scrum的定义：
一个框架，人们可以在其中解决复杂的适应性问题，同时高效地和创造性地交付尽可能高价值的产品。
因为定义很模糊，在接下来的长篇大论中，我唯一能批评的就是我熟悉的“Scrummers”的常见做法。希望你们中的一些可爱的读者能产生共鸣。
Scrum的核心是Sprint，一个月或更短的时间段，在此期间创建“完成”的、可用的和潜在的可发布的产品增量。
冲刺是有用的，就像电子游戏中的成就是有用的一样；它们让我们内心感到温暖和模糊。激励是一种强有力的工具，不要误解我的意思。问题是，那些温暖的模糊大多是为了管理团队。这会让他们觉得自己掌握了控制权，并被告知了情况。他们确切地知道做了什么，什么时候完成的。
短跑需要可实现的短期目标。让我们假设我是一个进行两周冲刺的团队的一员(因为持续时间必须是一致的)，并且我被指派构建一个在整个事情完成之前都没有用处的API。也就是说，在我的头脑中，我相信如果我能始终如一地工作，整个任务就需要两个月的时间。
我需要将API分成几个部分，可以在2周内完成。我也许可以在短短一两天内完成一些端点，但我不想错过任何一个目标，我知道一些更困难的逻辑可能需要每个端点整整一周的时间。有14个端点，所以我决定每个冲刺2个端点的整数。
一个本可以在2个月内完成的API现在将需要近4个月的时间，因为我在这一过程中浪费了时间来设置人工停靠点。我的冒名顶替者综合症开始出现，但至少管理层会有相当多的倦怠图表。
Scrum Master是Scrum团队的仆人领导。Scrum Master帮助Scrum团队之外的人了解他们与Scrum团队的哪些交互是有帮助的，哪些是没有帮助的。
https://www.scrumguides.org/scrum-guide.html。
根据Scrum大师的想法是如何实现的，它可能是一个糟糕的想法，也可能是一个更糟糕的想法。让我们来谈谈在我看来最常见的情况。
Scrum主管是一种非技术型的中层管理人员，喜欢掌管事情。
除了他们所有的开发工作之外，工程师们现在还经常被Scrum管理员打断，他询问Reaction应用程序的“Java代码”什么时候可以完成。
其目的是阻止外部世界打扰他们的开发人员的个人就是最大的麻烦。在我看来，非技术人员应该很少(如果有的话)管理技术人员(首席执行官除外)。我应该能够就我的任务向我的老板寻求帮助和建议，或者至少我应该希望他们理解我的任务。
即使Scrum大师是一个从高层掌握技术问题的可爱的人，Scrum Master也不是一份全职工作。Scrum大师的日常任务通常只是早上一两次站立，下午与上级开会，其他就没什么了。
如果您仍然觉得需要一个“Scrum大师”，那就让主要开发人员来处理这项工作。他们已经站起来了，很可能对正在发生的事情有更好的了解。你没有把更多的东西放在他们的盘子上，你很可能是在减少一些东西。
在Scrum中，评估有一个主要目的--计算出团队在给定的Sprint中可以完成多少工作。如果我承认冲刺是个好主意(我显然不相信)，那么官方Scrum指南中对估计的描述就不会有问题。
问题是，实践中的估计是对现实的私生化。Scrum指南在这个主题上含糊其辞，所以经理们自己动手解决问题。在这情况下，我会再次批评我在预算方面所见的一些常见做法。
许多超级时髦的组织喜欢使用最令人困惑的标准来进行估计。他们声称，不知何故，这使得评估过程更快、压力更小。可悲的是，我仍然不信服。
我在一家新公司的第一天参加了我们的评估会议，因为我听说他们使用了可怕的“故事点”系统：
Scrum大师：“斐波纳契数，其中8分是最大值，因为我们将其定义为开发人员在两周冲刺期间可以处理的工作量。”
估算的最终目标是转换工作量->；时间。为什么我们需要添加额外的工作负载步骤->；故事点->；时间？简单估计“多少天？”这样会更容易思考和推理，同时也提供了更多的粒度。
我们使用斐波纳奇数，因为很难想象7天和8天的区别。没有人能如此近距离地估计。斐波纳契数列在每一步都会上升~60%，所以你不会被迫非常接近你的估计值。
对于这一点，我建议基于您首先关心的标度，即时间，进行基数为2的幂运算。
如果估计是在可测量的时间内进行的，那么如果工程师没有达到他们的估计，他们会觉得自己搞砸了。
好的，估计是很困难的，我们不想让任何人因为他们不是完美的估计者而觉得自己是个糟糕的工程师。也就是说，与其开始一场“到底是谁的线？”的游戏，不如先玩一场“到底是谁的线？”
如果估计结果是不好的，则可以在不损害估计者的情况下对其进行重新估计。
我是敏捷方法论和敏捷宣言的粉丝。我不是Scrum的粉丝。在后面的一篇文章中，我计划回顾一下我对如何在运行“敏捷”组织的同时做些什么来代替Scrum的想法。