3.3　典型错误一览

一些无效的开发实践经常被许多人选用，这种可预测会带来坏结果的行为称为“典型错误”。大多数这类错误表面上都有诱惑性，比如你想挽救进度滞后的项目吗？加入更多的人员！你想缩短项目计划时间吗？使项目计划更具有挑战性！你的某位成员与项目组其他人之间矛盾重重？等项目结束后再解雇他！有急需完成的项目？尽快找到可用的开发人员，并尽快开始项目！

开发人员、项目经理和客户做决定通常都有很好的理由，经常发生这些典型错误的部分原因是由于它们有诱人的前景。但由于它们经常发生，因此其连锁反应经常可以预见，而且典型错误很少产生人们期望的结果。

图3-2列举了36种典型错误，每种错误我个人至少都见过一次，我自己也经历过一些典型错误。可以看出，即使是主宰项目的经理和技术总监，也无力回天。许多错误在案例研究3-1中已经出现。这些错误的共同特点是，如果能彻底避免这些错误，你就可能做到快速开发；但如果避不开它，开发就只能缓慢进行。

如果这些错误似曾相识，你就要警惕了——其他许多人也是这么做的。一旦理解了它们对开发速度的影响，就可以在项目计划中使用这种错误列表，并进行风险管理。

有些对开发速度影响大的错误将在本书其余部分相应的章节中讨论，其他错误以后不再讨论。为便于参考，错误列表按人员、过程、产品和技术四个开发维度划分。

3.3.1　人员

以下是与人员有关的典型错误。

典型错误1：挫伤积极性

反复的研究表明，激励可能比其他因素对生产效率和项目质量的影响更大（Boehm 1981）。在案例研究3-1中，贯穿整个项目过程，所采取的管理行为一直在挫伤人员的积极性。从项目开始时虚情假意地激励，到要求工作到深夜，从老板长时间休假而人员假期加班，到项目结束时每加班小时不足1美元的奖金，都是如此。

典型错误2：人员素质低

在激励之后，项目组人员的能力或者成员之间的关系可能对生产率有巨大的影响（Boehm 1981，Lakhanpal 1993）。聘请能力欠佳的人员极大地影响着快速开发。在案例研究中，人员的选择着眼于尽快聘请到人，而不是在项目周期中工作最好的人。这种方法可以使项目尽早启动，但不能确保项目尽快完成。

典型错误3：问题员工失控

不能很好地处理有问题的人员也会威胁开发速度，这是个很常见的问题。自从温伯格（Gerald Weinberg）于1971年出版《程序开发心理学》（Psychology of Computer Programming）后，这个问题也变得很好理解了。不对有问题的人员采取措施是项目组成员对领导最常见的抱怨（Larson and LaFasto 1989）。在案例3-1中，项目组知道Chip是个“坏苹果”，但项目组领导对此没有采取任何措施，结果就是重做Chip的所有工作，这是应该预料到的。

典型错误4：英雄主义

有些软件开发人员过于强调项目英雄主义，认为某种英雄主义是有益的（Bach 1995）。但我认为任何形式的英雄主义都将是弊大于利。在前面的案例中，中层管理者更重视积极的态度，而对项目的平稳推进和非常重要的进度报告关注不够。结果导致直到最后一刻，才发觉和认识到即将发生的进度拖延。一个小的开发组及其直接管理者肩负着整个公司的重任，他们不承认他们的进度有麻烦。强调个人英雄主义会导致发生额外的风险，也会削弱软件开发过程中多个角色的合作。

当有些项目经理过于强调必胜信念时，他们就会鼓励个人英雄主义行为。根据对准确的、有时甚至是沮丧的报告的分析，团队自信度的提高，会削弱项目经理改正错误的能力。直到损害发生时，他们才知道需要采取补救措施。正如迪马可（Tom DeMarco）所说，随着自信度的逐步上升，小的挫折就会演变成真正的灾难（DeMarco 1995）。

典型错误5：给延期的项目加人

