评估开发时间的重要性

首先，在一个项目中，所有的环节都是承上启下的，上一个环节结束的时间节点正是下一个环节开始的节点。那么在一个项目或者一次迭代正式启动前，所有的环节都应该有个时间评估。以一次APP需求迭代为例，项目计划像这样：

1.UI设计图 11.01 - 11.03（3工作日）

2.API接口讨论与设计 11.04（1工作日）

3.移动端开发 11.05 - 11.15（8工作日）

4.后端具备联调条件：11.11

5.产品体验 11.16 - 11.17（2工作日）

6.测试11.18 - 11.25（5工作日）

7.发布11.26

根据项目计划，各个部门自己要分配人员和时间。如果其中一个环节延期了，那么后面的各个环节都要顺延，就会造成损失。

其次，对于程序员来说，一个清晰的开发计划有助于自己有条不紊地开展工作，也能避免疏漏某个功能点。评估时间的过程，也是对需求详细拆分的过程，了解要做什么，做成什么样子。

在评估的过程中，根据专业知识和经验，充分预估会遇到的风险，怎样的解决方案，预留多少时间？都想好了的话，项目也就没啥风险了。

然而，开发时间评估，最大的好处是程序员受益。认真地评估开发时间，会让你在开始动手写代码之前搞清楚要怎么写，每个模块的设计心理得有个谱。从宏观上拆分模块，然后详细地分解任务，具体到一个很小的功能点。

这样你就能清晰地设计代码，而不是堆代码。也避免了很多时候写着写着发现不对，然后拉到重来的境地。就是要让你动手写代码之前胸有成竹！

初学者为什么评估不准？

如果你的项目经常delay，那么八成是时间评估不准。

刚毕业的学生被问到什么时候可以完成的时候，脑门一拍：“三天”，实际上两个星期过去了还没完成。

这里有一张表，看看你是不是这样子，对号入座：

越是老程序员越是“胆小”，评估时间越准。

如何精确评估开发时间

最近几年，我都是以小时为单位进行时间评估的，有没有觉得有点恐怖？长期以来这样的习惯让我收获颇多。这得感谢我之前的领导，三年前强迫我们这样做，刚开始很抵触，后来才体会到其中的甜头。

1、任务拆分

拿到新需求后，对其进行充分了解，不清楚的就去问清楚，然后对其进行模块化。之后，再进行技术上的拆分。由大到小，再到细节。细到什么程度呢？细到一个按钮的实现，细到一个点击动作是要用按钮还是要用手势的定夺，最好能细到代码块的划分。

这个能力是需要锻炼的，做好拆分，然后在实际开发过程中根据实际时间花销，回顾时间评估的准确性，以便让下次更准确。慢慢地，就会越来越精确，评估时间有依有据，不再是拍脑门给出的时间。下面看一个例子：

2、合理认知时间

一天工作八小时，但你不可能专注地连续八小时在编写代码。一天的工作中，有开会、讨论、阶段性休息（刷新闻、喝咖啡、发呆）的时间开销，真正有效时间其实不足六小时，杂事多的话可能是四五个小时。

3、预留buffer(缓冲区)

首先明确，预留buffer不是让你随便增加预估量，而是要明确知道buffer是给那些事情用的。要考虑到一下几点：

首先是沟通时间，你开发的时候不可能是闷着头一直写代码。要和UI设计师沟通，要和产品经理沟通，有可能还需要和组内的人沟通技术上的事情，以及和别的技术小组对接的问题。

等待时间。如果牵扯多部门协作，会有很多等待时间，因为你不能保证别的部门就能准确按照计划时间完成的。虽然等待过程中你可以安排其他任务，但你不能保证其他任务就能刚好填充等待时间，更何况任务切换也需要时间成本。

突发状况。例如，bug修改、需求微调、对接人请假。

不确定时间。和其他部门有交集的工作，最好多预留buffer。比如移动端和后台联调。后端信誓旦旦给你说11.11号可以进行联调，这次联调总共5个接口。如果你简单地认为他们给你提供的接口没问题，并且能顺利请求回来数据，预计一天联调时间足以，那你就等着delay吧。11.10号你已经准备好了所有联调准备，如果数据能正确返回，你的解析功能都是OK的，因为你之前用假数据已经处理的好好的。到了11号，你请求第一个接口就报错了，然后在即时通讯软件上问他们怎么回事，半个小时后给你回了“不好意思，地址变了，你用这个试试”。又错了……。终于回来数据了，然后发现缺少两个字段……。就这样，第一个接口调通已经快下班了。（当然很多后端技术人员也是很靠谱的，举这个例子只是为了让多考虑）

