#18：在压力中放弃计划

当项目进 度遇到麻烦，开发者会放弃原先制定好的计划（Humphrey 1989）。问题的严重性并不在于放弃了计划，而在于没有建立一个备用方案，从而陷入编写-修复的循环中。在案例分析3-1中，团队因为按时进行第一次发 布（这很正常），因而放弃了他恩的计划。结果是，这一时间点之后的工作都是无计划的，甚至Jill开始用一部分时间来为她以前的队员工作，且没有一个人知道。

#19：在“模糊的前端”中浪费时间

“模糊的前端”指的是在项目开始之间所进行的验证和预算阶段。不少项目会花上几个月甚至几年的时间来进行这项工作，然后制定出一个非常紧迫的项目进度。从“模糊的前端”中节约几个星期或几个月的时间要比在经过压缩后的项目进度中节约时间容易、便宜和有保障得多。

#20：不充足的前期工作

比较紧急的计划会尝试着缩减一些不必要的工作，所以诸如需求分析、建构和设计等不能产生代码的工作成为了缩减的首要目标。有一次我接手了一个非常糟糕的项目，我说我想看一下项目的设计图，团队领导却说他们没有时间做出设计图。

这个错误还被称为“直接跳进编码阶段”，其结果是可以料想到的。在案例分析中，条状设计图被质量设计工作所代替。在产品可以被发布之前，设计图的工作只能被否决，更高的质量工作必须要立刻完成。缩减了前期工作的项目肯定要在后期工作中弥补这些工作，而花费的精力却是10倍甚至100倍的（Fagan 1976; Boehm and Papaccio 1988）。如果你没有额外的5个小时去把第一项工作做好，难道你能找到额外的50个小时去做接下来的工作吗？

#21：不充足的设计

在不充足的前期工作中，不充足的设计是一个特例。紧急的项目会使用来进行项目是设计的时间减少，同时高压的环境会让提出替代方案变得非常困难。项目设计的目的在于权宜而不是质量，所以在项目完成之前你需要一些非常耗时的项目设计周期。

#22：不充足的质量保证

一个紧急的项目会 通过减少设计和编码的检查、减少测试计划并只进行简单地测试。在案例分析中，设计回顾和编码回顾都只花了很少的时间以完成项目进度。而结果是，当项目进行 到关键的地方，仍有过多的程序错误导致推迟5个多月发布。这种后果是很典型的。在质量保证过程中减少了的工作，会在后期增加3到10天的工作量 （Jones 1994）。这会降低项目开发的速度。

#23：不充足的管理控制

在案例分析中，有一些管理控制措施会用来对即将发生的工作失误进行警告。但是，当项目出现了问题，这些管理控制被放弃了。如果你想让项目一直保持在轨道上，那你必须知道项目是否在轨道上，即有一个评定的标准。

#24：过早的或过于频繁的整合

在产品即将发布之前，应该做一些准备，如提高产品的星等、打印终使用文档、组织终的帮助系统挂钩、修饰一下安装程序、找出不能完成任务的组件等。在紧急的项目中，人们喜欢把项目过早地整合起来。由于在完成之间不能进行组合，于是有人在工作过程中对项目进行许多次的整合，直到成功。这些额外的整合并没有使项目受益，而只是浪费时间和拖延进度罢了。

#25：忽略了某些任务

如果人们不对已经完成的项目作仔细的记录，而忘记了其中某些不显眼的任务，那这些任务会越积越多。这些被忽略的工作会累计到整个进度的20%到30%。

#26：计划以后再抓紧

如果你要完成一个6个月的项目，而用了3个月的时间完成了2个月的工作，你会怎么做？许多开发人员会说他们计划以后再抓紧，但是他们从来没有这样做过。你在建立项目的时候你会知道得越多，其中包括还需要多少时间去完成它。所以这些信息也需要反映在项目日程中。

另一种错误来自于项目的变更。如果你的项目变了，那你需要完成该项目的时间也会发生变化。在案例分析3-1中，项目的主要需求改变了，而项目开发团队却没有制定相应的措施来对进度表作出调整。面对日益增多的新要求，而不在项目进度中反映出来，一定会导致不能按期交货。

#27：糟糕的编码

有些组织认为快速、随意的编码是同样快速开发的捷径。他们争辩道，如果开发者被充分地激励了，他们能克服万难。这远远不是实施，本书的其他章节会阐述其中原因。“企业家模式”通常是守旧的“编码-修复”模式的幌子，而且这种模式几乎不管用。这也是“错加错不等于对”的一个例子。

产品

以下列举一些在定义产品的时候所容易犯的错误。

#28：过高的需求

有些项目从一开始被提出了过高的需求。项目需求的提出往往会超过实际的需求，这无疑会增长项目的进度。用户对市场和开发速度的需求要比那些复杂的特性来得高，而且复杂的特性会大大改变项目的开发进度。

#29：过低的需求

即使你成功避免了过高的需求，平均每个项目都会在其生命周期中发生25%的改变（Jones 1994）。某一个改变至少会增长25%的开发进程，这对快速开发来说是致命的。