计算速度是否要把 bug 修复考虑在内?视情况而定

阅读数:831 2011 年 9 月 18 日

话题:敏捷语言 & 开发文化 & 方法

计算速度是否要把 bug 修复考虑在内?近来,在这个问题上有大量争论。看起来似乎没有一个绝对正确的答案。不过,敏捷人士提出一些建议,说明什么时候应该考虑,如何放进去,以及什么时候可以避免。

Syed 认为:是否要放进去, 要看你怎么定义速度。如果速度是从“价值”角度出发,那么 bug 修复就不应该放进去,因为这些工作没有为客户加入任何新的价值。然而,如果速度是从“成本”角度考虑,那么 bug 修复应该放进去,因为它们占用了时间和精力。

Mike Cohn 推荐 为 bug 赋予故事点数。他认为:

这样做对两个阵营来说是最好的。我们可以看到团队真正能够完成多少工作,还能看到历史数据,知道每个 sprint 中有多少工作放在修复 bug 的故事点数上。

Jason Yip 提出一个有趣的比喻,他把速度看作我们向目标终点奔跑的一个指示。 Jason 强调:重要之处是跑向目标。

现在,如果有人施加反向推力,往后推动 5 米,速度就降低了。因此,速度更像是向量,而不是标量。

Robert 认为:可以采取财务中的 复式记账法来判断速度。他说:

我会把 bug 修复算在速度内——但是,在传统的复式记账方法中,我还会把产生 bug 的那个迭代的速度拿过来,作为负值记录在当前迭代的速度上。

Greg 推荐的做法是:只用简单一句话说明不把 bug 修复工作放在速度里面,这样很危险。是否应该计算在内,要看很多具体情况,还有目标的真实定义:

也许目标是开发多个新功能,也许目标是开发一个能让很多客户兴奋的特性。也许目标是修复遗留产品中的 bug。不把 bug 修复放在速度中,也许对某个团队有意义,但是还有很多上下文这么做有问题。

Jack Milunsky 提到:是不是把 bug 修复工作放到速度里面并不重要,重要的是要认真对待它,因为修复 bug 需要耗费时间。

在 Sprint 或迭代计划会议时,应该把 bug 和用户故事放进去。如此,完成任务和修复 bug 的总时间不应超过团队的能力范围。我知道很多教练会争辩,说 bug 应该单独跟踪,而且应该在发现 bug 的 sprint 里面解决掉。但是在实践中,这不是总能做到的。尝试一下,你就会大大改进团队的可预测性。

因此,应该认真对待 bug,这是大家的强烈共识。是否应该把修复 bug 的工作放到速度里面去,还是个问题,大家意见不一致,也许,正确的做法是:根据具体情况。

查看英文原文: InfoQ:Count Bug Fixes Towards Velocity? Depends…