我正在一个Scrum项目中编写ASIC的C固件代码。
我们时常遇到难以找到的致命错误。但是，我如何估算这些错误需要多少时间呢？
我总是告诉Scrum主管我没有能力估算它们，因为我真的很讨厌估算错误的时间。
在你们的Scrum项目中，你们是如何处理这种情况的？
15个回答
24
估计漏洞是一件非常困难的事情。如果您能够做到这一点，则很可能已经找到了解决方案，那就不再是漏洞了 :) 因此，与其尝试逐个估计它们，我更喜欢在Sprint期间分配一些“漏洞修复时间”，并在那段时间内修复最重要的漏洞。这是一种尽力而为的策略，您只需在分配的时间内尽可能地修复漏洞。
- Pascal Thivent
3
2是的，要测量修复错误所需的时间。也许将它们分类为“什么鬼？-错误”、“当然啦-错误”等。根据同一类别过去错误的平均值来估计未来的错误。不过，在实践中，跟踪花费的时间是另一个困难的问题。 - Christian
啊！修复最重要的漏洞意味着你不会在发现它们后立即修复所有漏洞。推迟修复的漏洞成本更高。 - Adrian McCarthy
@Adrian 我完全同意并相信“停线”文化：发现问题后立即修复。但是，你并不总能在一个迭代中找到所有的问题。 - Pascal Thivent
10
我采用的一种方法是在一开始就不出现bug :)
具体做法是，当发现bug时，修复它比实现故事更优先。只有在已有的功能百分之百正常工作后，才能添加新功能。
当然，我们会对bug进行分类。这种停止生产线的方法仅适用于关键性的bug。不太关键的bug被视为功能增强故事，并像其他故事一样在即将到来的迭代中进行估算和计划。
为关键性bug修复分配的时间最终会反映在团队速度中。
- laalto
5
"很难对未来进行预测。"
除非你已经分析了一个错误并提出了解决方案，否则无法估计。这就像在不知道待办事项清单的情况下进行Scrum规划会议。
您可以使用大量的估算来传达不确定性。历史数据具有一定的有限价值。即使新错误的工作分配相同，它也不能为手头的一个错误提供太多帮助。此外，新错误平均可能更容易或更难。
- Thomas Jung
5
我问Jeff Sutherland，他告诉我PatientKeeper为修复一个错误估计需要半天的时间。如果你的bug性质是可以相当可预测，这样你可以找到一个近似平均值，我想这是一种公平的策略。然而，在实践中，我发现这并不总是奏效。理解错误有时很困难，可能需要更长的时间来分析它而不是解决它。这使得bugs变得高度不可预测和难以估计。在你的迭代中包括的所有任务都必须进行分析，而bugs通常需要比其他任务更多的分析。
在这种“不可预测”的bug情况下，我们所做的是分配固定的时间来弄清楚问题所在。例如，我们选择花一天（或x点）来挖掘bug以尝试理解它，然后计划在下一个迭代中处理实际修复。但是，如果那不足够的时间来找出原因，我们不想在当前迭代中浪费更多时间，必须重新考虑它。在某些情况下，此bug可能非常重要，您只能接受不确定的估计。
在这种“不可预测”的bug情况下，我们所做的是分配固定的时间来弄清楚问题所在。例如，我们选择花一天（或x点）来挖掘bug以尝试理解它，然后计划在下一个迭代中处理实际修复。但是，如果那不足够的时间来找出原因，我们不想在当前迭代中浪费更多时间，必须重新考虑它。在某些情况下，此bug可能非常重要，您只能接受不确定的估计。
- stiank81
4
将它们估算为几周而不是几小时。
如果你的Scrum-master不理解时间估算修复错误的问题，那么你的项目可能会受益于拥有至少具有较小编程知识的Scrum-master。
- Viktor Sehr
1
有点严厉 :)我认为在许多情况下，开发人员将拥有一些背景知识，使他/她能够_大致_ _估计_修复问题所需的时间。 - Cocowalla
3
我们可以将bug分类为以下三种：
1. "我知道哪里出错了，我需要更新它"
2. "我知道这个bug与这个模块有关，通过调试一些文件我可以解决它"
3. "我不确定为什么出现了这个bug"
对于前两种情况，我们可以根据在该项目中的经验进行估计。但是对于最后一种情况的估计真的很困难。
对于前两种情况，我们可以根据在该项目中的经验进行估计。但是对于最后一种情况的估计真的很困难。
- Manoj Attal
2
根据修复之前的漏洞平均所花费的时间来估计它们，这个方法如何？
- Klaus Byskov Pedersen
1
根据一致的故事点估算，您应该能够建立一个关于每周完成多少故事点的历史记录。这也将包括修复错误所需的时间。
例如，我们知道我们可以在一周内完成20个故事点，这是从以前的冲刺中得出的结论。这20个点的开发可能在2天内完成，但是接下来需要进行测试和错误修复。我们不会在开发错误上进行估算，因为每个新故事都应该有一个估算，其中大约包括错误修复时间。在估算之前应该先调查现有错误，然后就可以准确地估算了。
- cjk
1
我们估计每个漏洞的分析时间为4小时。此外，我们有一个故障优先级。必须在实施其他任何功能之前修复阻止或关键性质的错误。修复许多错误会导致实施的故事减少。但是我们已经为下一个功能提供了一个强大的软件。
- bzs
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接