缺陷报告及缺陷生命周期_调整缺陷大小的三个技巧

缺陷报告及缺陷生命周期

在我为“实际产品负责人”讲习班授课时，有些采购订单正难以理解缺陷的严重程度。 当然，他们希望有一个较小的故事，但要等到所有问题都得到解决之后，缺陷才能解决，团队已经决定是否需要在烟熏测试中添加自动回归测试。

因此，这里有三种可能的缺陷尺寸：

1. 要求人们共同解决缺陷。 如果他们可以在一天或更短的时间内解决问题，则缺陷大小为1（或任何适合您的小故事）。
2. 让整个团队蜂拥而至或围攻以加深缺陷。 在一天结束时，他们要么修复缺陷，要么他们足够了解就可以采取修复措施。
3. 假设每个缺陷的大小都是1，除非团队认为它的大小更大。 当团队不得不考虑是否可以在一天内解决此问题的默认选项时，它可能会改变团队对缺陷的看法。

当您使用这些可能性时，就会得到以下结果： 没有人一个人工作 。 并且， 团队在一天结束时对价值有一些想法（无论是估计还是完成的工作） 。

我注意到的缺陷（尤其是来自旧产品的缺陷）的一件事是，它们通常比看起来更复杂。 当人们一起工作时，无论他们如何合作，他们都可以在进行过程中查看这些复杂性风险。

如果团队成员一起工作以配对，蜂拥而至或暴民来解决问题，那就太好了。 如果团队成员共同努力评估缺陷的大小，他们就会开始考虑可能性和风险。

我不知道这是否适合您。 它可能。 让我知道您的想法或您如何尝试确定缺陷的大小。 实际上，我们总是将初始缺陷修复的时间定为一天，唯一的区别是我们的处理方式。

我要解决的问题是无法修复的缺陷修复，需要永久修复。

翻译自: https://www.javacodegeeks.com/2016/09/three-tips-sizing-defect-fixes.html

缺陷报告及缺陷生命周期