快速开发 pdf下载

压力大，进度失控，是几乎所有公司和商业软件开发团队长期面临的顽疾。在《快速开发》一书中，作者通过整体策略、具体的最佳实践以及宝贵的技巧提示来“驯服”失控的进度，推动项目向前推进。和《代码大全》一样，本书主题全面紧凑，更是从231个参考文献中萃取出含金量高的研究成果与硬核技术实践，具体特色如下：
● 一个可以应用于任何项目的快速开发策略及相关的27个最佳实践
● 客观公正地对比讨论快速开发策略（包括好的和不那么好的）：估算、原型、996、激励、团队、快速开发语言、风险管理以及其他技术主题
● 列出快速开发项目需要规避的36种经典错误，包括需求蔓延、质量缺陷和银弹综合征
● 26个实际案例生动刻画了对或错的根源以及如何确保软件开发项的顺利推进
《快速开发》作为一本实操指南，可以惠及广大程序员、技术领导和项目经理，帮助他们看清项目失控的真相与项目掌控的幻象，真正助力他们成为高效能的专业人士。

进度失控，几乎是每一个软件开发项目挥之不去的噩梦。如何从容赶急，如何通过正确的开发策略和原则，避免典型错误，有效地进行风险管理，从多个方面贯彻执行快速软件开发，都可以从本书中找到答案。《快速开发(纪念版)》借助于实际案例和数据，阐述了快速软件开发方法的要领和精髓。

《快速开发(纪念版)》前两部分描述快速开发的策略和理念，其中的案例讨论有助于读者清楚地领略到策略和理念在实践中的作用。第Ⅲ部分则由27个快速开发实践构成，对于技术领导、程序员和项目经理具有重要的参考和指导意义。

史蒂夫·麦康奈尔（Steve McConnell）

与比尔·盖茨和Linux之父林纳斯·托瓦兹齐名

《软件开发》杂志两届技术类图书震撼大奖得主

《软件开发》杂志两届生产力效率大奖得主

华盛顿西雅图大学校友会专业成就奖

IEEE计算机学会金牌核心奖章得主

《普吉特商业杂志》杰出青年人物奖

硅谷工程领导力峰会常年演讲嘉宾

前言

软件开发人员基本上处于进退两难的境地，一方面他们为解决开发中所碰到的各种问题殚精竭虑，几乎没有时间去钻研有效的实用技术；另一方面，如果不学习掌握软件快速开发方法，他们永远不会有足够的时间。

摆在他们面前的问题是，在“尽快交工”计划的压力下，如何在开发进度与软件质量之间达到最理想的平衡。如果开发人员需要放弃看电影、读报纸、购物、休闲、锄草或与孩子玩耍的所有时间，连续工作20 天才能按计划完成开发项目，指望他们投入很多精力研究软件可用性方面的问题又从何谈起？ 也就是说，除非我们把对项目进度的控制作为软件从业人员的必修课程，并为开发人员和经理们留出学习这方面专业知识的时间，否则，对开发人员来说，将很难有足够的时间进行有关方面知识的学习。

软件开发时间的问题普遍存在。一些调查表明，2/3 的项目超出了估算的时间(Lederer and Prasad 1992，Gibbs 1994，Standish Group 1994)。大型项目平均超出计划交付时间的20% ～ 50%，项目越大，超出计划的时间越长(Jones 1994)。一直以来，开发速度的问题都是软件行业必须解决的首要问题(Symons 1991)。

虽然软件开发速度缓慢的现象普遍存在，但有些组织还是在进行快速的开发。调查人员发现，同一行业的两家公司生产效率的差别有可能达到10:1，甚至更大(Jones 1994)。

本书的目的在于为当前是“10 ∶ 1”中“1”的一方提供所需的信息，帮助他们向“10”的一方转移。本书将帮助你把项目变得可以控制，从而以更短的时间向用户交付功能更为丰富的产品。在阅读本书时，你可以只看你感兴趣的内容，而无须阅读整本书。不管你的项目处于何种阶段，你都会在本书中找到能够帮助你改善当时境况的实用内容。

