不要估计软件缺陷

软件缺陷=没有估计

我不估计软件缺陷。好吧，我有两个例外：如果我有一个待办事项列表旧的缺陷烧毁，我可以估计那些。如果我发现了一些我们计划在一些后来的Sprint中修复的新错误，我可能会估计那些。虽然我真的不喜欢推迟缺陷修复，但是 - 否则 - 我不估计缺陷。

为什么不估计软件缺陷？

在解释为什么之前，暂停并考虑我的上下文很重要。要逃避估算软件缺陷，您必须具有高质量标准，强大的单位测试套件和TDD的惯常实践。您还必须尽快修复所有缺陷，或者最多1个Sprint。如果这不是你的上下文，请停止阅读并放置TDD到的地方。

在这些条件下，决定不估计软件缺陷，这就是更容易的。它使得更保守的释放和迭代计划不估计缺陷，或者至少不包括它们以速度。这是一个简单的规则，简单解释。

那么，用其他方法有什么问题吗?如果您估计新的缺陷，并在您修复它们时将它们包含在您的速度中，那么您不能仅仅通过将积压的大小除以速度来确定何时完成。通过这样做，您将在您的速度中包含固定的缺陷，但将您还没有发现的东西排除在您的积压中。可以肯定的是，您将发现更多的缺陷，因此您的积压正在增长，不管您是否认识到这一点。

将膨胀的速度数除以低估的积压是有风险的计划。当然，您的燃耗图可能会向您显示您的积压和燃耗截距的增长的预测，但这只是在您正确地估计您的缺陷相对于您的故事的情况下。如果只考虑新的故事范围的增加，那么在估计backlog的增长速度时就有足够的猜测了。为什么在计算中包含缺陷会使它变得更加困难?

估算软件缺陷的挑战

为例，让我们说我们每个Sprint都有一个新的缺陷，并让我们平均每1分。还假设初始速度为10（不估计缺陷）和200分的积压（没有任何措施对于未知的未来缺陷）。如果我在没有估计的情况下修复缺陷，我将继续具有10的稳定速度。我将有一个稳定的200.我的数学很容易：200/10 = 20冲刺。这很容易教导。而且它是保守的。

另一方面，估计缺陷给了我一个稳定的11点的速度，但是每冲刺增加1点的积压。这个数学是，让我想想…

斜坡是，呃......某物

我们有拦截，呃......

哦，我不知道。

如果我们知道平均缺陷大小和缺陷到达率，我们可以很容易地计算出这一点。但是，大多数团队不知道他们的平均缺陷大小或缺陷到达率。这是很难教的。当人们在脑子里计算信封背面时，让他们记住和解释日益增加的积压就更加困难了。

另外，缺陷是很难估计的，我们对缺陷所做的估计通常不能反映出与for相同的行为故事。它们有不同的方差。不同的分布和每个点的平均努力通常与故事显著不同。缺陷和故事之间的相对估计并不是最好的。

总结

如果一个组织发现自己还没有准备好开始下一个版本，他们将让其他空闲的团队修复缺陷，直到产品负责人团队准备好，那么为什么要评估缺陷呢?

我倾向于对交付的价值进行速度度量——而不是针对缺陷、返工或研究。我这么做是因为我非常关心我的发行承诺/预算。如果我因为缺陷和峰值(游戏邦注:如未计划的事情)而提高了速度，那么我最终会过度投入到发行中。我的速度数将会高于实际已知的要传递的值。

让我提醒你，这里有很多情况这很重要。如果您的团队具有高质量标准，并且在找到它们的情况下，他们会解决所有缺陷，或者稍后可能会修复所有缺陷，那么我的方法就不会估计有效，因为它们不允许增加积压缺陷以累积。但是，如果您的团队往往缺陷，并打算在释放后稍后修复它们 - 那么我的方法就是真的，真的很糟糕。此时，您应该估计您的所有缺陷并理解当前的到达率和每个版本的历史缺陷负载。

对于这条规则，我也会有例外，但我并不总是持有相同的信念。一个关于这个主题的老帖子，估计缺陷-使用原则性谈判，讨论了在各种不同的环境下您可以做什么。

底线：分别跟踪、量化和表示软件缺陷的影响。