您会增加预计的项目完成日期吗？[关闭]

如果可以，为什么？多少？

我倾向于夸大我的看法，因为我可能会过于乐观。

霍夫施塔特定律：即使考虑到霍夫施塔特定律，任何计算项目所花费的时间也会是您认为的两倍。

如果您根据过去的经验来夸大您的估计，以弥补自己内在的乐观，那么您就不会夸大了。您正在尝试提供准确的估算值。但是，如果您充气以至于您总是会有起伏的时间，那不是很好。

哦，是的，我学会了始终将我的初始估计值乘以2。这就是为什么FogBUGZ的基于证据的计划工具如此有用的原因。

任何要求其程序员估计粗粒度功能的时间的组织都从根本上被破坏了。

破解步骤：

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

这不是火箭科学。关键是步骤3。如果营销需要看似复杂的东西，那么您的PM（带开发人员的意见）便会确定第一步将花费不到一周的时间。如果这些PM不是技术性的，那么所有的一切都会丢失。

这种方法的缺点：

1. 当市场营销人员问“获得[X]需要多长时间？”时，他们没有得到估计。但是我们都知道，他们也知道，他们之前获得的估计纯属虚构。至少现在，他们每周都可以看到[X]正在开发的证据。
2. 作为开发人员，我们每周工作的选择较少。的确如此。不过，有两点：首先，好的团队要让开发人员参与有关将分配哪些票证的决策。其次，IMO，这实际上使我的生活变得更好。

没有什么比我在1个月大关上意识到我给出的2个月估算值绝望不足而令人沮丧的了，但是不能更改，因为它已经在官方营销文献中出现。我要么通过更改估计值来冒犯上流人士，冒着差评和/或错过奖金的风险，或者我做很多无偿加班。我已经意识到，很多加班不是坏开发商的标志，也不是“热情”标志的标志-它是有毒文化的产物。

是的，（很多）XP，“敏捷”，“ SCRUM”等都涵盖了很多此类内容，但实际上并没有那么复杂。您不需要一本书或顾问。您只需要公司意愿。

斯科蒂规则：

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

例：

• 您认为这需要3.5个小时
• 约四小时
• 是16小时的四倍
• 最多转移16天

塔达！在不到8天的时间内完成工作，您就是一个奇迹。

通常是，但是我有两种策略：

1. 始终以范围（即1d-2d）而不是单个数字的形式提供估算值。数字之间的差异告诉项目经理您对您的信心有多少，并可以使他们更好地计划。
2. 使用诸如FogBugz的“基于证据的计划”之类的工具或个人电子表格，将您的历史估算值与实际花费的时间进行比较。这比总是加倍为您提供更好的主意。尤其是因为加倍可能还不够！

我将在3到6周内回答。

这不是所谓的“膨胀”，而是所谓的“使它们遥不可及”。

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

别忘了您（工程师）实际上是在理想时间（临时术语）中进行估算的。

而管理工作是实时的。

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

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

示例：估计时间40小时（理想），管理人员将认为这是1周的实时时间。

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

• 假设每天召开一次会议（持续1小时）
• 每天一顿午餐（1小时）
• 加上20％的闲聊费用，让浴室聊天时间变得越来越咖啡等。

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

您40个小时的理想状态将需要80个小时的实时时间才能完成。

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

斯科蒂：当然，先生。我还能怎样保持我作为奇迹工作者的声誉？

一个好的经验法则是估计将花费多长时间并再次增加1/2的时间来解决以下问题：

1. 要求将改变
2. 您将被拉到另一个项目进行快速修复
3. 隔壁服务台的新人将需要一些帮助
4. 重构项目部分所需的时间，因为您找到了一种更好的做事方法

<sneaky>
不必夸大项目的估算值，而要分别夸大每个任务。上司很难用这种方式挑战您的估计，因为谁将在几分钟内与您争论。
</ sneaky>

但是，认真地说，通过使用EBS，我发现人们通常在估计小任务时比在大任务上要好得多。如果您估计项目需要4个月的时间，那么很可能要7个月才能完成；否则可能不会。另一方面，如果您估计一项任务为35分钟，则通常是正确的。

FogBugz的EBS系统为您显示了您的估算历史记录，根据我的经验（也可以参考其他人的图表），人们在估算短期任务方面确实更好。因此，我的建议是从对项目进行伏都乘运算转变为总计，然后开始将它们分解为很多非常小的任务，而这些任务您会更好地估计。

然后将整个结果乘以3.14。

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

风险领域包括：

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

因此，对于涵盖组件A的给定任务（或一组任务），初始估计为5天，根据需求范围将其视为高风险-您可以添加50％至100％

六个星期。

行业标准：每个请求将花费六个星期。有些会更长，有些会更短，最终所有结果平均。

另外，如果您等待足够长的时间，它将不再成为问题。我不能告诉你我经历了几次防火练习只是为了削减项目/功能。

