Scrum冲刺是否意味着以最快的速度工作？

21

我最近采访了一些从事敏捷，Scrum的公司，以进行更精确的介绍，有些事情在我看来并不像敏捷。现在，我将考虑一个特别令我感兴趣的案例，即Scrum冲刺。

我与一位特定的项目经理交谈（是的，我说项目经理）自豪地说，她的团队中的人们理解（“被告知”这是我从上下文中挑选的），当工作时间结束时，您不回家，无论完成多少工作，您都会在工作完成后回家。我在这两行之间读到的是，我们将尽可能多的功能组合到sprint中，并加班以实现它。

现在，我还没有做敏捷（与大多数仍然喜欢瀑布的金融和政府机构合作），但是我的理解是：

Scrum中的sprint是敏捷中通用迭代的名称；
团队应该以可持续的速度工作，并尽量避免长期加班，因为这只会在短时间内产生影响，并且这种影响因长期存在的问题而相形见war。

我的陈述正确吗？而且，我是否应该将经理的介绍作为危险信号？

agile scrum development-methodologies

— 约翰·杜多
source

敏捷方面也没有真正的经验，但是据我了解，您的sprint工作量应与sprint的持续时间保持平衡，因此开发人员低估了他们的工作量，或者经理只是在不要求他们反馈工作量的情况下就给他们工作。在这种情况下，可能是后者。-如果我错了，请纠正我

— Andreas 2014年

4

@gnat我认为问题太过不同了

— Andreas

27

“……工作时间结束后，您不回家，完成工作后回家，无论需要多少时间……”。像风一样奔跑。她是个白痴。

— JᴀʏMᴇᴇ

我投票重新提出这个问题。提议的重复项“敏捷-新-微观管理”与该问题的共同点是，经理称某事为“混乱”，而问询的人想知道这是否真的是混乱。这个问题是关于“加班”的，关于“不允许与其他开发者交谈”的提议。

— k3b 2014年

“……上班时间不回家，完成工作就回家，不管花多少钱”似乎与可持续步伐的关键概念直接冲突。如果我不得不把食物放在桌子上，那就在那里工作。HST，如果这种情况不时发生，我对此没有任何问题。有时，尽管付出了一切努力，但还是很紧缩，客户至上。但是她使这听起来像是经常发生的，而且令人钦佩。这意味着他们没有做根本原因来理解为什么会发生并解决根本问题。

— 唐·布兰森

27

您无需费心寻找这些实践与敏捷背后的原理背道而驰。敏捷宣言背后的原则之一是：

敏捷过程促进可持续发展。赞助者，开发者和用户应该能够无限期地保持恒定的步伐。

几年前，Scrum做出了微妙但重要的改变。他们预测团队认为自己可以完成的工作，而不是团队致力于可以完成的工作。

这种变化来自滥用，这听起来很像您描述的“不回家，直到完成”的态度。在开发中，团队无法控制的因素很多，他们无法承诺-使用天气类比，您不能“承诺”明天会下雨。

要直接回答您的问题：

是的，Sprint是Scrum中迭代的名称。有关差异，请参见此答案
是的，团队应该以可持续的速度工作。唯一的加班可以肯定的是，它会降低生产效率的团队长期。
是的，这是一个危险信号！

— 戴夫·希里尔
source

23

是的，你是对的，如果我被告知你被告知，我会尽快离开那里。他们只是以敏捷为借口。听起来像经典的死亡游行。

— 米奇·瓦茨（Miki Watts）
source

3

死亡游行通常不会结束吗？如果那是他们一次又一次地冲刺的工作方式，那么这个项目听起来就像是一个永恒的地狱。

— DXM 2014年

5

不，在死亡游行中，总会出现“我们只需要推送到下一个版本，然后我们就可以重构和修复错误！哎呀，我们向客户承诺两个月内可以发布下一个版本，只需要推送到下一个版本即可。版！” 等等，您就明白了。

— Miki Watts

2

@DXM当每个人退出或被解雇时就结束了。死亡三月计划可能会持续数年。

— Dogweather 2014年

3

死亡时@DXM死亡行军结束。

— Dave Hillier 2014年

嗯，我想我在那儿投射自己的经历。在我看来，管理不善的项目在某种程度上是死亡行军与接下来数月不确定下一步去处的结合。我们的团队最长的等待时间是空着积压了将近8个月。然后，我们将有4-6个月的发布时间声明“我们处于年度发布周期”

— DXM 2014年

11

有一件关键的事情可以使之接受：团队接受冲刺的范围。

在Scrum中，团队不只是得到分配的工作。产品负责人与团队协商以确定产品工作和技术（债务）工作的优先级。然后，项目经理，产品负责人和团队就什么因素进入冲刺以及该工作的范围进行协商。

在这个世界上，团队实质上是在说“我们可以完成X工作，测试并交付此迭代”。因此，我希望团队偶尔会加班以实现这些承诺。

就是说，这么多地方都混混了敏捷-很少有团队负责人可以与通常是老板的人进行有效的谈判...我将其视为一个巨大的危险信号。

— 特拉斯坦
source

8

“偶尔加班以履行这些（错误估计的）承诺” =>使错误的估计成为一种习惯

— t 2014年

1

