程序员怎么预估自己的项目开发时刻？

项目时刻的预算对项意图成败至关重要。项目时刻管理包括了项目准时完成所需的各个进程。可是，在实践项目中，常常出现项目延期，预算严峻不精确的现象。

预估时刻本身就很难。每个程序员的估量都会跟真实需求的时刻有些距离。估量时刻短了阐明有些工作被忽略了(编译，测验，提交代码)。估量时刻超了阐明使命太大，难以了解。
关于资格较浅的程序员，这种估量误差是混乱的，他们常常会小看一些使命，一起又对一些稍微有难度的使命过火高估。我以为，对一个有经历的程序员，一个使命的时刻应该在半小时到24小时之间，超出24小时的使命都需求拆分。程序员在脑中想一想或许会以为要60小时，但实践上即使是很有经历的程序员也需求将使命分红可控的模块再来分析做决议。
还有一个很重要的需求认识到的一点是，编程上的经历并不等同于时刻估量上的经历。一个从没有做过工期估量的程序员不会拿手估量时刻。假如不去拿真实需求的时刻和估量出的时刻进行比较，你不行能从其它反馈信息之得到正确估量时刻的经历。
每个程序员都会用到评价技巧。为了进步你的这项技能，你能够在你从事的每个使命上进行训练。在使命开端时先预估开发所需时刻，拿它跟你最终真实用掉的时刻进行对比。这样，你不只在对使命细节的了解上有进步，一起也进步了你对时刻预估的技能。
霍夫斯塔特规律：实践时刻总是比预期要长，即便你考虑到了霍夫斯塔特规律。
常常会有PM诉苦说，为什么公司的开发永久不能估量自己的项目时刻？！可是机敏的程序员早就对此习以为常了。我乃至见过一个估计2天完成的项目最后花了4个月的时刻，即使依照「时刻翻倍」的经历法则来看也是挺夸张的。从高级层面来看，问题在于——工程师和PM或许其他人员对时刻预算的办法和思维方式不同。
大多数工程师的第一反应是，假如一切依照计划正常进行的话，写出一个原型所需求的最短时刻。而PM或许其他下游人员的想知道的是，项目什么时候能够预备完毕，从此刻到发布的这段时刻是多长？因而这完全是两个不同的故事了。
所以关于工程师来说，掌握时刻预算是一项必备技能，这意味着你是专业、安稳而高效的开发者。
为什么需求进行时刻预算？
外部依靠
任何有效的工作都不会凭空发作。项目通常存在外部依靠性，比方跟功用团队的交流（财务、PR、客户支撑）以及客户的交流等。而跟这些外部依靠和谐的往往是PM或许CEO的工作，这意味着最有资格做时刻预算的人（工程师）并不是最需求做这些测算的人。这种不对称导致了根本性的紧张。
优先级
时刻测算对确定优先级也很关键。工程领域中性价比是一项重要目标，哪怕你在做的功用是全世界最厉害的，通过时刻测算发现需求很长时刻才干完成的话，那这个功用的优先级也不会太高。
比方说你正在做一个项目，做成之后能够让网站快50%，但用同样的时刻你本来能够完成2个项目，而且每个项目都能够让网站快40%。假如你不花点时刻进行初步测算的话，你永久都不知道还能够做一个更快的网站！
初级时刻预算
假定咱们达成了时刻预算非常重要这个一致，那么咱们持续看一下如何预算。通常情况下，咱们轻视所需时刻是因为咱们想的是「写出一个原型需求多长时刻？」。
可是，交给的东西往往要比原型大多了，你还需求考虑测验、调试、优化所花费的时刻。还有开会、访谈、代码评定，乃至发邮件都是需求花费时刻的。
轻视所需时刻的另一个原因是意外的问题，这些问题往往不能被充沛考虑到，比方IDE更新而让你多花了一天去配置环境等等。
基于此，咱们最好不要太信赖所谓的经历和直觉。
Step1：制定技能计划
在开端任何一个重要项目之前，你都应该有一份技能计划或许规划文档。这个文档的意图在于让别人知道你在做的工作，并能取得反馈。当你注意到其间的技能细节时，你就会更清晰知道详细所耗费的时刻，比方把某个库更新到新版本，或许会多花一天的时刻。你乃至还得自己写一个库。
颗粒度在这里是很重要的。假如有哪一部分让人觉得不清楚，要么是你应该了解更多相关知识，要么得把它分解为更详尽的进程。与此一起，假如一个进程太细的话，又或许会太软弱导致整个计划无效，所以要掌握好这个度。
想要知道你的文档里应该考虑哪些东西，能够看看AliciaChen的这篇文章。关键在于跟PM交流清楚，消除有歧义的地方，这样才不会导致最后要推翻重来。
Step2：为每一步增加时刻预算
文档里的每一步完成需求多少时刻，这往往牵涉到对细节的研讨（这个是不是已经有库了？）。因而视项目性质而言，先做一个简略的原型能够协助揭示许多潜在的痛点。
Step3：追加容错时刻
现在你已经有了初步的时刻预算，不过还有许多其他需求考虑的因素。
随时调试：Bug难以避免，这取决于开发者对特定代码库的经历以及代码库的成熟度。会议和假期：开会或许放假时一般来说是不会敲代码的，所以真实敲代码有多长时刻？因而刻刻预算时要好好看看日程表。最终测验：通常应该一边编码一边测验，但很多团队在发布前还需求做集成测验，因而在你的预算中留出这部分的时刻。代码评定：在这个代码库中你一般需求进行几轮？每轮需求多少时刻？要通过多少评定人？留心评定人的日程安排保证代码评定的时刻。
当你把交给时刻的开销也考虑进去，你就能看到自己的时刻预算和项意图实践发布时刻要匹配得多。虽然实践情况或许还会更长，你也或许会因压力而需求缩短工期。但当大家理解你的预算更精确时，也会更信赖你。
Step4：发布后评定上期时刻预算
复盘还挺苦楚的，可是回忆能让你鄙人一次做得更好。每一个实践与预期时刻不匹配的项目都发作了什么，找到原因并改进它。
总而言之一切在于交流。提早交流、常常交流，了解互相的日程和需求改变。
跟PM等相关参与者的交流也能让对方供给或许会影响你预算的重要信息。一位规划师或许会说这个动画需求一周工期，爽性砍掉不要了。另一位PM也或许补充说这个原型仅仅对用户进行研讨的罢了，这次迭代不必处理太多bug。
关于工程师来说，不要做不切实践的更短工期的退让，开诚布公更显专业。关于PM和其他人来说，尊重这一预算或许需求一个进程，但要知道光靠唠叨是不行能缩短工期的。
项目时刻预算不容易，唯有善于交流、有同理心以及确定功用优先级才干够。