本书适用的对象

慢速的开发会对软件开发中的每个人造成影响，包括开发人员、项目经理、项目委托人和软件的最终用户——甚至包括其家庭和朋友。每个项目组在解决开发速度缓慢的问题时都有其各自的困难，本书将对常见难点逐一加以讨论。

本书旨在帮助开发人员和项目经理理解什么是可行的，帮助经理和用户认识哪些是可实现的，同时也讲述了开发人员、项目经理和用户之间可行的沟通方式与方法，从而使得他们能够共同找到一条最佳的途径以满足项目计划、成本、质量与其他目标的要求。

1. 技术领导

本书主要为技术领导或项目经理而编写。如果你是这样的角色，你可能经常要为提高软件开发速度承担主要责任，本书将告诉你如何去做，同时也描述了开发速度的限制，这将为你准确区分可实现过程与想象过程打下坚实基础。

本书中有些实用方法完全是技术性的，作为技术领导，学习并实施这些方法你应该没有问题，而另外一些实用方法则更多的是基于管理方面的考虑。可能你会问：“此处为什么包括这些内容？”在写书时，我做了这样一个简单的假设，即你是一个超级技术领导，你比快速的黑客还快，比疯狂的经理还强，能够同时解决技术问题与管理问题。我知道，有时这可能并不现实，但做这样的假设，可以让我专注地讨论中心的议题，而不必分心去描述“如果你是经理，这样做；如果你是开发人员，那样做。”我做的另一个假设是，技术领导同时肩负技术与管理工作，而不仅仅像字面想象的那样。技术领导经常肩负着为高层领导提供技术建议的职责，本书将帮助他们更好地完成这方面的工作。

2. 程序员

很多软件项目都是由程序员个人或自行管理的项目组来承担的，事实上，这就将参与项目的技术人员推到了技术领导的角色上。如果你是处于这一角色，那么本书将帮助你提高开发速度，基于同样的原因，也可以帮助你成为一名好的技术领导。

3. 项目经理

项目经理有时认为实现快速软件开发主要是技术工作。其实，作为一名项目经理，常常也会像开发人员一样，在改善软件开发速度方面有很多事情要做。本书将描述许多管理层面上的快速开发实用方法，当然，你也可以阅读技术方面的实用方法，以便更好地理解开发人员所做的一切。

本书的主要特色

我是以“软件开发人员的直觉”，围绕“为什么我们常见的快速开发方法都基本失败了”这一中心来构思本书的。书中讲述的所有实践活动都是特定环境下开发人员实际工作的真实写照，正是这个原因，本书提倡在学习使用书中的方法时，应根据自身情况，做一些自己的小小变革。

我个人对于软件开发的观点是，软件项目可以基于多种目的进行优化，如基于最低错误率、基于最快执行速度、基于最佳用户接受度、基于最佳维护性、基于最低的成本、基于最短开发周期等。软件工程方法的一个主要目的就是要平衡得失：你能够通过降低质量要求、降低可用性要求、让开发人员超时工作等手段优化开发时间吗？当项目结束的时间逼近时，你最终要压缩哪些环节？本书将回答这些关键性的权衡问题及其他一些问题。

1．提高开发速度

你可以在特定的项目中采用本书所描述的策略和最佳实践方法，尽可能地提高开发速度。通常，大多数人都能够通过采用本书中的策略和实践方法使开发速度大大改善。我可以说，对任何软件项目，你总会在本书中找到若干适用的方法。根据你的项目情况，“最佳开发速度”有可能并不像你期望的那样快，这不仅仅是运气，也与你没有使用快速开发语言，或还在使用过时的代码，或工作在嘈杂不利于生产的环境中有关。