@gnat-pssh。估计有时很高。估计有时很低。如果低估成为趋势，那肯定是一个问题。但这很大程度上就是存在迭代的原因：帮助优化估计。

— Telastyn 2014年

8

编程血汗工厂通常不接受工人的谈判。

— maple_shaft

1

@gnat：如果您发现作为一个团队，您习惯上低估了这项工作，则应该在下一个冲刺中减少工作量。

— Bart van Ingen Schenau 2014年

如果管理目标是要尽可能多地完成工作，而不受工作时间的限制（经验表明，在大多数情况下这是对的），而员工目标就是在不超过有偿工作的情况下完成最多的工作小时（我承认有些经理可能会认为这是乐观的），那么，不管估算中固有的误差如何，调度总是会趋于> =工作时间。逻辑上的扩展是，员工的目标必须转向低估。@BartvanIngenSchenau，这就是习惯自然发展的方式。

— 史蒂文·埃弗斯

1

Scrum分为多个Sprint，您可以在其中估算出在该Sprint持续时间内（通常为2周，但我见过1天至4周的任何时间）要完成的一组任务。我认为这会诱使错误估计任务。PO（产品负责人）希望较低的估算值能使每个冲刺获得较大的承诺。该团队将进行大量估算，以生成漂亮的燃尽图以供PM查看。这些当然表示组织organization脚。您确实希望获得准确的估计，而不要害怕落空，将故事延续到下一个冲刺，或者尽早完成并从积压中撤出额外的任务。我认为“冲刺”一词可以使人们更快地工作。

— 吉吉
source

1

除了采购订单不应该参与估算过程。如果要敏捷，团队将全权负责估算，并根据团队的估算PO只能更改积压优先级。

— DXM 2014年

2

“团队将进行大量估算，以生成漂亮的燃尽图供PM使用。”：这就是我认为整个机制存在缺陷的原因之一。我认为，与强迫团队提供要输入图表的估算值相比，经理可以从他们信任的团队获得更好的绩效。

— Giorgio 2014年

团队应该，但是就像我说的那样，他们有动力去增加估算。如果采购订单是付费的，他们可以施加压力以更积极地进行估算。对于背景，我从事咨询工作，因此Scrum团队是我的同事，而PO通常是外部人员，并支付我们虚高的账单率:)

— jiggy 2014年

@Giorgio一个不值得信任的团队总会增加估算并使情况变得更糟。但是，即使是专家，值得信赖的团队也可以学会更好地估算。这就是为什么要进行估算，然后将其与实际工作进行比较，以尝试提高估算能力的原因。该机制没有缺陷，拥有一个利用系统优势的团队是问题所在，而与管理系统无关。

— 克里斯（Chris

1

否：Scrum冲刺是一个时间框，仅此而已。在sprint /迭代开始时，团队会根据先前的性能，可用性，即将发生的事件，开放的障碍等因素，估算他们认为可以实现的故事点数量。然后，他们与产品负责人进行谈判。有关将哪些用户故事纳入冲刺的信息。那就是（或者曾经是？参见其他答案）团队对产品所有者的承诺。

在开发过程中，如果发现结果与预期不符（毕竟是软件开发），并且团队存在无法兑现承诺的风险，则他们会通知产品所有者存在一个或多个故事会风险的风险。尚未完成。

很好。当然，感觉很糟糕，必须在sprint结束时承认sprint失败了，但这并不是失败，这是一个改进的机会。因为在sprint结束/开始新的sprint后，您需要进行sprint回顾，而任何人都会问的第一件事是：“为什么我们使该sprint失败了，我们需要做些什么以免使其再次失败？？”。一种选择是放弃更少的承诺（=减少故事点）。

tl; dr：可持续步伐。Scrum与节奏有关，团队可以在各个Sprint之间无限期保持同步。超时工作不是；团队将变得过度劳累，工作变得草率，成员将请病假或完全辞职，那么与失败的冲刺相比，您面临的是更大的问题。

— 克苏鲁
source

0

敏捷过程促进可持续发展。赞助者，开发者和用户应该能够无限期地保持恒定的步伐。

来自敏捷宣言的人们

一直加班对我来说听起来并不可持续。

话虽如此，我认为春季承诺是一个强有力的承诺（如果这是团队想要的工作方式）没有问题，并且在您过度使用或加重估算时不得不加班是很好的动力，可以使他们更好地进行估算或沟通对PO的期望。

— 聚氨脂
source

0

我与一位特定的项目经理交谈（是的，我说项目经理）自豪地说，她的团队中的人们理解（“被告知”这是我从上下文中挑选的），当工作时间结束时，您不回家，无论完成多少工作，您都会在工作完成后回家。我在这两行之间读到的是，我们将尽可能多的功能组合到sprint中，并加班以实现它。

那不是Scrum。时间表的建议工作量是基于团队速度，而不是经理的愿望清单。他们只是在试图欺骗您，让他们相信无休止的加班是“敏捷的”，而事实并非如此。团队将在不受干扰和专注的情况下提高效率，但是Scrum并不是获得无限效率的魔杖。

经理要么对敏捷稍有误解，要么（更可能是）他认为开发人员是如此愚蠢。另一方面，当团队一次又一次地接受冲刺时，知道他们将需要加班，那也许他们确实是愚蠢的，不应该得到更好的回报吗？

我想，您知道答案了... ;-)

— 詹斯
source