estimation - 在不花费大量时间的情况下进行估算的最佳方法是什么？

Question

背景

我的团队目前正处于发布重大重写的“错误修复和抛光”阶段。我们仍然有大量的错误需要修复，计划针对几个里程碑。我们被要求估计需要多少工程工作来修复每个里程碑的错误。

对于之前的里程碑，我们遵循以下流程：

将错误分配给最了解该代码区域的人，并且很可能是修复错误的人。
让每个人检查分配给他们的错误，并估计他们认为修复错误需要多长时间，以小时为单位。如果一个 bug 看起来可能需要一两天以上的时间来修复，他们会将 bug 分解为可能的子任务，并对其进行估计。
总计每个里程碑分配给每个人的工作量，如果人们的工作量大不相同，请尝试平衡事情。
将每个里程碑的每个人的总数乘以“填充因子”，以解释过于乐观的估计（我们一直使用 1.5）。
取给定版本的团队成员的最大总数，并确定团队关闭现有错误所需的时间。
估计我们在达到特定里程碑所需的时间内预计会创建的错误数量，并估计我们认为关闭这些错误中的每一个平均需要多长时间。将此添加到关闭每个版本的现有错误的时间。这是我们所需工作量的最终数量，作为我们确定交付该里程碑的日期交付。

这是相当准确的（我们在之前的三个里程碑中几乎处于同一位置），但它相当耗时。

当前问题

我们被要求为即将到来的里程碑估计工程时间，但要求不要使用上述过程，因为它太耗时。相反，作为团队的技术负责人，我被要求提供不太确定的估计值，以及确定的时间间隔（即 1 个月，正负一周）。

我的主要估算经验是我上面描述的方法的一些变化（来自多年的自由职业背景）。我发现当我在大型任务中“从臀部射击”时，我往往会走得很远。我怀疑在估计修复我不太了解的代码区域中的错误需要多长时间时，情况会更糟。

您发现哪些技巧、窍门或技术可以成功地进行快速估算，而无需将事情分解成细粒度的任务并进行估算？

不能选择的事情：

没有给出估计 - 我试过这个，它没有飞:)
选择一个非常宽的数字和置信区间 - 我已经考虑过这一点，但我认为它也不会飞。
基于证据的调度 - 我们使用的是 JIRA，它没有任何为其编写的基于证据的调度工具，我们目前无法迁移到 FogBugz（顺便说一句，如果有人去编写一个基于证据的调度插件JIRA，我们很乐意为此付费）。

score 7 · Accepted Answer

估算的最佳技巧：将大量数据四舍五入。

听起来您已经是估算主题的专家，并且您知道可能发生的事情的局限性。如果不评估完成任务需要做什么，就不可能估计任务！

评估的时间量与估计的准确性成正比。这些事情会在时间评估如此准确的时候收敛，你已经解决了任务，在那一刻，你确切地知道需要多长时间。

嗯，对不起，这可能不是你想听到的答案……不过这只是我的想法。

score 5 · Accepted Answer

随时准备创建版本
让利益相关者优先考虑完成的工作
处理优先级最高的项目

第 1 步意味着您永远不会错过最后期限。

第 2 步是一种将问题转回到那些要求您进行估算而无需花费时间估算的人的方法。

编辑...

以上并没有真正回答你的问题，对不起。

利益相关者将希望根据每项任务的时间和成本来确定工作的优先级，并且您可能会被问到您希望在下一个截止日期之前能够完成哪些优先级最高的更改。

我花费最少时间的技巧是使用三倍于我认为需要多长时间的印象。

您正在寻找比这更长的时间，但不像您之前的出色估计那样长。

您仍然需要查看每个错误，即使只是猜测它是容易、平均还是棘手，或者工作 1、2、4、8、16 或 32 小时。

