你是否夸大了预计的项目完成date？

如果是这样的话多less？

我倾向于夸大一点，因为我可以过于乐观。

霍夫斯塔德定律 ：任何计算机计算都将花费你想象的时间的两倍，甚至当你考虑霍夫斯塔德定律时也是如此。

如果你根据过去的经验夸大你的估计，试图弥补你固有的乐观，那么你不是在膨胀。你正在尝试提供一个准确的估计。不过，如果你膨胀，你总是会有绒毛的时间，那就不是那么好。

哦，是的，我已经学会总是把我最初的估计乘以二。这就是为什么FogBUGZ的基于证据的调度工具非常有用。

任何要求程序员估算粗粒度特征时间的组织都已经基本上被打破了。

步骤来破解：

聘请技术计划经理。如果需要的话，开发者可以将这些人加倍。
将任何function请求，更改请求或错误都放入数据库中。（我的组织使用的Trac不完全吸引）。
让您的项目经理将这些请求分解成每个需要一周或更短时间的步骤。
在每周一次的会议上，您的项目经理会决定他们当周想要完成哪些票（可能需要市场营销等方面的投入）。他们把这些门票分配给开发者。
开发者尽可能多地完成他们分配的票据。和/或，他们与首长们讨论他们认为任务持续一周以上的任务。根据需要调整门票，拆分，重新分配等。
代码每周都会被写入并检查。 QA总是有事情要做。优先级最高的更改首先完成。市场营销人员确切地知道什么是pipe道，何时。最终：
您的公司在软件项目20％的成功率的右侧。

这不是火箭科学。关键是步骤3.如果市场营销希望看起来复杂一些，那么您的PM（开发人员的投入）会弄清楚第一步将需要不到一周的时间。如果PM不是技术性的，所有的都会丢失。

这种方法的缺点：

当营销人员问“获得[X]需要多长时间？”，他们没有得到估计。但是我们都知道，他们也都知道，他们之前的估计是纯粹的虚构。至less现在他们每个星期都能看到证据正在被处理。
作为开发者，我们每周工作的select较less。这是毫无疑问的。有两点，首先，好的团队会让开发人员决定要分配什么样的门票。其次，海事组织，这实际上使我的生活更美好。

没有比在1个月的时间里认识到的那么令人沮丧，我所给出的2个月的估计是绝望的不足，但是不能改变，因为它已经在官方的营销文献中。要么通过改变我的估计，冒着不好的评论和/或错过我的奖金，或者我做了很多无报酬的加class，来剥夺更高的职位。我意识到很多加class并不是坏开发商的标志，也不是一个“激情”的标志，而是一种有毒文化的产物。

是的，很多这些东西都被XP（“敏捷”，SCRUM等等）覆盖，但并不是那么复杂。你不需要一本书或一个顾问去做。你只需要公司的意志。

Scotty规则：

让你最好的猜测
取整到最接近的整数
双重四倍（谢谢亚当！）
增加到更高一级的计量单位

例：

你认为这将需要3.5小时
四至四小时
四倍到16个小时
转移到16天

TA-DAA！当你在不到8天的时间里完成工作，你就是个奇迹工人。

通常是的，但我有两个策略：

总是提供一个范围的估计（即1d-2d），而不是一个单一的数字。数字之间的差异告诉项目经理一些关于你的信心，并允许他们更好地计划。
使用FogBugz的“基于证据的计划 ”或个人电子表格等方式，将您的历史估计值与实际使用时间进行比较。这会给你一个比总是翻倍的更好的主意。不仅仅是因为加倍可能还不够！

我可以在3-6周内回答这个问题。

这不是所谓的“膨胀” – 这叫做“使它们变得更加逼真”。

采取你认为合适的估计。然后加倍。

不要忘了你（一名工程师）实际上是在理想时间（scrum term）估算的。

而pipe理工作在实时。

不同之处在于，理想的时间是没有中断的时间（每次中断之后30分钟热身）。理想的时间不包括会议时间，午餐时间或普通聊天等。

考虑到所有这些，理想的时间将趋于实际的时间。

示例：预计时间40小时（理想）pipe理层将假定为1周实时。

如果您将这40小时转换为实时：

假设每天开一次会议（持续1小时）
每天一顿午餐（1小时）
加上20％的开销，可以聊聊天浴室rest时间得到科菲等。

