您是否夸大了预计的项目完成日期？

Question

如果是这样，为什么？多少？

我倾向于夸大我的一点因为我可能过于乐观。

Answer 1

霍夫施塔特定律：任何计算项目都会花费你想象的两倍 - 即使你考虑到霍夫施塔特定律。

Answer 2

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

Answer 3

哦，是的，我已经学会了将我的初步估计乘以2。这就是FogBUGZ's Evidence-Based Scheduling工具非常有用的原因。

Answer 4

任何要求程序员估算粗粒度特征时间的组织都会被彻底打破。

破裂的步骤：

1. 聘请技术项目经理。如果需要，开发人员可以像这些人一样加倍。
2. 将任何功能请求，更改请求或错误立即放入数据库中。（我的组织使用Trac，这并不完全糟糕。）
3. 让您的PM将这些请求分解为每个需要一周或更短时间的步骤。
4. 在每周一次的会议上，您的PM决定他们希望在那一周完成哪些门票（可能需要营销方面的投入等）。他们将这些门票分配给开发人员。
5. 开发人员尽可能多地完成指定的门票。和/或，他们与PM讨论他们认为持续时间超过一周的任务。根据需要调整，拆分，重新分配门票等。
6. 每周都会编写代码并进行检查。 QA总是有事可做。优先级最高的更改首先完成。市场营销人员确切知道管道即将发生什么，以及何时。最终：
7. 您的公司属于软件项目成功率20％的右侧。

这不是火箭科学。关键是第3步。如果市场营销需要看起来很复杂的东西，那么你的PM（有开发者输入）就会知道第一步是不到一周。如果PM不是技术人员，则全部丢失。

这种方法的缺点：

1. 当市场营销问道时，“获得[X]需要多长时间？”，他们没有得到估计。但我们都知道，他们之前得到的估计也是纯粹的虚构。至少现在他们每周都能看到[X]正在进行的证据。
2. 作为开发人员，我们每周工作的选项较少。这无疑是真的。但有两点：首先，优秀团队让开发人员参与决定将分配门票的决定。第二，IMO，这实际上让我的生活更美好。

没有什么比在1个月大的时候意识到的那样令人沮丧的是，我给出的2个月的估计是绝对不足的，但不能改变，因为它已经在官方营销文献中。我要么通过改变我的估计来惹恼上级，冒着糟糕的评论和/或错过我的奖金，要么我做了很多无偿的加班。我已经意识到很多加班不是一个糟糕的开发者的标志，或者是一个“热情的”标志 - 它是有毒文化的产物。

是的，很多这些东西都包含在（各种）XP，“敏捷”，“SCRUM”等中，但它并不是那么复杂。您不需要书籍或顾问来完成它。你只需要企业意愿。

Answer 5

斯科蒂规则：

• 做出最好的猜测
• 向上舍入到最接近的整数
• 加倍四倍（感谢Adam！）
• 增加到下一个更高的计量单位

示例：

• 您认为需要3.5小时
• 将其缩短至4小时
• 四倍至16小时
• 将其提升至16天

的Ta-DAA！当你在不到8天的时间内完成它时，你就是一个奇迹工作者。

Answer 6

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

1. 始终将估算值作为范围（即1d-2d）而不是单个数字。数字之间的差异告诉项目经理一些关于你的信心，并允许他们更好地计划。
2. 使用类似FogBugz' Evidence Based-Scheduling或个人电子表格的内容，将您的历史估算值与实际拍摄时间进行比较。这会给你一个更好的想法，而不是总是加倍。尤其是因为加倍可能还不够！

Answer 7

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

Answer 8

它不被称为“膨胀” - 它被称为“使它们远程逼真”。

Answer 9

不要忘记你（工程师）在理想时间（scrum term）实际估计。

管理层在实时工作。

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

考虑所有这些因素，理想的工作时间将趋于实际时间。

实施例：     预计时间40小时（理想）     管理层将假设实时为1周。

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

• 假设每天一次会议（持续时间1小时）
• 每天午餐一小时（1小时）
• 加上20％的开销用于聊天浴室休息，以获得coffie等。

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

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

Answer 10

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

Answer 11

Kirk ：斯科特先生，您是否总是将修理预算乘以四倍？

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

Answer 12

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

1. 要求会改变
2. 您将进入另一个项目进行快速修复
3. 下一桌的新人需要帮助
4. 重构项目部分所需的时间，因为你找到了更好的做事方式

