时间紧迫和计划压力如何影响总拥有成本和交付时间？

一位朋友的父亲是软件工程经理，他强调说：“造成计划超支的首要原因是计划压力。”

研究站在哪里？是适度的调度压力在鼓舞人心，还是我提到的经理是对还是错，还是“您的调度压力越大，交货时间越长，总拥有成本越多”的问题？理想情况下，软件工程可以在没有调度压力的情况下工作，但实际上我们必须在现实情况的约束下工作，这是其中之一吗？

与软件工程文献的任何链接将不胜感激。

计划超支的首要原因是计划压力。

我不同意。造成计划超支的首要原因是计划表过于乐观，无法反映现实情况。人性决定了一定的调度压力是绝对必要的。在没有计划压力的情况下出现的几个问题是有趣的问题，“最好的是足够好的敌人”。我们的技术人员将更愿意处理我们感兴趣的问题，而不是将产品推向市场所需解决的问题。消除最后期限（又称时间表压力），我们将致力于解决这些有趣的问题，从而损害产品。

另一个问题是产品需要“足够好”。它不需要是完美的。工程师和科学家认为简化的假设在某些特殊情况下并不完全有效。图形设计师看到了其他人看不见的锯齿问题。程序员认为其体系结构中的疣对产品的行为造成零影响。“最好是足够的敌人”，这意味着有时候我们不得不忍受那些并不是真正问题的问题。

缺乏调度压力将导致产品拥有非常高的拥有成本。造成超支的原因是不良的日程安排。这可以有多种形式。低估了所需的工作量，无法解决依赖性，将人员添加到了已经很晚的项目中。仅举几个。

时间，质量，资源和功能部件数量都已连接。您可以修复其中的任何三个，并获取最后一个作为调度过程的输出。

问题的表达方式意味着时间是您的变量，而其他三个（质量，资源和要素数量）都是固定的。通过固定时间^*并让质量浮动，可以从稍微更改角度的问题中受益。

现在您的问题变成了：“时间限制是否会对质量产生负面影响”？这个问题的答案是肯定的 “是”：研究证实，人们在与数学有关的问题的压力下^**会变得更糟^**，他们以前没有广泛练习过（即尝试过50次以上），因此您朋友的父亲是对的。

^**这里有一个隐含的假设，即编程类似于做数学；我认为这个假设是公平的。

调度压力越大，交货时间越长，总拥有成本越多？

好吧，经理所做的任何安排而没有与技术负责人讨论的安排都很容易做到。很明显的事实是，不基于事实的计划或估计容易失败。

此外，避免基于证据的计划的管理人员也正在朝着项目的下一个失败迈进。有关此主题的研究很多，基于指标的调度是遵循的正确方法。

从右到左调度。

管理人员总是认为他们是史蒂夫·乔布斯（Steve Jobs），他著名的现实畸变区。在产品开发人员对他们进行教育之前，非技术经理可能常常对调度如此了解，就像法国早期电影“ Le voyage dans la lune”（“月球之旅”）是针对火箭科学的。

问题已经存在了一段时间。弗雷德·布鲁克斯（Fred Brooks）在《神话人月》中谈到了无肠估计。巴里·博姆（Barry Boehm）在他的“ W理论”管理方法提案中谈到了这一点。最近，史蒂夫·麦康奈尔（《代码完成》的作者）将“有原则的谈判问题”的概念引入“如何捍卫不受欢迎的时间表”中。

敏捷将项目范围推向了高度可见的地方。在敏捷宣言呼吁“在合同谈判的客户合作。” 我希望，它也能赋予被追究责任的人们权力。该规划的游戏避免了非技术性风险承担者强迫开发者，他们很久以前作出的承诺已通过要求或新发现改变了溢出。

如果您的组织拒绝敏捷，那么有很多与估计值校准有关的方法可以根据挣值重新制定时间表。我认为，挣值对于预测中的一些实际问题并不能起到很大的作用，但它可以帮助消除对项目速度的妄想以及对我们估计的事实的怀疑。