我不会说我给它们充气，就像我试图根据过去的经验设定更现实的期望一样。

您可以通过两种方式来计算项目的持续时间：一种是计算所有涉及的任务，并弄清每个任务要花费多长时间，包括延迟，会议，问题等。这个数字总是很短，这就是为什么人们总是说些什么的原因。就像“加倍”。经过一些交付项目的经验之后，您只需简短地查看规格将花费多长时间，便能够非常迅速地做出判断，并且总是将第一种方法得出的数字翻倍。

最好为调试和测试之类的操作添加特定的缓冲时间，而不是仅仅增加总时间。另外，通过花一些时间真正地计划工作的各个部分，您将使估算本身变得更加容易（可能还有编码）。

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

我不会说我给它们充气，但是我想为该项目可能涉及的所有可能任务使用模板。

您会发现列表中的并非所有任务都适用于所有项目，但是拥有列表意味着我不会让任何任务从裂缝中溜走，而我却忘记为它们留出一些时间。

当您发现新任务是必要的时，请将其添加到列表中。

这样，您将获得一个现实的估计。

我倾向于对可以实现的目标持乐观态度，因此我倾向于估计偏低。但是我知道我的自我，所以我倾向于增加15-20％。

我还跟踪我的实际值和估计值。并确保所涉及的时间不包括其他干扰，请参阅我关于如何重返流程的SO问题的公认答案。

高温超导

干杯

除非您确实在原始估算之前就完成了项目，否则我不会将项目的额外估算时间称为“膨胀”。如果您习惯于始终在原先的预计时间之前完成项目，那么项目负责人将变得明智并期望更早完成。

您的估计依据是什么？

如果它们只是基于模糊的直觉，即需要多少代码以及编写该代码需要花费多长时间，那么最好将它们填充很多，以解决您没有想到的子任务，通信和同步开销和意外问题。当然，这种估计几乎是毫无价值的。

OTOH，如果您的估算是基于对上一次使用给定的技术和开发人员数量完成该任务的时间的具体了解，那么就不必进行通货膨胀，因为上述通货膨胀因素已经包括在其中过去的经验。当然，可能会有一些新因素对您当前的项目没有影响，您无法预见-这样的风险证明一定数量的额外填充是合理的。

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

我以最坏的情况来看，加倍，但这还不够。

承诺不足，超额投放。

哦，是的，长期的经验总结是给项目最好的时间估计，将其加倍，这就是实际需要多长时间！

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

我完全希望成为第一个提交为期两年的预算以更改对话框措辞的人。

感叹。

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

1. 始终从将项目分解为可管理的部分开始，实际上，您可以轻松地想象自己在同一天开始和完成的部分

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

3. 当您的风险上升时，这就是您从最佳猜测开始的地方，然后将其加倍以覆盖一些意外情况，但是请记住，这是在项目的一小部分上完成的，而不是整个项目本身

4. 当您无法控制某个因素时，风险也会上升，例如输入的质量或该库似乎可以满足您的所有需求，但从未进行过测试

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

6. 汇总所有内容以获得小计...

7. 然后，在整个项目中，始终为您等待的所有答案/文档/好的事情再加上大约20-30％（该数字将根据您的公司而变化），我们总是忘记的会议，在此期间想法的改变项目等等...这就是我们所谓的人为/政治因素

8. 再次添加另外30％到40％的内容用于说明您通常自己做的测试中所进行的测试和更正...例如，当您第一次向老板或客户展示时

当然，如果您查看所有这些内容，最终可以使用神奇的“ double it”公式将其简化，但是不同之处在于，您将能够知道在紧迫的期限内可以榨取什么，可以榨干什么。致力于什么是危险的任务，如何制定重要里程碑的时间表等。

我非常确定，如果您记下在每个纯“​​编码”任务上花费的时间，并将其与您对它的风险的估计进行比较，那么您将相距不远。关键是，要想一想前面的所有小问题，并且要想做到无障碍，要现实（而不是乐观）是不容易的。

我说什么时候可以完成。我确保更改请求后跟有新的估算值，而不是“是的，我可以做到”。不提，这将需要更多时间。请求更改的人不会认为它会花费更长的时间。

由于以下原因，我总是将估计数字加倍：

1）墨菲定律的缓冲器。在您无法解释的地方总会出问题。

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

3）议价空间。高层管理人员始终认为可以缩短工期。“只是让开发人员更加努力！” 这使您可以给他们他们想要的东西。当然，过度使用（不止一次）会训练他们以为您总是高估自己。

注意：最好总是将缓冲放在项目进度表的末尾，而不是针对每个任务。而且永远不要告诉开发人员缓冲区是否存在，否则帕金森定律（工作量会扩大，以填补完成该缓冲区所需的时间）将改为生效。有时我确实告诉高层管理人员缓冲区是存在的，但是显然我没有给他们理由3作为理由。当然，这取决于您的老板对您诚实的信任程度。

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