Answer 13

＆lt; sneaky＆gt;
不要夸大项目的估算，而是单独夸大每项任务。你的上司很难以这种方式挑战你的估计，因为谁会在几分钟内与你争论。
的＆LT; /偷偷摸摸＆GT;

但严重的是，通过使用EBS，我发现人们在估算小型任务时通常比大型任务要好得多。如果你估计你的项目在4个月，它可能在完成之前7个月;或者它可能不会。另一方面，如果你对任务的估计是35分钟，那通常是正确的。

FogBugz的EBS系统向您显示您的估计历史图表，根据我的经验（也查看其他人的图表），人们在估算短期任务方面确实要好得多。所以我的建议是从你的项目的伏都教乘法转换为总数，并开始将它们预先分解为许多非常小的任务，你可以更好地估算。

然后将整个事物乘以3.14。

Answer 14

很大程度上取决于您想要获得的详细程度 - 但额外的“缓冲”时间应该基于风险评估 - 在任务级别，您可以在其中放置以下各种缓冲时间： 高风险：50％至100％ 中等风险：25％至50％ 低风险：10％至25％（均取决于之前的项目经验）。

风险领域包括：

• EST。需求覆盖范围（＃1风险区域缺少设计和要求级别的组件）
• 正在使用的技术知识
• 对您资源的了解/信心
• 外部因素，如影响您的其他项目，资源变化等。

因此，对于涵盖组件A的给定任务（或任务组），初始est为5天，并且根据需求覆盖率被认为是高风险 - 您可以添加50％到100％

Answer 15

六周。

行业标准：每个请求需要六周时间。有些会更长，有些会更短，最后一切都是平均的。

此外，如果你等待足够长的时间，它就不再成为一个问题。我不能告诉你我多少次经历过这次火爆只是为了让项目/功能被削减。

Answer 16

您可以通过两种方式计算项目持续时间 - 一种是计算所涉及的所有任务，并计算每项任务需要多长时间，考虑延迟，会议，问题等。这个数字看起来总是很短暂，这就是为什么人们总是说'加倍'之类的东西。在完成项目交付的一些经验后，您将能够非常快速地讲述，只需简单地查看一个规范需要多长时间，并且总是将它的数量增加一倍......第一种方法...... p>

Answer 17

我不会说我夸大了他们，因为我试图根据过去的经验设定更切合实际的期望。

Answer 18

为调试和测试之类的事情添加特定的缓冲时间比仅仅增加总时间更好。此外，通过预先花时间来真正规划工作的各个部分，您将使估算本身更容易（也可能是编码）。

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

Answer 19

这是敏捷团队在story points（任意和相对测量单位）中估算任务的部分原因，然后随着项目的进展跟踪团队的速度（每天完成的故事点）。有了这些数据，您可以在理论上准确计算完成日期。

Answer 20

您的估算基于什么？

如果它们只是基于对它需要多少代码以及编写代码需要多长时间的模糊直觉，那么你最好填充它们以考虑你没想到的子任务，通信和同步开销，以及意外问题。当然，无论如何，这种估计几乎一文不值。

OTOH，如果您的估算基于具体知识，即上次用给定技术和开发人员数量完成该范围的任务需要多长时间，那么通货膨胀不应该是必要的，因为上面的通胀因素应该已经被包括在过去的经历中。当然，可能会出现一些新的因素，这些因素对当前项目的影响是无法预见的 - 这种风险证明了一定数量的额外填充。

Answer 21

我不会说我给他们充气但是我喜欢使用模板来处理项目中可能涉及的所有可能的任务。

您发现并非列表中的所有任务都适用于所有项目，但拥有一个列表意味着我不会让任何任务漏掉，而我忘记留出一些时间。

当您发现有必要执行新任务时，请将它们添加到列表中。

这样你就可以得到一个真实的估计。

我倾向于对可实现的目标保持乐观，所以我倾向于估计偏低。但我知道关于我的自我，所以我倾向于额外增加15-20％。

我还跟踪我的实际情况与我的估计值。并确保所涉及的时间不包括其他中断，请在how to get back in the flow上查看我的SO问题的接受答案。

HTH

欢呼声

Answer 22

我采取最糟糕的情况，加倍，但仍然不够。

Answer 23