这也许是个最常见的典型错误。当项目工期拖后，认为加入人员可以提高项目组目前的生产率。布鲁克斯（Fred Brooks）把给延期的项目加人比作火上浇油（Brooks 1975）。

典型错误6：办公环境拥挤嘈杂

绝大多数的开发人员对工作环境不满意。大约60%的人员抱怨他们的办公环境既不安静、也不隐蔽（DeMarco and Lister 1987）。办公环境安静、隐蔽的人员比环境嘈杂和拥挤中的人员往往表现更好。嘈杂、拥挤的工作环境会延长项目工期。

典型错误7：开发与客户之间有摩擦

有几种情况会导致开发人员与客户之间发生摩擦。例如，当开发人员拒绝在客户提出的开发计划上签字，或者他们无法履行承诺按时交付的项目时，客户可能会感到开发人员不配合，而开发人员则认为客户在已经确定需求之后固执己见地坚持不现实的项目计划或者进行需求变更。这可能只是简单的两组人员之间的个性冲突。

这种冲突的主要原因是缺乏沟通。缺乏沟通还会导致缺乏对需求的准确理解和导致用户界面设计较差，最坏的情况是客户拒绝接收已完工的产品。一般情况下，客户与开发人员之间摩擦的加剧会导致双方考虑取消项目（Jones 1994）。这种摩擦耗费时间，它会转移客户和开发人员双方对项目工作的注意力。

典型错误8：不现实的预期

导致开发人员和客户或项目经理之间产生摩擦最常见的原因之一是不现实的预期。在案例研究3-1中，Bill并没有充分的理由认为Giga-Quote项目在6个月内可以开发完成，那只是执行委员会想要完成的时间。Mike没有能力改变这个不现实的期望是导致所有问题的主要根源。

另外一些情况，根据过于乐观的计划提供资金会使项目经理或开发人员碰到麻烦，有时他们会承诺天上掉馅饼那样的功能集。

虽然，不现实的预期本身不会延长项目周期，但它会助长认为项目开发周期太长这种风气，而这是有害的。Standish Group的调查将现实的预期作为影响商业软件项目成功的前5个因素之一（Standish Group 1995）。

典型错误9：缺乏有效的项目支持

快速开发的许多方面都需要高层对项目的支持，包括实际的计划、变更控制以及新型开发方法的采用。没有有效的高层支持，组织内部的其他高层人员会强迫你接受不现实的项目完成日期，或者进行会破坏项目的变更。澳大利亚的咨询顾问汤塞特（Rob Thomsett）（《极限项目管理》的作者）得出结论，缺乏有效的高层支持事实上注定了项目的失败。

典型错误10：缺乏各种角色的齐心协力

软件开发中所有主要人员必须齐心协力专注于项目，包括高层支持者、项目领导、项目成员、市场人员、最终用户、客户和任何项目介入者。只有当你完全投入到项目中，才能允许准确调整各种角色的协同关系，没有全身心的投入，不可能达到快速开发。

典型错误11：缺乏用户参与

调查发现，IS项目成功的第一个原因是用户的参与（Standish Group 1995）。没有用户早期参与的项目充满需求误解的风险，易受项目后期功能蔓延的威胁。

典型错误12：政治高于物质

有报告提出，有四种不同政见类型的项目组（Constantine 1995a）。“政治家”型项目组强调“管理至上”，精力主要集中在与他们经理的关系上。“研究者”型项目组的精力集中在研究和收集信息上。“独立主义者型”项目组单打独斗，建立项目分界，以划清与非项目成员的关系。“多面手”型项目组对每件事都完成一点，他们往往保持好与经理的关系，执行一些信息侦察与收集活动，并通过正常的流程保持与其他项目组的协同。报告还指出，项目初期，高层管理部门都看好政治家和多面手型这样的项目组，二者都运行很好；但一年半以后，政治家型项目组就会沦落到死亡边缘。将政治加诸于结果之上对于快速开发来说是致命的。

典型错误13：想当然

我很惊讶怎么会有那么多软件开发问题是由于想当然造成的。你有多少次听到像这些人的说法。

