产品缺陷需要估算点数吗

先来看看哪些场景下会产生缺陷

场景一： 当前迭代产生的缺陷

团队在一个迭代开始计划完成100个点数的用户故事，开发在迭代过程中不断开发用户故事，QA发现缺陷并与开发达成一致需要再当前迭代内修复，此时需要为这些缺陷估算点数吗？

答案显而易见，不能。极端情况下，开发质量越差，写出的缺陷越多，如果为这些缺陷记录点数，那么完成的点数变得多了；而那些高质量的开发人员缺陷很少，完成的点数反而少了！这就本末倒置了！当然很多团队并不会记录这些再当前迭代内必须修复的缺陷。

场景二： 以前迭代产生的缺陷

还是场景一的延续，由于时间紧迫或者缺陷不严重，以前迭代中的缺陷被留到当前迭代修复。这些缺陷需要估算点数吗？

这时候各个团队的做法就不一样了。有的团队主张估算点数，因为估算点数后在迭代计划会议上便于根据velocity计划可以完成多少，在迭代过程中更好控制项目进度，燃尽图等报表也会比较好看。而有的团队基于对质量的高要求选择不估算点数，认为所有的缺陷都是之前在质量上所欠下的债，不应该为了报表好看就掩盖质量上的问题。

场景三: 修复另一个团队的缺陷

这个场景听上去比较有内伤，但是在很多团队确实发生。有时候两个团队基于同一套代码库进行开发，开发的功能或多或少会有交集。又或者有的缺陷是很久很久以前就留在系统中，造成这个缺陷的团队早就解散又重组。一个团队把烂尾留给了另一个团队，那么作为接盘侠的团队要估算这个缺陷点数，作为自己velocity的体现吗？

这种场景下，好像大家不会反对把缺陷记入velocity，毕竟欠债的人已经拍屁股走人了，给背锅的人记点功勋也无可厚非。

那么，事情还是要有个结论的，到底产品缺陷需要需要估算点数呢？

我的观点，不需要。

理由是：

• Velocity是很多Scrum团队衡量交付能力的体现，将velocity单纯体现在可以交付的用户故事上，才会让未来的计划更准确。缺陷点数的加入，只会让团队真正的交付能力被掩盖。

• 如果缺陷真的很多，那就让这种低质量的问题通过velocity暴露出来把。让我们看看是有怎么样缺陷拖慢了团队的速度。

• 估算这个过程的加入最重要的是团队成员对将要完成的工作达成共识。而缺陷一般都已经很清楚“Actual Result” 和“Expected Result”，再讨论的意义并不大。以前一个同事的话记忆犹新：“整个团队在一起估算的时间，我已经把这个缺陷修复了”。对于缺陷，只要团队成员对期望结果达成共识即可，接下来要做的就是看代码，而不是浪费时间在估算上。要知道

估算本身就是一种浪费