除非您在原始估算之前确实完成项目，否则我不会将项目的额外估计时间称为“虚增”项目。如果你习惯于在原定的预计时间之前完成项目，那么项目负责人就会越来越明智并期待它。

Answer 24

我说什么时候能完成它。我确保更改请求的后续操作是一个新的估算，而不是“是的，我能做到”。没有提到它将需要更多的时间。请求更改的人不会认为需要更长时间。

Answer 25

由于以下原因，我总是加倍估算：

1）Murphy定律的缓冲区。在某些你无法解释的地方总会出现问题。

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

3）讨价还价空间。高层管理人员总是认为可以缩短进度。 “只是让开发人员更加努力！”这允许您给他们想要的东西。当然，过度使用（不止一次）将训练他们假设你总是高估。

注意：最好将缓冲区放在项目计划的末尾，而不是每个任务。并且永远不要告诉开发人员缓冲区存在，否则帕金森定律（工作扩展以填补其完成的可用时间）将生效。有时我告诉上层管理人员缓冲区存在，但显然我不会将理由＃3作为理由。这当然取决于你的老板多么信任你是真实的。

Answer 26

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

1. 总是首先将项目分解为可管理的部分，事实上，您可以轻松地想象自己在同一天开始和结束

2. 当你不知道如何做某事时（比如第一次），风险就会上升

3. 当你的风险上升时，那就是你从最佳猜测开始的地方，然后加倍来覆盖一些意想不到的事情，但请记住，你是在项目的一小部分，而不是整个项目本身

4. 当你有一个无法控制的因素时，风险也会上升，比如输入的质量或那个看起来它可以做你想做但你从未测试过的那个库

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

6. 总结一切以获得小计......

7. 然后，在整个项目中，总是添加大约20-30％（这个数字将根据您的公司而变化）所有答案/文件/等待您将等待，我们总是忘记的会议，项目期间理念的变化等......这就是我们所说的人/政治因素

8. 再次添加另外30-40％用于测试和更正的帐户，这些测试和更正不属于您通常自己做的测试...例如，当您首次向老板或客户展示时/ p>

当然，如果你看一下这一切，最终你可以用神奇的“双倍”公式来简化它，但区别在于你将能够知道你可以在紧迫的期限内挤出什么，你可以承诺什么，有什么危险的任务，如何用重要的里程碑建立你的日程安排等等。

我很确定如果你注意到每个纯粹的“编码”任务花费的时间，并将其与你的风险估计相比较，你就不会那么遥远。问题是，要想到前面的所有小块并且在没有任何障碍的情况下能够做到的事情是现实的（而不是乐观的）并不容易。

Answer 27

承诺不足，过度交付。

Answer 28

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

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

叹息

Answer 29

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

Answer 30

我不会“膨胀”，因为我最不可能解决最糟糕的情况。根据项目的复杂程度，我可能会更多地考虑到不可预见的情况。

由于我的项目通常不会达到“最坏情况”状态，我通常在预计时间之前完成，但足够接近以达到目的。考虑到做得太早或太晚的选择，我每次都会提前做好。

Answer 31

我从未想过估计是不准确的，因为程序员无法估计编写代码所需的时间，但是因为他们估计只需要多长时间编写代码。会议，客户响应时间，测试，客户变更，业务规则修订等都无法估算。

当这些项目在开始时计算，并且项目估计在任务级别，而不是“哦，我认为这将花费... 7周！”然后估计通常是准确的。

所以，如果我填写，那是因为我碰巧知道这些项目没有被考虑，或者这些项目没有得到适当的计算。

Answer 32

是的，我给他们充气。但还不够。

Answer 33

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

当我估算一个项目时，每项任务有四个组成部分：

1. 我最好猜测需要多长时间。
2. 不确定性（风险） - 也许有一些东西（已知/未知的未知）不在规范中，会使时间加倍。
3. 错误修复
4. 意外时间

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

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

对于整个项目，突发事件和错误修复被收集到两个单独的任务中，并随着项目的进展而被收集。

当然，这不包括我通常做的测试等于每项任务的总价值。

Answer 34

我的估计通常非常准确（来自20年的经验），但我仍然经常夸大我的一点;在奖励时间方面，承诺不足和过度交付总是更好： - ）

但是，如果您的项目经理有价值（有些人不值得他们消耗的氧气，但我相信他们只占少数），那么您对估算的处理方式应该差别不大。

