使用Scrum的四个主要问题

Scrum是一个流行语，是软件组织中层管理人员选择的美德信号。如果您作为经理的目标是实现一个系统，您可以：加快进度的出现、支付两倍于您所需人数的费用、根据无意义的指标收集细粒度的数据。然后，在Scrum中我们先来就简单的举个例子： “哦，您上一个雇主在Scrum上遇到了问题吗?嗯，那不是真正的Scrum。”您的Scrum主管，他不是真正的苏格兰人不用说，我们不在Qvault使用scrum 。这给我们带来了第一个问题...

　　问题1-Scrum模糊

很难批评Scrum。我脑海中的“ Scrum”想法可能与您熟悉的想法大不相同。这是设计使然，也因录取而定。在官方的《Scrum指南》中，我们找到了Scrum的定义：

一个框架，人们可以在其中解决复杂的适应性问题，同时以富有创造力的方式交付最高价值的产品。

更简洁地说：

Scrum(名词)-1. [软件]任何运行良好的良好过程

因为定义太含糊，所以我在接下来的文章中唯一可以批评的就是我所熟悉的“ Scrummers”的常见做法。希望你们中的一些可爱的读者可以建立联系。

　　问题2-“冲刺”

根据官方指南：

Scrum的核心是Sprint，即一个月或更短的时间范围，在此期间创建“完成”，可用且可能发布的产品增量

冲刺是有用的，就像电子游戏中的成就是有用的;它们使我们内心感到温暖和模糊。动机是一个强大的工具，请不要误解我。问题在于，那些热烈的毛病主要是为了管理团队。这使他们感到有控制权并了解情况。他们确切地知道完成了什么以及何时完成。

我不反对通知管理人员…… 但是要付出什么代价？

短跑需要可实现的短期目标。假设我是一个进行两周冲刺的团队的一员（因为持续时间必须保持一致），并且我被分配去构建一个直到完成所有事情才有用的API。也可以说，在我的脑海中，我相信如果我能始终如一地工作，整个任务将花费两个月。

我需要将API分成可以2周为增量完成的部分。我也许可以在一两天之内完成一些端点，但是我不想错过任何目标，而且我知道一些较困难的逻辑可能要花费整整一周的时间每个端点。有14个端点，因此我决定每个冲刺2个端点的整数。

一个本来可以在2个月内完成的API 现在将花费将近4个月，因为我浪费了沿途添加人工停止点的时间。我的冒名顶替综合症开始出现，但至少管理层会有不错的燃尽图。

　　问题3-Scrum Master

Scrum Master是Scrum团队的仆人领导。Scrum Master帮助Scrum团队之外的人员了解他们与Scrum团队的哪些互动是有帮助的，哪些没有帮助。

根据Scrum Master想法的实现方式，它可能是坏主意，也可能是更糟的主意。让我们谈谈我看来最常见的情况。

Scrum Master是一种非技术性的，中层管理的类型，喜欢负责一些事情。

除了他们所有的开发工作之外，工程师现在还经常被Scrum主管打断，后者要求什么时候完成React应用程序的“ Java代码”。

旨在阻止外界打扰开发人员的个人是最大的麻烦。我认为，非技术人员很少（如果有的话）管理技术人员（CEO除外）。我应该能够向上司寻求有关我的任务的帮助和建议，或者至少我应该期望他们能理解我的任务。

即使Scrum Master是一个可爱的人，从高层次上掌握技术问题，Scrum Master也不是一个全职工作。Scrum Master的日常任务通常涉及早上一两口的站立，下午与上级的会议，等等。

如果您仍然需要“ Scrum Master”，则让首席开发人员来处理。他们已经站起来，可能会对发生的事情有更好的了解。您不会在他们的盘子上放更多东西，您可能会摘下一些东西。

　　问题4-估算

在Scrum中，估算的主要目的是-确定团队在给定的sprint中可以完成多少工作。如果我同意Sprint是个好主意（我显然不相信），那么官方Scrum指南中对估算的描述就不会有问题。

问题在于，实际中的估算是现实的混蛋。Scrum指南在该主题上含糊不清，因此管理人员可以自己处理问题。考虑到这一点，我将再次批评一些关于估算的常见做法。

　　斐波那契和T恤尺寸

许多超级公司组织喜欢使用最令人困惑的量表进行估算。他们声称，这使估算速度更快，压力较小。我仍然深信不疑。

我在新公司的第一天，在我们的估算会议上，听说他们使用了可怕的“故事积分”系统：

　　这里的分数是多少？

Scrum master：“斐波那契，最高为8分，因为我们将其定义为开发人员在两周的冲刺中可以处理的工作量”。

我最终了解了实际的系统。

1分：0-8小时

2分：8小时-2.4天

3分：2.4天-1周

5分：1周-1.5周

8分：2周

估算的最终目标是将工作量->时间转换为。为什么我们需要增加工作量->故事点->时间?简单估算“多少天?” 本来可以更容易地思考和推理，同时还可以提供更多的粒度。

使用这种野蛮简单的系统的普遍反对意见是：

我们使用斐波那契是因为很难想象7天和8天之间的差异。没有人能对此做出精确估计。斐波那契数列的每一步都会增加约60%，因此您不必被迫非常接近您的估计。

为此，我建议基于您首先关心的规模time的 base-2取幂。

1、2、4、8。小时，天或周。

看来我们已经解决了问题!直到另一个好主意的Scrum管理员开始：

如果估算是基于可测量的时间，那么工程师如果错过估算，就会觉得自己搞砸了。

好的一点是，估算很困难，我们不希望任何人仅仅因为他们不是理想的估算员而觉得自己是一名糟糕的工程师。就是说，也许不是开始游戏“反正是谁的线?”

可以设定合理的期望，即估算值就是估算值。

估计-粗略计算或判断其价值，数量，数量或范围。

如果估算结果很差，则可以在不损害估算器的情况下重新估算。

最后说明：敏捷！= Scrum

我喜欢敏捷方法论和敏捷宣言。我不是Scrum的粉丝。在以后的文章中，我计划在仍然运行“敏捷”组织的同时，重新思考如何代替Scrum。想了解更多关于Scrum的信息，请继续关注中培教育吧。