以上是可能会出现的状况，实际中有可能只是出现了一部分，这要根据实际情况而定。并不是让你能多预留buffer就多留，毕竟每个项目的时间都是很紧张的。一般buffer留在15%-25%。

4、回头看

在实际开发过程中，测量实际花费时间，并与估算相比较。如果有些地方相差较大，就要看差在哪里，然后在下次预估中避免相同的差错。

总结

编程经验不等同于估算经验。一个不被包含在估算流程中的开发者将不会擅长估算。同样，如果实际的时间花费不被测量和用于与估算比较，那么将没有反馈来学习。

最后，每个程序员都应该具备估算的技能。为磨练这个技能，接手每个任务时，先决定你要做什么。然后在开始之前估算任务所需时间。最后测量实际花费时间，并与估算相比较。同样比较你实际完成的与计划完成的。这样你将会既提高你对一个任务包含细节的理解，同样也提高了你的估算技能。

尽管进行了精确估算，也不能保证每个项目都会100%精确。偶尔会遇到一些突发情况和没预估到的风险是不可避免的。那么面对风险，有一些原则可以帮助你：

报风险时间置前，如果开发开始或者任何过程有可能导致项目延期或者需求无法实现的时候就报警，不要等加班能实现或者存在侥幸心理；
对于不确定的需求，一定要沟通到位；
涉及到交互细节，必须提前沟通好，充分明确细节；
技术可行性方案提前调查清楚。

程序员如何精确评估开发时间？相关推荐

为什么程序员不擅长评估开发时间？(转)
一个曾经与我一起工作过的经验丰富的项目经理声称,他拿到程序员的时间估算以后,先将它乘以π,然后转化下一个时间数量级后,才能得到真正的值.1天转化成3.14周.他过去因为程序员不擅长估算时间而吃尽了苦头 ...
如何精确评估开发时间的 4 个小套路？
一个程序员能否精确评估开发时间,是一件非常重要的事情.如果你掌握了这项技能,你在别人的眼里就会是这样: 靠谱经验十足对需求很了解延期风险小合格的软件工程师正规军,不是野路子评估开发时间的重 ...
如何精确评估开发时间？
一个程序员能否精确评估开发时间,是一件非常重要的事情.如果你掌握了这项技能,你在别人的眼里就会是这样: 靠谱经验十足对需求很了解延期风险小合格的软件工程师正规军,不是野路子评估开发时间的重 ...
本科毕业四年时间如何从月薪7k到年薪60w，讲下个人从菜鸟程序员到公司核心开发工程师的历程！
本科毕业四年时间如何从月薪7k到年薪60w,讲下个人从菜鸟程序员到公司核心开发工程师的历程,本帖主要分享下个人经历,只要努力最终会收获一个相对于自己较好的结果的,工位照镇楼毕业四年到现在总共换了三份 ...
编程开发学习笔记之程序员如何用1年时间获得3年成长（图）
2019独角兽企业重金招聘Python工程师标准>>> 编程开发学习笔记之程序员如何用1年时间获得3年成长(图) 前言这世界存在这么一个银行,你一出生,就自动享有这家银行为你开设的 ...
BAT 程序员们常用的开发工具
阿里篇一.Java 线上诊断工具 Arthas Arthas 是阿里巴巴 2018 年 9 月开源的一款 Java 线上诊断工具. 使用场景: 这个类从哪个 jar 包加载的?为什么会报各种类相关的 ...
BAT程序员们常用的开发神器
BAT程序员们常用的开发神器黄小斜今天作者丨InfoQ编辑部工欲善其事必先利其器,一个优秀的程序员除了代码写得好,善于利用各种开发工具同样可以事半功倍.以 BAT 为代表的各大厂程序员们在平时 ...
收藏！！BAT 程序员们常用的开发工具
阅读本文大概需要 15 分钟. 作者:infoQ来源:https://tinyurl.com/y4wohyqt 工欲善其事必先利其器,一个优秀的程序员除了代码写得好,善于利用各种开发工具同样可以事半功 ...
「程序员的思维修炼——开发认知潜能的九堂课」读书笔记
书名:程序员的思维修炼--开发认知潜能的九堂课作者:(美) 亨特 (Andy Hunt) 译者:崔康关于本书本书从德雷福斯模型入手,阐释了程序工程师发展的五个阶段:接着从阶段间的特征中引出 L ...

程序员如何精确评估开发时间？