如何在SCRUM板上报告错误？

Question

我们的团队已经决定，在作为国防部的一部分重新开放之后，应该在同一个故事中报告与特定故事相关的所有错误。这也意味着错误不会有额外的SP。 这些错误将作为回顾展的一部分进行讨论，以及错过的原因。

这是SCRUM值之后的正确方法吗？我不同意。请建议。

Answer 1

重要的是要认识到故事点衡量的是商业价值的交付，而不是衡量工作量。如果要修复错误或任何无法提供业务价值的任务，则会将其视为通过减少可实现的故事点数来降低团队速度的开销。

团队的速度不是衡量团队绩效的标准。这是一个用于帮助建立未来冲刺队伍能力的指标。

一般情况下，当故事发生在同一冲刺中的故事时，故事正在被开发出来，那么它们只被视为完成故事所需工作的一部分。

如果在一个被认为是在之前的sprint中完成的故事中出现了错误，那么通常只会修复当前的sprint。你通常不会因为报告错误而重新打开旧故事。

讨论回顾展中错过错误的原因是一个好主意。查找错误所需的时间越长，修复错误通常需要的时间越长，因为开发人员不太熟悉导致问题的代码。

Answer 2

我个人更喜欢将bug作为新的积压项目，以便对它们进行优先排序。

我会给你一个场景：

让我们说一个故事，你有接受标准，并说让你的国防部包括符合验收标准。这意味着在满足验收标准之前，甚至不会考虑故事。

因此，在故事完成后发现的任何错误都会成为接受标准中未被考虑过的东西。在这种情况下，新的错误应该是新的积压项目，并进行优先级排序和sprint计划。

...然而

在一天结束时，scrum团队必须就其特定情况下的最佳方法达成共识。在scrum中，我们没有一个老板/英雄/领导者来指示这个过程。这样的决定是由整个团队做出的。所以如果你不相信你的团队需要说服你。或者你需要说服你的团队。

Answer 3

错误是缺乏质量。在SCRUM中，开发团队有责任提供高质量的产品。如果产品质量不好，每个人都会责怪开发人员。因此团队本身应该注意如何处理错误。质量是不可协商的，这就是除了开发团队之外没有人应该优先考虑错误的原因。

我们决定将错误修正作为sprint中最重要的工作项处理。当出现错误报告时，我们在WIP列的顶部放置一张红牌，并立即开始处理。对我们而言，这导致了高质量的产品和高质量的代码以及更高的速度。