程序员必备的项目时间估算指南.docVIP

程序员必备的项目时间估算指南

程序员必备的项目时间估算指南

程序员必备的项目时间估算指南

程序员必备的项目时间估算指南

霍夫斯塔特定律：实际花费的时间总是比预期的要长，即便你考虑到了本条定律。--DouglasHofstadter

有位PM最近告诉我她面临的一个难题:“软件工程师永远不能估算出他们的项目需要多长时间.我该怎么办?”还有两位CEO最近也告诉我同样的事情.

《为什么程序员总是不能准确估测项目时间？》，我们都深有体会。我曾经遇到过一个项目，预计需要两天完成,结果做了四个月。在这种情况下，即使用“时间翻倍”的经验估算，也依然差出了一个数量级之多。这样真的非常影响业务。我曾见过整个公司为了举办一个发布活动费尽心力，结果却不得不推迟数月.

从高级层面上讲,这个问题在于在时间估算的时候，工程师、PM、经理、公关以及其他所有人的看法存在不同.大多数工程师本能考虑的是，如果一切都按照计划进行,写出一个可用的原型需要的最短时间.但下游的人想知道的是项目何时准备发布——这完全是另外一回事了。

对于工程师而言,把握估算项目所需时间是一段终身的旅程.忽视这个问题，会给你以及与你直接或间接接触的每个人带来困扰。精准把握估算项目所需时间会让你脱颖而出，同事们将会把这些和你的专业精神，稳定性和工作质量相关联。

为什么我们要时间估算

首先我来回答一下工程师经常问到的问题：“为什么要估算时间？许多工程师抱怨（有一定道理）这是一份间接成本。“如果我开足马力去做，会更快地完成项目!”

主要有两个原因：外部依赖和优先次序。

外部依赖

没有任何有效活动会在真空中运作.项目通常有外部依赖，例如与非工程团队（通讯,金融，公关，客服）、其他工程团队甚至最终用户本身的协作。协调这些外部依赖关系通常是经理、PM或CEO的职责。这意味着最有资格做时间估算的人（工程师）不是最需要估算时间信息的人.这种不对称导致了根本的矛盾。

优先次序

时间估算也是确定工作优先级的关键。“钱花的值不值”是项目中的重要指标，没有真正的估算，也就无法确定钱花的值不值。即使你正在做的功能是世界上最棒的,如果花时间做一个全面的估计，你可能会意识到这将需要花费很长时间才能完成.

假设你正在做一个项目，这将使网站的速度提升50%,但在相同的时间内，可以完成两个项目，每个项目将使网站快40％.如果没有花时间做一个初步的估计，你永远不会知道你可以做出一个访问速度更快的网站！

时间估算入门

现在大家都同意绝大多数时候都需要时间估算，我们来谈谈技巧.

我们低估时间是因为我们考虑的是“我需要多长时间才能写出这个基本版本？”

但交付的东西不仅仅是基础版。还需要考虑到编写，测试，调试和润色所需的时间。不要忘了开会、访谈、做代码审查以及发送电子邮件等事情也需要时间。

低估时间的另一个原因是我们几乎总是在编码过程中遇到“未知数，这些未知数是不可能完全预测和考虑周全的。也许IDE会更新，中断了项目，你花费一天的时间去修复它。在时间估算中无法考虑到这一点.

但是，我们仍然可以比最初的直觉做的更好。以下是我的做法:

第一步:制定技术计划

在着手开始工作前,你应该已经有了一份技术规划或设计文件,可以为任何重要的项目提供帮助.可以用这个让别人知道你在做什么，并获得反馈。制定技术计划是启动时间估算的理想阶段。当完成技术细节设计时，会发现未知问题，你将会神奇地修改估算时间。也许你会意识到，可能需要把一个正在使用的库升级到新版本，这可能会增加一天的时间。甚至可能意识到计划使用的库实际上并不存在，需要自己写。

颗粒度在这里很重要。如果任何一步感到模糊或者不清楚，或许你会跳过这个步骤（应该学习更多），或者需要将其分解成更小的步骤。同时如果某个步骤粒度太细，那么在实践中可能会不堪一击使整个计划无效。

有关技术计划里应该考虑哪些方面,请参阅AliciaChen的这篇文章《Whatdoyoumean‘weneedmoretime’？》。其中一个关键点是消除与PM或其他利益相关方之间的任何潜在歧义,这样最终你就不会因做错了某些事而不得不重新开始。

第二步：为每个步骤增加时间预算

估算一下技术方案中的每一步将执行多长时间.这通常会涉及对细节的研究（“有没有已经有人实现了这个库的功能？”）。根据项目的性质,罗列一个简单原型，可能会有助于暴露出许多未来潜在的痛点。

第三步:添加大量的额外时间

现在你已经有一个初步的估计,但是我们之前提到的所有的点还需要考虑。

随时调试：总是会有Bug.调试很大程度上取决于你对特定代码库的经验和代码库的成熟度。

会议、访谈、假期等：可能你不会在工位一直编码。你真正会有多少个小时进行编码？估算时应该至少看看你的日历。

最终测试和bug清理:通常你在编码的同时应该也在写测试，但是很多团队