2. 快速开发对传统理论的倾斜

本书中描述的有些方法并不属于典型的快速开发方法，如风险管理、软件开发原理和生命期计划，这些通常被看作是典型的“好的软件开发方法”，而非快速开发方法的范畴。然而，这些方法具有深刻的开发速度内涵，许多情况下，也称它们属于快速开发这一主题。本书将这些方法在提高开发速度方面的实践纳入到了与此相关的其他一些快速开发的实践方法中。

3. 实践方法的重点

对有些人而言，“实践”意味着“编码”，对这些人，我必须承认本书并不“很实践”。我避免基于编码的“实践方法”主要有两个方面的原因：第一，我已经写过一本800 页的有关编码实践方法与技巧的书籍《代码大全》，有关编码，我没有更多要说的了；第二，许多有关快速开发

的关键要素并非基于编码，而是一种策略和理念，有时，更是一种实践而非理论。

4. 快速阅读结构

我尽可能以更为实用的方式来组织本书的快速开发资料。本书的前两部分描述了快速开发的策略和理念，其中有约50 页的案例讨论，所以你可以清楚地看到策略和理念在实践中的作用。案例以明显的形式排版，如果你不喜欢这些案例研究，可以很方便地跳过。本书的其余部分是由一系列的快速开发实践构成的，这些实践也以便于快速查找的方式编排，你可以根据自己项目的需要，很方便地找到感兴趣的内容。本书描述了怎样使用这些实践中的方法、使用这些方法使进度缩短的程度以及伴随而来的风险。

我在书中也采用了一些图标和特殊文字，用来帮助你快速找到与你目前阅读内容有关的其他信息，指出应避免的典型错误、最佳实践中容易忽视的盲点，或查找书中提到的定量的支持信息。

5．有关快速开发的新思路

在软件开发领域，快速开发方面的谈论颇多。最近许多毫无价值的开发方法都打着“快速开发实践”的招牌，开发人员对这些所谓的“开发实践”非常气愤。尽管有些“实践”也还是有用的，但它们真正的作用被开发人员的冷嘲热讽所掩盖。

每种工具的提供者和每种方法的倡导者都想让人相信，他们的工具与方法可以满足你在开发中的所有需要。而本书的目的，就是指导你正确分析快速开发方面的各种资源，就像要将小麦从谷壳中分离出来一样，帮助你找到快速开发的真谛。

本书提供了一个可操作的模型，该模型可以帮助你客观地分析快速开发的工具，以及决定怎样将其为你所用。当一个人来到你的办公室说：“我刚从GigaCorp 公司获知，一种功能强大的新型工具可以将我们软件开发的时间缩减80% ！”你可能想知道这时你应该有何反应。我无需讲述任何有关GigaCorp 公司和它们新型工具的内容，当你读完本书的时候，你就会知道这种时候应该提什么样的问题，应该如何一分为二地判断GigaCorp 公司这种说法的可信程度，以及你如果决定采用这样的工具，应该怎样将它们集成到你的开发环境中去。

与其他的快速开发书籍不同，我并不要求你将所有的鸡蛋放到同样尺寸的篮子里。我认为不同的项目具有不同的需求，而一种方法很难解决项目计划中的所有问题。我一直以不能说是刻薄，也至少是挑剔的眼光看待这些快速开发实践的有效性，并一再假设这些实践不能很好地工作。

书中我也再访了一些曾大肆宣传的实践方法与工具，即便它们没有以前宣传的那样有用，但对其真正有用部分还是应该倡导的。

6. 为什么本书会这么厚

信息系统、办公软件、军事应用以及软件工程领域的开发人员都各自发现了一些有价值的快速开发实践方法，但不同领域的人员之间可能很难彼此交流经验。本书从各个领域收集最有价值的实践活动，很多快速开发的资料是首次汇总在一起。

