因此，我们刚刚被The Boss放在了现场。
我们需要15分钟才能得出信封估算值的底线，以增加一些新功能。老板(很幸运)认识到我们当时无法提供准确的估算，因此期望的是正确的数量级。

问题是，如何在时间范围内给出精确到一个数量级的估计？

请注意，这只是一个快速而肮脏的估计，而不是像这样的问题所期望的结果

解决方案

我个人拒绝这种事情。但是后来我为自己工作，所以我不回答老板。只是一个客户，但是它更容易使他们了解它在现场难以做到的事情。

在这样的时候，我记得麦肯锡兄弟(McKenzie Brother)转换为公制的规则："将其加倍，再加30。"

我通常会想出我本来想做一件事情的速度，然后加倍，因为我总是低估了它，然后加30进行测试，具体取决于我使用的单位。

回想一下我们过去完成的类似任务以及它们花了我们多长时间。

如果我们之前从未做过任何类似的工作，请尝试将任务分解为子任务，然后将每个子任务进一步分解，直到没有子任务为止，这听起来可能需要超过1-2天的时间才能以最幼稚的方式进行原型制作道路;如果我们不能分割估计超过3天的任务，则通常意味着我们并不真正知道执行该任务涉及什么；做一些快速的研究。一旦一切分解完毕，将其总计，将结果加倍并将其作为估计。

如果我们不知道如何解决问题，足以做上述事情，而老板却垂下了头，以致我们不觉得自己可以在那里进行研究，那就尝试给老板一个大概的估计时间将带我们进行必要的研究，以充分理解问题，从而为他做出正确的估计。

最好的方法是尝试对所有主要子组件进行快速细分，例如

• 更新数据模型脚本(2个表中的3个项目)
• 更改输入屏幕(3个新输入)
• 检查输入(3个新输入)
• 更新数据。
• 显示结果等...
• 构建单元测试

对每一个都进行粗略的猜测，如果我们不能想到至少放两个小时，因为即使是最简单的物品也可能至少需要一个小时，但是2倍会带来不确定性。

至少我们会想到必须要做的所有项目，以便按要求在正确的数量级上进行。

根据过去的经验，将手指放在嘴里，舔一下，挥舞一下，然后编一个数字。然后加倍。

确实，它的重要经验很重要。我们可以想象该任务需要执行什么操作，并且知道执行此操作需要花费多长时间。将其翻倍以获取意外项目。这也是为什么我们从不要求初级程序员提供这种估算值的原因。

我无法想象完全无法做出估计的情况-通常情况下，我可以想象出多种情况，这些情况会导致项目的时间表截然不同，这取决于可以合理裁切的各种因素。向上。而且我也不想说谎-与老板一起做的最糟糕的事情就是化妆。

因此，我解释了每种可能性。当然，这仅适用于有理解力的老板，但如果老板如此无知或者愚蠢，以至于他拒绝听取完整的解释，则我们还有其他问题。

例如，这是我在最近实际上确实必须执行此操作的情况下所做的操作。

我正在研究的视频编码器x264实现了一种非常原始的隔行编码形式，其唯一选择是因为它非常易于实现。我们想实现这种编码的完整形式，但是我不知道在这种情况下为简化版本做出的许多假设会失败。

因此，我仔细考虑了可能需要更改的各个级别，并将估算范围定为一个范围-充其量来说，它可能已经差不多起作用了，但这是值得怀疑的。最糟糕的是，有很多东西需要更改。因此，我告诉老板，最好在这里假设最糟糕的情况，因为规范非常复杂，尽管不了解任何复杂性，但我怀疑鉴于程序中主要缺少相关代码，因此几乎没有实际上已经实现了复杂性。最后我是对的-所需的更改最终变得非常复杂，他们将项目外包给了对H.264隔行编码复杂性有更多专业知识的承包商。

我最近一直在阅读《敏捷评估和规划》，对它的推荐不够。

如果我被迫提供估计数而没有足够的时间来正确调查眼前的问题，那么我倾向于大量高估。该修复程序几乎总是比我想的要困难。如果我认为某件事需要一天，那么我说两天。如果我说要花一个小时，那么我要说一天。我想用这些注释来说明的是，除了最普通的任务(例如拼写错误)外，即使很小的代码更改也可能会爆发一整天。对于我认为可能需要一天或者更长时间的任何事情，我将估算加倍。我知道很难做到这一点。管理层希望数量少。我们想在其他开发人员面前显得聪明又有能力。另请参见Scotty Factory。