·　“项目组没人真正相信他们能够按给定的计划进度完成项目，但他们认为如果每个人能够努力工作，并且不出现问题，他们可能会很幸运地按时完成项目。”

·　“我们项目组无须做太多协调产品的不同部分的接口工作，况且我们已经就某些事情进行了沟通，接口是相对简单的，所以，可能只花1～3天时间就可消除错误。”

·　“我们知道那个承包数据库子系统的外包方报价较低，很难看得出以他们的水平怎么来完成他们项目建议书中确定的功能，他们没有其他外包方那样的丰富经验。但也可能他们会通过努力弥补经验的不足并按时交付产品的。”

·　“我们无须向客户演示对产品原型所做的最终修改，我可以确认我们知道他们现在需要什么。”

·　“项目组说他们必须付出更多的努力才能满足最后发布期限的要求，他们错过第一个里程碑已经有一些天了，但我想他们能够及时赶上。”

想当然并不是乐观主义，它是你闭上眼睛毫无理由地希望某事将像想象的那样运作。项目初期想当然会导致项目结束时的大崩溃，它会破坏整个项目计划，并可能成为许多软件问题的根源。它所产生的问题比所有其他问题的组合导致的问题还多。

3.3.2　过程

由于与过程相关的错误浪费人员的聪明才智与努力，所以它会放慢项目进程。下面是与过程相关的影响最坏的错误。

典型错误14：过于乐观的计划

构建一个历时3个月的应用软件所面临的挑战是完全不同于构建一个历时1年的应用软件所面临的挑战的。制定过于乐观的项目计划相当于自己为项目失败画出了底线，破坏了有效的项目计划，并会缩短关键性的前期开发活动，如需求分析和设计。它也向开发人员施加了额外的压力，会对长期开发人员的自信心和生产率造成巨大的伤害。这是案例研究3-1中存在的主要问题。

典型错误15：缺乏风险管理

有些错误并不足以称为典型错误，这些错误称为“风险”。作为典型错误，如果你不主动管理这些风险，那么只要有一件事做错就会将一个快速开发项目变成一个慢速开发项目。这种风险的管理失败就是典型错误。

典型错误16：承包方导致的失败

有的公司急于完成项目，因此当不能在内部开发时，有时会把部分工作外包出去。但承包方往往延期交付，而且交付的东西质量差，无法接受，或者说不符合当初的规格说明（Boehm 1989）。当你将外包方带入整个项目计划中时，像“不稳定的需求”和“不合规定的接口”这样的风险就可能被放大。如果对承包方不加认真管理，签约外包非但不会加快项目速度，反而会降低项目速度。

典型错误17：缺乏计划

如果不订计划就进行快速开发，是达不到目的的。

典型错误18：在压力下放弃计划

项目组制定了计划，但当项目遇到麻烦时就放弃计划（Humphrey 1989）。项目失败的原因不在放弃计划本身，而是不能制定替代措施，并一头栽进编码和问题处理中去。在案例研究3-1中，当他们错过第一个里程碑后，项目组就放弃了他们的计划，这是很典型的错误。那个里程碑以后的工作是缺乏协调的和笨拙的，此时，Jill已经开始用部分时间为她从前的项目工作了，却甚至没人知道。

典型错误19：在模糊的项目前期浪费时间

模糊的项目前期（fuzzy front end）是项目开始之前的时间，通常是花在审批和预算过程中。项目前期花上几个月或几年的时间并不奇怪，然后进入压缩项目计划的关口。在项目前期节省几周或几个月的时间比将开发计划压缩同样的时间来得更容易、更廉价，风险也更少。

典型错误20：前期活动不合要求

由于需求分析、总体设计和详细设计并不直接生成编码，因此对于急于砍掉不必要活动的项目来说，它们是最容易想到的目标。我曾接手过一个最悲惨的项目，当我要求看设计时，项目组领导告诉我：“我们没有时间做设计。”