是否每个想了解快速开发的人都有时间读完这几百页的书呢？可能性很小，大多是读到一半的时候可能就不得不简化那些无关紧要的部分了。

作为补救措施，我将本书的结构组织成便于快速阅读与选择性阅读的形式，在旅行途中或等车期间，也可以只翻阅一下简短的摘录部分。第1章和第2 章包含有理解快速开发产品所必须的一些内容，读完这些章节后，你就可以任意选择自己感兴趣的部分来阅读了。

本书写作动机

项目客户和项目经理对慢速开发问题的第一个反应经常是加大项目计划进度的压力，让开发人员超时工作。有75% 的大型项目和将近100% 的超大型项目计划进度压力过重(Jones 1994)，将近60% 的开发人员说他们感到工作压力在增加(Glass 1994c)，美国的开发人员每周工作时间在48 ～ 50 小时(Krantz 1995)，甚至更多。许多人认为工作负担过重。

在这样的环境中，软件开发人员的总体工作满意度在过去的15 年中大幅度下降就不足为奇了(Zawacki 1993)。项目的进度计划依靠对开发人员工作的拼命挤压来完成，导致开发人员开发工作负担过重，他们很自然会告诉他们的朋友与家人说，这一领域毫无乐趣可言。

显然这一领域还是有乐趣的。我们大多数人以前都从事过这样的工作，因而我们并不苟同编写软件只是为了获得报酬的说法。当然，在开发过程中的讨论会上确实会有一些不愉快的事情发生，这些不愉快大多会与快速开发的话题密切相关。

是该在软件开发人员与项目进度这个海洋间设置一道堤坝了，本书中，我试图树立一个堤坝标杆，以确保大海那边的狂潮不致于打乱开发人员的正常生活。

致谢

首先，衷心感谢本书的项目编辑Jack Litewka，感谢他在本书编辑出版过程中提出的建设性意见。同时也感谢Kim Eggleston 为本书所做的精美设计，感谢Michael Victor 的图表、Mark Monlux 的插图与说明。感谢Sally Brunsman，David Clark，Susanne Freet，Dean Holmes，

Wendy Maier 和Heidi Saastamoinen 对本项目的顺利出版所做出的贡献。还有很多朋友为本书的出版做出了各种各样的努力，有些人没有直接打过交道, 但我也衷心地向他们表示感谢。主要有艺术家JeanieMcGivern，ArtSource 的经理Jean Trenary 和微软出版社排版及校样管理员Brenda Morris，Richard Carey，Roger LeBlanc，Patrick Forgette， Ron Drummond，Patricia Masserman，Paula Thurman，Jocelyn Elliott，Deborah Long 和Devon Musgrave。

通过对数以百计图书与文章的挖掘与分析奠定了本书的基础构架，微软公司的技术资料馆为此提供了无法估量的帮助。Keith Barland 为此付出了艰辛的劳动与宝贵的时间，对此提供帮助的技术资料馆其他工作人员包括Janelle Jones，Christine Shannon，Linda Shaw，Amy Victor，Kyle Wagner，Amy Westfall 和Eilidh Zuvich。

本书也从大量的第三方审阅中获益匪浅。Al Corwin、Pat Forman、Tony Garland、Hank Meuret 和Matt Peloquin 从头到尾对本书进行了仔细推敲，

感谢他们对本书所做的工作，使得你手中的这本书并不像当初我写完的样子！同时我也从Wayne Beardsley，Duane Bedard，Ray Bernard，Bob Glass，Sharon Graham，Greg Hitchcock，Dave Moore，Tony Pisculli，Steve Rinn和Bob Stacy收到大量有益的意见与建议。David Sommer(11岁)也为本书的图14-3 的最后一个图片提出了一个好建议，谢谢David。最后，

我要感谢我的夫人Tammy，感谢她的精神支持与诙谐和幽默。我必须迅速启动第三本书的写作了，好让她能停止笑我，还管我叫业余作者！