但凡有过商业项目开发经验的程序员都在开发时间估算方面遇到过各种状况，其中最常见的是——实际的开发时间总比估算的多很多。
很多人说不清楚为什么会这样，本文就来带你探究一下影响开发时间估算的因素有哪些 ！
作为个体软件工程师而言，你通常没有足够的背景、教育经历或经验来确定时间进度，所以你应该与项目经理进行沟通，向他们解释时间进度表中需要考虑的事项（不仅仅是编写代码所需的时间），然后构建一个估计时间的方法。
如何估计开发时间取决于你所参与的项目的规模，**比如是一个小型项目、中型项目还是一个大型项目，或者仅仅是一个项目的某一部分。
估计小型项目的开发时间
根据定义，一个小型项目是一个软件工程师可以单独完成的项目。对项目进度的主要影响是这个软件工程师的能力和生产力。
估计小型项目的开发时间比估计大型项目要容易得多，也更加准确。小型项目不会涉及并行开发，并且在进度表中只需要考虑单个开发人员的生产力。
毫无疑问，估计小型项目的开发时间，第一步是识别和理解需要完成的所有工作。如果此时项目的某些部分还没有被清晰定义，那么在进度表中就会引入相当大的错误，因为这些未定义的组件，不可避免地要花费比你想象的多得多的时间。
在估计某个项目的完成时间时，设计文档是项目中最重要的部分。如果没有详细的设计，那么就不可能知道项目由哪些子任务组成，以及每个子任务将花费多少时间来完成。一旦你将项目分解成适当大小的子任务（一个合适的大小，就是清楚地知道完成它需要多少时间），你需要做的就是将所有子任务的时间汇总起来，从而产生一个合理的初步估计。
然而，人们在估计小型项目的进度时最常犯的一个最大的错误是，他们会把子任务的时间加到进度表中，而忘记了会议、电话、电子邮件和其他管理任务的时间。
他们还容易忘记增加测试时间，以及发现和修复缺陷（和重新测试）的时间。
因为很难估计软件中存在多少缺陷，以及解决这些缺陷需要多少时间，所以大多数管理人员会将进度表中第一次估计的值扩大2~4倍。
假设程序员（或团队）在项目上能够保持合理的生产力，那么这个公式可以用来很好地估计小型项目的开发时间。
估计中型项目和大型项目的开发时间
从概念上讲，中型项目和大型项目是由许多小型项目（分配给各个团队成员）组成的，它们结合起来形成最终的结果。
因此，第一种估计大型项目进度的方法，是将其分解为一堆较小的项目，然后估计每个子项目的开发进度，再合并（汇总）起来进行总体估计。
这是估计小型项目进度的放大版本。
遗憾的是，在现实情况中，这种估计方式会带来很多问题。
第一个问题是，中型项目和大型项目会存在小型项目中不存在的问题。
一个小型项目通常只有一个工程师，并且正如前面所提到的，对小型项目的时间安排完全取决于这个工程师的生产力和可投入时间。
在一个较大的项目中，许多人（包括工程师以外的人）都会影响到对进度的估计。一个拥有关键知识的软件工程师可能在休假或者生病几天，耽误了另一个工程师获取所需信息来开展工作。
从事大型项目开发的工程师通常每周都会有几次会议（这些会议在大多数日程安排中都没有提到），这些会议会让他们持续下线几个小时，也就是说，在这段时间内他们没有在编程。
在大型项目中，团队组成结构也可能会发生变化，例如，一些有经验的程序员离开了，而另一些人不得不继续学习其他子任务，而且新加入项目的程序员需要时间来跟上进度。
有时候，即使是为新员工配备一个计算机工作站，也要花上几周的时间（例如，在一家非常官僚的大公司的IT部门）。
等待购买软件工具、开发硬件以及来自组织其他部分的支持，也会造成进度安排失效的问题。
这样的例子不胜枚举。很少有进度估计能够准确地预测出这些会消耗多少时间。
最终，估计中型项目和大型项目的进度会包括4个任务 ，即把项目分解成多个较小的项目，估计这些小项目的进度，增加集成测试和调试的时间（也就是让各个小项目结合到一起并且正常工作的时间），然后通过一个乘数因子得到最终的合计结果。
这种方式并不精确，但是它到今天依然有效。
估计开发时间的问题
因为项目进度估计涉及对开发团队未来能力的预测，所以很少有人相信计划的进度是完全准确的。
然而，常见的软件开发进度预测尤其糟糕，其中有以下一些原因：
- 它们是在研发项目。研发项目包括做一些你以前从未做过的事情。它们需要一个研究阶段，在此期间开发团队需要分析问题并试图确定解决方案。通常，没有办法预测研究阶段需要多长时间。
- 管理层已经预先制定了时间表。通常，市场部门决定其想要在某个日期之前销售产品，而管理部门则通过从该日期向前倒推时间来制订项目计划。在要求开发团队估计子任务的时间之前，管理层已经对每个任务应该花费的时间有了一些先入为主的想法。
- 这个团队以前做过类似的事情。管理层通常会认为，如果你以前做过某件事情，那么第二次做起来会更容易（因此会花费更少的时间）。在某些情况下，这是有道理的。如果团队做的是同一个研发项目，那么第二次做就会更容易，因为他们只需要做开发，可以跳过（至少大部分）研究阶段。但是，认为项目第二次做总是更容易的假设很少是正确的。
- 没有足够的时间和资金。在很多情况下，管理人员会在项目必须完成的前提下，设置某种资金或时间限制，否则该项目就会被取消。对于那些薪水跟项目进展挂钩的人来说，这是错误的。如果让他们在说“是的，我们能满足计划”和找一份新工作之间做出选择，大多数人即使知道机会很渺茫，也都会选择前者。
- 程序员会夸大他们的效率。有时候，当软件工程师被问到他们能否在一定时间内完成一个项目时，他们不会谎称需要多长时间，而是对他们的表现做出乐观的估计，但是实际上在工作中很少会站得住脚。当被问及他们可以产生多少有效工作时，大多数软件工程师会给出一个图表，展示其有史以来在一个较短时间内的最大产出（例如，在“危机模式”下每周可工作60~70个小时），但是他们很少会考虑意料之外的困难（例如，出现一个很严重的系统缺陷）。
- 进度取决于额外的时间。管理层（和某些工程师）经常会认为，当进度开始延后时，程序员总是可以多投入“几个小时”来赶上进度。结果是，进度往往比他们期望的会更加延后（因为他们忽略了工程师大量加班所带来的负面影响）。
- 工程师就像搭积木一样。**在项目进度安排中一个常见的问题是，管理层认为可以通过向项目中增加程序员人数来提前发布软件。然而，正如前面所提到的，这并不一定是正确的。你不能通过在一个项目中增加或者减少工程师人数，就期望项目进度能产生相应的变化。
- 对子项目的估计是不准确的。**实际的项目进度安排是以自上而下的方式制订的。整个项目被分成几个较小的子项目，然后这些子项目又被分成几个子项目，依此类推，直到子项目的规模非常小，有人可以准确地预测每个子项目所需的时间。但是，这种方法会面临三个挑战：
- 是否愿意尽力以这种方式来安排进度（即对项目提供正确、准确的自上而下的分析）。
- 是否能够对小的子项目进行准确的估计（特别是软件工程师，他们可能没有经过适当的管理培训，所以不清楚哪些因素是在估计进度时需要考虑的）。
- 是否愿意接受进度预估的结果。
本文节选自 《编程卓越之道（卷3）：软件工程化》 一书
