我们正在我们的团队中重新组织工作流程，其中一个关键决策是在Jira和Greenhopper的帮助下使用Scrum流程。
我已经阅读了各种Scrum指南，Greenhopper的文档，并在我们的团队中启动了Scrum流程实现。经过一些修正和改变后，它大部分都很好，但有一件事让我睡不着觉： bugs 。
Different解决方案是proposed developers，但我仍然无法找到自己的方式。
在我们的工作流程中，任何问题都存在于4种状态：打开 - ＆gt;在测试中 - ＆gt;已解决 - ＆gt;关闭
当开发人员对他的代码感到满意时，将问题发送到处于测试状态，并自动分配给QA线索。 质量检查验证问题，如果一切都正常，问题将变为已解决。如果不 - 再次打开。在已解决的状态下执行代码审核，如果代码是安全的，最优的并且适合已开发的结构，则问题变为已关闭。如果开发人员做了错误 - 再次打开。
这里棘手的部分是重新打开一个问题（故事），因为同时会出现错误，这会出现在产品积压中 - 而不是sprint积压，并且由于Scrum-way开发人员无法处理问题，这些问题不在sprint积压中，但同时故事无法关闭，因为代码有问题或写得不好。
所以，问题是：如果一个故事被关闭，即使它有一些与之相关的错误，这些错误计划在进一步的冲刺中得到修复吗？
或者故事无法关闭，直到所有相关的错误都得到修复，这意味着如果冲刺已经完成，但并非所有错误都是针对故事修复的，故事仍会打开，排除在完成的冲刺之后并转移到下一个冲刺，所以它的故事点不会在完成的冲刺中被烧掉？
答案 0 :(得分：2)
遇到类似的情况我们发现的一个关键问题是我们的故事缺失（或缺失）是一个明确定义（并同意）的“完成定义”（DoD）。如果你已经明确定义了“完成”标准，那么当故事完成时（符合国防部）那么它就完成了，当然诀窍就是如何定义一个不太模糊的完美定义，确保良好的质量，每个人都同意和实际上是可行的。对我而言，这也不是一次运动，我们会在每次回顾中不断重新审视它，以确保它们仍然相关并根据需要进行更改。关于建立一个好的国防部尝试Google的想法，有很多很好的练习团队可以做它来定义它（如this one）。
至于什么时候漏掉了，我会说他们应该反馈到Product Backlog并按照正常情况优先处理。冲刺期间出现的与冲刺工作相关的错误应该在sprint中修复（避免管理/文书工作！）。还记得很多错误（或越来越多的错误）通常意味着质量存在问题，也许还有一个更大的问题要处理（可能要承受太大的压力？）。
总结看看获得一个可靠的DoD（鼓励质量而不是数量）并不断改进它，减慢速度并做得更好而不是更多“带有错误”，当出现错误时，将它们反馈到产品中积压并让PO尽快确定优先顺序。
作为旁注，我们发现在处理大量错误时，像Kanban这样的精益方法比我们Scrum流程的每周2次迭代方法效果要好得多。
希望这有帮助吗？