[探讨]不靠谱的软件开发工期预估

导语：软件开发工期是软件项目评估的重要组成部分，而软件开发工期预估的精准性却一直是业界无法解决的难题。之前CSDN软件研发频道推荐过一篇“为什么软件开发工期预估都不靠谱”的稿件受到了技术网友们的热烈关注，并纷纷给出观点和评论。

小调查

影响软件开发工期时间预估准确性的原因是什么？不固定的项目范围开发时间由非程序员估算开发人员过度自信的乐观估算没有充分解剖项目就进行估算估算多少时间就使用多少时间错误地以开发人数提升速度客户需求的临时变更突发情况的产生遗忘了测试时间未预留机动时间

软件工期预估错误常见原因及分析

软件开发工期的预估工作包括了很多细节问题需要处理，比如：预估的准确性标准是什么、选择什么样的预估方法和工具、预估应遵守的原则和态度、预估人员的选择等。其中任何一个环节没有做到位，工期预估时间与实际时间就会产生较大差异。有业界人士评论，目前软件开发工期的实际完成时间，一般来讲总是会超过起初预估值的两到三倍。这究竟是开发公司的错误、抑或是管理问题？还是一些根深蒂固的原因在作祟？基于这些问题，业内专家对错估原因进行了分析：

1、项目范围边界未确定好

在对项目尚不了解的情况下，如何估算项目工期？很难找出一位客户可以准确地说出他们的系统应该如何运行。

例：开发人员参与的每一个大型项目几乎无一例外都要求系统具有“灵活性”，换句话说就是，客户希望系统能处理将来需要处理的一切，但他们也说不清究竟需要什么功能，因此，“灵活性”本质上不是系统需求，因为它是一个模糊的概念。

2、开发时间由非程序员估算

如果你不是程序员，不要私自猜测开发需要的时间，如果项目经理象写小说那样虚构估算，项目注定会失去控制，开发时间的估算应该听取程序员的意见。

3、开发人员的估算太过乐观

开发人员估算时间一般都只考虑了编码需要的时间，另外，每个人的开发速度和效率都不一样，许多开发人员在估算开发时间时都过于乐观，他们往往会忽略掉诸如项目管理，需求整理，讨论，缺勤，电脑问题等因素。

4、没有充分解剖项目

对于一个独立的功能，如果估算的开发时间超过了一周就要小心了，象这样的功能应该进一步细分，这样开发人员可以更详细地分析更复杂的问题。

5、估算多少时间就使用多少时间

给一个程序员5天时间让他完成一个任务，他就一定会用5天时间，软件开发是可以无级变速的，任何代码都可以进行改善，如果开发人员只花了3天就完成了任务，他们会用剩下的时间来调整代码或干脆做其它事情。

遗憾的是，这将会导致估算时间成为开发所需的最小时间，实际交付时间只能被进一步推迟。

6、开发人员多!=开发速度快

一个需要耗时100天的项目不可能用100个开发人员1天就完成了，开发人员越多只会导致项目复杂性呈指数级增长。

7、项目范围变更

这可能是每个开发人员感觉最头疼的问题，有时是应客户的要求对功能进行修改或添加，有时会是CEO一时兴起，觉得某个功能很酷就要求加上或修改。

8、估算被固定

估算应是一个持续的过程，应随系统的开发进度不断更新，程序员往往会认为他们能够弥补逝去的时间，但却很少有人真正做到。

9、遗忘了测试时间

要让开发人员自己测试自己的代码是不现实的，他们知道代码是如何工作的，因此会潜意识地使用一个特殊的测试方法，通常，测试和调试时间需要占到开发时间的50%。

10、估算得太死

非程序员很少能体会到软件开发的复杂性，因此很少有项目计划不被迫延后，影响项目进展的因素很多，估算时如果不预留部分机动时间，最终只会是一个失败的估算。

开发延迟会导致代价高昂的连锁反应，遗憾的是，出了问题大家都喜欢将责任归咎于底层的程序员，这样下去对以后的项目也会不利，因为程序员会吃一盏长一智，下一次他们要么拒绝提供估算时间，要么会夸大开发时间。

软件项目常常会出现各种各样的变更，最好的办法只能是面对变化，在每次变化后对项目进行重新估算并进行相应的工作调整。根据变化及时更改预估值，也不失是接近精确值的方法之一。

如何使用合适的管理工具保证工期顺利进行

每个软件项目往往会因为各种原因发生变数。我们只能是尽量主动在软件系统需求、设计、编码、测试、维护、文档等多环节中做好管理，并对出现的变动迅速作出应对，这样就能尽量把产生的误差降到最小，再通过调节来进一步缩小预估误差。在此不再对每一环节一一赘述，只对整个软件开发工期的管理作一详解，希望由此找到更多保证软件开发工期的解决之道。

在完成软件开发工期的预估后，相应的软件工期管理不仅是保证工期按期进行的必要条件，更是保证整个软件项目顺利完成的重点，所以需借助合适的软件开发工期的管理工具。选择这样的工具则要注意它是否具备下列特点：

