登入帳戶  | 訂單查詢  | 購物車/收銀台( 0 ) | 在線留言板  | 付款方式  | 運費計算  | 聯絡我們  | 幫助中心 |  加入書簽
會員登入 新用戶登記
HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類瀏覽雜誌 臺灣用戶
品種:超過100萬種各類書籍/音像和精品,正品正價,放心網購,悭钱省心 服務:香港台灣澳門海外 送貨:速遞郵局服務站

新書上架簡體書 繁體書
暢銷書架簡體書 繁體書
好書推介簡體書 繁體書

三月出版:大陸書 台灣書
二月出版:大陸書 台灣書
一月出版:大陸書 台灣書
12月出版:大陸書 台灣書
11月出版:大陸書 台灣書
十月出版:大陸書 台灣書
九月出版:大陸書 台灣書
八月出版:大陸書 台灣書
七月出版:大陸書 台灣書
六月出版:大陸書 台灣書
五月出版:大陸書 台灣書
四月出版:大陸書 台灣書
三月出版:大陸書 台灣書
二月出版:大陸書 台灣書
一月出版:大陸書 台灣書

『簡體書』快速开发(纪念版)

書城自編碼: 3555871
分類:簡體書→大陸圖書→計算機/網絡操作系統/系統開發
作者: [美] 史蒂夫·麦康奈尔[Steve,McConnell]
國際書號(ISBN): 9787302557104
出版社: 清华大学出版社
出版日期: 2020-09-01

頁數/字數: /
書度/開本: 16开 釘裝: 平装

售價:HK$ 169.0

我要買

 

** 我創建的書架 **
未登入.


新書推薦:
万历四大征(全两册)
《 万历四大征(全两册) 》

售價:HK$ 117.6
凝望:我的摄影与人生
《 凝望:我的摄影与人生 》

售價:HK$ 129.6
工业机器人从基础到实战
《 工业机器人从基础到实战 》

售價:HK$ 153.6
重症产科.1
《 重症产科.1 》

售價:HK$ 71.8
财之道丛书·表层的真理:当代经济学与社会
《 财之道丛书·表层的真理:当代经济学与社会 》

售價:HK$ 105.6
世界服饰艺术史
《 世界服饰艺术史 》

售價:HK$ 309.6
海外中国研究·卿本著者:明清女性的性别身份、能动主体和文学书写
《 海外中国研究·卿本著者:明清女性的性别身份、能动主体和文学书写 》

售價:HK$ 81.6
日耳曼通识译丛:近代哲学:从笛卡尔到康德
《 日耳曼通识译丛:近代哲学:从笛卡尔到康德 》

售價:HK$ 32.2

 

編輯推薦:
压力大,进度失控,是几乎所有公司和商业软件开发团队长期面临的顽疾。在《快速开发》一书中,作者通过整体策略、具体的*实践以及宝贵的技巧提示来驯服失控的进度,推动项目向前推进。和《代码大全》一样,本书主题全面紧凑,更是从231个参考文献中萃取出含金量高的研究成果与硬核技术实践,具体特色如下:
● 一个可以应用于任何项目的快速开发策略及相关的27个*实践
● 客观公正地对比讨论快速开发策略(包括好的和不那么好的):估算、原型、996、激励、团队、快速开发语言、风险管理以及其他技术主题
● 列出快速开发项目需要规避的36种经典错误,包括需求蔓延、质量缺陷和银弹综合征
● 26个实际案例生动刻画了对或错的根源以及如何确保软件开发项的顺利推进
《快速开发》作为一本实操指南,可以惠及广大程序员、技术领导和项目经理,帮助他们看清项目失控的真相与项目掌控的幻象,真正助力他们成为高效能的专业人士。
內容簡介:
进度失控,几乎是每一个软件开发项目挥之不去的噩梦。如何从容赶急,如何通过正确的开发策略和原则,避免典型错误,有效地进行风险管理,从多个方面贯彻执行快速软件开发,都可以从本书中找到答案。《快速开发纪念版》借助于实际案例和数据,阐述了快速软件开发方法的要领和精髓。 《快速开发纪念版》前两部分描述快速开发的策略和理念,其中的案例讨论有助于读者清楚地领略到策略和理念在实践中的作用。第Ⅲ部分则由27个快速开发实践构成,对于技术领导、程序员和项目经理具有重要的参考和指导意义。
關於作者:
史蒂夫麦康奈尔(Steve McConnell)
与比尔盖茨和Linux之父林纳斯托瓦兹齐名
《软件开发》杂志两届技术类图书震撼大奖得主
《软件开发》杂志两届生产力效率大奖得主
华盛顿西雅图大学校友会专业成就奖
IEEE计算机学会金牌核心奖章得主
《普吉特商业杂志》杰出青年人物奖
硅谷工程领导力峰会常年演讲嘉宾
目錄
第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 使用JAD421
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 天才能按计划完成开发项目,指望他们投入很多精力研究软件可用性方面的问题又从何谈起? 也就是说,除非我们把对项目进度的控制作为软件从业人员的必修课程,并为开发人员和经理们留出学习这方面专业知识的时间,否则,对开发人员来说,将很难有足够的时间进行有关方面知识的学习。
软件开发时间的问题普遍存在。一些调查表明,23 的项目超出了估算的时间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 Sommer11岁也为本书的图14-3 的最后一个图片提出了一个好建议,谢谢David。最后,
我要感谢我的夫人Tammy,感谢她的精神支持与诙谐和幽默。我必须迅速启动第三本书的写作了,好让她能停止笑我,还管我叫业余作者!

 

 

書城介紹  | 合作申請 | 索要書目  | 新手入門 | 聯絡方式  | 幫助中心 | 找書說明  | 送貨方式 | 付款方式 香港用户  | 台灣用户 | 大陸用户 | 海外用户
megBook.com.hk
Copyright © 2013 - 2024 (香港)大書城有限公司  All Rights Reserved.