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…
最新评论