霍夫斯塔特定律：任何计算项目都需要比您认为的时间长两倍 - 即使您考虑了霍夫斯塔特定律。

如果你根据过去经验膨胀估计，试图弥补你内在的乐观主义，那么你不是在夸大估计。你是在试图提供准确的估计。但是，如果你膨胀估计，以便总有松弛时间，那就不太好了。

哦，是的，我学会了将我的初始估计乘以二。这就是为什么FogBUGZ的“基于证据的进度安排”工具非常有用。

任何要求程序员为粗粒度特性估算时间的组织基本上是有缺陷的。

解除断裂的步骤：

1. Hire technical program managers. Developers can double as these folks if needed.
2. Put any feature request, change request, or bug into a database immediately when it comes in. (My org uses Trac, which doesn t completely suck.)
3. Have your PMs break those requests into steps that each take a week or less.
4. At a weekly meeting, your PMs decide which tickets they want done that week (possibly with input from marketing, etc.). They assign those tickets to developers.
5. Developers finish as many of their assigned tickets as possible. And/or, they argue with the PMs about tasks they think are longer than a week in duration. Tickets are adjusted, split, reassigned, etc., as necessary.
6. Code gets written and checked in every week. QA always has something to do. The highest priority changes get done first. Marketing knows exactly what s coming down the pipe, and when. And ultimately:
7. Your company falls on the right side of the 20% success rate for software projects.

这并不是火箭科学。关键在于步骤3。如果市场想要看起来很复杂的东西，你的PMs（带有开发者输入）找出了第一步是少于一周的时间。如果PMs不具备技术能力，则一切都会丧失。

这种方法的缺点：

1. When marketing asks, "how long will it take to get [X]?", they don t get an estimate. But we all know, and so do they, that the estimates they got before were pure fiction. At least now they can see proof, every week, that [X] is being worked on.
2. We, as developers, have fewer options for what we work on each week. This is indubitably true. Two points, though: first, good teams involve the developers in the decisions about what tickets will be assigned. Second, IMO, this actually makes my life better.

没有什么比在一个月的时间内意识到我所给出的两个月的估计是无望不足的更使人气馁了，但这已经写入了官方的营销资料之中已经无法更改了。要么我修改我的估计，冒着得到差评和/或错过奖金的风险而得罪上级，要么我需要做很多无薪加班。我意识到很多加班并不是一个糟糕的开发人员，也不是一个“热情”的开发人员的标志，而是有毒文化的产物。

是的，很多这样的东西都被（不同的）XP，"敏捷"，SCRUM等所覆盖，但实际上并不那么复杂。你不需要一本书或咨询师来做到这一点。你只需要企业意愿。

斯科蒂规则：

• make your best guess
• round up to the nearest whole number
• double that quadruple that (thanks Adam!)
• increase to the next higher unit of measure

例子:

• you think it will take 3.5 hours
• round that to 4 hours
• quadruple that to 16 hours
• shift it up to 16 days

塔达！当你在少于8天内完成任务时，你就是一个奇迹的创造者。

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

1. Always provide estimates as a range (i.e. 1d-2d) rather than a single number. The difference between the numbers tells the project manager something about your confidence, and allows them to plan better.
2. Use something like FogBugz Evidence Based-Scheduling, or a personal spreadsheet, to compare your historical estimates to the time you actually took. That ll give you a better idea than always doubling. Not least because doubling might not be enough!

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

它不叫“膨胀”——它叫“使它们在远程上看起来更现实。”

拿出您认为合适的估计数字，然后将其翻倍。

不要忘记，您（一位工程师）实际上是按照理想小时数（Scrum术语）进行估算的。

当管理人员在实际工时工作。

区别就在于理想时间是没有干扰的时间（每次干扰后有30分钟的热身）。理想时间不包括开会时间，午餐时间或正常的聊天时间等。

考虑到这一切，理想的时间将趋向于实际的时间。

Example: Estimated time 40 hours (ideal) Management will assume that is 1 week real time.

如果您将这40个小时转换成实际时间：

• Assume one meeting per day (duration 1 hour)
• one break for lunch per day (1 hour)
• plus 20% overhead for chit chat bathroom breaks getting coffie etc.

