快速软件开发
2008-8
清华大学出版社
麦克康奈尔/著,席相林/冯炳根 审校
508
无
《微软技术丛书·快速软件开发(珍藏版)》前两部分描述快速开发的策略和理念，其中的案例讨论有助于读者清楚地领略到策略和理念在实践中的作用。第III部分则由27个快速开发实践构成，对于技术领导、程序员和项目经理具有重要的参考和指导意义。进度失控，几乎是每一个软件开发项目挥之不去的噩梦。如何从容赶急，如何通过正确的开发策略和原则，避免典型错误，有效地进行风险管理，从多个方面贯彻执行快速软件开发，都可以从《微软技术丛书·快速软件开发(珍藏版)》中找到答案。《微软技术丛书·快速软件开发(珍藏版)》借助于实际案例和数据，阐述了快速软件开发方法的要领和精髓。
Steve McConnell，软件行业最有影响力的三大人物之一，与Bill Gates和Linus Torvalds齐名，曾两度获得《软件开发》杂志优秀震撼大奖。 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章 典型错误 3.1 典型错误案例研究3.2 错误对开发进度的影响 3.3 典型错误一览 3.3.1 人员3.3.2 过程3.3.3 产品 3.3.4 技术3.4 逃离格里甘岛 深入阅读第4章 软件开发的基本原则 4.1 管理原则 4.1.1 项目估算和进程安排 4.1.2 计划编制4.1.3 跟踪 4.1.4 度量4.2 技术的基本原则 4.2.1 需求管理4.2.2 设计 4.2.3 构建 4.2.4 软件配置管理4.3 质量保证的基本原则4.3.1 易错模块 4.3.2 测试 4.3.3 技术回顾4.4 按照指导来做 深入阅读第5章 风险管理 5.1 风险管理要素 5.1.1 风险评估5.1.2 风险控制5.2 风险识别 5.2.1 最常见的进度计划风险 5.2.2 进度计划风险的完整列表5.3 风险分析5.3.1 风险暴露量 5.3.2 估计损失的大小 5.3.3 评估损失发生的概率5.3.4 整个项目的延期和缓冲5.4 风险优先级 5.5 风险控制 5.5.1 风险管理计划5.5.2 风险化解 5.5.3 风险监控5.6 风险、高风险和冒险 深入阅读第Ⅱ部分 有效开发第6章 快速开发中的核心问题第7章 生命期计划第8章 估算第9章 进度计划第10章 面向客户开发第11章 激励机制第12章 团队合作第13章 团队结构第14章 功能限定第15章 生产率工具第16章 项目修复第Ⅲ部分最佳实践简介第17章 变更委员会第18章 日创建和冒烟测试第19章 变更设计第20章 渐进交付第21章 渐进原型第22章 目标设定第23章 检查第24章 联合应用程序开发第25章 生命期模型的选择第26章 度量第27章 小型里程碑第28章 外包第29章 原则谈判法第30章 高效开发环境第31章 快速开发语言第32章 需求提炼第33章 重用第34章 签约第35章 螺旋型生命期模型第36章 阶段性交付第37章 W理论管理第38章 舍弃型原型法第39章 限时开发第40章 工具组第41章 前十大风险清单第42章 构建用户接口原型第43章 自愿加班参考文献
第1章 欢迎学习快速开发 本章主题 什么是快速开发 实现快速开发 相关主题 本书适用对象：参阅“前言” 本书主要特色：参阅“前言” 为何编写本书：参阅“前言” 快速开发策略：参阅第2章 快速开发要点：参阅第6章 某产品经理告诉我，为改变现状，他想建立一套产品开发权限控制体系，该体系要更注重产品质量、防止功能蔓延、控制项目进度，并能够按计划交付产品。 但是，当实际运作项目时，他又不由自主地把将产品迅速推向市场放在了最优先的级别上。如何保证产品的可用性？我们没有足够的时间。如何保证产品的性能指标？可以等等再说。如何保证产品的可维护性？下一个项目再说。如何进行产品测试？我们的用户现在就要产品，马上送货。 这个产品经理并非只是某个特定的产品经理，他几乎是我为之工作的所有产品经理的化身。这种情形在整个软件业日复一日地重复着。开发时间已经变成头等重要的问题，以致忽略了其他应考虑的因素，甚至那些最终会影响开发时间的因素。 1.1 什么是快速开发 对有些人而言，快速开发是通过使用一个得力的工具或方法实现的；对黑客而言，快速开发可能意味着36个小时连续不断地编码；对信息工程师而言，快速开发就是RAD——CASE（计算机辅助软件工程）工具、积极的用户参与和紧凑的时限（timebox）的集合；对纵向市场的程序员而言，快速开发就是利用微软的最新版本的Visual Basic或Delphi快速建立原型的过程；对项目经理而言，无论最近一期商业周刊发布的实践亮点是什么，快速开发就是拚命缩短项目周期。 每种工具或方法都可能在特定的场合完美运行，并有助于提高开发速度，但要完全发挥它们的功效，则必须将它们作为周密完整策略的一部分合理编排。没有任何一种快速开发工具或方法适合所有快速开发场合，即使对只有一定速度要求的非快速开发实践，也没有任何一种快速开发工具或方法就肯定能满足它在速度方面的要求。 就本书而言，并不是要介绍具体的方法或工具，“快速软件”开发只是一个相对于“慢速和典型开发”的描述性说法。它并不是有注册商标的快速开发方法——一个不可思议的短语或行话。本书所说的“快速开发”是个普通的术语，与“快捷开发”或“更短的开发周期”具有相同的意义，它意味着能够以比你目前更快的速度开发软件。 总之，一个快速开发项目就是任何一个需要强调开发速度的项目，以今天的业界环境，可以说很多项目都是快速开发项目。 1.2 实现快速开发 本书的目的是为你进行快速开发提供一条捷径，虽然切换到这条捷径似乎存在着风险，但采用目前的开发方法则会导致成本增加、项目计划时间拖延、质量低下、项目失败、大量反复，造成项目经理、开发人员和用户的冲突，并出现其他我们本可以避免的问题。 如果你是在采用常规开发模式的组织中工作，则采用本书中的实践做法，你能够将开发时间大大缩减，可能多达50％，并能大大提高劳动生产率，而不会危及产品质量、性能、可维护性和项目投入。但这种改变不会因你采用了某种新的工具或方法而立刻实现，也不会因你采用某种封装软件而立刻奏效，实现快速开发需要时间与努力。 我们都幻想能有一个简单的方案可以解决开发速度问题，但简单的方案只能解决简单的问题，软件开发并不是一个简单问题，快速软件开发更不是一个简单问题。 如图1-1所示，所有可能的软件实践集合是巨大的，在这样的集合中，有效实践这一子集中的实践数量也是相当大的，在某个特定项目中，你可能只用到这些实践中的一小部分。从总的执行层面看，快速开发的成功取决于两个要素： 选择有效的实践而不是无效实践 选择有利于完成项目进度目标的实践 你可能认为这是显而易见的，但就像第3章所解释的那样，各组织机构往往选择的是无效实践，他们选择的实践已经证明是失败的或者是失败多于成功。当他们需要确保项目进度时间时，他们选择的是那些其实降低了达成计划目标机会的高风险实践。当他们需要降低成本时，他们选择的是那些反而导致成本上升的基于速度的实践。这些组织改善开发速度的第一步是管理好他们选定的无效实践，然后开始选择有效的实践。
案例翔实，传授名家过经过脉之实践，名著新解，演绎快速开发之精髓。 开发改进失控，如何才能倾全力拿出悬崖勒马的勇气和智慧将其牢牢掌控？ 几乎所有软件公司和商业软件开发团队都希望求得一个重要问题的解决方案：面对强大的压力，如何能将开发进度处于掌控之中？在本书中，作者Steve McConnell通过整体策略、特定的最佳实践和宝贵的提示解决了这个困扰他们很久的问题，有助于他们缩短和控制开发进度，并让项目步入正常轨道。正如《代码大全》读者所预期的一样，本书的内容翔实生动，结合了大量来之不易的最佳研究成果和对策。 本书重要主题： 一个快速开发策略（可以应用于任何一个项目）和27个使此策略发挥效用的最佳实践。 以客观角度讨论优秀和一般快速开发实践：估算、原型化、强迫加班、激励、团队合作、快速开发语言、风险管理等。 列出快速开发项目应该避免的典型问题，包括需求蔓延、质量低下和银弹综合症等。 以丰富的案例生动地描绘了错误是怎样发生的，如何纠正，如何把握项目前进方向。
无
工期和质量是一个永远存在于软件开发中的矛与盾么？？看看书中提到的所有失败，以及不成功的例子多是由于不断缩短工期而造成的，但是如果不能及时抢占市场，即使开发出完美的软件，却也犹如空有利剑而无用武之地。所以工期和质量的的矛盾，只有能找到他们之间平衡点的项目才能成功，或者说有可能成功吧。