Scrum，如何处理sprint中的bug，以及如何对bug进行计时估计

Question

我在一个Scrum项目中工作，用C语言为ASIC编写固件代码。

有时我们真的很难找到bug。但是我该如何估计这些bug呢？

我总是告诉Scrum管理员，我没有能力估计它们，因为我真的很讨厌对bug的时间估计。

你们是如何在Scrum项目中处理这个问题的？

Answer 1

估计bug是一件非常困难的事情。如果你能做到这一点，那么你可能已经有了解决方案，而且它不再是一个真正的bug :)所以，与其试图逐个估计它们，我更喜欢的选择是在Sprint期间分配一些"bug修复时间“，并在这段时间内修复最重要的bug。这是一种尽力而为的策略，您只需在分配的时间内尽可能多地修复它们。

Answer 2

对我有效的一种方法是，首先不要有bug :)

它的工作方式是，当发现一个bug时，修复它比故事实现更重要。只有当现有功能100%正常工作时，才能添加新功能。

当然，我们会对bug进行分类。这种停止生产线的方法只适用于严重的bug。不到关键的bug被视为功能增强故事，在即将到来的sprints中估计和计划为任何其他故事。

关键bug修复的时间分配最终会反映在您的团队速度中。

Answer 3

“很难做出预测--尤其是对未来的预测。”

除非您已经分析了一个bug并制定了解决方案，否则无法对其进行评估。这就像在不知道待办事项的情况下召开scrum计划会议一样。

您可以使用大的估计值来传达不确定性。历史数据的价值有限。它对手头的一个bug没有太大帮助，即使新bug的工作量分布是相同的。此外，新的bug通常会更容易或更难。