如何停止/避免Scrum团队超时工作？

实际上，我正在帮助一家小型软件商店进行Scrum实施。最近的Scrum Master那里告了我，他有一个问题，因为该小组正在随时间实现范围（承诺积压）。因此它们具有虚幻的速度。

我的正式问题是：

1. 除了在回顾会议上发表讲话外；您认为实施一些硬块以避免超时是一个好主意吗？

2. 如果是这样，您建议使用哪些技术/工具？

   • 修订控制系统（SVN，GIT，HG等），按小时（8到5）划分
   • 工作站按小时数（8到5）还是累计小时数（每天最多8个小时）进行分组？
   • 其他）...

3. 或者，也许不要硬阻这类事情；但是在不合理的加班时间内实施“罚款制度”？

@Baqueta（以及其他有类似问题的人）：不，他们没有被收取加班费。我对他们的第一个建议是审查他们的估计，因为他们可能低估了他们的估计。这是我最喜欢的建议：

如果他们有兴趣加班，将其删除。开发不是您每周可以工作60个小时并保持高效的东西，并且有大量研究证明了这一点。如果加班费是问题，那就摆脱它，提高他们的基本工资，使他们得到自己所需要的。

另外，我认为（对于该团队）根本问题是以下各项的组合：

1. 告诉开发人员他们在冲刺中必须实现的目标/未就可实现的目标进行咨询/在说太多工作时被忽略。
2. 开发人员始终低估了任务将花费多少时间/每个任务涉及多少个工作单元。

简介：我将与团队讨论评估他们的估算，并与采购订单进行沟通，因为正如您提到的那样，我认为没有就范围进行咨询。

坦白说，您在第二条中提到的“硬块”是我很久以来听到的最糟糕的想法。如果在4.45pm时发现了最高优先级的错误，并且有能力覆盖您的代码块的人病了，该怎么办？至于＃3-您建议惩罚因工作而受到惩罚的人。

如果团队一直在加班以完成冲刺，那么他们要么对加班有兴趣（例如加班费或在假期中加班），要么他们承诺在冲刺中做太多工作。

如果他们对加班有兴趣，请将其删除。开发不是您每周可以工作60个小时并保持高效的东西，并且有大量研究证明了这一点。如果加班费是问题，那就摆脱它，提高他们的基本工资，使他们得到自己所需要的。

如果需要太多的工作，这通常是出于以下三个原因之一：

1. 告诉开发人员他们在冲刺中必须实现的目标/未就可实现的目标进行咨询/在说太多工作时被忽略。
2. 开发人员始终低估了任务将花费多少时间/每个任务涉及多少个工作单元。
3. 开发人员不断被拉到不是Scrum一部分的任务上。

如果它是＃1，则说明您做错了。没有两种方法！

如果是＃2，则通常的原因是缺乏经验-要么进行时间估计，要么正在开发系统。解决此问题的一个好方法是停止进行时间估算，而开始估算“工作单位”。使用一些抽象单位，只需确保它不是实时时间（最终您仍代表一个时间间隔，但是抽象很重要！）。然后，您可以开始计算一周实际完成多少个工作单元，然后使用该数据设置冲刺。

如果是＃3，则需要以某种方式开始考虑其他任务。如果是一致的，则应该很容易解释（请参阅上面的＃2）。如果它频繁但不可预测，则处理起来会非常棘手。您将要看一看为什么会发生这种情况（例如，“活动”代码中的严重错误=>您的测试是否足够彻底？），但如果无法解决，那么最终Scrum可能不是您的正确选择。由于这个原因，我的团队最近改用了看板...

编辑：澄清了我对问题中提出的观点的批评。

首先，如果他们需要加班才能完成任务，听起来好像他们在冲刺上做的工作太多。是否已记录所有时间？如果是这样，那么您可以计算一个故事点的实际工作量，并使用该数字来计算下一个冲刺的工作量。

同样重要的是要确保团队了解自己只是在从事过多的工作而伤害自己。甚至敏捷宣言也谈到了可持续发展的步伐：“敏捷过程促进了可持续发展。发起人，开发商和用户应该能够无限期地保持恒定的步伐。” 一直加班是不可持续的。

总而言之，我建议您使用沟通方式，而不是武力和惩罚。我以为那只会导致团队的士气低落。

