Question

背景

我的团队目前正在进行重大改写的“错误修复和抛光”阶段。我们仍然有大量的错误需要修复，安排在几个里程碑上。我们被要求提出估算，以确定每个里程碑修复错误所需的工程量。

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

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

这是相当准确的（我们在之前的三个里程碑中已经有了很多地方），但它相当耗时。

当前问题

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

我的主要估计经验是我上面描述的方法的一些变化（从自由职业的背景多年）。我发现当我在大型任务中“从臀部射击”时，我倾向于离开。我怀疑在估算代码中我不太了解的代码区域需要多长时间时会更糟糕。

您发现哪些提示，技巧或技巧能够快速估算，而不会将细分任务分解为细粒度的任务并进行估算？

不可选择的事情：

没有估计 - 我试过这个，它没有飞过：）
选择一个非常宽的数字和置信区间 - 我考虑过这个，但我认为它也不会飞。
循证调度 - 我们正在使用JIRA，它没有为其编写的任何证据基础调度工具，我们目前无法迁移到FogBugz（BTW，如果有人去写一个基于证据的为JIRA安排插件，我们很乐意为此付费。）

Answer 1

估算的最佳提示：总结很多。

听起来你已经是估算主题的专家，而且你知道可能的局限性。如果不评估完成任务需要做什么，就无法估计任务！

评估的时间量与估算的准确性成正比。当时间评估如此准确以至于您已经解决了这项任务时，这些事情就会趋同，在那一刻，您确切知道需要多长时间。

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

Answer 2

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

步骤1.意味着您永远不会错过截止日期。

第2步是将问题转回给那些要求您估算而不花时间估算的人。

编辑...

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

利益相关者希望根据每项任务的执行时间和费用确定优先级，并且可能会询问您希望在下一个截止日期之前完成哪些最高优先级更改。

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

你正在寻找比这更长的东西，但不会像你之前的优秀估计那么长。

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

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

Answer 3

怎么样：

estimate=(bugs/devs)xdays (xK)

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

感到惊讶。

Answer 4

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

如果预计整个工作时间超过一周，我通常会在估算中使用半小时粒度而非小时粒度。

Answer 5

使用Planning Poker，查看How to estimate the length of a programming task

的答案

Answer 6

简单来说：

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

以上可能看起来像个笑话，但事实并非如此。我已经多次使用它了。任何类型的软件项目的时间估计都是一种游戏，就像与汽车经销商达成交易一样。该公式将为您提供一些帮助您管理的东西，并为您提供一些空间。

但是，如果你能够以某种方式获得更细粒度的细节（这是你能够更准确的唯一方式），Google Function Point Analysis，有时称为“快速功能点分析“或”快速功能点估计“。

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

希望这有帮助！

Answer 7

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;
        }
    }

Answer 8

您的估算与投入时间一样准确。这段时间可以是物理时间来解决问题，也可以利用您熟悉的领域的过去经验。如果这不是一个选项，请尝试将错误/打磨成小组。

几个小时的琐碎修复。
最多一天的努力。
非常复杂 - 一周的努力。

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

Answer 9

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

Answer 10

计算估算值的可变性所需的时间比计算估算值要长。

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

背景

当前问题

10 个答案: