不靠谱的软件开发工期预估

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

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

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天了”。如提前评估完了，相关人员应该收到电子邮件通知，以便安排下一步工作。若过了截止日期，而评估仍旧未完成，系统也可以发电子邮件，并列出未完成评估的人员。通过引入自动化的机制，势必降低了项目的人力管理成本，同时也提高了项目的执行效率。

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

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

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

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

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

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

来自：

 来自：

  来自：

  来自：