超时工作的开发人员可能会响应某些激励，无论是实际激励还是感知激励。它是删除激励（如果有的话）是现实的，或者是传达一种感知激励不起作用的信息。

每个建议的硬限制都有一些解决方法或其他问题。源代码控制块只会导致开发人员坚持提交，直到再次打开窗口。一旦出现一些支持问题，或者由于某种原因而需要一名工作人员转移工作时间，工作站就必须走了。惩罚制度只会导致隐藏或掩盖加班时间。

我认为问题是更根本的-团队有一定的动力（或认为他们有动力）加班。

这是需要解决的问题。他们的绩效评估是否与他们的速度数字挂钩？管理是否加班？是否向长期工作的人提供晋升和奖励？他们是加班费的承包商吗？

只需告诉团队不要加班。期。

这可能会导致他们无法完成某些工作。这不是问题，这是一个数据点。然后，他们可以使用该数据点来计划下一个冲刺。同样，不要让他们加班。无论完成与否，它们都有另一个数据点。泡沫，冲洗，重复。

无需任何技巧或限制。只是不要加班。了解您可以完成多少工作，并相应地调整冲刺计划。

也许存在一个问题，不是他们正在“工作”多少，而是何时工作。当有计划的工作日时，这可能会是一个问题，但是大部分正常时间都是由会议以及其他社交和个人干扰引起的。他们是否在加班期间工作，因为他们只是觉得自己更有生产力。

减少sprint中的工作量，然后开始弹性工作。让他们稍后再来。负责人只需要告诉人们回家即可。没关系。有些企业文化营造了一个环境，早退会带来一些皱眉。

当我第一次转向Scrum时，我为此感到挣扎。想要在截止日期前付出更多的努力是很自然的，但是scrum每两周就有截止时间，所以这是一个调整。除了其他人提出的减少每次迭代中承诺的故事点的建议外，我还建议确保将故事分解得足够多，以便每个开发人员至少可以在一次迭代中完成两个或三个。

这不仅确保每个开发人员都觉得自己在每次迭代中都完成了某些工作，而且还使您的工作范围有所懈怠。当您的倦怠表明您无法完成故事时，可以将其拉出，然后将人们重新分配到可以完成的故事中。当人们看到范围可以调整时，他们不太可能强调不切实际的期限。如果您在进行每个故事时都开始迭代，则没有调整的余地。

如果每个人每次迭代都要完成两个故事，则理想的累积流程图应如下所示：

看起来从来没有像现在这样，因为实际上很难安排所有故事在最后一天结束，同时又要让每个人都忙，但这是一个很好的经验法则。如果您使用过多，则红色区域会更大，您可以删除故事。如果您的服务不足，则蓝色区域会更大，您可以添加故事。如果您的故事太大，则绿色区域会更大，您应该拆分故事。

为了避免加班，您必须缩减项目范围。

下图显示了项目不确定性所在的位置：

如果您注意到，在产品定义和需求阶段，估算的工作量会有很大的差异。您不确定要实现该功能需要一个月还是一天。

我敢打赌，没有一个任务能完成，因为它们太大了而且没有指定，而且太多了。

如果您的团队可以在5天内处理10张票证，并且分配了20张票证，请减少该数量，然后将其交给产品负责人/项目经理/经理/客户，并告诉他们确定优先级。

在这一点上，这是使团队免于加班的唯一方法。您无法交付所有内容，但是无论您做什么交付，都不太可能出现错误。

我也建议您寻找一份新工作，并帮助您的队友做同样的事情，并修复他们的简历和专业档案。一家期望加班的人无人可为，而所生产的软件将像地狱般陷入困境。

我强烈建议不要使用“硬块”。这种控制可能被视为微观管理，可能无法解决根本问题。

我建议您找出为什么程序员加班的原因。答案可能会让你大吃一惊。听起来您是一个“局外人”（不是公司的雇员），并且如果您与他们私下会面（一对一），程序员可能会愿意与您坦诚。

是因为加班是真正的工作量，还是更多与文化或期望有关？

工作量原因可能是

• 提交的积压太大
• 程序员或产品所有者都是“镀金”（使功能比所需的更复杂）

期望可能是

• 由于加班而产生的某种经济奖励或表彰奖励
• 害怕失败。程序员担心如果不按时完成任务，他们看起来会很糟糕或会受到惩罚
• 程序员低估了加班的长期危害。