Debugging Scrum，如何在sprint中处理bug以及如何估计bug的时间

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

我们常常很难找到bug。但是我如何估计这些bug的时间呢

我总是告诉Scrum大师我没有能力估计它们，因为我真的很讨厌对bug进行时间估计

---

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

如何根据修复早期bug所花费的平均时间来估算这些问题？

用几周而不是几个小时来估算这些问题

如果您的Scrum管理员不了解估算bug修复时间的问题，那么您的项目可能会从拥有至少具有少量编程知识的Scrum管理员中受益。

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

除非您分析了一个bug并找到了解决方案，否则无法对其进行估计。这就像在不知道积压工作的情况下召开scrum计划会议

---

您可以使用较大的估计值来传达不确定性。历史数据的价值有限。对于手头的一个bug，即使新bug的工作分配相同，它也没有多大帮助。此外，平均而言，新的bug可能更容易，也可能更难。

基于一致的故事点估计，您应该能够建立一个一周内可以完成多少故事点的历史记录。这还包括bug修复时间

例如，我们知道我们可以在一周内完成20个故事点，这是以前的冲刺。这20点的开发可能会在2天内完成，但是接下来还有测试和bug修复。我们不估计开发错误，因为每个新故事都应该有一个估计，大约包括错误修复时间。在评估之前，应该先调查活的bug，然后才能准确地评估。

我问了这个问题，他告诉我，在PatientKeeper，他们有一个固定的半天时间来修复bug。如果你的bug本质上是可以预测的，那么你可以找到一个近似的平均值，我想这是一个公平的策略

然而，在实践中，我发现这并不总是可行的。通常很难理解错误是什么，分析它可能比解决它需要更长的时间。这通常会使bug高度不可预测，难以估计。必须对sprint中包含的所有任务进行分析，bug通常比其他任务需要更多的分析

---

在这种“不可预测”的bug情况下，我们所做的是分配固定的时间来找出问题所在。例如，我们选择花一天时间（或x点时间）深入研究bug，试图理解它，然后计划在下一个sprint中解决实际修复问题。然而，如果没有足够的时间来解决这个问题，我们不想在当前的sprint中浪费更多的时间，并且将不得不在下一个sprint中重新考虑它。在某些情况下，错误可能是非常严重的，你只能接受一个不确定的估计

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

我们可以将错误分类为 “我知道哪里出了问题，我需要更新它”， “我知道这个错误与这个模块有关，任何调试这些文件的行为我都能解决”， “我不知道为什么会出现这种错误”。 根据我们在该项目上的经验，我们可以估计前两种情况。

---

但对最后一个案例进行评估是非常困难的。

一个对我有效的方法是首先不要有bug：）

其工作原理是，当发现bug时，修复它的优先级高于故事实现。只有在现有功能100%正常工作后，才能添加新功能

当然，我们对bug进行分类。这种停止生产线的方法仅适用于关键缺陷。不太关键的bug会被视为功能增强故事，在即将到来的sprint中会像其他故事一样进行评估和规划

---

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

我们估计每个缺陷的分析时间为4小时。此外，我们还对bug进行了优先级排序。在执行任何其他操作之前，必须先修复阻塞程序或关键错误。许多bug需要在较低的实现层中修复。但是我们为下一个功能提供了一个如此强大的软件。

我发现，试图估计bug并没有多大用处。只要防止它们，找到它们，让它们可见（在你的任务板上或你使用的任何东西上），确定它们的优先级并修复它们。您花费的时间将影响速度。速度才是最重要的。速度是你在下一个冲刺中可以期望取得多大进步的指标

---

如果您对某些指标感兴趣，请改用每次冲刺的bug数量。

我之前问过类似的问题，得到了一些。

真正的目标是减轻与bug相关的风险；i、 e.不让时间表生效。通常，团队能够提前确定哪些故事可能会产生棘手的bug。因此，一种缓解策略是首先处理这些故事，给团队尽可能多的时间来应对意外情况

我听说过除虫和钓鱼相比。修复一个神秘的bug需要多长时间？钓一条鱼要多长时间？你可以试着用这些术语向你的产品所有者解释它。

你也可以考虑在Sprint中分配一个“偶然”来代替使用看板方式来处理它们。这意味着你可以和P谈谈