程序员如何预估本身的项目开发时间？

项目时间的估算对项目的成败相当重要。项目时间管理包括了项目按时完成所需的各个过程。可是，在实际项目中，常常出现项目延期，估算严重不许确的现象。

预估时间自己就很难。每一个程序员的估计都会跟真正须要的时间有些差距。估计时间短了说明有些事情被忽略了(编译，测试，提交代码)。估计时间超了说明任务太大，难以理解。

对于资历较浅的程序员，这种估计偏差是混乱的，他们常常会轻视一些任务，同时又对一些稍微有难度的任务过度高估。我认为，对一个有经验的程序员，一个任务的时间应该在半小时到24小时之间，超出24小时的任务都须要拆分。程序员在脑中想想可能会认为要60小时，但实际上即便是颇有经验的程序员也须要将任务分红可控的模块再来分析作决定。

还有一个很重要的须要认识到的一点是，编程上的经验并不等同于时间估计上的经验。一个从没有作过工期估计的程序员不会擅长估计时间。若是不去拿真正须要的时间和估计出的时间进行比较，你不可能从其它反馈信息之获得正确估计时间的经验。

每一个程序员都会用到评估技巧。为了提升你的这项技能，你能够在你从事的每一个任务上进行锻炼。在任务开始时先预估开发所需时间，拿它跟你最终真正用掉的时间进行对比。这样，你不只在对任务细节的理解上有提升，同时也提升了你对时间预估的技能。

霍夫斯塔特定律：实际时间老是比预期要长，即使你考虑到了霍夫斯塔特定律。

常常会有 PM 抱怨说，为何公司的开发永远不能估计本身的项目时间？！然而机智的程序员早就对此司空见惯了。我甚至见过一个预计 2 天完成的项目最后花了 4 个月的时间，即便按照「时间翻倍」的经验法则来看也是挺夸张的。从高级层面来看，问题在于 —— 工程师和 PM 或者其余人员对时间估算的方法和思惟方式不一样。

大多数工程师的第一反应是，若是一切按照计划正常进行的话，写出一个原型所须要的最短期。而 PM 或者其余下游人员的想知道的是，项目何时能够准备完毕，今后时到发布的这段时间是多长？所以这彻底是两个不一样的故事了。

因此对于工程师来讲，掌握时间估算是一项必备技能，这意味着你是专业、稳定而高效的开发者。

为何须要进行时间估算？

外部依赖

任何有效的事情都不会凭空发生。项目一般存在外部依赖性，好比跟职能团队的沟通（财务、PR、客户支持）以及客户的交流等。而跟这些外部依赖协调的每每是 PM 或者CEO的工做，这意味着最有资格作时间估算的人（工程师）并非最须要作这些测算的人。这种不对称致使了根本性的紧张。

优先级

时间测算对肯定优先级也很关键。工程领域中性价比是一项重要指标，哪怕你在作的功能是全世界最厉害的，通过时间测算发现须要很长时间才能实现的话，那这个功能的优先级也不会过高。

比方说你正在作一个项目，作成以后可让网站快 50%，但用一样的时间你原本能够完成 2 个项目，并且每一个项目均可以让网站快 40%。若是你不花点时间进行初步测算的话，你永远都不知道还能够作一个更快的网站！

初级时间估算

假设咱们达成了时间估算很是重要这个共识，那么咱们继续看一下如何估算。一般状况下，咱们低估所需时间是由于咱们想的是「写出一个原型须要多长时间？」。

可是，交付的东西每每要比原型大多了，你还须要考虑测试、调试、优化所花费的时间。还有开会、访谈、代码评审，甚至发邮件都是须要花费时间的。

低估所需时间的另外一个缘由是意外的问题，这些问题每每不能被充分考虑到，好比 IDE 更新而让你多花了一天去配置环境等等。

基于此，咱们最好不要太相信所谓的经验和直觉。

Step 1：制定技术方案

在开始任何一个重要项目以前，你都应该有一份技术计划或者设计文档。这个文档的目的在于让别人知道你在作的事情，并能得到反馈。当你注意到其中的技术细节时，你就会更清晰知道具体所耗费的时间，好比把某个库更新到新版本，可能会多花一天的时间。你甚至还得本身写一个库。

颗粒度在这里是很重要的。若是有哪一部分让人以为不清楚，要么是你应该了解更多相关知识，要么得把它分解为更细致的步骤。与此同时，若是一个步骤太细的话，又可能会太脆弱致使整个计划无效，因此要把握好这个度。

想要知道你的文档里应该考虑哪些东西，能够看看AliciaChen 的 这篇文章。关键在于跟 PM 沟通清楚，消除有歧义的地方，这样才不会致使最后要推翻重来。

Step 2：为每一步添加时间估算

文档里的每一步实现须要多少时间，这每每牵涉到对细节的研究（这个是否是已经有库了？）。所以视项目性质而言，先作一个简单的原型能够帮助揭示许多潜在的痛点。

Step 3：追加容错时间

如今你已经有了初步的时间估算，不过还有许多其余须要考虑的因素。

随时调试：Bug 难以免，这取决于开发者对特定代码库的经验以及代码库的成熟度。会议和假期：开会或者放假时通常来讲是不会敲代码的，因此真正敲代码有多长时间？所以时间估算时要好好看看日程表。最终测试：一般应该一边编码一边测试，但不少团队在发布前还须要作集成测试，所以在你的估算中留出这部分的时间。代码评审：在这个代码库中你通常须要进行几轮？每轮须要多少时间？要通过多少评审人？留意评审人的日程安排确保代码评审的时间。

当你把交付时间的开销也考虑进去，你就能看到本身的时间估算和项目的实际发布时间要匹配得多。尽管实际状况可能还会更长，你也可能会因压力而须要缩短工期。但当你们明白你的估算更准确时，也会更信任你。

Step 4：发布后评审上期时间估算

复盘还挺痛苦的，可是回顾能让你在下一次作得更好。每个实际与预期时间不匹配的项目都发生了什么，找到缘由并改进它。

总而言之一切在于沟通。提早沟通、常常沟通，了解彼此的日程和需求变动。

跟 PM 等相关参与者的沟通也能让对方提供可能会影响你估算的重要信息。一位设计师可能会说这个动画须要一周工期，干脆砍掉不要了。另外一位 PM 也可能补充说这个原型只是对用户进行研究的而已，此次迭代不用处理太多 bug。

对于工程师来讲，不要作不切实际的更短工期的妥协，开诚布公更显专业。对于 PM 和其余人来讲，尊重这一估算可能须要一个过程，但要知道光靠唠叨是不可能缩短工期的。

项目时间估算不容易，惟有善于沟通、有同理心以及肯定功能优先级才能够。

阅读更多

到外企？为何别的程序员那么容易

一招教你打造一个滑动置顶的视觉特效

NDK项目实战—高仿360手机助手之卸载监听

（Android）面试题级答案（精选版）

相信本身，没有作不到的，只有想不到的