您的敏捷/ Scrum团队的错误工作流程是什么？

您的敏捷/ Scrum团队的错误工作流程是什么？

这是我们的：-如果该错误与当前sprint中的一个故事有关，我们将对其进行修复。-如果错误与当前sprint中的故事无关，并且不重要，则将其发送给产品所有者以进行优先级排序。-如果该错误与sprint中的故事无关，并且非常重要，则我们将其修复。

当前sprint中与工作相关的所有问题都是固定的，我们甚至不考虑它们的错误，也不会这样写。我们仅将某些错误视为已经属于“完成”的错误。

当出现新错误时，我们将其添加到待办事项中，并由利益相关者确定优先级。如果我们在冲刺中还有剩余时间，我们倾向于解决一些较简单的错误，这些错误可能具有较低的优先级，但是可以在剩余时间内完成。

我一直认为错误只是一个已经通过测试失败的故事，因此比典型的功能故事初稿更好地定义了错误。

因此，如果您确信错误是故事，那么就估计和优先级而言，您就像对待其他故事一样对待它们。

我认为解决此问题的最佳方法是首先确定您实际要考虑的Bug。

许多开发人员不会将当前无法正常工作的事情视为错误，因为这实际上不是错误。如果您当前正在处理某些东西，但仍然存在缺陷，则特定的错误实际上并未完成，因此没有实际的缺陷。反之适用于已完成的工作，如果您确定某些东西已经完成并且可以进行测试/发布/生产，并且后来发现代码或使用中存在缺陷，那么您肯定有错误。

我的公司使用以下方法来确定何时应纠正错误：

如果该错误很严重，则会以适当的优先级将其添加到与该产品相关的当前sprint中。通常，我们计划将大约10％的额外时间安排在冲刺中，并安排一些我们实际上不打算完成的额外工作，但如果没有错误或完成得比预期的快，我们可以完成。

如果错误不是很关键，那么我们只需将其添加到积压中，然后通常在下一个冲刺中完成它。

为什么这是理想的流程，却有一些明显的漏洞，如果管理层认为需要比我们认为的要早完成，那么从编程的角度来看并非关键的事情有时可能需要立即完成。完成。

顺便说一句，我认为最好的办法是选择一个结构，然后坚持下去。当您开始做没有结构的事情时，就会开始造成生产力的最大损失。一旦开始破坏结构，就很容易陷入困境。

那可能已经回答了您过多的问题，但是那只是我对如何处理这些问题的想法。

我们正在进行持续的缺陷工作。与您的设置类似，如果存在与当前工作相关的关键问题，我们会在工作中进行修复。毕竟，如果存在与故事有关的缺陷，就不能称其为“完成”。

对于其他错误，我们通常会在时间允许的情况下对其进行修复。如果存在紧迫的问题，我们会回顾一些故事并花一些时间进行错误修复，然后再恢复正常的功能工作。

在Sprint中发现的错误只是开发的一部分。

Sprint结束后发现的错误进入产品待办事项列表。我们从不与用户争论是否有错误，增强或更改。如果用户希望将其称为错误，那就可以了，但是它仍然会和其他任何新工作一起进入PB。