错误修复时间分配

Question

我们已经被客户要求给我们一个关于我们每个错误的时间估计。

虽然我们确实设定了错误修复计划并为其分配了时间，但我们没有为每个错误分配时间。简单地说，我们已经优先考虑我们的错误，并确保在分配的时间内修复最高优先级的错误。

我不喜欢为bug分配时间，原因只是因为：

1. 通常不准确。很难弄清楚修复需要多长时间。
2. 浪费时间。
3. 影响代码质量
4. 从长远来看会产生更多错误（我们可能会在截止日期前尝试完成某些事情。）

如果我们不想提供每个bug的小时数，我们应该如何解决这个问题，而只是确定哪些错误会被修复的时间框架？

如何为错误分配时间？有效吗？值得花时间和精力吗？

Answer 1

我能给出的唯一答案是非常保守。猜猜需要多长时间，然后将你的猜测加倍。使用它作为您的估计。正如你所说，很难弄清楚修复需要多长时间，而且最好说它需要比实际操作更长的时间，而不是因为你不够保守而被抓到“违反截止日期”。

Answer 2

我工作的公司经常收到客户的无理要求。 要记住的关键是客户希望获得充分的信息。我们发现最好的方法就是状态报告。

因此，我们首先要很好地解释我们的立场。在您的示例中，这将是这样的：

  

我们有一套固定计划错误的时间表，我们在历史上一直保持良好的记录。但是，详细说明每个bug修复需要多长时间的过程非常容易出错。我们很乐意为您提供每周更新（或每周两次或每天取决于客户）有关已修复的错误和已经过测试的修复程序。

但是，我确实认为最好估计每个bug修复需要多长时间。原因是您需要了解修复所有错误所需的总时间。如果您没有估计各个部件需要修复的时间，您将无法获得准确的估算。当然，这些可能是粗略的估计（估计不会花费一个小时研究问题） - 你不想浪费太多时间估算。然后我通常考虑额外的20％。所以说错误的估计是3天，5天和2天。然后我会向客户报告我们应该能够在12天内修复错误。当然，您可能需要增加更多时间来测试和重新包装您的产品，然后才能为其提供可交付成果。

Answer 3

在估计修复错误所需的时间方面，请不要考虑这一点，因为您无法正确估计错误。

从管理客户愤怒的角度来考虑这一点。如果你告诉他们这些错误会花费很长时间来解决，他们最终需要3个月的时间，你的客户现在会对你感到满意并且对你未来感到愤怒。

如果你告诉他们这些错误将花费3个月的时间来解决，他们实际需要3个月的时间来修复（他们会这样做），你的客户现在会非常愤怒，并且对你很满意。

我通常说虫子根本不会花时间（2-3天似乎是一个很好的安抚号码）。

Answer 4

它应该与估计您拥有的任何其他任务相同。将其分解为尽可能最小的任务，并尽可能准确地估算出那些意外的填充。然后给它们一个范围，这样你就不会固定到没有明确定义的任务的特定日期。估计修复错误的时间与估计实施具有模糊要求的要素的时间之间没有区别。

Answer 5

你是对的，估计通常是不准确的。

也许你想问一下，如果它们不固定，每个bug会花多少钱。然后，您可以执行适当的计算，以确定是否应该修复它们，以及您（或实际上，他们）花费多少时间来投入到每个错误中。

Answer 6

为什么不选择几个波段来确定bug的严重程度，例如： 1小时，半天，1天，1周并分配给他们。一般来说，你会有一种错误的感觉 - 你不知道的错误，把最坏的情况数字给它！

我认为你不会因为你引用的原因（花费太长时间去调查等等）而在任何更精细的水平上进行评估。

我不认为这是浪费时间。您的客户想知道的不仅仅是错误的数量和优先级 - 他们想要了解剩余的工作量。

在任何情况下都不会导致您产生更多错误。你不应该匆匆忙忙来解决这些问题。如果你估计1天，花了10个小时，那没关系。如果你估计1周，花了2个小时，结果很好！

这只是一个估计练习！

Answer 7

通常我们会同意为特定版本修复哪些错误，然后定义修复所有错误的时间范围。对于每个单独的错误，修复需要多长时间存在很多不确定性/可变性，但往往会出现大量错误。对于您知道需要更长时间的某些错误，可能会给出一些估算值，例如：如果你需要为它编写模拟器或测试框架。

Answer 8

如果这些是已发现并报告的错误，那么您应该能够估计修复它的时间（以及重新测试的时间）。估计值的置信度可能与您在估算上花费的时间成正比，也许可以向客户解释此成本。

如果有许多相关的小错误报告，您可以将它们合并为一个综合报告。这可能会避免客户试图根据个人估算来挑选和修改哪些错误。