快速软件开发(珍藏版)
点击看大图基本信息
- 作者： (美)Steve McConnell [作译者介绍]
- 译者： 席相林
- 丛书名： 微软技术丛书
- 出版社：清华大学出版社
- ISBN：9787302178132
- 上架时间：2008-7-11
- 出版日期：2008 年8月
- 开本：16开
- 页码：508
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件方法/软件工程
编辑推荐
·一个快速开发策略（可以应用于任何一个项目）和27个使此策略发挥效用的最佳实践
·以客观角度讨论优秀和一般快速开发实践：估算、原型化、强迫加班、激励、团队合作、快速开发语言、风险管理，等等
·列出快速开发项目应该避免的典型问题，包括需求蔓延、质量低下和银弹综合症等
·以丰富的案例生动地描绘了错误是怎样发生的，如何纠正，如何把握项目前进方向
内容简介回到顶部↑
进度失控，几乎是每一个软件开发项目挥之不去的噩梦。如何从容赶急，如何通过正确的开发策略和原则，避免典型错误，有效地进行风险管理，从多个方面贯彻执行快速软件开发，都可以从本书中找到答案。本书借助于实际案例和数据，阐述了快速软件开发方法的要领和精髓。
本书前两部分描述快速开发的策略和理念，其中的案例讨论有助于读者清楚地领略到策略和理念在实践中的作用。第iii部分则由27个快速开发实践构成，对于技术领导、程序员和项目经理具有重要的参考和指导意义。
本书前两部分描述快速开发的策略和理念，其中的案例讨论有助于读者清楚地领略到策略和理念在实践中的作用。第iii部分则由27个快速开发实践构成，对于技术领导、程序员和项目经理具有重要的参考和指导意义。
作译者回到顶部↑
本书提供作译者介绍
Steve McConnell，软件行业最有影响力的三大人物之一，与Bill Gates和Linus Torvalds齐名，曾两度获得《软件开发》杂志优秀震撼大奖。
Steve McConnell是Construx公司的首席软件工程师，负责领导客户软件项目，讲授课程和著书立说。他还是IEEE Software杂志的总编和软件工程知识体（SWEBOK）项目构建知识领域的领导。Steve曾先后就职于微软公司、波音公司和西雅图地区的公司。他拥有惠特曼大学学士学位和西雅图大学软件工程硕士学位。
.. << 查看详细
Steve McConnell是Construx公司的首席软件工程师，负责领导客户软件项目，讲授课程和著书立说。他还是IEEE Software杂志的总编和软件工程知识体（SWEBOK）项目构建知识领域的领导。Steve曾先后就职于微软公司、波音公司和西雅图地区的公司。他拥有惠特曼大学学士学位和西雅图大学软件工程硕士学位。
.. << 查看详细
目录回到顶部↑
第1部分 有效开发
第1章 欢迎学习快速开发
1.1 什么是快速开发
1.2 实现快速开发
第2章 快速开发策略
2.1 快速开发的总体策略
2.2 开发速度的四维
2.2.1 人员
2.2.2 过程
2.2.3 产品
2.2.4 技术
2.2.5 协同
2.3 快速开发的一般分类
2.3.1 有效开发
2.3.2 侧重于最佳进度的有效开发
2.3.3 全面快速开发
2.4 哪一维更重要
2.5 快速开发的权衡策略
深入阅读
第3章 典型错误
第1章 欢迎学习快速开发
1.1 什么是快速开发
1.2 实现快速开发
第2章 快速开发策略
2.1 快速开发的总体策略
2.2 开发速度的四维
2.2.1 人员
2.2.2 过程
2.2.3 产品
2.2.4 技术
2.2.5 协同
2.3 快速开发的一般分类
2.3.1 有效开发
2.3.2 侧重于最佳进度的有效开发
2.3.3 全面快速开发
2.4 哪一维更重要
2.5 快速开发的权衡策略
深入阅读
第3章 典型错误
译者序回到顶部↑
译 者 序
第29届奥林匹克运动会即将在北京隆重举行的前夕，Steve McConnell的《快速软件开发(珍藏版)》由清华大学出版社出版发行，实为一件极为庆幸的大好事。
随着信息技术的飞速发展，我国从事软件开发业务的公司数量在急剧增加，软件开发队伍成倍膨胀，软件开发项目数目和规模也越来越大。长期以来，软件开发人员一直受估算不准、功能蔓延、团队人员流失等问题的困扰。巨大的进度压力，突然而至的风险，总是使这支队伍的开发工作征程步履艰难。尽早、有效地解决这些问题是每个软件人员的期待。我的工作方向转移到项目管理领域以后，也在力图以现代项目管理的知识体系和工具、方法找到一些解决这些问题的途径。
2001年初，我有幸阅读了McConnell撰写的这本《快速软件开发》(英文版)一书，书的内容深深地吸引着我，从头至尾逐章浏览本书以后，收获颇丰，如何解决这些困扰的思路日益清晰起来。
Steve McConnell是微软公司的一位经验丰富的软件顾问，他最初的工作是开发分布式商业软件，在5年中编写了5万行产品代码，积累了大量的实践经验。与此同时，他也进行更多的理论探讨，撰写了许多论文和书籍。“Rapid Development”就是佳作之一。除了这本书之外，他还撰写了“Code Complete: A Practical Handbook of Software Construction”，“Software Project Survivals Guide”和“After the Gold Rush:Creating a True Profession of Software Engineering”等多部著作。
在《快速软件开发(珍藏版)》这本书中，他先从正面提出了完整的软件开发战略，然后详细地阐述各种最佳实践，同时提供众多有价值的运作技巧，这些都有助于帮助项目开发人员缩短和控制开发的进度，保持软件项目健康推进。
本书分为三部分，共43章。
第Ⅰ部分，列举了软件开发中经常犯的36种错误，列出了常遇到的120多种风险，论述了实现快速开发的基本原则和战略。
第Ⅱ部分，以清醒的思路逐个专题地阐述了软件开发中的几个核心问题，包括进行估算、开发原型、编制现实的计划、激励、团队工作、快速开发语言、控制需求蔓延等的原则、技术和方法。
第Ⅲ部分，向读者推荐了有利于快速开发的27种行之有效的最佳实践，诸如变更控制委员会、选择恰当的生命期模型、有原则地谈判、W理论等，对于每条最佳实践的潜在效率和风险都进行了恰如其分的描述和
分析。
在本书的前16章中，McConnell都向读者提供了失败的案例和成功的案例，用不可辩驳的数据进行证明，以富有洞察力的趣事进行点缀。
这是一本为团队领导、经理和程序人员撰写的一本好书，是使软件开发工作更高效、更为现实的工作指南。
参与本书初次翻译和校对的人员有丁丽、朱莉、李华、陈新、陈蔚力、林鄂华、高福春、韩梅、韩蓬和黎缨。由席相林进行全文的统稿工作。冯炳根教授和王利文教授对全部译文进行了精心地校对，其中王教授校对了前两部分(第1～16章)，冯教授校对了第Ⅲ部分(第17～43章)。
为了本珍藏版的出版发行，本人对于前一版的全部译稿又进行了一次认真细致的整理和加工，纠正了存在的一些不足和问题，并在前16章的每一章，写了“译者注”，把本人对该章内容的理解和体会呈现出来与读者分享。冯炳根教授对本译文再次进行认真的校对和完善。
在整个过程中，清华大学出版社文开琪老师给予了详细的指导，汤斌浩老师对译文逐字逐句进行校对和推敲，不放过丝毫的疑点，他们严谨治学的态度令我非常敬佩。此外，北京中科项目管理研究所给予了项目管理方面的帮助。杜端甫教授、许书珎、许成绩、赵欣如、沈天阳、王星、张嘉飞等也提供了其他方面的帮助。本书是大家共同努力的结果，在此向参与该书翻译、校对和提供支持和关注的所有人员一并致谢。
书中译文中如有不当之处，恳请读者批评指正。
席相林
第29届奥林匹克运动会即将在北京隆重举行的前夕，Steve McConnell的《快速软件开发(珍藏版)》由清华大学出版社出版发行，实为一件极为庆幸的大好事。
随着信息技术的飞速发展，我国从事软件开发业务的公司数量在急剧增加，软件开发队伍成倍膨胀，软件开发项目数目和规模也越来越大。长期以来，软件开发人员一直受估算不准、功能蔓延、团队人员流失等问题的困扰。巨大的进度压力，突然而至的风险，总是使这支队伍的开发工作征程步履艰难。尽早、有效地解决这些问题是每个软件人员的期待。我的工作方向转移到项目管理领域以后，也在力图以现代项目管理的知识体系和工具、方法找到一些解决这些问题的途径。
2001年初，我有幸阅读了McConnell撰写的这本《快速软件开发》(英文版)一书，书的内容深深地吸引着我，从头至尾逐章浏览本书以后，收获颇丰，如何解决这些困扰的思路日益清晰起来。
Steve McConnell是微软公司的一位经验丰富的软件顾问，他最初的工作是开发分布式商业软件，在5年中编写了5万行产品代码，积累了大量的实践经验。与此同时，他也进行更多的理论探讨，撰写了许多论文和书籍。“Rapid Development”就是佳作之一。除了这本书之外，他还撰写了“Code Complete: A Practical Handbook of Software Construction”，“Software Project Survivals Guide”和“After the Gold Rush:Creating a True Profession of Software Engineering”等多部著作。
在《快速软件开发(珍藏版)》这本书中，他先从正面提出了完整的软件开发战略，然后详细地阐述各种最佳实践，同时提供众多有价值的运作技巧，这些都有助于帮助项目开发人员缩短和控制开发的进度，保持软件项目健康推进。
本书分为三部分，共43章。
第Ⅰ部分，列举了软件开发中经常犯的36种错误，列出了常遇到的120多种风险，论述了实现快速开发的基本原则和战略。
第Ⅱ部分，以清醒的思路逐个专题地阐述了软件开发中的几个核心问题，包括进行估算、开发原型、编制现实的计划、激励、团队工作、快速开发语言、控制需求蔓延等的原则、技术和方法。
第Ⅲ部分，向读者推荐了有利于快速开发的27种行之有效的最佳实践，诸如变更控制委员会、选择恰当的生命期模型、有原则地谈判、W理论等，对于每条最佳实践的潜在效率和风险都进行了恰如其分的描述和
分析。
在本书的前16章中，McConnell都向读者提供了失败的案例和成功的案例，用不可辩驳的数据进行证明，以富有洞察力的趣事进行点缀。
这是一本为团队领导、经理和程序人员撰写的一本好书，是使软件开发工作更高效、更为现实的工作指南。
参与本书初次翻译和校对的人员有丁丽、朱莉、李华、陈新、陈蔚力、林鄂华、高福春、韩梅、韩蓬和黎缨。由席相林进行全文的统稿工作。冯炳根教授和王利文教授对全部译文进行了精心地校对，其中王教授校对了前两部分(第1～16章)，冯教授校对了第Ⅲ部分(第17～43章)。
为了本珍藏版的出版发行，本人对于前一版的全部译稿又进行了一次认真细致的整理和加工，纠正了存在的一些不足和问题，并在前16章的每一章，写了“译者注”，把本人对该章内容的理解和体会呈现出来与读者分享。冯炳根教授对本译文再次进行认真的校对和完善。
在整个过程中，清华大学出版社文开琪老师给予了详细的指导，汤斌浩老师对译文逐字逐句进行校对和推敲，不放过丝毫的疑点，他们严谨治学的态度令我非常敬佩。此外，北京中科项目管理研究所给予了项目管理方面的帮助。杜端甫教授、许书珎、许成绩、赵欣如、沈天阳、王星、张嘉飞等也提供了其他方面的帮助。本书是大家共同努力的结果，在此向参与该书翻译、校对和提供支持和关注的所有人员一并致谢。
书中译文中如有不当之处，恳请读者批评指正。
席相林
前言回到顶部↑
前 言
软件开发人员基本上处于进退两难的境地中，一方面他们为解决开发中所碰到的各种问题殚精竭虑，几乎没有时间去钻研有效的实用技术；另一方面，如果不学习掌握软件快速开发方法，他们永远不会有足够的
时间。
摆在他们面前的问题是，在“尽快交工”计划的压力下，如何在开发进度与软件质量之间达到最理想的平衡。如果开发人员需要放弃看电影、读报纸、购物、休闲、锄草或与孩子玩耍的所有时间，连续工作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. 项目经理
项目经理有时认为实现快速软件开发主要是技术工作。其实，作为一名项目经理，常常也会像开发人员一样，在改善软件开发速度方面有很多事情要做。本书将描述许多管理层面上的快速开发实用方法，当然，你也可以阅读技术方面的实用方法，以便更好地理解开发人员所做的一切。
本书的主要特色
我是以“软件开发人员的直觉”，围绕“为什么我们常见的快速开发方法都基本失败了”这一中心来构思本书的。书中讲述的所有实践活动都是特定环境下开发人员实际工作的真实写照，正是这个原因，本书提倡在学习使用书中的方法时，应根据自身情况，做一些自己的小小变革。
软件开发人员基本上处于进退两难的境地中，一方面他们为解决开发中所碰到的各种问题殚精竭虑，几乎没有时间去钻研有效的实用技术；另一方面，如果不学习掌握软件快速开发方法，他们永远不会有足够的
时间。
摆在他们面前的问题是，在“尽快交工”计划的压力下，如何在开发进度与软件质量之间达到最理想的平衡。如果开发人员需要放弃看电影、读报纸、购物、休闲、锄草或与孩子玩耍的所有时间，连续工作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章
快速开发要点：参阅第6章
某产品经理告诉我，为改变现状，他想建立一套产品开发权限控制体系，该体系要更注重产品质量、防止功能蔓延、控制项目进度，并能够按计划交付产品。
但是，当实际运作项目时，他又不由自主地把将产品迅速推向市场放在了最优先的级别上。如何保证产品的可用性？我们没有足够的时间。如何保证产品的性能指标？可以等等再说。如何保证产品的可维护性？下一个项目再说。如何进行产品测试？我们的用户现在就要产品，马上送货。 这个产品经理并非只是某个特定的产品经理，他几乎是我为之工作的所有产品经理的化身。这种情形在整个软件业日复一日地重复着。开发时间已经变成头等重要的问题，以致忽略了其他应考虑的因素，甚至那些最终会影响开发时间的因素。
1.1什么是快速开发
对有些人而言，快速开发是通过使用一个得力的工具或方法实现的；对黑客而言，快速开发可能意味着36个小时连续不断地编码；对信息工程师而言，快速开发就是RAD——CASE（计算机辅助软件工程）工具、积极的用户参与和紧凑的时限（timebox）的集合；对纵向市场的程序员而言，快速开发就是利用微软的最新版本的Visual Basic或Delphi快速建立原型的过程；对项目经理而言，无论最近一期商业周刊发布的实践亮点是什么，快速开发就是拚命缩短项目周期。
每种工具或方法都可能在特定的场合完美运行，并有助于提高开发速度，但要完全发挥它们的功效，则必须将它们作为周密完整策略的一部分合理编排。没有任何一种快速开发工具或方法适合所有快速开发场合，即使对只有一定速度要求的非快速开发实践，也没有任何一种快速开发工具或方法就肯定能满足它在速度方面的要求。
就本书而言，并不是要介绍具体的方法或工具，“快速软件”开发只是一个相对于“慢速和典型开发”的描述性说法。它并不是有注册商标的快速开发方法——一个不可思议的短语或行话。本书所说的“快速开发”是个普通的术语，与“快捷开发”或“更短的开发周期”具有相同的意义，它意味着能够以比你目前更快的速度开发软件。
总之，一个快速开发项目就是任何一个需要强调开发速度的项目，以今天的业界环境，可以说很多项目都是快速开发项目。
1.2实现快速开发
本书的目的是为你进行快速开发提供一条捷径，虽然切换到这条捷径似乎存在着风险，但采用目前的开发方法则会导致成本增加、项目计划时间拖延、质量低下、项目失败、大量反复，造成项目经理、开发人员和用户的冲突，并出现其他我们本可以避免的问题。
如果你是在采用常规开发模式的组织中工作，则采用本书中的实践做法，你能够将开发时间大大缩减，可能多达50％，并能大大提高劳动生产率，而不会危及产品质量、性能、可维护性和项目投入。但这种改变不会因你采用了某种新的工具或方法而立刻实现，也不会因你采用某种封装软件而立刻奏效，实现快速开发需要时间与努力。
本章主题
什么是快速开发
实现快速开发
相关主题
本书适用对象：参阅“前言”
本书主要特色：参阅“前言”
为何编写本书：参阅“前言”
快速开发策略：参阅第2章
快速开发要点：参阅第6章
某产品经理告诉我，为改变现状，他想建立一套产品开发权限控制体系，该体系要更注重产品质量、防止功能蔓延、控制项目进度，并能够按计划交付产品。
但是，当实际运作项目时，他又不由自主地把将产品迅速推向市场放在了最优先的级别上。如何保证产品的可用性？我们没有足够的时间。如何保证产品的性能指标？可以等等再说。如何保证产品的可维护性？下一个项目再说。如何进行产品测试？我们的用户现在就要产品，马上送货。 这个产品经理并非只是某个特定的产品经理，他几乎是我为之工作的所有产品经理的化身。这种情形在整个软件业日复一日地重复着。开发时间已经变成头等重要的问题，以致忽略了其他应考虑的因素，甚至那些最终会影响开发时间的因素。
1.1什么是快速开发
对有些人而言，快速开发是通过使用一个得力的工具或方法实现的；对黑客而言，快速开发可能意味着36个小时连续不断地编码；对信息工程师而言，快速开发就是RAD——CASE（计算机辅助软件工程）工具、积极的用户参与和紧凑的时限（timebox）的集合；对纵向市场的程序员而言，快速开发就是利用微软的最新版本的Visual Basic或Delphi快速建立原型的过程；对项目经理而言，无论最近一期商业周刊发布的实践亮点是什么，快速开发就是拚命缩短项目周期。
每种工具或方法都可能在特定的场合完美运行，并有助于提高开发速度，但要完全发挥它们的功效，则必须将它们作为周密完整策略的一部分合理编排。没有任何一种快速开发工具或方法适合所有快速开发场合，即使对只有一定速度要求的非快速开发实践，也没有任何一种快速开发工具或方法就肯定能满足它在速度方面的要求。
就本书而言，并不是要介绍具体的方法或工具，“快速软件”开发只是一个相对于“慢速和典型开发”的描述性说法。它并不是有注册商标的快速开发方法——一个不可思议的短语或行话。本书所说的“快速开发”是个普通的术语，与“快捷开发”或“更短的开发周期”具有相同的意义，它意味着能够以比你目前更快的速度开发软件。
总之，一个快速开发项目就是任何一个需要强调开发速度的项目，以今天的业界环境，可以说很多项目都是快速开发项目。
1.2实现快速开发
本书的目的是为你进行快速开发提供一条捷径，虽然切换到这条捷径似乎存在着风险，但采用目前的开发方法则会导致成本增加、项目计划时间拖延、质量低下、项目失败、大量反复，造成项目经理、开发人员和用户的冲突，并出现其他我们本可以避免的问题。
如果你是在采用常规开发模式的组织中工作，则采用本书中的实践做法，你能够将开发时间大大缩减，可能多达50％，并能大大提高劳动生产率，而不会危及产品质量、性能、可维护性和项目投入。但这种改变不会因你采用了某种新的工具或方法而立刻实现，也不会因你采用某种封装软件而立刻奏效，实现快速开发需要时间与努力。
加载中...