这种错误——也可称作“直接跳到编码”，其结果有很多是可以预测到的。在案例研究3-1中，柱状图报表中的设计方案意味着需要进一步设计。在产品发布前，必须剔掉临时方案，用高质量的取而代之。前期被跳过的活动的项目通常在后期会以10到100倍的代价来完成（Fagan 1976；Boehm and Papaccio 1988）。如果一项工作在项目初期需要5小时完成，那么在项目后期你至少需要50小时才能完成它。

典型错误21：设计低劣

前期活动不合要求的一个特殊情况就是设计低劣。一个紧急项目由于没有足够的设计时间，以及由于高压环境所导致的设计缺乏周密考虑，往往导致设计失败。设计强调的重点是权宜而非质量，所以，在你完成整个系统前，往往需要几个耗时的设计周期。

典型错误22：缺少质量保证措施

紧急项目经常会砍掉一些表面看来不重要的工作，如取消设计和编码审核、取消测试计划、只进行必要的功能测试等。在案例研究3-1中，为了实现项目计划，设计审核和编码审核工作被大大削减，其结果就是，当项目达到了功能完成这个里程碑之后，还有5个多月的麻烦事情需要处理。项目前期砍掉1天的质量保证（QA）活动，到项目后期就需要3到10倍的处理代价（Jones 1994），这是个很典型的结果。这种削减会破坏项目的开发速度。

典型错误23：缺少管理控制

在案例研究中，项目过程中很少设置管理控制点，缺乏必要的计划拖延迫近警告，而仅有的几个控制点是设在项目遇到麻烦打算放弃的那几个点上。在保证项目是否按正常轨道运行前，你必须能够说出它所处的阶段和位置。

典型错误24：太早或过于频繁的集成

产品按计划发布前，会经历一个推出产品的准备过程，进一步改进产品性能、打印最终的文档、集成最终的帮助系统、美化安装程序、剔除不能及时发布的功能等。对于紧急项目，倾向于尽早集成。由于不可能按希望的那样进行产品集成，有些快速开发项目试图在项目结束前，进行6次或更多次的项目集成。这种额外的集成不利于产品。它们只是在浪费时间，延长进度。

典型错误25：项目估算时遗漏必要的任务

如果人们不能仔细记录以前项目的情况，他们就可能会忘掉一些可视性较差的任务，但这些任务是必须的。遗漏这些任务会导致项目计划延长20%～30%（van Genuchten 1991）。

典型错误26：后期赶进度

一种重新评估的错误是对计划拖延的不适当的反应。如果你的项目为期6个月，花3个月的时间才完成2个月的里程碑，你会怎样做？许多项目只是简单地决定将进度赶上原计划时间，但他们从来都做不到。当构造产品时，你会学到许多有关产品的知识，包括构造产品需要什么，学到的这些东西需要反映到重新安排的计划中。

另一种重新评估错误来自于产品变更。如果你正在构建的产品发生了变更，你需要构建的时间也需要变更。在案例研究3-1中，原始项目建议书和启动的项目之间的主要需求变更没有体现在相应的计划和资源的重新评估上，增加了一堆新功能，但没有做相应的计划调整，这必然导致无法按期完成项目。

典型错误27：噩梦式编码

有些组织认为，直接随意地进行编码是实现快速开发的捷径。如果开发人员足够自信和理智，他们可以克服任何障碍。通过本书所揭示的种种原因可知，事实上并非如此。这种方法有时表现为开发的“企业家”方法，但它实际是传统的“边编码边修改”方法和含糊进度的结合，这种结合大多以失败告终。这是“错上加错仍然是错”的典型例子。

3.3.3　产品

以下是与产品定义有关的典型错误。

典型错误28：需求镀金

项目开始时，有些项目具有比实际需求多得多的性能。性能往往以超出实际需要的方式提出，而这会不必要地延长软件计划时间。与市场和开发人员相比，用户往往对复杂的功能并不感兴趣，而复杂功能的增加与开发进度延长的时间简直是不成比例。

典型错误29：功能蔓延