8 hour day is now 5 hours work time (8 - meeting - lunch - warm up).
Times 80% effeciency = 4 hours ideal time per day.

你的40小时计划将需要80个真实时间才能完成。

柯克：斯科特先生，您总是将维修估算乘以四吗？

Scotty：当然，先生。否则我怎么能保持我的奇迹工作者的声誉呢？

一个好的经验法则是估计所需时间，然后再增加1/2的时间来解决以下问题：

1. The requirements will change
2. You will get pulled onto another project for a quick fix
3. The New guy at the next desk will need help with something
4. The time needed to refactor parts of the project because you found a better way to do things

<sneaky>
Instead of inflating your project s estimate, inflate each task individually. It s harder for your superiors to challenge your estimates this way, because who s going to argue with you over minutes.
</sneaky>

但说真的，通过使用 EBS，我发现人们通常比较擅长估计小任务，而不是大任务。如果你将你的项目估计为 4 个月，很可能在完成之前需要 7 个月；或者可能不是。另一方面，如果你对任务的估计时间是 35 分钟，通常就会差不多。

FogBugz的EBS系统可以展示您的估算历史图表，从我的经验来看（同时查看了其他人的图表），人们确实更擅长估算短期任务。因此，我的建议是放弃将您的项目总结作为巫术乘法运算，并开始提前拆分成大量非常小的任务，这样您就能更好地估算任务了。

然后将整个东西乘以3.14。

A lot depends on how detailed you want to get - but additional buffer time should be based on a risk assessment - at a task level, where you put in various buffer times for: High Risk: 50% to 100% Medium Risk: 25% to 50% Low Risk: 10% to 25% (all dependent on prior project experience).

风险区域包括：

