软件工程师如何估算项目时间

原文：The Software Engineer’s Essential Time Estimation Guide
作者：Kat Busch
翻译：雁惊寒

译者注：本文介绍了软件工程师在开发过程中进行时间估算的原因和方法，从而可以更加合理地安排项目进度。以下是译文。

我的一个产品经理朋友最近跟我提起她遇到的问题：“软件工程师永远不会估算他们的项目需要多长时间。我能做什么呢？“ 两位CEO最近也告诉了我同样的事情。

我们的工程师也都证实了这一点。我曾经看到过原本预估只要两天就能完成的项目最终却花了4个月的时间。在这种情况下，即使是采用“只需把时间翻倍”的经验也比实际情况差了一个数量级。这可能会对业务产生真正的影响。我曾经见到过一家公司为了一场发布会而竭尽全力，但是最终还是推迟了几个月。

站在较高的层次来看，问题出在工程师估算的时间与PM、经理、公关人员以及其他所有人估算的时间不一致上。大多数地工程师从本能上想的是，如果一切按照计划进行，写出一个可以运行的原型所需的最短时间。但是，那些受阻的下游部门想要知道的是项目什么时候能够为发布准备就绪，这完全就是另外一回事了。

对于工程师来说，掌握估算技能是一段终身的旅程。如果忽视它，这会让你以及与你直接或间接接触的每个人造成麻烦。掌握估算技能能让你在同事中脱颖而出，你的同事会把你跟专业、稳定和高质量的工作联系在一起。

为什么需要估算

让我先回答一下从工程师那里听到最多的问题：“为什么要这么麻烦估算时间？”许多工程师抱怨这是一个额外的开销。 “如果我加把劲全力去做的话，很快就能完成了！”

进行估算主要有两个原因：存在外部依赖，以及需要确定优先级顺序。

外部依赖

任何有效的事情都不会在真空中发生。项目通常都具有外部依赖性，例如跟非工程团队（通讯、金融、公关、客户支持）、其他工程团队甚至最终用户之间的协调。与外部依赖协调通常是经理、PM或CEO的工作。这意味着最有资格做出时间估算的人（工程师）并不是最需要估算结果的人。这种不对称性导致了最主要的紧张关系。

优先级顺序

时间估算也是确定工作优先级顺序的关键。 “物有所值”是工程中的一项重要指标，没有经过真正的估算就不值“钱”。即使你正在开发的功能是世界上最棒的东西，如果你花时间做一个全面估算的话，你可能也会意识到需要花太多时间来完成。

假设你正在开发一个项目，它能使网站的速度提升50％，但在相同的时间内，你可以完成两个项目，这些项目能使网站快40％。如果你不花点时间做一个初步估算的话，你永远都不会知道自己本来可以做出一个更快的网站！

时间估算基础

现在大家都同意时间估算在绝大多数情况下都是必须的，下面我们就讨论一下估算技巧吧。

我们低估时间是因为我们想的是“写出一个基本版本需要花多长的时间？”

但是交付出去的东西要比基本版本庞大得多。你需要考虑编码、测试、调试以及优化程序所花费的时间。别忘了还有开会、访谈、代码评审、发送邮件等事情。

我们低估的另一个原因是我们在编码的过程中总是会遇到“未知的未知数”。而这些是不可能完全预料到的。也许你的IDE要进行更新而中断了你的项目，然后你不得不花一整天的时间去弄好环境。你的估算是无法将这个也考虑进去的。

但是我们的估算依然能够做得比最初的直觉要准得多。以下是我的做法：

第一步：制定技术计划

在开始一个重要的项目之前，你应该已经有了一份技术计划或者设计文档了。用这个来让其他人知道你在做什么并且获得反馈。技术计划是开始进行时间估算的理想的地方。当你在关注技术细节时，你发现的那些未知的未知数就已经在魔术般地改进你的估算了。也许你会意识到你可能要把某个库更新到最新版本，这个可能要花你一天的时间。你甚至还可能会意识到自己本来打算要用的一个库根本就不存在，得自己写。

