0

我有一个由 5 名开发人员组成的团队，他们按照 10 天的冲刺计划工作。在我从他们的总容量（300 小时）中扣除 Scrum 会议时间后，我最终得到 247.5 小时。

细分是——

总计 - 计划 - 每日 Scrum * 10 - 回顾 - 回顾 - 积压梳理

300(5*6*10) - 10 - 12.5 - 5 - 5 - 20

速度目前是 25pts/sprint。

然而，当团队进入 sprint 计划的后半部分时，他们几乎总是会计划 80-85 小时的工作。这相当于约 35% 的承诺。

显然这里有几种可能性。要么团队严重低估了任务时间，要么有很多隐藏的工作进入 sprint 或帕金森定律即将生效，并且工作正在扩大以填补分配的时间。我的直觉告诉我这三个都是。

我的问题真的是，如果团队发现他们在 sprint 计划的第二部分中承诺不足，那么好的行动方案是什么？

  • 重新召集产品负责人并承担更多工作？
  • 重新审视任务估计，也许使用 3 点方法来清除关键路径？
  • 跟踪实际情况并使隐藏的工作显而易见，这样我们就知道时间去哪儿了？
  • 还有什么？

我不热衷于我的前 3 个建议，所以“其他东西”也许是我正在寻找的。任何建议都会非常有帮助。

提前致谢。

编辑：我几年前问过这个。我很天真。不要做这种事情，...永远。离开这里让别人笑:-)

4

4 回答 4

2

您面临的最大问题是您的团队（有意或无意地）掩盖了他们的工作，并隐藏了他们正在做的事情。你需要提高知名度。

你总是说，所以我认为你有一些统计数据。

假设您的团队没有将剩余的产能用于非生产性（处理计划外的任务、浏览社交媒体网站、做白日梦），那么您的团队似乎计划不足。如果是这种情况，您应该努力公开正在执行的计划外任务，然后添加它们、说明它们，或者在必要时让团队停止执行它们。

另一方面，您的团队可能会故意降低生产力，并且没有简单的方法来处理它。如果这是您所面临的，我会尝试弄清楚为什么会发生这种情况。也许他们感到不知所措，需要一个出口，或者他们觉得无论付出什么努力，他们都注定要失败，还不如玩得开心。如果没有任何改变他们的想法，这需要非常小心地处理，尽管可能非常有力。

重要的是要记住，数字和会计不是问题——它们只是更深层问题的症状和指标，Scrum Master 应该努力解决这些问题。

于 2013-08-08T08:47:33.830 回答
2

几年前我几乎在同一条船上，除了我们经常会过度承诺，​​主要是由于估计的分形性质。

在我目前的团队中，我们决定采用不同的方法，仅依靠故事点和速度来确定冲刺承诺。我们确实将故事分解为任务并为任务提供粗略的工时估算，但我们这样做本质上是作为讨论/探索的借口并消除技术不确定性。我们不会试图总结估计并将其与计划的速度联系起来。

作为一个团队，我们为防止您所描述的（理论上的）帕金森效应所做的是，我们总是为即将到来的冲刺设定一个雄心勃勃的目标。这通常意味着比我们的速度通常允许我们做的更多的“奖励”用户故事。通过这种方式，我们总是在推动事情向前发展，挑战自己，即使假设我们在某个时候有 35% 的承诺（我不确定你是如何达到的），差距很快就会被填补，以实现完整的团队速度。

通过那次经历，我意识到不跟踪任务时间（尤其是不进行涉及 Scrum 仪式时间、外部活动或会议持续时间的复杂计算）并且不生活在对未能“正确估计”的持续恐惧中是一种解放——它让您专注于真正重要的事情：交付业务价值。运输质量功能是第一要务。估算只是副产品。让平均速度作为您的指导，以确定您可以承诺的粗略工作量。拥抱潜在的失败，无论如何你永远不会完全正确。

在起始速度相同的情况下，我会选择一个不擅长估算的团队，因为它令人惊讶地反复提高了生产力，而不是一个每天都在改进其估算（甚至最终使它们接近完美）的团队。

于 2013-08-20T11:25:08.120 回答
1

对于我们的新团队，我们“强迫”他们计划可用小时数。我没有强迫他们在故事中增加几个小时，我们只是承担了更多的故事，因为还有更多的时间（你如何向你的 PO 证明他们将在剩下的几个小时内做什么？）。然而，我们确实告诉了 PO 这个策略，他们不会成功。

因此，当然，他们最终会过度承诺前几个冲刺。但随后，他们意识到他们需要更好地估计任务。大约需要 3 个冲刺才能更接近现实。每次回顾的重点是找出故事被低估的地方（错误的任务、缺失的任务、低估的任务、未知等）。从一个冲刺到另一个冲刺，我可以看到任务正在被细化。

于 2013-08-07T13:35:46.717 回答
0

Sprint 容量规划不仅仅是从 Sprint 持续时间中减去会议。我通常使用这个计算：

对于 2 周的 sprint，假设您只有 9 个工作日（Scrum 会议浪费了一天）。将此数字乘以团队中的人数（在我的示例中假设为 7）。所以我们现在有63天。

对于每个人，减去计划的离开办公室的时间（假期、医疗预约、场外会议等）。假设我们没有计划缺勤。所以我们还有63天。

对于每个人，请考虑他们每天只能“在区域内”（即：编码）一定时间。对于一个新团队，我将使用每天 4 小时进行计算。所以我们现在有 4 * 63 = 252 小时。将此与更简单的 63 个工作日 * 每天 8 小时 = 504 小时进行比较，您可以看到它几乎是一半。

最后，我应用了一个“缓解因素”来允许那些总是发生的干扰。我减去 10%。所以现在，我们有 227 小时，这就是我们用于计划目的的时间。

这个计算不是很科学，但它似乎在大多数情况下都能奏效。

最后一件事。我只在团队新人时使用 Sprint Capacity Planning。一旦我们确定了速度，我们就会使用它。它更快，通常更准确。

于 2013-08-06T19:13:19.050 回答