原文出处：Programmer Time Translation Cheatsheet -or- Why Programmers Are Bad at Estimating Times
这里的时间不是指项目总的所需开发时间，而是程序员完成分配的任务需要的估算时间。
每个程序员都应该具备估算的技能。为磨练这个技能，接手每个任务时，先决定你要做什么，而且要注意不要遗漏构件，测试，检查代码的时间开销，然后在开始之前估算任务所需时间。最后测量实际花费时间，并与估算相比较。同样比较你实际完成的与计划完成的。这样你将会既提高你对一个任务包含细节的理解，同样也提高了你的估算技能。
以下是一个用来翻译程序员时间估算的表格，目的是希望尽量缩小估算错误
——-20170626补
- 第一步：制定技术计划
在着手开始工作前，你应该已经有了一份技术规划或设计文件，可以为任何重要的项目提供帮助。可以用这个让别人知道你在做什么，并获得反馈。制定技术计划是启动时间估算的理想阶段。当完成技术细节设计时，会发现未知问题，你将会神奇地修改估算时间。也许你会意识到，可能需要把一个正在使用的库升级到新版本，这可能会增加一天的时间。甚至可能意识到计划使用的库实际上并不存在，需要自己写。
颗粒度在这里很重要。如果任何一步感到模糊或者不清楚，或许你会跳过这个步骤（应该学习更多），或者需要将其分解成更小的步骤。同时如果某个步骤粒度太细，那么在实践中可能会不堪一击使整个计划无效。
有关技术计划里应该考虑哪些方面，请参阅 Alicia Chen 的这篇文章《What do you mean ‘we need more time’?》。其中一个关键点是消除与 PM 或其他利益相关方之间的任何潜在歧义，这样最终你就不会因做错了某些事而不得不重新开始。
- 第二步：为每个步骤增加时间预算
估算一下技术方案中的每一步将执行多长时间。这通常会涉及对细节的研究（“有没有已经有人实现了这个库的功能？”）。根据项目的性质，罗列一个简单原型，可能会有助于暴露出许多未来潜在的痛点。
- 第三步：添加大量的额外时间
现在你已经有一个初步的估计，但是我们之前提到的所有的点还需要考虑。
随时调试：总是会有Bug。调试很大程度上取决于你对特定代码库的经验和代码库的成熟度。
会议、访谈、假期等：可能你不会在工位一直编码。你真正会有多少个小时进行编码？估算时应该至少看看你的日历。
最终测试和bug清理：通常你在编码的同时应该也在写测试，但是很多团队在发布前，需要进行一轮润色工作或集成测试。在估算中要给予这些工作足够的预算。如果分阶段进行推出，最初推出的1％内容，可能会暴露需要修复的bug，需要考虑到这一点。
代码审查：项目需要做几轮代码审查？通常需要多长时间？一定要确保有充足的评审人员（也可以确认一下他们的日程安排）。如果这是只有一个评审人员的项目，应该提前征求他们同意，要求他们安排一名候补人员，以防评审人员会休假或者在关键节点太忙。
一旦开始将所有这些时间开销添加到项目中，就会开始看到自己的时间估算值与项目实际启动时匹配地多了。是的，实际情况可能会比估计的更长，你可能会倍感压力去缩短工期。但是当大家知道他们可以依靠你时，他们会欣赏你的估算。
- 第四步：项目发布后，对时间估算做回顾总结
在项目完成之后回顾一下所做的工作，这听起来很痛苦。但是这种审查回顾会让你从中学到很多，下次做的更好。
哪个过程结果与预期的时间不同？如果集成测试花费了比预期两倍的时间，记下来，下次给测试留下更多的时间。或者尝试改进集成测试系统。
你一定会看到自己的估算随着时间的推移而不断改善。甚至可以在这个过程中提出一些很好的见解，来帮助整个团队。