最终测试和bug清理：通常你在编码的同时应该也在写测试，但是很多团队在发布前，需要进行一轮润色工作或集成测试。如果集成测试花费了比预期两倍的时间，记下来，下次给测试留下更多的时间。或者尝试改进集成测试系统。PM可能会补充说：“这只是用户研究中的一个原型实验。我们不需要为这个迭代做太多的bug清理。”唯一的办法就是保持开放、多沟通、有同理心，并果断地确定优先次序。
项目时间估算方法?制定技术计划在着手开始工作前，你应该已经有了一份技术规划或设计文件，可以为任何重要的项目提供帮助可以用这个让别人知道你在做什么，并获得反馈制定技术计划是启动时间估算的理想阶段当完成技术细节设计时，会发现未知问题，你将会神奇地修改估算时间也许你会意识到，可能需要把一个正在使用的库升级到新版本，这可能会增加一天的时间甚至可能意识到计划使用的库实际上并不存在，需要自己写，今天小编就来说说关于项目时间估算方法?下面更多详细答案一起来看看吧!
项目时间估算方法
制定技术计划
在着手开始工作前，你应该已经有了一份技术规划或设计文件，可以为任何重要的项目提供帮助。可以用这个让别人知道你在做什么，并获得反馈。制定技术计划是启动时间估算的理想阶段。当完成技术细节设计时，会发现未知问题，你将会神奇地修改估算时间。也许你会意识到，可能需要把一个正在使用的库升级到新版本，这可能会增加一天的时间。甚至可能意识到计划使用的库实际上并不存在，需要自己写。
颗粒度在这里很重要。如果任何一步感到模糊或者不清楚，或许你会跳过这个步骤（应该学习更多），或者需要将其分解成更小的步骤。同时如果某个步骤粒度太细，那么在实践中可能会不堪一击使整个计划无效。
有关技术计划里应该考虑哪些方面，请参阅 Alicia Chen 的这篇文章《What do you mean ‘we need more time’?》。其中一个关键点是消除与 PM 或其他利益相关方之间的任何潜在歧义，这样最终你就不会因做错了某些事而不得不重新开始。
为每个步骤增加时间预算
估算一下技术方案中的每一步将执行多长时间。这通常会涉及对细节的研究（“有没有已经有人实现了这个库的功能？”）。根据项目的性质，罗列一个简单原型，可能会有助于暴露出许多未来潜在的痛点。
添加大量的额外时间
现在你已经有一个初步的估计，但是我们之前提到的所有的点还需要考虑。随时调试：总是会有Bug。调试很大程度上取决于你对特定代码库的经验和代码库的成熟度。会议、访谈、假期等：可能你不会在工位一直编码。你真正会有多少个小时进行编码？估算时应该至少看看你的日历。
最终测试和bug清理：通常你在编码的同时应该也在写测试，但是很多团队在发布前，需要进行一轮润色工作或集成测试。在估算中要给予这些工作足够的预算。如果分阶段进行推出，最初推出的1％内容，可能会暴露需要修复的bug，需要考虑到这一点。
代码审查：项目需要做几轮代码审查？通常需要多长时间？一定要确保有充足的评审人员（也可以确认一下他们的日程安排）。如果这是只有一个评审人员的项目，应该提前征求他们同意，要求他们安排一名候补人员，以防评审人员会休假或者在关键节点太忙。
一旦开始将所有这些时间开销添加到项目中，就会开始看到自己的时间估算值与项目实际启动时匹配地多了。是的，实际情况可能会比估计的更长，你可能会倍感压力去缩短工期。但是当大家知道他们可以依靠你时，他们会欣赏你的估算。
项目发布后，对时间估算做回顾总结
在项目完成之后回顾一下所做的工作，这听起来很痛苦。但是这种审查回顾会让你从中学到很多，下次做的更好。哪个过程结果与预期的时间不同？如果集成测试花费了比预期两倍的时间，记下来，下次给测试留下更多的时间。或者尝试改进集成测试系统。
你一定会看到自己的估算随着时间的推移而不断改善。甚至可以在这个过程中提出一些很好的见解，来帮助整个团队。最后，一切都与沟通有关
你的时间表和其他变动事宜，应该提前告知其他人。如果在发布前一个月让经理知道你正在使用的库中存在新的安全漏洞，不得不从头开始，他们会有时间相应的通知公关，财务或用户，需要推迟发布。和其他协作方沟通得来的重要反馈，有助于调整时间估算。设计师可能会说：“哦，如果这个花哨的动画将要花一整周的时间，我们可以完全剪掉它。”PM可能会补充说：“这只是用户研究中的一个原型实验。我们不需要为这个迭代做太多的bug清理。”经理可能会说，“你把一半的时间用在了开会？我来解决这个事情！”对于工程师来说，不要为了取悦上级，向不切实际的时间表妥协。坦诚地说出你的估算时间和变更方式，这样更专业。对于其他所有人来说，尊重估算的时间是很难的，而且这需要一个过程。你只能坐下来砍掉实际上不需要发布的功能或阶段，来缩短预计的时间，而不是通过唠叨把时间缩短。
我们永远无法完美估算项目所需的时间。唯一的办法就是保持开放、多沟通、有同理心，并果断地确定优先次序。