如果您在代码库上生成一些代码复杂度指标（例如圈复杂度），并且对于每个任务，请尝试在该代码库中最需要更改的两个或三个部分，然后根据以下假设进行估计较不复杂的代码部分将比更复杂的部分更改得更快。您可以根据之前的一些估计提出一些启发式方法，用于每个错误修复，估计所需的时间和可变性。

score 3 · Accepted Answer

怎么样：

estimate=(bugs/devs)xdays (xK)

就这么简单，它实际上是相当准确的。并且可以在1分钟内估算。它的置信水平低于您的详细方法，但我建议您检查最后三个里程碑的数据，并检查此快速估算与您的详细估算之间的差异，这将为您提供代表团队常数的“K”值。

惊奇。

score 2 · Accepted Answer

用最简单的话来说：

您最绝对自由的估计 * 3 = 您的估计

以上可能看起来像个笑话，但事实并非如此。我已经用过很多次了。任何类型的软件项目的时间估算都是一场游戏，就像与汽车经销商做交易一样。该公式将为您提供一些东西，以在紧要关头为您的管理提供帮助，并为您提供一些玩耍的空间。

但是，如果您能够以某种方式了解更精细的细节（这实际上是您能够更准确的唯一方法），Google on Function Point Analysis，有时称为“快速功能点分析”或“快速功能点估计”。

许多人有无数的电子表格、PDF 等可以帮助您尽快估算。首先查看电子表格，因为它们会为您内置公式。

希望这可以帮助！

score 2 · Accepted Answer

您一直在问如何产生估计和不确定区间。考虑这一点的更好方法是进行最坏情况估计和最佳情况估计。将两者结合起来就有一个估计范围。很好理解的问题自然会比对不太了解的问题的估计更具体。例如，一个看起来像 1.5-2 天的估计可能是一个很好理解的问题，一个看起来像 2-14 天的估计对于一个根本不理解的问题来说是典型的。通过允许估计值之间的更大差距来限制调查量和生成估计值所花费的时间。这是有效的，因为它相对容易想象现实的最佳情况和最坏情况。当不确定性范围超出您在日程安排中的承受能力时，然后花一些时间来了解不太了解的问题。分解它们可能会有所帮助。

如果整个工作预计需要一周以上的时间，我通常会在我的估计中选择半天粒度而不是小时粒度。

score 2 · Accepted Answer

2

使用 Planning Poker，查看如何估计编程任务长度的答案

于 2009-04-07T22:59:39.477 回答

score 1 · Accepted Answer

public static class Time
    {
        /// <summary>
        /// Estimates the hours.
        /// </summary>
        /// <param name="NumberPulledFromAss">The number pulled from ass.</param>
        /// <param name="Priority">The priority.</param>
        /// <param name="Complexity">The complexity.</param>
        /// <returns>
        ///  a number in hours to estimate the time to complete a task.
        /// Hey,  you will be wrong anyway why waste more time than you need?
        /// </returns>
        public static int EstimateHours(int NumberPulledFromAss, int Priority, int Complexity)
        {
            var rand = new Random(NumberPulledFromAss);
            var baseGuess = rand.Next(1, NumberPulledFromAss);
            return (baseGuess + (Priority * Complexity)) * 2;
        }
    }

score 1 · Accepted Answer

您的估计与您投入的时间一样准确。这个时间可以是分解问题的实际时间，也可以是在你熟悉的领域借鉴过去的经验。如果这不是一个选项，请尝试将错误/抛光分成几组。

几个小时的微不足道的修复。
最多一天的努力。
非常复杂 - 一周的努力。

一旦你对这些进行了分类，你就可以做出一个粗略的猜测。

score 1 · Accepted Answer

1

敏捷博客上的这篇文章中的许多提示可能很有用：Agile Estimating。

于 2009-04-07T22:58:10.667 回答

score 0 · Accepted Answer

0

计算估计值的可变性将比计算估计值花费更长的时间。

于 2009-04-07T22:40:39.787 回答

estimation - 在不花费大量时间的情况下进行估算的最佳方法是什么？

背景

当前问题

10 回答 10

Related

Reference