有一种说法是，您越早开始编写代码，所需的时间就越长。进度压力可能会迫使方法发生变化。有时是从瀑布到“像地狱般的代码”。这可能对质量产生负面影响，更不用说当员工无法尽力而他们的同事和未来的维护者看到他们处于最坏而不是最好的时候的士气。在这样的环境中，可以使用源代码控制，每日构建和测试（或持续集成和单元测试），代码审查来控制一定程度的混乱，使用经验丰富且技术精湛的团队，可以避免在后期增加员工的诱惑。项目和旧的备用数据库都需要加班。

在其他时候，方法的变化可能是从瀑布到迭代增量。我的经验是，管理层在接受敏捷方面进展缓慢。但是过了一会儿，出现了新的管理层，这些管理层更支持敏捷。时间拳击可以像预算一样-它可以迫使我们考虑有限资源的最佳利用。 Scrum有两个时间框-一个是每天用于团队成员之间反馈的时间，另一个是每月用于通过烧坏列表进行冲刺的时间。

知识共享许可-请访问http://en.wikipedia.org/wiki/File:Scrum_process.svg

您不需要软件工程文献。本科生提供的概念概率和统计信息就是您所需要的。

估算值就是估算值。这不精确，不能保证。对于任何估计，都有一定的可能性您会跑赢它，或者将其撞到鼻子上，并且有一定的可能性您会跑赢它。

概率101：p（超限或准确命中）+ p（超限）= 100％。

基于估计的时间表具有完全相同的特征。

您无法完全消除不确定性。总是会有超支的可能性。可能很小，伊朗有可能破坏您的办公大楼，但它仍然存在。您能做的最好的就是看一切，并尽可能减少不确定性。完成此操作后，如果幸运的话，您将有一个不确定性很小的时间表，并且双方各占50％的概率。

现在，考虑一下：如果将进度表拉入，则会降低进度不足或完全达到进度表的可能性。总数仍然必须达到100％。这种可能性在哪里？答案是进入超支概率。

通用动力/沃思堡分校很难学到这一点。他们对F-16C / D的发展进行了初步估算，并将其发送到整个食物链。更高层的人任意砍掉一年，然后将其发送给空军。直接的结果是，GD / FW推迟了一年的飞行测试，空军对此并不高兴。（请注意，“迟到一年”是按照修订后的时间表进行的，这意味着原始时间表是按目标进行的。）

我认为在项目中施加一定程度的压力是可以的，因为它有助于保持重点。

但是，如果压力不切实际，或者管理层与技术人员之间的沟通无法正常进行，则存在这样的风险，即调度压力会导致质量下降和/或交货延迟。

有经验的开发人员将知道，他/她不会提供完美的解决方案，而是会提供足够好的解决方案。因此，这样的开发人员给出的估算将已经反映出他们对特定项目足够好的理解。

有许多因素影响足够好的定义。

例如，该项目可持续几个月？如果该项目持续一年，则可以在项目开始时很快就编写该特别困难的模块的原型，然后您将有几个月的时间对其进行测试和调试，这是开发其他更常规模块的附带活动。（您可以让该模块在几个月内成熟，直到它足够好为止，因此您不需要从一开始就尝试并使其正确。）我发现此策略非常有效，但是您需要一个信任您并且可以让您满意的经理保持项目开放数月。另一个（不信任的）经理可能会敦促您尽快完成该模块（无论您是否稍后要修复它，以及这种方法最终是否会花费更多的时间）。

另一个例子：该项目是针对只有一个发行版的产品。然后，您可以尝试快速完成它，并依靠广泛的测试来确保产品按预期工作（快速而肮脏就足够了）。另一方面，如果该产品将要发布两个或三个版本，则最好花一些时间进行设计，以避免为以后的版本大量重写代码。（在这种情况下，快速而肮脏的环境不够好，因为三个版本的总开发时间更长。）

归根结底，我认为管理人员和技术人员之间的沟通不畅，以及对目前手头的项目是否足够好缺乏共识，可能会导致过度的调度压力，从而导致质量差/交货晚。

永远没有足够的时间来第一次正确地执行此操作，但是总是有足够的时间来稍后进行修复。