通过 GreenHopper 处理 Scrum 中的错误 [关闭]

Question

我们正在重新组织团队中的工作流程，其中一项关键决定是在 Jira 和 Greenhopper 的帮助下使用 Scrum 流程。

我阅读了各种 Scrum 指南、Greenhopper 文档，并开始在我们的团队中实施 Scrum 流程。经过一些更正和更改后，它大部分都很好，但有一件事让我睡不好觉：bugs。

Different 解决方案是 proposed by developers，但我仍然无法在这里找到我的方式。

在我们的工作流程中，任何问题都处于 4 种状态：打开 -> 测试中 -> 已解决 -> 已关闭

当开发人员对其代码感到满意时，他将问题置于测试中状态，并自动分配给 QA 负责人。 QA 验证问题，如果一切都ok，问题将变为已解决。如果不是 - 再次打开。在已解决状态下执行代码审查，如果代码是安全的、最优的并且符合开发的结构，则问题变为关闭。如果开发者做了错误 - 再次打开。

这里的棘手部分是重新打开一个问题（故事），因为同时提出了 错误，这些问题落在 product backlog 中 - 而不是 sprint backlog，并且由于 Scrum-way 开发人员无法处理不在 sprint backlog 中的问题，但同时由于代码有错误或写得不好，故事无法结束。

所以，问题是：是否应该关闭一个故事，即使它有一些与之相关的错误，并且这些错误计划在进一步的冲刺中修复？

或者故事不能关闭，直到所有相关的错误都得到修复，这意味着如果一个冲刺完成，但不是一个故事的所有错误都得到修复，故事保持打开状态，从完成的冲刺中排除并移至下一个冲刺，所以它的故事点不会在完成的冲刺中燃烧？

Answer 1

遇到类似情况，我们发现我们的故事中缺少（或不足）的关键内容之一是定义明确（并达成一致）的“完成的定义”（DoD）。如果你有明确的“完成”标准，那么当故事完成（符合国防部）时，它就完成了，当然诀窍在于如何定义一个不太模糊的完成的良好定义，确保质量好，每个人都同意并且实际上是可行的。对我来说，这也不是一次练习，我们会在每次回顾中不断地重新审视它，以确保它们仍然相关并根据需要进行更改。有关建立良好 DoD 的想法，请尝试 Google，团队可以做很多很好的练习来定义它（例如 this one）。

至于漏掉的错误什么时候完成，我想说它们应该被反馈到产品待办列表中，并按照正常情况进行优先级排序。冲刺期间出现的与冲刺工作相关的错误应该在冲刺中修复（避免管理/文书工作！）。还要记住很多错误（或越来越多的错误）通常意味着质量存在问题，也许有更大的问题需要处理（可能完成压力太大？）。

总结一下，看看获得一个可靠的 DoD（鼓励质量胜于数量）并不断改进它，放慢速度并做得更少而不是更多“有错误”，当错误确实出现时，将它们反馈到产品中积压并尽快让 PO 确定优先级。

附带说明一下，我们发现在处理大量错误时，像 Kanban 这样更精益的方法比我们的 Scrum 流程的每周 2 次迭代方法效果更好。

希望这有帮助吗？