是否应该为 Bug 分配故事点数?

  • Dan Puckett
  • 鲍央舟

2011 年 1 月 30 日

话题:敏捷文化 & 方法

在将一个项目迁移至 Scrum 时,经常会面对一份 Scrum 时代之前的缺陷列表。如何最好地处理这份缺陷列表呢?Mike Cohn 推荐向以前的缺陷分配故事点数,并用标准的 Scrum 流程在每个 Sprint 对他们排序:

我通常推荐对缺陷修复分配故事点数。... 那样,我们不仅能看到团队真正能完成多少工作,也能通过历史数据看出每个 Sprint 中花在修复缺陷上的工作量。知道这些对团队和产品负责人都很有用。比如,假想一种情况,产品负责人考虑在接下来的 6 个 Sprint 中暂停缺陷修复,为的是在下一次发布中增加一个有用的新功能。如果我们知道团队的历史平均速率是 25,但是其中 5 点花在缺陷修复上,那我们就可以知道暂停下 6 个 Sprint 的缺陷修复工作可以增加 30(6*5)个点数的新功能。

除了 Mike Cohn 推荐的 Sprint 排序策略外,Charles Bradley 想要有更多的选择,让开发团队在 Sprint 之内修改缺陷。

...PO 可以排序缺陷的优先级使他们出现在 Sprint 中,开发团队也可以任意挑选他们认为需要修改的缺陷(不管缺陷是否在 Backlog 中),并且把它列为 Sprint 中的一个任务(他们不会为此得到速率中的点数,无论缺陷是否在 Backlog 中)。只有开发团队可以决定在一个 Sprint 中做多少产品 Backlog 条目,所以,如果他们决定花 Sprint 中 50% 的时间来修复 PO 没有排序的缺陷,那就只能这样。但这会清晰可见,因为他们的速率会减慢。

Jack Milunsky 在处理遗留缺陷和当前 Sprint 产生的缺陷之间做了一个重要的区分:

如果要向缺陷分配故事点数,那只能分配给遗留缺陷。这对 PO 绝对有好处,特别是质量。在 Sprint 中发现和解决的缺陷不应该被分配故事点数,因为这会影响速率,造成团队工作更快的假象。

如果是在 Scrum 实施中产生的,由于一些原因在 Sprint 验收中漏掉的缺陷,我们应该分配故事点数嘛?也就是说,在之前 Sprint 认为“完成”的用户故事中发现的缺陷应该怎么办?Ron Jeffries写到

如果由于某些原因一个故事已经完成,然后发现了一个缺陷,而那个故事已经被记录在速率中,那速率是虚高的。我们应该做什么?一种做法是从我们的进度条中去掉那些量,当缺陷被修复后再把那些量加回去。这可能更准确,但却不必要。

我们所要做的,只是计算下次做完的故事。花在修复缺陷的时间不算在内。我们的进度线从现在开始减少了一个故事。这条线虚高了一阵子,但现在又恢复了。

注意,修复错误的时间可能比构建一个出错故事的时间要短,或者长。无论如何,正确 完成故事所必须的时间,以及完成故事的数目,对那个故事来说会回归平衡。不需要估计,不需要解释为什么我们应该如对待好事般对待一个明显的浪费。

查看英文原文:Should You Assign Story Points To Bugs?

敏捷文化 & 方法