在 Agile/Scrum 项目中处理 Bug

  • Mark Levison
  • 曹云飞

2009 年 7 月 23 日

话题:敏捷文化 & 方法

Bugs人们常问这样一个问题: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 SchielArtisan 咨询 公司的认证 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 指出的问题了么?

查看英文原文:Coping with Bugs on an Agile/Scrum Project

敏捷文化 & 方法