错误修复时间分配

我唯一能给出的答案是非常保守。猜猜要花多长时间,把你的猜测乘以4。用它作为你的估计。正如你所说,很难弄清楚事情需要多长时间才能解决,最好是说,要比实际时间长,而不是因为你不够保守而被抓住“违反最后期限”。

我为之工作的公司经常收到客户不合理的要求。 要记住的关键是,客户希望得到充分的信息。 我们发现最好的方法是在状态报告方面。

所以,我们首先很好地解释了我们的立场。在您的示例中,如下所示:

我们有一个固定的计划来修复我们项目中的错误,这在历史上是一个很好的记录保持在计划中。但是,详细说明每个bug修复所需的时间的过程非常容易出错。我们很乐意为您提供每周更新(或每周两次或每天两次,具体取决于客户),以了解已修复的错误和已测试的修复。

但是,我相信尝试估计每个bug修复需要多长时间是很好的。原因是您需要了解修复所有错误所需的总时间。如果没有对单个部件修复所需时间的估计,您将无法获得准确的估计。当然,这些可以是粗略的估计(估计不超过花一个小时研究问题),你不想浪费太多的时间估计。然后我通常会考虑额外的20%。所以假设bug的估计值是3天、5天和2天。然后我会向客户报告,我们应该能够在12天内修复缺陷。当然,你可能需要增加更多的时间来测试和重新包装你的产品,然后才能给他们一个可交付成果。

不要从估计修复缺陷需要多长时间的角度来考虑这一点,因为您不可能正确地估计这一点。

从以下方面考虑 管理客户愤怒 . 如果你告诉他们这些虫子根本不需要时间来修复,而且它们最终需要3个月的时间,那么你的客户现在会对你感到高兴,将来会对你感到愤怒。

如果你告诉他们这些错误需要3个月的时间来修复,而他们实际上需要3个月的时间来修复(他们会这样做),那么你的客户现在会非常愤怒,将来也会对你感到高兴。

我通常说,虫子不会花任何时间(2-3天似乎是一个很好的安慰数字)。

它应该与估计您拥有的任何其他任务相同。将它拆分为尽可能小的任务,并尽可能准确地估计这些任务,并为意外事件添加填充。然后给他们一个范围,这样你就不会被固定到一个具体的日期,在任务上没有明确定义。估计修复错误的时间和估计实现需求模糊的功能的时间没有区别。

你说得对,估计通常不准确。

也许你想问他们如果错误没有解决,每个错误要花多少钱。然后,您可以执行适当的计算,以确定它们是否应该是固定的,以及您(或现实地说,它们)可以花多少时间来处理每个bug。

为什么不根据bug严重程度选择几个频段,例如1小时、1/2天、1天、1周,然后针对它们进行分配呢?一般来说,你会对一个bug有一种感觉——对于那些你不知道的bug,把最坏的情况放到它上面!

我不认为你会因为你引用的原因(花了太长时间去调查等)而被要求以比这更好的水平来估计。

我认为这不是浪费时间。您的客户希望了解的不仅仅是错误的数量和它们的优先级——他们希望了解还有多少工作要做。

在任何情况下,这都不会导致产生更多的错误。你不应该赶时间去修这些。如果你估计是1天,10个小时,就可以了。如果你估计一个星期花了两个小时,结果很好!

这只是一个估计练习!

通常,我们会同意在特定版本中必须修复哪些bug,然后定义修复所有bug的时间框架。对于每个单独的bug,修复所需的时间都有很多不确定性/可变性,但这往往会导致更多的bug。对于某些您知道会花费更长时间的错误,可能会给出一些估计,例如,如果您需要为它编写模拟器或测试框架。

如果这些是已经发现和报告的错误,那么您应该能够对修复时间(以及重新测试的时间)进行估计。估计的可信度很可能与您花费在估计上的时间成正比,也许可以向客户解释这个成本。

如果有许多相关的小错误报告,也许您可以将它们折叠成一个综合报告。这可能会避免客户机仅仅根据单个估计来选择和选择要修复的错误。