所以你刚刚被The Boss放在了现场。 你有15分钟的时间来提出增加一些新功能的信封估计值。你的老板（幸运的是）认识到你无法在那段时间内提供准确的估计，所以期待一些正确的数量级。
问题是你如何在准确到一个数量级的时间范围内做出估计？
请注意，这是一个快速而肮脏的估算，而不是像this
这样的问题。答案 0 :(得分：17)
将手指放入嘴中，舔，在空中挥动，并根据过去的经验编造一个数字。然后加倍。
真的，它的经验非常重要。你想象一下这个任务需要你做什么，而且你知道你需要多长时间才能做到这一点。加倍意外的项目。这也是你从不向初级程序员询问这种估计的原因。
答案 1 :(得分：7)
最好的方法是尝试快速细分所有主要子组件，例如：
对每一个进行粗略猜测，如果你不能想到至少放下2个小时，那么即使是最简单的项目也可能需要至少一个小时，但是2x将允许不确定性。
至少你会想到你将要做的所有项目，所以它将按照要求的正确数量级。
答案 2 :(得分：5)
回想一下你过去做过的类似任务以及他们花了多长时间。
如果你之前没有做任何类似的事情，请尝试将任务分解为子任务，然后进一步减少每个子任务，直到没有留下任何子任务，听起来需要超过1-2天才能在最天真可能的方式;如果你不能将任务估计超过3天，这通常意味着你并不真正知道完成这项任务所涉及的内容;做一些快速研究。一旦所有内容都被分解，将其总计，将结果加倍并将其作为估计值。
如果你不知道如何解决问题就足以完成上述任务，而你的老板正在呼吸你的脖子让你不觉得你可以在那里研究，而是试着让你的老板估计你需要花多长时间进行研究才能理解这个问题，足以给他一个适当的估计。
答案 3 :(得分：3)
我无法想象一种我根本无法做出估计的情况 - 更常见的情况是，我可以想象多种情况会导致项目的时间框架大不相同，具体取决于各种事情。可以合理地突然出现。而且我不想撒谎 - 你可以对老板做的最糟糕的事情就是制造东西。
所以我解释了每种可能性。当然，这只适用于理解老板，但如果你的老板如此无知或愚蠢以至于他拒绝听取完整的解释，那么你还有其他问题。
例如，以下是我为最近的一个案例做的事情，其中我实际上必须这样做。
x264，我工作的视频编码器，实现了一种非常原始的隔行编码形式，仅仅因为它很容易实现。我们想要实现这种编码的完整形式，但我不知道在这种情况下为简化版本做出的假设有多少会失败。
所以我考虑了可能需要改变的各种层面的事情，并使估计成为一个范围 - 好吧，充其量，它可能已经接近工作，但这是值得怀疑的。最糟糕的是，有大量的东西需要改变。所以，我告诉我的老板，假设这里最糟糕的可能更好，因为规范非常复杂，尽管不知道任何复杂性，我怀疑由于程序中缺少相关代码，几乎没有实际上已经实现了复杂性。最后我说得对 - 所需的更改最终变得非常复杂，他们将项目外包给了一位在H.264隔行编码复杂性方面具有更多专业知识的承包商。
答案 4 :(得分：3)
除了必要的细分之外：我从实用程序员那里获得的建议是在几周内表达超过15天的估计值，并估计在几个月内超过8周;以便该单位反映估计的准确性。 30周以上要非常小心。
您还可以根据已经完成的类似任务进行估算。
答案 5 :(得分：2)
如果您确实需要非常快速的估算，您可以在每个任务中执行工作分解结构1-2天或更短时间，然后通过提供最小和最大估计值来估算每项任务。
最小值和最大值之和指定整个任务的间隔。这为您的老板提供了有关风险的信息，这一直非常有用。
您将获得一些间隔，例如12-15天或5-30天 - 这比16天而不是提到的间隔更有用。
史蒂夫麦康纳Software Estimation: Demystifying the Black Art对你的好书有用。
答案 6 :(得分：2)
想一个数字，加倍然后再加倍（即弹出头部的第一个数字的四倍）
当老板说“完成一个项目需要多长时间”时，他就意味着它完成并实时部署到用户的时间。程序员（自然）只会考虑完成编程所需的时间（物理输入问题解决方案的时间），因此通常会低估。
经验法则是：
“第一个数字”是您认为根据刚才描述的任务范围完成任务所需的天数。 （但当然，你没有被告知一切）。
第一个倍数是在向老板提供第一个演示/原型后重新编码所需的额外时间，他说“很好，很棒。但是你可以添加......”
第二个倍数是将重新编码重新编码为正确生产标准所需的时间。
第三个倍数是测试时间，文档和时间;部署以及您需要做的所有其他管理员工作才能真正实现这一目标。
第四个倍数是你对上述事件的偶然性。
这应该给你一个安全的估计。当然，你应该坚持进行更彻底的规划和估算。
答案 7 :(得分：1)
我最近一直在阅读Agile Estimating and Planning，并且不能推荐它。
答案 8 :(得分：1)
如果我没有足够的时间来正确调查手头的主题而被迫提供估计，我倾向于高估。修复几乎总是比我想象的要困难。如果我认为某事需要一天，那么我说两天。如果我说某事需要一个小时，那我就说一天。我想用这些评论来说明的是，对于除了拼写错误等最平凡的任务之外的所有任务，即使是一个小的代码更改也可以爆炸成一整天。对于我认为可能需要一天或更长时间的任何事情，我估计会加倍。我知道这样做很难。管理层想要小数字。您希望在其他开发人员面前显得聪明且能干。另请参阅Scotty Factory。
即使您有能够测试代码的QA团队成员，您也必须记住，测试代码也是您的工作。确保将其纳入任何估计值。这是我见过的很多开发人员都没有考虑到他们的估算过程。
答案 9 :(得分：1)
因素＃1是未知数，你是对的，你无法全部了解它们。但是，您通常会知道当时没有人可以为您解答的一些主要问题。
因素＃2是手头工具和资源的感知难度和可用性。
结果=估计值的两倍
答案 10 :(得分：1)
将任务分解为多个部分并为每个部分分配时间
以每天不少于1/2的单位工作。这将阻止微调度
项目估算的一个大问题是低估了。如果您很好地了解任务并且几乎可以看到代码，那么将任务加权1.如果存在某些不确定性或任务需要未知技术，则将其乘以更高的因子，具体取决于不确定性水平
< / LI>不要过分担心每个部分的准确性。这些错误往往会被取消，因为唯一真正重要的是总持续时间
在采用乐观的时间尺度并将其乘以PI时，始终存在良好的待机状态。比它应该更频繁地工作！
答案 11 :(得分：0)
“六到八周”的效果非常好，另一个有效的方法是基于数据模型。
想象一下应用程序所需的数据库表（或类似表）的数量，乘以您需要为每个表编码模型，CRUD，UI等所需的天数，并添加30％到50％的时间除此之外。
答案 12 :(得分：0)
我个人拒绝这种事情。但后来我为自己工作，所以我不回答老板。只是一个客户，但它更容易让他们理解当场难以做到的事情。
答案 13 :(得分：0)
我相信答案总是“六到八周。”
答案 14 :(得分：0)
要按正确的数量级进行估算，您需要：
答案 15 :(得分：0)
我通常将任务分解成几件，但我不会在不到半天的时间内估计这些事情。只要故障后至少有5或6个特征，我发现错误大部分都是平衡的（某些任务需要一个小时以内等）
当然，某些程度的舒适所需的最小时间分数和件数需要根据问题领域而变化 - 至少5或6个半天的块似乎对我所问的东西是正确的最近，但需要每隔几个月审查一次。
当我被要求代表其他人进行评估时，我会更加抗拒，并采用类似的做法，使用大量的填充系统（如上所述，“加倍并添加x”可能是一个很好的近似值）
答案 16 :(得分：0)
在这些时候，我记得McKenzie Brother关于转换为公制的规则：“加倍，加三十。”
我通常会想到我最初认为做一件事会有多快，然后加倍，因为我总是低估，然后根据我正在使用的单位添加30进行测试。 / p>