8小时的一天现在是5个小时的工作时间（8 – 会议 – 午餐 – 热身）。
时间80％效率=每天理想时间4小时。

这40小时的理想将需要80小时实时完成。

柯克：斯科特先生，你总是把你的维修估计乘以四倍吗？

Scotty ：当然可以，先生。我还能如何保持我作为奇迹工作者的声誉？

一个好的经验法则是估计需要多长时间，并且再次增加1/2以覆盖以下问题：

这些要求将会改变
你会被拉到另一个项目，以快速修复
下一个桌子上的新人需要帮助
重构项目的一部分所需的时间，因为你find了一个更好的方式去做事情

<偷偷摸摸>
不要夸大项目的估算，而要单独扩大每项任务。上司很难以这种方式挑战你的估计，因为谁会在几分钟之内与你争论。
</偷偷摸摸>

但是，严肃地说，通过使用EBS，我发现人们在估计小任务方面通常要比大规模任务好得多。如果你在4个月的时间估计你的项目，可能会在7个月前完成。或者它可能不会。如果你的任务估计是35分钟，那么通常是正确的。

FogBugz的EBS系统向您显示了您的估计历史的图表，并且根据我的经验（同时查看其他人的图表），在估计短期任务时，人们确实更好。所以我的build议是从做你的项目的巫术倍增作为总数，并开始把它们分成许多非常小的任务，你估计更好。

然后把整个事情乘以3.14。

很大程度上取决于你想获得多less详细信息 – 但是额外的“缓冲”时间应该基于风险评估 – 在任务级别，在这里你可以在不同的缓冲时间内进行：高风险：50％到100％中等风险： 25％至50％低风险：10％至25％（全部取决于以前的项目经验）。

风险领域包括：

需求覆盖率的估计（＃1风险区域在devise和需求层面缺less组件）
正在使用的技术知识
您的资源的知识/信心
外部因素，如影响您的其他项目，资源变化等

因此，对于包含组件A的给定任务（或任务组），初始估值为5天，根据需求覆盖率将其视为高风险 – 您可以添加50％至100％

六个星期。

行业标准：每个要求将需要六个星期。有些会更长，有些会更短，一切平均到最后。

而且，如果你等待足够长的时间，它不再成为一个问题。我不能告诉你我已经经历了多less次，只是为了减less项目/function。

我不会说我夸大了他们，尽pipe我根据过去的经验设定了更现实的期望。

你可以用两种方法来计算项目的持续时间 – 一是计算所有涉及的任务，并计算每个项目需要多长时间，包括延误，会议，问题等等。这个数字总是看起来非常短，这就是为什么人们总是说事像“加倍”。在交付项目的一些经验之后，只要简单地看一下规格需要多长时间，就可以很快得知，而且总是会是第一种方法达到的数字的两倍。

为debugging和testing添加特定的缓冲时间比仅增加总时间更好。另外，通过花时间预先确定工作内容，您可以更容易地进行评估（也可能是编码）。

如果有的话，记下所有的估计值，并将它们与实际完成时间进行比较，以了解你倾向于低估多less，以及在什么条件下。这样你可以更准确地“膨胀”。

我不会说我夸大了他们，但我确实喜欢使用模板来处理可能涉及项目的所有可能的任务。

你发现列表中的所有任务都不适用于所有的项目，但是列出一个列表意味着我不会让任何任务从这些漏洞中溜走，而我忘了给他们一些时间。

当你发现新的任务是必要的，将它们添加到您的列表。

这样你会有一个现实的估计。

我倾向于乐观，所以我倾向于低估。但我知道我的自我，所以我倾向于额外增加15-20％。

我也跟踪我的实际情况和我的估计。并确保所涉及的时间不包括其他中断，请参阅我的SO问题的接受答案，如何恢复stream量。

HTH

干杯

除非您在原来的估算之前确实完成了您的项目，否则我不会再要求额外的估算时间。如果你习惯于在原来的估计时间之前总是完成项目，那么项目负责人就会变得明智起来，并且期待更早。

你的估计是基于什么？

如果它们只是基于一个模糊的直觉，它需要多less代码，多长时间才能写出代码，那么你最好把它们填充到一个LOT中，以解决你没有想到的子任务，通信和同步开销和意想不到的问题。当然，那种估计几乎毫无价值。

OTOH，如果您的估计是基于具体的知识，即上一次用特定的技术和开发人员数量来完成这个范围的任务，那么通胀就不是必须的，因为上面的通货膨胀因素应该已经包含在过去的经验。当然，可能会有一些新的因素影响你目前无法预见的项目 – 这样的风险certificate了一定数量的附加填充。

这就是敏捷团队评估故事点任务（一个任意的和相对的测量单位），然后随着项目进度追踪团队速度（每天完成的故事点数）的原因之一。有了这些数据，你可以在理论上准确地计算出你的完成date。

我把我的最坏的情况，加倍，这还不够。

哦，是的，从长期的艰苦经验中得出的一般规则是给项目最好的时间估计，加倍，这就是实际需要多长时间！

我们必须，因为我们的白痴经理总是减less他们没有任何理由。当然，一旦他意识到我们这样做，我们就陷入了军备竞赛。

我完全希望成为第一个提交两年预算的人来改变对话的措词。

叹气。

很多人说，这是经验和风险之间的微妙平衡。

总是从可分解的项目中分解项目开始，事实上，你可以很容易想象自己在同一天开始和结束
当你不知道该怎么做时（比如第一次），风险就会上升
当你的风险上升的时候，那就是你以最佳猜测开始的地方，然后把它加倍，以涵盖一些意想不到的情况，但请记住，你是在一小块项目上做的，而不是整个项目本身
当有一个你不能控制的因素时，风险也会上升，比如input或者图书馆的质量，它似乎可以做你想做的一切，但是你从未testing过
当然，当你获得某项特定任务的经验时（比如将模型连接到数据库），风险就会降低
总结一切，以获得您的小计…
然后，在整个项目中，所有的答案/文件/你会等待的时间总是会增加20-30％（这个数字会根据你的公司而变化），会议我们总是会忘记，项目等……这就是我们所说的人/政治因素
再加上另外30-40％的数据，说明你通常自己做的testing中的testing和更正，比如你什么时候先把它展示给老板或者客户

当然，如果你仔细观察这一切，结果你可以用神奇的“双重”公式来简化它，但不同之处在于，你将能够在紧迫的期限内知道你能挤压什么，你能承诺，什么是危险的任务，如何build立你的时间表与重要的里程碑等等。

我敢肯定，如果你注意每个纯粹的“编码”任务花费的时间，并将其与你的风险估计相比较，你就不会太离谱。问题在于，想想所有的小细节并不容易，而且要做到现实（而不是乐观），而不是任何障碍。

我说什么时候可以完成。我确信，变更请求是通过一个新的估计而不是“是的，我可以做到”。没有提到它将需要更多的时间。请求更改的人不会认为这需要更长的时间。

我总是加倍估计，原因如下：

1）墨菲定律的缓冲。有些东西总是会出现问题，你无法解释。

2）低估。程序员总是认为事情很容易做到。 “哦，是的，只需要几天时间。”

3）讨价还价的空间。上层pipe理者总是认为时间表可以缩短。 “让开发人员更努力！” 这可以让你给他们想要的东西。当然，过度使用（不止一次）会训练他们认为你总是高估自己。

注意：最好在项目进度结束时放置缓冲区，而不是每个任务。不要告诉开发者缓冲区存在，否则帕金森定律（扩展工作以填补可用时间）将会生效。有时候我会告诉上级pipe理部门，缓冲区是存在的，但显然我不会给他们理由3的理由。这当然取决于你的老板相信你是多么的诚实。

不满足，过度交付。

这里有很多人在说估计和加倍（有时再翻一番）。其他人则说使用基于证据的调度（al la Joel）。

当我估计一个项目时，每个任务有四个组件：

我最好的猜测要多久。
不确定性（风险） – 就像也许有一些东西（一个已知的/未知的未知的东西）不在规格中，会使时间加倍。
Bug修复
应急时间

对于＃1，我使用最现实的估计，我可以。
对于＃2，我决定风险的可能性，然后乘以＃1得到一个调整的估计，
对于＃3和＃4，我将调整后的估计值乘以20％，并成为每个值。

因此，对于任何任务，最终的总数是原来估计的140％或更多。

对于整个项目，将意外事件和错误修复集中分解为两个独立的任务，并随着项目的进展而吃掉。

当然，这不包括我通常使每个任务的总值相等的testing。