• est. of requirement coverage (#1 risk area is missing components at the design and requirement levels)
• knowledge of technology being used
• knowledge/confidence in your resources
• external factors such as other projects impacting yours, resource changes, etc.

因此，对于覆盖组件A的给定任务（或任务组），初始估计为5天，根据需求覆盖范围判断属于高风险 - 您可以增加50％至100％。

六周。

行业标准：每个请求需要六周时间，有些请求可能需要更长时间，有些可能需要更短时间，但最终平均时间是六周。

此外，如果您等待足够长的时间，它将不再成为问题。我无法告诉您有多少次我遇到过这种紧急情况，最终项目/功能都被削减了。

我不会说我夸大了它们，而是我会尝试根据过去的经验设定更现实的期望。

你可以用两种方法计算项目期限 - 其一是计算所有相关任务所需时间，考虑延迟、会议、问题等因素。这个时间通常看起来很短，这就是为什么人们总是说像“倍数”这样的话。在交付项目方面积累一些经验后，你会很快地能够通过简略查阅规格书来判断所需时间，而且通常会是第一种方法得出时间的两倍...

为调试测试等添加特定的缓冲时间比仅仅扩大总时间更好。此外，通过花时间来详细规划工作的各个部分，你将使估计本身变得更容易（可能编码也是如此）。

如果可以的话，要记下所有的估算并将其与实际完成时间进行比较，以了解自己倾向于低估多少以及在什么情况下低估。这样你就可以更准确地“膨胀”估算。

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

你会发现你列表中的任务并不都适用于所有的项目，但有个列表意味着我不会漏掉任何任务，因为我会在安排时间时记得它们。

当您发现有新的任务是必要的时候，把它们加入到您的清单中。

这样您将得到一个实际的估计。

我倾向于乐观地看待可实现的事情，因此我倾向于低估。但我知道这一点，所以我倾向于再增加15-20%。

我也会跟踪我的实际情况和我的估计情况。并确保所涉及的时间不包括其他干扰，参见我的 SO 问题的已接受答案，如何重新进入状态。

HTH: 希望能帮助到你 (Xīwàng néng bāngzhù dào nǐ)

干杯 (Gān bēi)

除非您实际上在原定估计时间之前完成了项目，否则我不会将额外估计的时间称为“过高”。如果您习惯于始终在原定估计时间之前完成项目，则项目领导人将变得聪明并期望提前完成。

你的估计是根据什么基础的？

如果它们只基于对需要多少代码和编写代码需要多长时间的模糊直觉，那么最好要非常充裕地进行填充，以解决您没有考虑到的子任务、通信和同步开销以及意外问题。当然，这种估算几乎是没有用的。

另一方面，如果你的估计是基于对上次使用相同技术和开发人员完成同等规模任务所需时间的具体了解，那么通货膨胀就不是必要的，因为上述通货膨胀因素应该已经包含在过去的经验中了。当然，可能会有新因素对当前项目产生影响，你无法预见 - 这些风险会为某些额外的填充提供合理的理由。

这就是敏捷团队使用“用户故事点”（一种任意相对的测量单位）估算任务，然后随着项目的进行跟踪团队的速度（每天完成的用户故事点）的部分原因。通过这些数据，理论上可以准确地计算出完成日期。

我想到最糟糕的情况，乘以二，仍然不够。

做事要低调，但表现要超出预期。

哦，是的，从漫长而艰苦的经验中得出的一般规律是给项目最好的时间估计，将其加倍，那就是它会 实际 进行多长时间！

我们必须这样做，因为我们愚蠢的经理总是毫无理由地减少它们。当然，一旦他意识到我们在做这件事，我们就陷入了一场军备竞赛……

我完全期望成为第一位提交两年修改对话措辞的人。

叹息。

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

1. 始终要从可管理的部分开始分解项目，实际上是切成容易想象自己在同一天开始和结束的部分。

2. 当你不知道如何做某件事情时（比如第一次），风险会增加。

3. 当你的风险增加时，你应该从你最好的猜测开始，然后把它翻倍以涵盖一些意外，但记住，你只是在项目的一小部分上这样做，而不是整个项目本身。

4. 当存在你无法控制的因素，比如输入的质量或者那个似乎可以满足你所有需求但你从未测试过的库时，风险也会增加。

5. 当然，当您在特定任务上获得经验（例如将您的模型连接到数据库）时，风险会降低。

6. 把所有的加起来来得到你的小计...

7. 然后，在整个项目中，始终要增加大约20-30％（这个数字将根据您的公司而变化），以考虑您将等待的所有答案/文档/批准，我们总是忘记的会议，项目期间的想法变化等等...这就是我们所说的人类/政治因素。

8. 再加上另外30-40％，这些涉及到测试和修正，并且超出了您通常自己进行的测试......比如当您第一次向上司或客户展示时。

当然，如果您看到这一切，最终可以通过神奇的“加倍”公式简化它，但不同之处在于您将能够知道您可以在紧迫的截止日期内挤出什么，您可以承诺什么，哪些任务是危险的，如何建立具有重要里程碑的时间表等等。

我相信，如果您记录每个纯粹的“编码”任务所花费的时间，并将其与其风险评估相比较，您的估计就不会有太大偏差。问题在于，很难考虑到所有细节，并对您能够无障碍地完成的任务进行真实而非乐观的评估。

我说我何时可以完成。我确保更改请求后跟新的评估而不是没有提到需要更多时间的“是的，我可以这样做。”请求更改的人不会假设需要更长时间。

当然，如果不添加25-50％，你将成为白痴。

问题在于身旁的白痴不停地给出比你低25-50%的估计，而项目经理认为你蠢笨、慢吞吞或者故意拖延。

有没有人注意到项目经理似乎从不将估算与实际情况进行比较？

我总是将我的估计翻倍，原因如下：

1）莫菲定律的缓冲。总会有一些你无法预料的地方出错。

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

3）讨价还价空间。高管们总是认为时间表可以缩短。“让开发人员加倍努力！”这样您就可以满足他们的要求。当然，过度使用此方法（超过一次）会让他们认为您总是高估时间。

注：最好将缓冲区放在项目进度表的末尾，而不是每个任务中使用。而且，千万不要告诉开发人员缓冲区的存在，否则帕金森定律（工作总会扩大以填补可用时间）会开始生效。有时，我会告诉上级管理人员缓冲区的存在，但显然我不会给他们提供第三个理由作为理由。当然，这取决于你的上司对你的诚实程度有多少信任。