整合的系统（Integrated System）。 现今针对软件开发工期中各个阶段的工作管理，虽然可选的管理工具颇多，但它们多半是由不同的公司开发出来，且是各自独立的。这至少造成了以下两个问题。第一，各阶段的数据不能被共享。举例来说，同样的需求会在需求管理工具中记录，又同时需要出现在缺陷跟踪工具里。若要把这些数据要从一个工具拷贝到另一个工具，不但在时间上有延迟，同时在费用上也会增加，而且发生错误的可能性也变大。第二，项目执行的流程无法被固化。由于工具是各自独立的，工具间的流程自然是没法被固化的。如果我们能够找到一套整合的系统，这些问题势必迎刃而解。不但解决了软件应用生命周期中各个阶段工作的管理，而且也解决了阶段性数据的共享。

项目的透明度（Visibility）要高。 由于项目包含了庞大的数据，参与者往往都在雾里。对于关键的数据，看似存在，却无从提取。就如前面故事里的项目经理Jeff，他无法对项目的成本、所需人力以及时间等等进行合理的估算。由于缺乏真实的数据支撑，公司决策层对项目的投资报酬率不清楚，对整体策略步履蹒跚。其他如缺陷修复现状、缺陷率、任务完成时间估算和任务现状等都是项目里提高透明度的一些指标。这些年被敏捷团队所津津乐道的任务时间估算方式是以Burndown Chart来实现的。Burndown Chart通常以时间为横轴,以未完成的工作为纵轴。它显示随时间推移,项目中还剩下多少工作未完成。从而帮助项目管理层掌控项目的执行进展。

可追溯性（Traceability）要高 。 理想上，项目成员在软件开发工期管理系统中，可将相关的文档（包括需求及参考资料等）、测试用例及代码等建立链接，并有办法从其中的任意一个节点，追溯到其他的相关条目。如果软件开发工期管理系统的各个子系统不是整合的，那这种追溯事实上是不可能完善的。在上头的故事里，Tom、 John和Dianna把重要的设计文档丢失了，就是因为只是单纯的将文档放在服务器上，而没有保存到管理系统中管理，造成无法追溯。在实际的项目执行中，最常发生的例子可能是，研发人员要修复某个缺陷，他常常需要找出原本的设计文档及其他相关缺陷的修复状况。知道了来龙去脉后，他便可以很准确地完成他的工作。

自动化（Automation）程度要高。在项目的执行过程中，很多机械性的工作是可以经由软件系统自动触发的。最常见的例子是，当经理在工作流程中把某研发任务交给某个研发工程师时，一个电子邮件（或短信）就应该自动地邮寄到该工程师信箱（或手机）里。另一个例子是，某个项目要由10个委员在2周内评估完。在2周截止日前3天，系统也可以发个电子邮件通知提醒委员们“只剩3天了”。如提前评估完了，相关人员应该收到电子邮件通知，以便安排下一步工作。若过了截止日期，而评估仍旧未完成，系统也可以发电子邮件，并列出未完成评估的人员。通过引入自动化的机制，势必降低了项目的人力管理成本，同时也提高了项目的执行效率。

更多解决之道，欢迎开发者一共探讨。下面来看看业界人士针对工期预估的评论与观点：

前IBM资深软件工程师 刘冬清：预估的周期时间是不靠谱的，但并不代表不需要估计。必须有这样的估计才能做其他的决策，比如投入多少资源，市场推广如何做等。粗略的估计也是估计，问题在于你不能死抱着初始估计不放，而是要在信息增加的时候调整你的估计，这样随着项目的进行，真正所需的时间数就会越来越清晰。

知乎网Randal Truong：三个主要原因会导致工期预估错误。一是开发人员不准确的预估，进行估计工作需要拥有该类项目的系统知识和丰富的实践经验。还有，人们总是不自觉地愿意提供乐观消息，或者对自己过于自信，在这些情况下，开发人员往往会作出错误的预估。第二个原因是软件自身的“bug”。软件开发者总是为了完成新的任务而学习新的东西。在这种状态下，即使是最有经验的开发者也会遇到不可预见的困难和产生错误。此时，在预估时间里需要附加处理不可预见事件的额外时间。第三个原因是来自开发之外的外部因素。由于需求发生的变化，而使原产品的设计和规格等产生的改变，也会导致时间的延长。这种情况就只有在开发初期，与其他团队或客户进行充分的沟通和协调，以避免需求临时变化来影响开发周期。

知乎网Revett Eldred：软件开发工期难以精确预估，但有两点是必须要做到的。一.把整个工程分成不同的阶段，为每一阶段设定时间表，并在规定时间内完成任务实施。二.在计划初期就全面考虑将会出现的情况，一一作出应对规划，并严格执行。

本文由以下参考资料整合整理

为什么软件开发预估工期总是要超过2至3倍 来自：quora.com

软件应用生命周期平台应用的特点 来自：CSDN

软件项目评估失败的十个原因 来自：51testing.com

软件项目估计  来自：pcdog.com

如何进行软件项目估算  来自：uml.org.cn