项目的开发时间，你会怎么评估？

php教程 1 年前 0 10

一个程序员能否精确评估开发时间，是一件非常重要的事情。如果你掌握了这项技能，你在别人的眼里就会是这样：

靠谱
经验十足
对需求很了解
延期风险小
合格的软件工程师
正规军，不是野路子

一、评估开发时间的重要性

首先，在一个项目中，所有的环节都是承上启下的，上一个环节结束的时间节点正是下一个环节开始的节点。那么在一个项目或者一次迭代正式启动前，所有的环节都应该有个时间评估。

以一次APP需求迭代为例，项目计划像这样：

UI设计图 11.01 – 11.03（3工作日）
API接口讨论与设计 11.04（1工作日）
移动端开发 11.05 – 11.15（8工作日）
后端具备联调条件：11.11
产品体验 11.16 – 11.17（2工作日）
测试11.18 – 11.25（5工作日）
发布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%精确。偶尔会遇到一些突发情况和没预估到的风险是不可避免的。那么面对风险，有一些原则可以帮助你：