Square-Cal 3.0 版要在2.0 版上市后的10 个月发布，项目经理Mickey 与上司Kim 讨论后
决定：他们将为项目组成员提供私人办公室、最新型的计算机以及免费的碳酸饮料，并且要
求开发者在前8 个月按照预先设计好的接口各自开发、8 个月之后进行可视化锁定，在最后
两个月中完成系统集成。一个完美的计划。
项目组成员各自做着自己的工作，而随着可视化锁定日期的来临，他们开始进行代码集成。
他们在可视化锁定最终截止日期前一天的下午2 点开始工作，但很快发现程序不能编译，更
不用说运行了。代码在编译时有数十个错误，而似乎每处理一个错误就会产生10 个以上的
新错误。他们一直干到午夜也没有结果，只好决定第二天再说。
但测试发现问题的速度远比开发人员解决问题的速度快，处理系统这部分的错误经常会导致
系统其他部分的问题。项目超期了，项目组成员在巨大的压力下工作，士气逐渐低落。最后，
整个软件开发过程花了15 个月的时间，公司错过了最佳的发布日期，市场份额也从第二位
下降到第四位。
生动的教材
看到上面的那段话，你有什么感想？我只觉得如有芒刺在背：在我主持开发的一个证券业务
系统中，几乎完全相同的故事就发生在我们的身上。在项目开始时，我们有近乎完美的计划；
到最后，我们的项目拖延了50%的时间，让客户极其不满。你呢？难道你对这个故事没有
似曾相识的感觉吗？
这是《快速软件开发：有效控制与完成进度计划》中研究的第一个案例。在McConnell 的这
本软件工程书籍里，这样生动的案例共有数十个。通过这些案例，以及无数准确而有说服力
的统计数据，作者把“软件工程”用一种精确的语言描述出来。在这里，软件工程不是玄不
可及的空谈，而是每天都发生在你身边的故事。
作者在前言中这样写道：
项目客户和项目经理对开发速度过慢的第一个反应经常是加大项目计划进度的压力，让开发
人员超时工作。截至1995 年，有75%的大型项目和将近100%的超大型项目计划进度压力过
重，将近60%的开发人员说他们感到工作压力在增加。美国的开发人员每周工作时间是48~50
小时，甚至更多。许多人认为工作负担过重。
在这样的环境中，软件开发人员的总体工作满意度在过去15 年中大幅度下降就不足为奇了。
项目的进度计划依靠对开发人员工作的拼命挤压来完成，导致开发人员工作负担过重，他们
很自然会告诉他们的朋友与家人：这一领域毫无乐趣可言。
显然这一领域还是有乐趣的。我们大多数人以前都从事过这样的工作，因而我们并不苟同编
写软件只是为获得报酬的说法。当然，在开发过程中的讨论会上确实会有一些不愉快的事情
发生，但是这些不愉快大多会与快速开发的话题密切相关。
是该在软件开发人员与项目进度这个海洋中设置一道堤坝了。本书中，我试图树立一个堤坝
标杆，确保大海那边的狂潮不致大乱开发人员的正常工作。
读者大可不必迷惑于本书的名字。所有的软件工程方法，其最终目的无非是在保证产品质量
的前提下提高开发速度。这本书的主旨就是从软件工程学的角度来加速软件开发的过程。所
以，你完全可以放心的把“快速软件开发”理解为“有效的软件开发”或“实用软件工程方
法”，没有问题。
另一方面，由于本书优美的格式和丰富的内容（不要着急，我还会专门介绍这些），以及作
（译）者认真负责的态度和幽默诙谐的语言，我认为它完全可以并且应该成为一本传统软件
工程（同样不要着急，我会在后面解释这个词）方面的高级教材。
按照作者的说法，本书面向的读者是团队领导人、项目经理和程序开发人员。在阅读本书之
前，读者应该具有软件工程方面的基础知识。
传统软件工程的经典
首先应该解释一下“传统软件工程”这个词。必须声明，这个词并未正式出现在任何科技文
献中，乃是我凭着自己对软件工程的一点理解生造出来的，也没有非常严格的定义。在这里，
“传统软件工程”是指1968 年德国NATO 会议之后产生的、以瀑布模型和结构化分析及设计
为代表的一系列软件工程方法，其主要特征是强调生命周期前期的需求分析，不鼓励后期的
需求变化。与之相对的，则是2001 年2 月“敏捷软件开发联盟”成立之后出现的各种敏捷
开发方法。它们的主要特征是不做过多的前期分析，鼓励需求变化，甚至主动拥抱变化。其
代表性的方法就是著名的XP（极限编程）[Bec, 00]。
我也是一个程序员。看过了不少的编程书籍，迄今为止对我的编程能力和思想影响最大的，
当属《设计模式》[GoF, 95]。不夸张的说，一本《设计模式》，让我的编程能力在两个月内
提高了整整一个档次。为什么会有这样的奇效？Vlissides 教授曾经说过，设计模式的作用有
两点：
1. 用一种相似的格式记录所有人的经验，方便后来人阅读和理解。
2. 为开发者提供通用的词汇表，方便开发者之间的交流。
从这样的角度来看，《快速软件开发》这本书中非常重要的两个部分可以叫做“软件工程模
式”（最佳实践）和“软件工程反模式”（典型错误）。尽管它们面对的是软件工程领域而非
程序设计领域，但是它们同样起着这两点作用，对于软件工程人员具有同样重要的指导意义。
在本书的第三部分中，作者用了160 多个页码来介绍传统软件工程方法中的27 条“模式”。
在以往的软件工程专著中，我曾经看到过这些方法中的一部分。但是作者不但将这些久经实
践验证的方法归纳整理起来，并且用一种统一的格式来描述它们：首先是效果，包括缩短进
度的潜力、可视性的改善、对风险的影响、一次成功的可能性、长期成功的可能性5 项量化
指标；然后是实施该方法主要的风险；最后总结该方法与其他方法的相互影响和必须作出的
权衡。只要有这样一张表，软件工程师就可以在一分钟之内评估出一种方法是否适用于自己
的项目，并决定是否采用该种方法。
来看一个例子（摘自第28 章，“外包”）:
外包就是把软件开发承包给第三方厂商而不是在公司内部开发。承包方在特定的领域有着较
丰富的经验，能够在给定的时间内投入足够的开发人员，并且备有一个大的程序库可提供重
用源码。由于上述因素，公司可以很快完成一个新项目。在一些情况下，外包能够节约开发
成本。
效果
*** 缩短原定进度的潜力：极好
*** 过程可视性的改善：无
*** 对项目进度风险的影响：增大风险
*** 一次成功的可能性：大
*** 长期成功的可能性：很大
主要风险
*** 把专业知识扩散到其他公司去
*** 失去对进一步开发的控制
*** 泄露机密信息
*** 丢失进度可视性和对进度的控制
主要的相互影响和权衡
文章来源于领测软件测试网 https://www.ltesting.net/