过去几天我一直在学习和阅读有关 Scrum 的内容，并阅读有关 Sprint 计划和任务的内容。我想到的一个问题是如何处理 Scrum 中的 bug。 Henrik Kniberg 在他的好书 Scrum and XP from the Trenches 中列出了处理这个问题的一些方法。 :
- 产品负责人打印的内容最多 高优先级 Jira 项目，带来 他们参加冲刺计划 session ， 并将它们卡在墙上 和其他故事一起 (从而隐式指定 这些项目的优先级相比 其他故事)。
- 产品负责人创建涉及 Jira 的故事 项目。例如“修复最 关键的后台报告错误， Jira-124、Jira-126 和 Jira-180”。
- 错误修复被认为是 在冲刺之外，即团队 保持足够低的聚焦系数(对于 例如 50%)以确保他们 有时间修复错误。正是那时 简单地假设团队将 每人花费一定的时间 sprint 修复 Jira 报告的错误
- 将产品待办事项放入 Jira 中 (即放弃 Excel)。只对待错误 就像其他故事一样。
这真的需要根据每个项目来决定还是有更好的解决方案？我可以想到每种方法的问题。这些方法中是否存在最有效的混合方案？您在项目中如何处理这个问题？
最佳答案
这是一个非常好的问题，当涉及到解决这个问题的不同方法时，我有一些观察。
- 将所有错误与积压项目同等对待在理论上可能听起来是个好主意(在单个位置跟踪工作)，但在实践中效果不佳。错误通常是低级的且数量较多，因此如果您为每个错误创建单独的用户故事，那么“真实”的故事很快就会被掩盖。
- 如果以产品所有者可见的方式完成，则在每个冲刺中为修复保留明确的时间就可以了。应该在日常 scrum 期间提及错误，并在冲刺评审期间讨论已修复的错误。否则产品负责人将不会知道项目中发生了什么。
- 将整个积压工作放入错误跟踪工具会导致与 1 中相同的问题。此外，大多数错误跟踪器在设计时并未考虑到 Scrum，因此将它们用于此目的可能会很痛苦。
我们发现最令人满意的解决方案是在每个冲刺中放置一个名为“Tickets”或“Bugs”的用户故事。然后，这样的故事可以分为描述特定错误的低级任务(如果在计划期间已知)或为一般错误修复保留给定时间的元任务。这样，产品负责人就可以了解流程，并且燃尽图可以反射(reflect)进度。
记住要毫不留情地关闭所有实际上是新功能的“错误”，并为它们创建新的积压项目。另外，请确保在冲刺结束之前修复当前冲刺报告的所有错误，以便将冲刺视为已完成。
关于debugging - 将错误修复融入 Scrum 流程的最佳方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1593328/