VIP会员
内容简介
为什么70%以上的软件项目会失败？至今没有人能给出系统且合理的解释，本书试图探究其中的原因并给出解决方案。这是所有软件开发团队都应该反复阅读的一本经典著作，是一位拥有十几年软件开发和项目管理经验的专家的智慧结晶，这其中有成功的经验，更多的则是在项目中经历的挫折和失败的教训总结，可以借鉴，发人深省。
本书分为两部分。第一部分（第1～4章）比较详细地描述了软件项目失败的原因，阐释使软件开发与众不同的12个特征，并揭示不适用于软件开发项目的10个隐藏假设，涉及范围管理、时间管理、成本管理、质量管理以及风险管理等内容，然后通过一个模拟案例的研究，说明这些问题是如何导致一个本来前途光明的项目走向失败的。第二部分（第5～7章）详细介绍项目成功的方式与方法，涉及水晶方法、极限编程和Rational统一过程，并重点介绍一些战略，它们可能有助于使软件项目获得成功。
目录
目 录
译者序
致谢
第一部分 为什么软件项目会失败
第1章 简介 2
第2章 为什么软件与众不同 6
2.1 软件是复杂的 7
2.2 软件是抽象的 9
2.3 需求不完整 11
2.4 技术在快速变化 12
2.5 实践不成熟 13
2.6 技术是一个庞大的领域 15
2.7 技术经验不完整 16
2.8 软件开发就是调查研究 17
2.9 自动处理重复性工作 19
2.10 构造实际上就是设计 20
2.11 改变被认为很容易 22
2.12 改变是不可避免的 23
2.13 小结 24
第3章 项目管理假设 26
3.1 隐藏的假设 27
3.2 范围管理 28
3.3 时间管理 32
3.3.1 活动定义 32
3.3.2 活动排序 35
3.3.3 活动持续时间估计 39
3.3.4 进度安排 42
3.4 成本管理 43
3.4.1 资源规划 44
3.4.2 软件文档 46
3.4.3 开发人员生产率 48
3.4.4 成本估计 50
3.5 质量管理 51
3.5.1 指标 51
3.5.2 检查表 52
3.6 风险管理 53
3.6.1 风险接受 53
3.6.2 风险转移 55
3.6.3 风险避免 55
3.6.4 风险缓解 55
3.7 小结 56
第4章 案例研究：计费系统项目 57
4.1 需求 57
4.2 规划 58
4.3 设计 60
4.4 构造 61
4.4.1 编码 61
4.4.2 集成 62
4.5 测试 64
4.6 后果 67
4.7 小结 68
第二部分 怎样使软件项目获得成功
第5章 新的敏捷方法 72
5.1 所选的方法 73
5.2 水晶方法 75
5.2.1 频繁交付 76
5.2.2 反思改进 77
5.2.3 密切或渗透式交流 78
5.2.4 人身安全 80
5.2.5 专注 81
5.2.6 容易访问专家级用户 82
5.2.7 具有自动化测试、配置管理和频繁集成的技术环境 82
5.2.8 使用水晶方法 84
5.3 极限编程 84
5.3.1 规划策略 86
5.3.2 测试 87
5.3.3 结对编程 87
5.3.4 重构 88
5.3.5 简单设计 89
5.3.6 代码集体所有权 89
5.3.7 持续集成 90
5.3.8 现场客户 91
5.3.9 小型发布 91
5.3.10 每周40小时工作制 92
5.3.11 编码标准 92
5.3.12 系统隐喻 93
5.3.13 使用XP 94
5.4 Rational统一过程 95
5.4.1 阶段 97
5.4.2 迭代 98
5.4.3 角色 98
5.4.4 工件 99
5.4.5 活动和工作流 99
5.4.6 过程配置 100
5.4.7 用例驱动的开发 100
5.4.8 可视化建模 101
5.4.9 使用RUP 102
5.5 利用敏捷缓解风险 103
5.5.1 不完整的需求和范围改变 103
5.5.2 工具和技术没有像预期的那样工作 104
5.5.3 开发人员缺乏技能和专业知识 104
5.5.4 新软件有缺陷并且需要返工 105
5.5.5 参与项目的员工离职 105
5.6 小结 106
第6章 规划敏捷项目的预算 108
6.1 软件开发的预算 109
6.2 持续开发 111
6.3 按需编程 113
6.4 SWAT团队 115
6.5 子团队封装 116
6.6 特性权衡 118
6.7 分诊 119
6.8 范围研究 121
6.9 结合这些技术 123
6.9.1 主要的遗留系统 123
6.9.2 次要的遗留应用程序 124
6.9.3 主要的新系统 124
6.9.4 次要的新应用程序 125
6.10 敏捷离岸外包 126
6.11 小结 128
第7章 案例研究：再论计费系统 129
7.1 方法 129
7.2 初始阶段 130
7.3 范围研究 131
7.4 细化 136
7.5 构造 139
7.6 交付 142
7.7 结局 143
7.8 小结 144
后记 146
附录 敏捷宣言 148
术语表 150
参考资料 159
摘要与插图
第一部分为什么软件项目会失败
第1章 简介
第2章 为什么软件与众不同
第3章 项目管理假设
第4章 案例研究：计费系统项目
第1章
简 介
你的老板要求你监督新计费系统的开发，你把一位能干的项目经理和一组精挑细选的开发人员召集在一起。他们选择了的技术和工具来构建该系统。商业分析师与会计经理促膝长谈，并且写出了一组详细的需求。项目具有获得成功所需的一切条件，不是吗？
显然不是。6个月后，项目已经延期了，并且超出了预算。开发人员连续加班了几个星期，并且其中一位已经离职了，尽管如此，这个软件似乎从来没有接近完成。一部分问题在于会计团队一直声称该软件没有做他们需要的工作，并且他们总是不断地提出一连串“基本的”变更要求，更不要说泛滥成灾的错误报告了。你的老板在听到这些后，感到异常震怒。
那是什么地方出了问题呢？
无论怎样，大多数公司都会出这样的问题。依据Standish Group [2001]的研究报告，2000年只有28%的软件项目获得了成功（参见图1-1）。另外有大约23%的软件项目被取消了，其余的则出现了各种各样的问题，比如严重延期（平均有63%）、超出预算（45%）、功能缺乏（33%），或者更常见的是，所有这些问题集中出现。
图1-1 2000年软件项目的成功和失败
在新西兰司法部，耗资4200万美元的新案件管理系统超出了预算800万美元，并且延期一年才完成，于2003年推广使用。人们本来翘期盼该系统提供27种功能，但是只实现了其中的16种。这个系统不仅没有提高工作效率，反而由于数据输入量增加了一倍，实际上增加了法院管理案件的时间。系统实现后的审查确定了超过1 400个显著的问题。但是，“开发人员面临的挑战是大型、复杂的系统常见的那些问题”[Bell 2004]。
与之相反，在工程和建筑业中将有很大的差别。依据Engineering News-Record的观点，对于客户的质疑，94%的项目都能够满足他们想要的项目结果，这暗示建筑项目的失败率比软件项目要低得多。这也就是为什么2004年5月在戴高乐机场（巴黎）新建的2E航站楼管形屋顶倒塌事件成为全世界的头条新闻：它是如此罕见。失败的软件项目太常见了，很难获得这样的关注。
通过查看商业和非商业软件开发，我们可以知晓其原因。商业软件是公司出于盈利目的而制作的。一些软件是为个别客户量身定制的，比如计费系统，但是也有一些像Microsoft Word这样通用的“现成”产品。这些软件几乎全都是在一个项目或者一系列项目内创建的。
非商业软件通常是开源（open source）的，这意味着任何人都可以阅读它的源代码。用户可以查明它的工作方式，并做出修改以修正错误，以及添加他们想要的功能。开源软件由来自世界各地的开发人员一起开发，它没有固定的功能列表、预算或期限。开源开发人员协调他们工作的方式与传统的项目管理差别相当大。
开源软件是一个巨大的成功。“Internet运行在开源软件（BIND、Sendmail、Apache、Perl）上”，的计算机图书出版商O扲eilly & Associates的CEO Tim O扲eilly说道。开源软件一般具有比商业软件少得多的可靠性问题或错误。但是，如果按照我们用于衡量商业项目的相同标准，那么它还是成功的吗？毕竟，如果没有时间限制，任何项目不都将获得成功吗？
事实上，无限的时间足以弥补低下的工作效率。不过，开源工作人员的工作效率名扬四海。1991年，Linus Torvalds在不到一年的时间内基本上靠他自己一个人就编写了一个完整的、稳定的操作系统内核（Linux）。与此同时，8位核心贡献者一起组建了Apache Group，之后用了不到一年的时间就创建了Apache 1.0，它是一款如此有吸引力的软件，以至于