Jira 通过GreenHopper处理Scrum中的bug

我们正在团队中组织工作流程，其中一个关键决定是使用Scrum流程，由Jira和Greenhhopper提供帮助

我已经阅读了各种Scrum指南、Greenhhopper的文档，并在我们的团队中开始了Scrum流程的实施。经过一些修正和修改后，它基本上是好的，但有一件事让我睡不好觉：臭虫

解决办法已经找到了，但我还是找不到我的路

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

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

这里棘手的部分是重新打开一个问题（故事），因为同时出现了bug，它们落在产品待办事项中，而不是sprint待办事项中，并且由于Scrum的方式，开发人员无法处理不在sprint待办事项中的问题，但同时故事无法关闭，因为代码有缺陷或写得不好

所以，问题是：一个故事是否应该结束，即使它有一些与之相关的bug，并且这些bug计划在以后的sprint中修复

---

或者，在所有相关的bug都被修复之前，故事不能被关闭，这意味着，如果一个sprint已经完成，但并不是一个故事的所有bug都被修复，那么故事将保持打开状态，从完成的sprint中排除并移到下一个sprint中，因此，它的故事点没有在完成的冲刺中烧毁？

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

至于什么时候漏掉的bug得到了解决，我认为应该将它们反馈到产品待办事项列表中，并按照正常情况进行优先级排序。在sprint期间出现的与sprint工作相关的bug应该在sprint中修复（避免管理/文书工作！）。还要记住，很多bug（或者越来越多的bug）通常意味着质量有问题，可能还有更大的问题要处理（可能完成的压力太大？）

总结一下，看看如何建立一个坚实的国防部（鼓励质量胜于数量），并不断改进它，放慢速度，做得少一些，而不是更多的“有缺陷”，当缺陷确实出现时，将其反馈到产品待办事项中，并让采购订单尽快确定其优先级

作为补充说明，我们发现，当涉及到处理大量bug时，一种更精简的方法，比如，比我们的Scrum过程中每两周迭代一次的方法要好得多

---

希望这有帮助吗？

在我工作的地方，经理大喊大叫，bug得到修复，不管是Scrum还是no Scrum。是的，我知道这不是一个答案：-）但请记住，太多的僵化也可能是一件坏事。@phs，是的-这与编程语言或算法无关，但它肯定与编程有关。FAQ说，我可以问一些关于“程序员常用的软件工具”的问题，Jira和Greenhhopper就是这些。此外，我的问题中的链接本质上会导致类似的问题。另一方面，请注意：确保您有良好的实践，以防止出现大量错误，如持续集成（当然是持续测试）、同行评审、单元测试等。帮助我们的还有早期和经常集成，并在sprint的早期，甚至在它完成之前，向我们的测试人员介绍这些特性，以消除我们只有在故事完成后才会发现的潜在bug。这里的关键，协作：）感谢您分享您的经验！这正是我想要实现的，但我想，Greenhhopper希望我把bug放到backlog中，并在下一个sprint中修复它们，而不是在当前sprint中。