他们将根据您的实际情况跟踪您的估算值，并在将其输入项目计划之前使用该信息调整您的下一组估算值。这将使他们能够准确地了解您对某些任务的评估程度（我总是以UI，DBMS，中间件等类型和大小/复杂性为基础）。

然后，如果他们发现你不断低估UI任务，他们就会知道在下一次迭代中将它们搞砸。如果他们能够看到你正在为一些任务做好准备，那么他们就会知道减少你的估计。这具有随时间自动调整的优点。

说真的，有些人认为PM总是坐在他们的ars s（或者在美国的USofA屁股上），整天无所事事，但至少有一点工程和科学背后工作。我知道，在我恢复对代码切割的热情之前，我曾经是一个人。

Answer 35

我加50％。但是，如果我之前曾与客户合作过，那么这可能会增加一倍或更多，我知道他们希望在最后做出改变。我试图尽可能地预测未知......有时我会成功，有时会失败。

Answer 36

我记得在当前项目的开始时，当时的项目经理直接估计了6周的袖口！

我的眼睛刚从插座中伸出来！知道还有很多领域我们甚至不知道如何解决。这个人很资深，因为他有更多的“经验”

毋庸置疑，6周后规范仍在编写中，几乎没有任何代码被考虑过。

最终我们缩小了团队规模（仅限我！），最终取得了实际进展。 我很久以前就成了合同起草人如何准确估计的。

涉及两项主要技能。

第一次练习估算。没有什么比估计各种项目更好了 - 即使你不是项目经理，如果你弄错了也没关系 - 但是对你做的每个项目都要做一个内部评估（如果你这么做就好了）是项目经理）

第二次大多数项目井喷都是由项目依赖性造成的，事先确定这些项目对于了解哪些因素能够在项目失效时脱轨是至关重要的。

Answer 37

1. 计算您认为尽可能准确的估算值。
2. 加倍。
3. 引用结果，但添加“加或减25％”。

例如，如果您认为它应该需要6个工作日，则预测“12个工作日，正负3个工作日”。

Answer 38

在评估项目的前十分钟内，我通常会考虑初始时间跨度的250％左右。第一个100％用于我知道可以快速完成的事情，下一个100％是因为无法预料的事件而额外的，而最后一个额外的50％是“与其他人的沟通”。

似乎对我来说很好。

Answer 39

我的一位朋友曾告诉我他使用这种算法：

1. 估算
2. 以最大的时间单位表达它，而不会低于0.5
3. 我们称之为x（单位）
4. 结果为 2 * x + 2（单位）

Answer 40

Death March对此有一些很好的写作。

我最喜欢的是，当他说我们在一家公司玩的游戏之一是工程师将估计值增加一倍，然后管理和市场营销将其减少一半 - 工程师不应该告诉他应该加倍他的估计。 ＆LT;的笑容 /＆GT;

他提到的另一个游戏是当经理让你不断修改你的估计时，直到你到了他们一直想要的日期。我实际上没有这个问题，只要工程师被允许摆弄范围，实施细节，他们使用的第三方包，甚至可能是预算...只要营销/管理/工程设计最终都在同一页面上，而工程师并没有被迫人为地带来估算。

[编辑]哦，我差点忘了 - 还有另一种经典方法：* 2，+ 1。首先，将您的估计值乘以2，然后将您的计量单位增加一。如果你的诚实估计是3周，而不是6个月。 ＆LT;的恶笑容 /＆GT;

Answer 41

我的一般估计是guess * 2.5 + 1 week。

Answer 42

我不会夸大我的预算，我会填补它们！

Answer 43

当然，你是一个白痴，不要加25-50％

问题在于，你旁边的白痴一直在想出比你的估计低25-50％的估计，并且PM认为你是愚蠢/缓慢/摆动它。

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

Answer 44

两周。

行业标准：每个请求需要两周时间。有些会更长，有些会更短，最后一切都是平均的。

Answer 45

我采取相反的方法来看似最常见的态度，我尽量让我的估计尽可能准确，然后确保项目经理知道我没有填写我的估计。然后由他们来应用任何随机因素2或他们感觉舒服的东西。

当我给出估计时，我也想给出一些关于如何通过估算的指示。某种类型的价值范围从“我刚刚从我的屁股中掏出这个数字”到“我花了最后一周详细说明并列出了所有任务，对任何复杂或未知的整合进行原型设计并且估算是事实陈述” （不是常见的那个:)