颗粒度在这里很重要。如果任何一个步骤给人感觉不清楚的话，要么忽略细节（应该了解更多），要么得把它分解为更细一点的步骤。同时，如果某个步骤的颗粒度太细的话，那么在实践中可能会使整个计划无效。

想要知道技术计划里应该要考虑哪些东西，可以看看Alicia Chen的这篇文章。关键点之一是消除跟PM或者其他利益相关者之间的分歧，这样最后才不会把东西做错而不得不重新开始。

第二步：为每个步骤添加时间估算

估算技术计划里每一个步骤完成所需的时间。这通常涉及到对细节的研究（“是不是已经有现成的库来实现这个了？”）。根据项目的性质，抛出一个简单的原型可能有助于暴露很多潜在的痛点。

第三步：增加大量的额外时间

现在你已经有一个初步的时间估算了，不过我们还要考虑上文提到过的很多东西。

随时调试：Bug总是存在的。调试很大程度上取决于你对特定代码库的熟悉程度以及该代码库的成熟度。
会议、访谈、假期等：在这期间你是不会在办公桌前编程的。你真正用于写代码的时间究竟有多少呢？在估算的时候，你至少应该看看自己的日程表。
最终测试与bug大扫除：你通常应该一边写代码一边写测试用例，但很多团队还需要进行额外的优化工作或者在发布前进行集成测试。要在估算中充分考虑到这些。如果你是分阶段推出的话，前面最初的1%可能会暴露出那些需要修正的bug。你要把这个也考虑进去。
代码评审：在这个代码库中你一般要评审几轮？通常要花多长的时间？确保要给评审人足够的时间（可能要留意一下他们的日程表）。如果只有一位评审人，你应该事先问一下他的备岗，以防关键时刻那个人出去度假或者因为太忙而耽搁了。

一旦你把所有这些交付所需的时间开销都考虑进去了，你就会看到自己的时间估算跟项目的实际发布时间会更加匹配。是的，实际情况会比估算的更长。是的，你可能会在缩短工期上受到压力。但是，当大家都知道可以依赖你时，他们会欣赏你的估算。

第四步：在发布之后对估算进行回顾

是的，在项目完成之后再回过头来看看你的时间估算感觉是一种痛苦。但是这种回顾就是你可以学到东西的时候，并且下次能做得更好。

如果实际花费的时间跟预期不一样会怎么样？如果集成测试花费的时间是你原先估算的两倍，那么请记下来，下一次留出更多的时间。或者尝试着改进你的集成测试系统。

你肯定会看到你估算的能力随着时间的推移而得到提升。你甚至可以在这个时候找到一些有助于整个团队的伟大见解。

最终，一切都是跟沟通有关

尽早地、经常地跟别人沟通你的时间表和变化。如果你在发布前一个月让你的经理知道你正在使用的一个库被发现了一个新的安全漏洞，你将不得不重头开始的话，他们将有时间通知公关、财务或者用户说版本需要推迟。

跟相关参与者进行沟通也会让他们为你提供可影响你估算的重要信息。某位设计师可能会说：“哦，如果那个花絮动画需要整整一周才能做出来的话，我们干脆砍掉好了。”PM可能会补充说：“这只是一个在用户研究中进行实验的原型。这次迭代我们不需要做太多的bug大扫除。”经理可能会说：“你有一半的时间都用在开会上了？让我来帮你解决这件事！”

对于工程师来说，不要屈服于压力，为了取悦上级而报告比实际情况要短的时间。诚实地说明你的估算和变化的方法，这显得你更加的专业。

对于涉及到的其他任何人来说，尊重估算出来的时间是很难的，这需要一个过程。你只有坐下来砍掉发布时不需要的功能才能减少时间。唠叨是不可能把时间减下来的。

我们永远都无法完美地估算出项目的时间。唯一的办法就是开放沟通、有恻隐之心以及坚定地确定优先次序。