即使我们有QA团队成员来测试代码，我们也必须记住，测试代码也是工作。确保将其纳入任何估算。我已经看到很多开发人员没有进行评估。

如果我们确实需要非常快速的估计，则可以对每个任务进行1-2天或者更短的工作分解结构，并在此之后通过提供最小和最大估计值来估计每个任务。

最小值和最大值的总和指定整个任务的时间间隔。这会给老板有关风险的信息，这总是非常有用的。

我们将获得一些时间间隔，例如12-15天或者5-30天比16天有效，而不是提到的间隔。

史蒂夫·麦康奈尔(Steve McConnel)的《软件评估》(The Estimation：Demystifying the Black Art)一本好书可能对我们有用。

我通常将任务分解为几部分，但我不会在不到半天的时间内估计出这些事情。只要在分解后至少有5到6个特征，我发现错误会在大多数情况下使自身平衡(某些任务需要不到一个小时的时间，依此类推)

当然，一定程度的舒适度所需的最小时间划分和件数根据问题域的不同而有所不同，至少5或者6个半天的块似乎适合我最近被问到的问题，但是需要每几个月进行一次审核。

当我被要求代表其他人进行估算时，我会反抗多一点，并采用慷慨的填充系统进行类似的练习(如上所述，" double and add x"可能是一个很好的近似值)

因素＃1是未知数，而我们是正确的，我们不可能一无所知。但是，我们通常会知道一些主要问题，当时没人能为我们回答。

因素2是手头上的工具和资源的感知难度和可用性。

结果=大约两倍于估计

• 将任务分解为多个部分，并为每个部分分配时间
• 以每天不少于1/2的单位工作。这将防止微调度
• 项目估算的最大问题是估算不足。如果我们对任务了解得很清楚并且几乎可以看到代码，则将任务的权重加1. 如果存在某些不确定性或者任务需要未知的技术，则将其乘以较高的因数，具体取决于不确定性的程度
• 不必太担心每个零件的准确性。错误往往会被抵消，因为真正重要的是总持续时间

总是有一个很好的备用方法，那就是采用乐观的时间尺度并将其乘以PI。比预期更多地工作！

除了必要的细目分类之外：我从Pragmatic程序员那里学到的一个建议是要在15周内估算出几周的时间，而在8周内估算出数个月的时间；这样单位就可以反映估算的准确性。在30周内要非常小心。

我们也可以根据已经完成的类似任务进行估算。

要以正确的数量级进行估算，我们需要：

• 没有为所需功能引入新技术或者框架；
• 在纯粹的开发时间和开发人员(以及客户和测试人员的可用性)中分开估计。
• 获得有关我们先前估计的反馈；
• 在安全估算范围内的特征尺寸(不是2倍大，而人数增加了2倍)
• 稳定的开发团队。
• 没有项目启动开销。
• 只估计自己做的工作。

考虑一个数字，将其加倍然后再加倍(即，第一个突然出现在我们脑海中的数字的四倍)

当老板说"一个项目要完成多长时间"时，他指的是项目完成并向用户实时部署的时间。程序员自然会只考虑完成编程所需的时间(以物理方式输入问题的解决方案的时间)，因此我们通常会估计不足。

经验法则是：

"第一个数字"是指我们认为我们需要根据刚刚描述的任务范围完成任务的天数。 (但是，当然，我们还没有被告知一切)。

第一个倍数是在向老板提供第一个演示/原型后需要额外的时间来重新编码，他说："很好，很好。但是我们可以添加..."

第二个倍数是重新编码达到正确的生产标准所需的时间。

第三个倍数是测试，文档编制和部署的时间，以及我们需要进行的所有其他管理工作，才能真正实现并投入使用。

第四个倍数是我们遇到上述情况的偶然性。

这应该给我们一个安全的估计。当然，我们应该坚持进行更彻底的计划和评估。

我相信答案总是"六到八个星期"。

"六到八周"的效果非常好，另一件事基于数据模型。

想象一下应用程序所需的数据库表(或者类似数据库)的数量，再乘以我们需要为每个表编码模型，CRUD，UI等的天数，并在此基础上增加30％至50％的时间那。