描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787302557104
压力大，进度失控，是几乎所有公司和商业软件开发团队长期面临的顽疾。在《快速开发》一书中，作者通过整体策略、具体的*实践以及宝贵的技巧提示来“驯服”失控的进度，推动项目向前推进。和《代码大全》一样，本书主题全面紧凑，更是从231个参考文献中萃取出含金量高的研究成果与硬核技术实践，具体特色如下：
● 一个可以应用于任何项目的快速开发策略及相关的27个*实践
● 客观公正地对比讨论快速开发策略（包括好的和不那么好的）：估算、原型、996、激励、团队、快速开发语言、风险管理以及其他技术主题
● 列出快速开发项目需要规避的36种经典错误，包括需求蔓延、质量缺陷和银弹综合征
● 26个实际案例生动刻画了对或错的根源以及如何确保软件开发项的顺利推进
《快速开发》作为一本实操指南，可以惠及广大程序员、技术领导和项目经理，帮助他们看清项目失控的真相与项目掌控的幻象，真正助力他们成为高效能的专业人士。
进度失控，几乎是每一个软件开发项目挥之不去的噩梦。如何从容赶急，如何通过正确的开发策略和原则，避免典型错误，有效地进行风险管理，从多个方面贯彻执行快速软件开发，都可以从本书中找到答案。《快速开发(纪念版)》借助于实际案例和数据，阐述了快速软件开发方法的要领和精髓。 《快速开发(纪念版)》前两部分描述快速开发的策略和理念，其中的案例讨论有助于读者清楚地领略到策略和理念在实践中的作用。第Ⅲ部分则由27个快速开发实践构成，对于技术领导、程序员和项目经理具有重要的参考和指导意义。
第I 部分 有效开发
第1 章 欢迎学习快速开发 3
1.1 什么是快速开发 3
1.2 实现快速开发 4
第2 章 快速开发策略 7
2.1 快速开发的总体策略 10
2.2 开发速度的四个维度 13
2.2.1 人员 14
2.2.2 过程 16
2.2.3 产品 18
2.2.4 技术 19
2.2.5 协同 20
2.3 快速开发的一般分类 20
2.3.1 有效开发 20
2.3.2 侧重于进度的有效开发 22
2.3.3 全面快速开发 22
2.4 哪一个维度更重要 23
2.5 快速开发的权衡策略 24
深入阅读 29
第3 章 典型错误 31
3.1 典型错误案例研究 31
3.2 错误对开发进度的影响 38
3.3 典型错误一览 40
3.3.1 人员 41
3.3.2 过程 45
3.3.3 产品 48
3.3.4 技术 49
3.4 逃离吉利根岛 50
第4 章 软件开发的基本原则 52
4.1 管理原则 56
4.1.1 项目估算和进程安排 56
4.1.2 计划编制 56
4.1.3 跟踪 57
4.1.4 度量 58
深入阅读 59
4.2 技术的基本原则 60
4.2.1 需求管理 62
4.2.2 设计 63
4.2.3 构建 64
4.2.4 软件配置管理 65
深入阅读 66
4.3 质量保证的基本原则 68
4.3.1 易错模块 71
4.3.2 测试 72
4.3.3 技术审查 72
深入阅读 74
4.4 按照指导来做 76
深入阅读 77
第5 章 风险管理 78
5.1 风险管理要素 81
5.1.1 风险评估 82
5.1.2 风险控制 82
5.2 风险识别 82
5.2.1 常见的进度计划风险 83
5.2.2 进度计划风险的完整列表 83
5.3 风险分析 87
5.3.1 风险暴露量 87
5.3.2 估计损失的大小 88
5.3.3 评估损失发生的概率 89
5.3.4 整个项目的延期和缓冲 89
5.4 风险优先级 90
5.5 风险控制 91
5.5.1 风险管理计划 92
5.5.2 风险化解 92
5.5.3 风险监控 95
5.6 风险、高风险和冒险 97
深入阅读 100
第Ⅱ部分 快速开发
第6 章 快速开发中的核心问题 103
6.1 一个标准是否适合所有情况 103
6.2 你需要什么样的开发方法 105
6.2.1 进度计划有严格限制的产品 105
6.2.2 表面上的快速开发 106
6.2.3 你是否真正需要全力开发 109
6.3 按时完成的可能性 110
6.4 感知与现实 113
6.4.1 不切实际的用户期望 114
6.4.2 克服慢速开发的感觉 115
6.5 时间都去哪儿了 115
6.5.1 典型的观点 115
6.5.2 可以改进的问题 116
6.6 开发速度的平衡 119
6.6.1 进度、费用和产品的平衡 119
6.6.2 质量的权衡 120
6.6.3 个人效率的权衡 121
6.7 典型的进度改进模式 121
6.8 向快速开发前进 123
深入阅读 124
第7 章 生命周期计划 125
7.1 纯瀑布模型 128
7.2 编码修正模型 131
7.3 螺旋模型 132
7.4 经过修改的瀑布模型 134
7.4.1 生鱼片模型 135
7.4.2 具有子项目的瀑布模型 136
7.4.3 能够降低风险的瀑布模型 137
7.5 渐进原型 138
7.6 阶段性交付 139
7.7 面向进度的设计 140
7.8 渐进交付 141
7.9 面向开发工具的设计 142
7.10 商品软件 144
7.11 为项目选择快速的生命周期 144
深入阅读 150
第8 章 估算 152
8.1 软件估算的故事 154
8.1.1 软件和建筑 154
8.1.2 软件开发是一个改进的过程 155
8.1.3 可能细化的数量 156
8.1.4 估算与控制 158
8.1.5 合作 159
8.1.6 估算实例概要 161
8.2 估算步骤概述 162
8.3 规模估算 162
8.3.1 功能点估算 163
8.3.2 估算技巧 165
8.3.3 估算的表达方式 167
8.4 工作量估算 170
8.5 进度估算 170
8.5.1 基于承诺的进度安排 171
8.5.2 一阶估算实践 172
8.6 大致的进度估算 173
8.6.1 背景 173
8.6.2 可能的短进度 175
8.6.3 有效进度 180
8.6.4 普通进度 182
8.6.5 对大致的进度首先应怎么办 184
8.7 估算修正 184
深入阅读 189
第9 章 进度计划 191
9.1 过分乐观的进度计划 192
9.1.1 一个关于过分乐观的进度计划的实例 193
9.1.2 产生过分乐观的进度计划的根源 195
9.1.3 过分乐观的进度计划产生的不良后果 196
9.1.4 超负荷的进度压力 200
9.1.5 底线 203
9.2 战胜进度压力 205
9.2.1 原则谈判法 206
9.2.2 将人和问题分开 207
9.2.3 关注于共同利益，不要过分坚持立场 208
9.2.4 提出对双方均有利的备选方案 209
9.2.5 坚持客观标准 211
深入阅读 215
第10 章 面向客户的开发 217
10.1 客户对于快速开发的重要性 220
10.1.1 提高效率 220
10.1.2 减少返工 221
10.1.3 降低风险 221
10.1.4 消除矛盾 221
10.2 面向客户的开发方法 222
10.2.1 规划 222
10.2.2 需求分析 223
10.2.3 设计 225
10.2.4 实现 226
10.3 合理控制客户的期望值 226
深入阅读 230
第11 章 激励机制 231
11.1 开发人员的典型激励 233
11.2 重要的5 个激励因素 236
11.2.1 成就感 236
11.2.2 发展机遇 238
11.2.3 工作乐趣 239
11.2.4 个人生活 241
11.2.5 成为技术主管的机会 241
11.3 利用其他激励因素 242
11.3.1 奖赏和鼓励 242
11.3.2 试验性项目 244
11.3.3 对业绩的评价 245
11.4 士气杀手 245
11.4.1 保健因素 246
11.4.2 其他士气杀手 247
深入阅读 252
第12 章 团队合作 254
12.1 软件项目中的团队合作 256
12.2 团队合作对快速开发的重要性 257
12.2.1 团队生产率的变化 257
12.2.2 凝聚力和业绩 258
12.3 创建高绩效团队 259
12.3.1 共同的、可提升的愿景或目标 260
12.3.2 团队成员的认同感 261
12.3.3 结果驱动的结构 262
12.3.4 胜任的团队成员 263
12.3.5 对团队的承诺 265
12.3.6 相互信任 265
12.3.7 团队成员间相互依赖 266
12.3.8 有效的沟通 266
12.3.9 自主意识 267
12.3.10 授权意识 267
12.3.11 团队规模较小 268
12.3.12 高层次的乐趣 268
12.3.13 如何管理高绩效团队 268
12.4 团队为什么会失败 269
12.5 长期的团队建设 273
12.6 团队合作指导方针总结 274
深入阅读 275
第13 章 团队结构 277
13.1 团队结构应该考虑的因素 279
13.1.1 团队的种类 280
13.1.2 其他团队设计特征 281
13.1.3 何种类型的团队适用于快速开发 282
13.2 团队模式 283
13.2.1 业务团队 284
13.2.2 主程序员团队 284
13.2.3 科研项目团队 286
13.2.4 特征团队 286
13.2.5 搜索救援团队 287
13.2.6 SWAT 团队 287
13.2.7 专业运动员团队 288
13.2.8 戏剧团队 289
13.2.9 大型团队 291
13.3 管理者和技术主管 292
深入阅读 295
第14 章 功能限定 297
14.1 项目早期：功能的简化 299
14.1.1 规格说明小化 299
14.1.2 需求筛选 306
14.1.3 版本化开发 307
14.2 项目中期：功能蔓延的控制 308
14.2.1 变更的根源 308
14.2.2 变更的影响 312
14.2.3 完全停止变更的智慧 313
14.2.4 变更控制的方法 314
14.3 项目后期：功能剪切 318
深入阅读 320
第15 章 生产率工具 321
15.1 快速开发中生产率工具的作用 324
15.1.1 特定应用领域 325
15.1.2 生产率工具的局限性 326
15.1.3 快速开发项目中生产率工具的终极作用 327
15.2 生产率工具的战略 328
15.3 生产率工具的获取 329
15.3.1 获取计划 330
15.3.2 遴选标准 331
15.3.3 承诺 334
15.4 生产率工具的使用 334
15.4.1 何时使用 334
15.4.2 培训的重要性 335
15.4.3 进度缩减的期望值 336
15.5 银弹综合征 339
15.5.1 识别银弹 341
15.5.2 忍辱负重 343
深入阅读 345
第16 章 项目修复 347
16.1 一般的修复方案 349
16.2 修复计划 351
16.2.1 步 351
16.2.2 人员 352
16.2.3 过程 355
16.2.4 产品 358
16.2.5 找准时机 361
深入阅读 364
第Ⅲ部分 实践
第17 章 变更委员会 380
第18 章 每日构建和冒烟测试 381
18.1 使用每日构建和冒烟测试 383
18.2 管理每日构建和冒烟测试中的风险 388
18.3 每日构建和冒烟测试的附带效果 389
18.4 每日构建和冒烟测试与其他实践的相互关系 389
18.5 每日构建和冒烟测试的底线 390
18.6 成功使用每日构建和冒烟测试的关键 390
深入阅读 390
第19 章 变更设计 391
19.1 使用面向变更的设计 392
19.2 管理变更设计带来的风险 397
19.3 变更设计的附带效果 398
19.4 变更设计与其他实践的相互关系 398
19.5 变更设计的底线 398
19.6 成功使用变更设计的关键 398
深入阅读 399
第20 章 渐进交付 400
20.1 使用渐进交付 402
20.2 管理渐进交付中的风险 404
20.3 渐进交付的附带效果 405
20.4 渐进交付与其他实践的相互关系 406
20.5 渐进交付的底线 406
20.6 成功使用渐进交付的关键 406
深入阅读 407
第21 章 渐进原型 408
21.1 使用渐进原型 409
21.2 管理渐进原型中的风险 410
21.3 渐进原型的附带效果 415
21.4 渐进原型与其他实践的相互关系 415
21.5 渐进原型的底线 416
21.6 成功使用渐进原型的关键 416
深入阅读 417
第22 章 目标设定 418
第23 章 检查 419
第24 章 联合应用程序开发 420
24.1 使用JAD 421
24.2 管理JAD 中的风险 430
24.3 JAD 的附带效果 431
24.4 JAD 与其他实践的相互关系 431
24.5 JAD 方法的底线 432
24.6 成功使用JAD 的关键 432
深入阅读 433
第25 章 生命周期模型的选择 434
第26 章 度量 435
26.1 使用度量 436
26.2 管理度量中的风险 444
26.3 度量的附带效果 445
26.4 度量与其他实践的相互关系 445
26.5 度量的底线 445
26.6 成功使用度量的关键 446
深入阅读 446
第27 章 小型里程碑 448
27.1 使用小型里程碑 451
27.2 管理小型里程碑中的风险 454
27.3 小型里程碑的附带效果 454
27.4 小型里程碑与其他实践的相互关系 455
27.5 小型里程碑的底线 455
27.6 成功使用小型里程碑的关键 456
深入阅读 456
第28 章 外包 457
28.1 使用外包 458
28.2 管理外包中的风险 464
28.3 外包的附带效果 466
28.4 外包与其他实践的相互关系 466
28.5 外包的底线 466
28.6 成功使用外包的关键 467
深入阅读 467
第29 章 原则谈判法 468
第30 章 高效开发环境 469
30.1 使用高效开发环境 471
30.2 管理高效开发环境中的风险 473
30.3 高效开发环境的附带效果 474
30.4 高效开发环境与其他实践的相互关系 475
30.5 高效开发环境的底线 475
30.6 成功使用高效开发环境的关键 476
深入阅读 476
第31 章 快速开发语言 477
31.1 使用快速开发语言 481
31.2 管理快速开发语言中的风险 481
31.3 快速开发语言的附带效果 483
31.4 快速开发语言与其他实践的相互关系 483
31.5 快速开发语言的底线 484
31.6 成功使用快速开发语言的关键 484
深入阅读 485
第32 章 需求提炼 486
第33 章 重用 487
33.1 使用重用 488
33.2 管理重用中的风险 495
33.3 重用的附带效果 496
33.4 重用与其他实践的相互关系 497
33.5 重用的底线 497
33.6 成功使用重用的关键 498
深入阅读 498
第34 章 签约 499
34.1 使用签约 500
34.2 管理签约中的风险 503
34.3 签约的附带效果 505
34.4 签约与其他实践的相互关系 505
34.5 签约的底线 505
34.6 成功使用签约的关键 505
深入阅读 506
第35 章 螺旋型生命周期模型 507
第36 章 阶段性交付 508
36.1 使用阶段性交付 511
36.2 管理阶段性交付中的风险 514
36.3 阶段性交付的附带效果 515
36.4 阶段性交付与其他实践的相互关系 516
36.5 阶段性交付的底线 517
36.6 成功使用阶段性交付的关键 517
深入阅读 517
第37 章 W 理论管理 518
37.1 使用W 理论管理 520
37.2 管理W 理论管理中的风险 525
37.3 W 理论管理的附带效果 526
37.4 W 理论管理与其他实践的相互关系 526
37.5 W 理论管理的底线 527
37.6 成功使用W 理论管理的关键 527
深入阅读 527
第38 章 舍弃型原型法 528
38.1 使用舍弃型原型法 529
38.2 管理舍弃型原型法中的风险 530
38.3 舍弃型原型法的附带效果 531
38.4 舍弃型原型法与其他实践的相互关系 531
38.5 舍弃型原型法的底线 531
38.6 成功使用舍弃型原型法的关键 532
深入阅读 532
第39 章 限时开发 533
39.1 使用限时开发 535
39.2 管理限时开发中的风险 538
39.3 限时开发的附带效果 539
39.4 限时开发与其他实践的相互关系 539
39.5 限时开发的底线 540
39.6 成功使用限时开发的关键 540
深入阅读 540
第40 章 工具组 541
第41 章 前十大风险清单 542
第42 章 构建用户界面原型 543
42.1 使用用户界面原型 545
42.2 管理用户界面原型中的风险 548
42.3 用户界面原型的附带效果 549
42.4 用户界面原型与其他实践的相互关系 549
42.5 用户界面原型的底线 550
42.6 成功使用用户界面原型的关键 550
深入阅读 550
第43 章 自愿加班 551
43.1 使用自愿加班 552
43.2 管理自愿加班中的风险 557
43.3 自愿加班的附带效果 558
43.4 自愿加班与其他实践的相互关系 558
43.5 自愿加班的底线 558
43.6 成功使用自愿加班的关键 559
深入阅读 559
参考文献 561
软件开发人员基本上处于进退两难的境地，一方面他们为解决开发中所碰到的各种问题殚精竭虑，几乎没有时间去钻研有效的实用技术；另一方面，如果不学习掌握软件快速开发方法，他们永远不会有足够的时间。
摆在他们面前的问题是，在“尽快交工”计划的压力下，如何在开发进度与软件质量之间达到理想的平衡。如果开发人员需要放弃看电影、读报纸、购物、休闲、锄草或与孩子玩耍的所有时间，连续工作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，感谢她的精神支持与诙谐和幽默。我必须迅速启动第三本书的写作了，好让她能停止笑我，还管我叫业余作者！
评论
还没有评论。