人们常问这样一个问题：Scrum 建议一个团队如何处理 bug？Bug 是应当放在产品 backlog 中还是在一个单独的 bug 清单中？如果 bug 在产品 backlog 中，那么是由产品所 有者来确定 bug 优先级还是 bug 自动成为最重要的项目？是否应该有一个单独的 bug 修复 sprint？
在Pascal Maugeri的团队 ，即使在改善了对“完成”和正在做“正确的测试 / 单元测试”的定义之后 ，他们还是能发现从 sprint 中逃逸的 bug 。他问如何解决这个问题。
George Dinwiddie， 敏捷教练， 建议团队在回顾时提出这个问题——他曾与只有微乎其微的 bug 率的团队共事。Mark Levison （本文记 者）建议： “我会问为什么没有在发现 bug 的 sprint 中修复它们？我的重点是减少发现（然后修正）问题所花费的 时间。毕竟，如果我们在一个 sprint 的故事中发现了一个 bug，那么产品负责人不应该同意该故事已经完成。此外， 早期发现 bug 将使人们更容易修复，因为开发团队的脑海中对相关代码依然有清晰的印象。
Jim Schiel ，Artisan 咨询 公司的认证 Scrum 训练师，认为只需把 bug 放在产品 backlog 中，由产品负责人确定优先级， “除非修复起来很简单，在这种情况下，你可以在 sprint 的规划会议中确定 解决方案并且在 sprint 中实施该方案。”
Bruce Kantelis说，这一 切都与发展一种文化有关：“我们会把缺陷分类。让用户工作陷于停滞的 bug 会被设定为头等优先级，并且马上得 到注意，开发团队会中断当前工作来修复程序并打补丁。其他的缺陷都成为故事，放在下一个 sprint 的任务列表顶部 。随着时间的推移，团队认识到与质量相关的度量和行为真的会影响他们的日常工作，他们就会尽量减少缺陷及其 带来的干扰。”
Mike Cohn提醒我们， 对于在 sprint 中发现的 bug，最好的处理方法是在整个团队房间里面大声喊出这个 bug。如果做不到这一点，可以用 一张卡片来描述该 bug 并添加到任务板上。然而对于在 sprint 中漏掉的 bug，他宁愿将它们添加到产品 backlog 中，由 产品负责人考虑它们的优先级。许多现有的团队仍然有 bug 数据库，他们还得继续使用该数据库。在这种情况下， 他建议保持一个独立的 bug backlog，产品负责人安排各个队列中任务的优先级：例如，头两个条目来自产品 backlog，接下来的条目是 bug，最终两个条目来自 backlog。
Kev lin Henney不太认同这种做法，他认为这近乎等同于将 bug 看作会产生负面价值的特性：
如果缺陷被视为具有负面价值的特性，它们就会像特性一样 被管理。开发团队会把划分了优先级的 bug 存储起来，像对待用户故事一样对待 bug，把修复 bug 的工作外包，等等 做法都会冒出来。虽然这些做法对于处于过渡期或者危机的项目来说有些作用，但并不是一个应予以鼓励的长期观 点。毕竟，正如“敏捷软件开发宣言”所说： “可工作的软件是工作进展的首要度量方式。”一个功能特性中已经 存在已知的缺陷，还要把它看做是已完成和可工作的，这样的做法可有点不太诚实。——“是的，这个功能已经完 成了……但还有一些 bug。”
Ron Jeffries 认为：在功能特性开发结束后再修复其中的缺陷，这样做的代价总是比在刚发现的时候就去修复要昂贵。
所以，如果我们错误地编写软件然后修复它，客户会花费更多金钱：除了给付应有的，她还得为 bug 的修复 付出额外代价。她真的应该责备我们。我愿意鼓励客户把所有的缺陷区分优先次序，这能让客户体验到团队不恰当的软件过 程所带来的痛苦。我确信客户会表达那种痛苦，从而使得团队明白把事情做好是更好的方式。
你总是避免 bug 么？将 bug 放在产品 backlog 中？你发现 Kevlin 指出的问题了么？
注册/登录 InfoQ 发表评论