在Scrum Sprint中管理生产问题

Question

最近，在我的脑海中，管理生产中的bug是一个很大的问题。Sprint不打算将任何项目添加到其中，但是对于关键的bug来说，这是不可避免的。

如何在冲刺中管理这段休息时间？你是否只是给一个冲刺一个百分比的“预留”的时间，从而只填补了80%的时间表上的冲刺项目“以防万一”？

Answer 1

如果这是关键的，你必须处理它。

要度量它对sprint的影响，您必须记录它。

看看这个信息散热器：

有一个叫做“计划外物品”的部分。把你的关键窃听器放在那里。正如您所看到的，在"Next“部分中，您放置的用户故事比计划的要多，以防您更快地完成sprint。

您将在sprint和/或回溯中讨论这个问题。目标是找到如何限制它们，并相应地调整您的速度。

Answer 2

如果你使用速度作为昨天天气的“允许”指标，它将自动调整一些平均额外的工作量，切割成冲刺。

如果生产问题是由早期sprint中创建的bug引起的，那么将修复工作切割到当前sprint的速度是可以的。这样，球队的速度就可以得到补偿，因为他们以前不应该得到分数。

有时你没有完成所有的冲刺目标，克服它;-)如果经常发生这种情况，速度平均会降到一个较低的数字。

任何其他非关键的东西都可以包含在待办事项中，以便正常地包含在sprint中。我更喜欢把bug放在最优先的位置，而不是让它们计算速度。

修复和排除生产问题所需的所有时间都会自动被考虑到团队的速度中。平均起来只需要时间，不需要单独的零用钱。

Answer 3

我在一个主要从事开发工作的团队中工作，但也负责现有的复杂系统。我们也遇到过这个问题。

基本上，我们根据最后一次冲刺(S)来估算我们的点数，然后为预期的维护工作保留一些积分。如果发生了明显超过此值的维护任务，如大停电，我们将其添加为用户故事，并删除一个尚未启动的现有事件，以保持相同大小的sprint。如果出现了一个不那么紧迫的重大问题，我们就把它移到下一个sprint。

是的，从技术上讲，这不是跟随scrum。但这种灵活性对我们来说效果很好。

我们在每次计划会议上询问团队是否认为有理由偏离标准保留，从而完善了这一保留时间。我们在做了一次办公室搬迁之后介绍了这一点，这比我们预期的花费了更多的时间，导致许多故事没有完成。

然而，不要只停留在我的团队或其他团队是如何做到的。选点什么，然后就去做。没有办法确保它能在你的团队中发挥良好的作用。试一试，并在回顾中进行评估。如果团队不高兴，尝试一些不同的东西，然后再进行评估。所有的团队都是不同的，他们的需求和局限也是不同的。