0. 我是前言

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

1. 评估开发时间的重要性

首先，在一个项目中，所有的环节都是承上启下的，不管你是身处瀑布流团队还是敏捷团队，不管团队用的是 Sprint 还是 Kanban，上一个环节结束的时间节点正是下一个环节开始的节点。那么在一个项目或者一次迭代正式启动前，所有的环节都应该有个时间评估。

对于项目，合理的预估可以减低延期风险，促进高效协作。

对于个人，合理的预估能让你宏观把控，细节拆分，了解需求，合理安排工作。

2. 为什么评估不准h1>

首先我们要知道，“评估” 天生就会产生偏差。但是，我们可以通过科学手段无限消除偏差。

先来看一个有趣的例子：

从 A 地到 B 地，总共20公里。请你预估一下骑自行车过去得多久。

我：每小时骑行10公里肯定没问题，所以就预估2小时吧。

现实a：20公里都是乡间小路，用时4小时。

现实b：晚上十点出发，抹黑骑行，用时6小时。

现实c：刚出发就开始下大雪了，被迫停歇一天，用时15小时。

现实d：唯一的跨江大桥坍塌了，被迫绕行100公里，路上爆胎，用时24小时。

。。。

再看看一张很贴近日常开发的示例：

图3. 预估示例

是不是很真实p>

从以上两个例子可以看出，导致预估不准确的原因有如下几种：

• 想当然
• 经验缺乏
• 依赖的不确定性
• 对需求和上下文了解不清楚

总之就是，假设不成立。

3. 不同的预估标准

3.1 以 Point 为单位

敏捷开发中，是以 Point 为单位评估一件事情的「复杂度」。一般使用菲波那切数列（1，1，2，3，5，8，13，…）中的数字。

「复杂度」的评估标准应该提前拟定好。要知道，「复杂度」仅仅体现事情的复杂度，不与个体的能力绑定。

一般迭代周期是固定的，如果知道团队的 Capacity，那么就能算出这次迭代可以完成多少个 point。

例如，迭代周期是20个工作日，Capacity 是 0.8，团队成员 4 人，那么这次迭代就可以完成 20 x 0.8 x 4 = 64 个 point。

3.2 以 Day 为单位

在瀑布流开发模式中，一般以 Day 为评估单位，并且和个人能力挂钩。所以可以直接估算出开发时间。

任务数量确定，评估出开发时间后，就可以算出交付日期。这个就不展开讲了。

不管是敏捷开发，还是瀑布模式开发。他们在时间预估上只是形式不同。

4. 如何科学地预估

上面提到过，评估是准确是因为很多假设不成立。那么如何做到假设成立呢需要提高多个维度的认知。

4.1 提高需求认知 – 任务拆分

我们需要把任务拆分的尽可能小，以敏捷模式为例，一般 1 到 8 个 point 为宜，尽量不要超过 8 个 point。如果某个 story 超过 8 个 point，那么这个 story 必然很笼统，包含了太多的内容，估点肯定不准确。这时可以要求 PM 或 BA 去拆分这个庞大的 story。

拆分任务的时候，也是对需求详细了解的过程。对于不明确的地方，一定要和 PM 或 BA 沟通清楚。让一个 “事务” 变成一个个可执行且明确的 “任务”。

4.2 提高技术认知 – 做 Spike

对于开发者来说，不是所有的技术点都了然于胸。对于不确定的技术点，应该提前调研，可以建 Spike ticket 专门去做调研。进行可行性验证后，再基于调研结果做时间估算。

4.3 提高时间认知 – 计算有效时间

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

还要考虑人员请假和人员变动的时间开销。

虽然在敏捷模式下以「复杂度」为单位估算，但我们仍然需要清楚有效时间。这有助于我们计算 Capacity。

4.4 提高风险认知 – 合理预留 Buffer

自身风险：虽然做了调研，但也避免不了在工程中实践的时候不出问题，这是技术实践中的风险。

其他团队的风险：比如说前后端 API 联调，前端和后端团队都是对方的风险。后端开发人员告诉前端所有接口都已准备好并且自测了，但是当你去调用的时候发现有各种问题。（只是个例子，不针对后端）。还有需求改动。大的改动当然是不允许的，但是小改动往往不可避免。

面对这些风险，如何应对p>

预留 Buffer ！也可称为“容错时间”。这是在合理认知风险和认知时间的基础上进行余量预估，可不是随便增加预估量嗷。

具体要根据团队的沟通成本、配合默契度、依赖程度进行估算，一般在15%~25%之间（主观经验值，无从考证）。

4.5 回头看

一项能力的建设过程，都是不断反馈的过程。不同的项目不同的开发团队，往往评估策略是有差异的。所以我们要通过回头看，不断校正，逐步趋于精确。

预估 -> 实际用时统计 -> 回顾分析。不断练习，积累经验， 预估时间会越来越接近实际用时。

5. 结束语

Robert C. Martin 说：“Just as the Hare was overconfident in its speed, so the developers are overconfident in their ability to remain productive.” 是的，我们总是过于自信，很多时候在预估时间的时候体现的淋漓尽致。在多次交付延期或被迫加班之后，我们会逐渐趋于成熟，心里默念：谦和朴诚，保持敬畏。

最后，虽然有些团队是不要求严格预估时间，但是作为开发者，我们自己心里得有数，请养成这个习惯。