即便你已成功地避免了需求镀金，在整个开发过程中，项目平均仍会有25%的需求变更（Jones 1994）。这样的变更对软件计划至少会有25%的影响，这对快速开发项目可能是致命的。

典型错误30：开发人员镀金

开发人员着迷于新的技术，有时渴望尝试使用开发语言或开发环境中新的特性或功能，或者在自己的产品中实现那些从其他产品中发现的华而不实的功能，而不管这些功能是否需要。设计、实现、测试、文档化以及支持这些不必要的功能会延长整个项目的进度。

典型错误31：协商与谈判

当管理者批准进展慢于预期进度的项目顺延并在进度更改之后加入全新任务的时候，会发生一种奇怪的商讨策略。这种情况的根本原因很让人费解，因为批准进展顺延的管理者已经含蓄地承认进度有问题。但一旦纠正了进度，这个人又会采取明确的行为再度犯错。这对进度毫无帮助，反而会破坏进度。

典型错误32：研究导向的开发

Cray超级计算机公司的设计人员克雷（Seymour Cray）说，他不想同时在两个以上领域超越工程界限，因为失败的风险太高（Gilb 1988）。许多软件项目可能都会从克雷学习到一些教训。如果项目存在要求创建新的算法逻辑或者采用新的计算技术这样的计算机科学约束，就不能做软件开发，只能做软件研究。软件开发进度是完全有理由可以预测的，而软件研究进度甚至理论上都不可预知。

如果产品目标是追求品质完美——运算法则、速度、内存使用，等等，你就可以假定你的进度计划具有高度的投机性。如果想达到完美的目的，而项目中存在一些弱点——人员短缺、人员素质低、需求含糊不清、与外包商接口不稳定，那么，你可以将这个可预测的注定要失败的计划扔到窗外了。如果是想提高产品，那做就是了，只是不要指望它有多快。

3.3.4　技术

余下的典型错误是有关现代技术的使用与误用的。

典型错误33：银弹综合征

在案例研究中，过于相信以前没有采用过的技术的宣传（报表生成器、面向对象的设计以及C++），缺少在特定环境下使用这些工具的必要信息。当项目组锁定到一种新的方法、新的技术或严格的过程上并期望用它们来解决他们的进度问题时，注定会失望的（Jones 1994）。

典型错误34：过高估计了新技术或方法带来的节省量

无论组织采用多少新工具或方法，以及这些工具或方法有多好，他们很少能够大幅度提高生产率。这些方法的优点部分被学习掌握它们所花费的大量时间和过程所抵消。新的方法还要承担由此而带来的新的风险。你可能更喜欢慢慢地、有条不紊地体验与提高，而不是剧烈的变化。案例研究3-1中，项目组可以预估因采用新技术而带来的生产率的提高最高可达到10%，而不能假设可以提高1倍的生产率。

项目重复使用以前项目的代码，是过高估算的一个特例。重用是一种非常有效的方法，但时间节省很少像预期的那样多。

典型错误35：项目中间切换工具

老的产品不能很好地运行时，对其改进升级，如从3.0版本到3.1版本，有时甚至是到4.0版，应该讲是合理的。但当你在项目中间更换工具时，伴随采用新工具而来的人员学习和掌握的过程、重复的工作、不可避免的错误会彻底抵消它所带来的益处。

典型错误36：缺乏自动源代码控制手段

缺乏自动源代码控制会使项目遭受不必要的风险。如果两个开发人员负责开发程序的同一部分，没有自动源代码控制工具，他们就必须人工协调他们之间的工作。他们可能同意将程序的最新版本放到主控目录中，而每次向主控目录写入文件前必须彼此进行检查。但有些人可能总是覆盖其他人的文件。人们在为旧接口开发新代码时，如果发现自己使用的是错误版本的接口，就只能重新设计代码了。而由于你没有办法重建用户正在使用的版本，你也就无法重现用户报告的错误。通常，每个月源代码的改变量大约在10%左右，而人工源代码控制难以维护这样的变更频率（Jones 1994）。

表3-1包含典型错误的完整列表。