计算速度是否要把 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 的工作放到速度里面去，还是个问题，大家意见不一致，也许，正确的做法是：根据具体情况。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论