这主要来自几个项目，似乎管理链中的每个人都在估算中添加了自己的小提琴因素，使得初始项目计划的时间比应有的长3倍。似乎遵循这些事情的是随机的马匹交易，它将项目时间缩短，而没有任何真正的参考办公室政治以外的任何东西。

我想这是你信任你估计的人多少，我真诚地相信你必须能够信任并对你的项目/产品经理100％诚实，并能够给予他们估计你真的相信是真实的。另一方面，他们必须是合理的，当你过度拍摄时，你的估计会谈论它并尝试改进你的估计而不只是咀嚼你一个新的。

Answer 46

我不惜一切代价避免对项目进行时间估算。相反，我更倾向于预测到第一个里程碑的时间并绘制里程碑以完成，并在我去的时候定期审查待定的里程碑。

例外：当代码基本完成时，只需要修改里程碑。当项目微不足道或与之前的项目大致相同时。当存在完整且准确的规范时（例如在应用程序平台转换的情况下）。

如果客户或经理坚持确定目标日期，那么我将坚持完整的规范。或者我找到另一位经理或客户。如果这些都不是一个选项，我会在空中抽出一个日期，让他们知道这是非常不准确的，很可能会被遗漏，但会随着里程碑的完成而改进。

时间估算技巧和方法的类型各不相同，从项目类型到项目类型，这就是为什么估算仍然是模糊艺术的原因。

Answer 47

我从不加倍。通常一个设计/想法/变化出现在一个便条纸上我通常以大约一年的估计开始，它所记录的帖子越精致我得到的估计越好。

即便如此，我知道当我完成实施时，我只完成了一半。这通常在原始年度估计范围内，所以有足够的时间让作者写出来解决任何设计问题。

Answer 48

如果您是一家咨询公司，那么您真的需要考虑过多填充您的估算。你需要赚钱，对吧？如果你保护你的资源不会更快地接受他们的下一个任务，你就不能这样做。另外，考虑一下你将要进行什么样的项目。你能和客户一起做T＆amp; M吗？如果没有，并且您被迫提供固定的出价，也包括固定的持续时间并与客户分担风险。我不能告诉你我看到有多少同事在讨论中讨论了各种主题。作为PM，你必须加强并且a）提供一个小的，合理的填充以确保交付日期可以满足，b）通过在SOW中获得良好的语言来协商和分享在固定投标项目中调用的风险保护你，c）你正在努力赢得工作，对吧？这样做，并确保您的A团队在规划阶段获得估算，以保持竞争力。

WPF和Silverlight相当新颖，但我们很快就让竞争对手低估了我们。

稍微偏离主题，但帮助客户在与Sales协商项目时意识到团队的强度。一个好的PM可以帮助赢得新客户的尊重和信任。

谈论内部资助的项目时，几乎没什么区别。由于野兽的性质和谴责生命周期以及许多这类项目的需求，他们需要比一些高风险，短期外部项目更强大的项目管理。

最后，您必须从将要执行工作的资源中获得支持。团队负责人应该保佑估计并能够判断他们是高还是低。您必须能够在每个项目上获得投资回报率，因此有时您可能需要填充超出预期的估算值。但是，如果工作量很小，并且您在项目中投入了B或C资源团队，那么如果出价太高，请将这个机会留在桌面上。除非它具有重要的商业意义，否则如果你真的没有足够的资源来取消它，就要避免参加演出。在这种经济形势下，这并不总是一种选择。

Answer 49

请记住，大多数开发人员不会考虑很多测试时间，也没有太多的错误修复时间，也没有管理开销（电子邮件，咖啡，会议等等），有些团队每周只安排20小时和/或乘以at至少2.5

Answer 50

我喜欢“双重”政策。但是，至少增加30％。我的上一次IBank的高级经理曾经告诉过我们。

Answer 51

如果你必须加倍或夸大你的估计值才能使它们接近现实，那么你原来的估计显然是错误的或不完整的。估计需要包括任务可能遇到的所有因素。添加额外的时间没有正当理由只是覆盖你的**，应该有一个完整金额背后的原因，而不仅仅是添加X是安全的。如果你知道会有重新设计和调整，那么请考虑那些因素，会议，测试，错误修复等。

正确的估计值应与atcuals匹配或接近，否则估计值不正确。

我们的目标是让实际值尽可能接近估计值，并且在估算游戏恕我直言中进行的操作与其相同。