在成为一个拼命想要运行Scrum的项目的一部分并且惨遭失败以维护大多数原则之后，现在我已经找不到管理这个项目了，我很想避免以前看到过的错误。< / p>
我有一个关于处理新发现的缺陷的问题。我知道一般的感觉是它们被添加到当前的sprint或下一个sprint并快速修复。其他人把它们全部扔进了积压的地方，当它们变得更重要时就把它们拿走。
没关系，但请考虑以下情况： 当前sprint是史诗的一部分，我们正在实现作为更大要求的一部分的新功能，虽然我们希望构建和发布以供客户审查，但我们还不希望将这些功能发布到产品中不适合使用。如果我们发现一个关键错误，可能是客户，如何将其纳入计划，该怎么办？
我看到它们的选项是：
删除sprint上的所有内容并执行带外释放 +客户快速解决问题 - 扰乱当前的冲刺并可能导致其失败 - 需要另一个分支和合并操作
将他们加入当前或下一个sprint +保持Scrum带给我们的顺序 +无需在合并中分支VCS /处理问题 - 客户必须等待更长时间才能获得修复，特别是当我们正在制作一部史诗时，可能需要一段时间才能进行RTC
我错过了其他选择吗？我完全错过了关于这个过程的一些事情吗？
答案 0 :(得分：2)
Scrum中有两种类型的错误。第一种类型是在开发期间发生的错误，在被释放之前被捕获。第二种类型是在生产环境中发现的错误。
通常，Scrum团队会以不同的方式处理这两种类型的错误。
开发过程中出现的错误通常会立即得到修复。请记住，Scrum的想法是在每个sprint结束时都有一个可释放的产品。如果你在冲刺结束时有突出的错误，那么你通常不会将其描述为可释放的。此外，当您延迟修复错误时，修复错误所需的时间通常会增加。开发人员修复他们当天编写的代码的错误通常会很快修复它。要求他们修复几周前他们所使用的代码的错误，这可能需要更长的时间。
对于生产错误，确定错误的严重性非常重要。例如，可能需要立即处理非常严重的生产错误并需要紧急释放。当发生这种情况时，您可能必须考虑结束当前的冲刺并重新规划。如果缺陷较少，则应将其添加到积压工作中，并优先考虑现有工作。例如，产品负责人可能会决定在修复错误之前等待，因为他们认为这是次要的并且影响不大。