项目管理之殇：为什么你的软件项目会失败

译者序
致谢
第一部分　为什么软件项目会失败
第1章　简介
第2章　为什么软件与众不同
2.1　软件是复杂的
2.2　软件是抽象的
2.3　需求不完整
2.4　技术在快速变化
2.5　最佳实践不成熟
2.6　技术是一个庞大的领域
2.7　技术经验不完整
2.8　软件开发就是调查研究
2.9　自动处理重复性工作
2.10　构造实际上就是设计
2.11　改变被认为很容易
2.12　改变是不可避免的
2.13　小结
第3章　项目管理假设
3.1　隐藏的假设
3.2　范围管理
3.3　时间管理
3.3.1　活动定义
3.3.2　活动排序
3.3.3　活动持续时间估计
3.3.4　进度安排
3.4　成本管理
3.4.1　资源规划
3.4.2　软件文档
3.4.3　开发人员生产率
3.4.4　成本估计
3.5　质量管理
3.5.1　指标
3.5.2　检查表
3.6　风险管理
3.6.1　风险接受
3.6.2　风险转移
3.6.3　风险避免
3.6.4　风险缓解
3.7　小结
第4章　案例研究：计费系统项目
4.1　需求
4.2　规划
4.3　设计
4.4　构造
4.4.1　编码
4.4.2　集成
4.5　测试
4.6　后果
4.7　小结
第二部分　怎样使软件项目获得成功
第5章　新的敏捷方法
5.1　所选的方法
5.2　水晶方法
5.2.1　频繁交付
5.2.2　反思改进
5.2.3　密切或渗透式交流
5.2.4　人身安全
5.2.5　专注
5.2.6　容易访问专家级用户
5.2.7　具有自动化测试、配置管理和频繁集成的技术环境
5.2.8　使用水晶方法
5.3　极限编程
5.3.1  规划策略
5.3.2　测试
5.3.3　结对编程
5.3.4　重构
5.3.5　简单设计
5.3.6　代码集体所有权
5.3.7　持续集成
5.3.8　现场客户
5.3.9　小型发布
5.3.10　每周40小时工作制
5.3.11　编码标准
5.3.12　系统隐喻
5.3.13　使用XP
5.4　Rational统一过程
5.4.1　阶段
5.4.2　迭代
5.4.3　角色
5.4.4　工件
5.4.5　活动和工作流
5.4.6　过程配置
5.4.7　用例驱动的开发
5.4.8　可视化建模
5.4.9　使用RUP
5.5　利用敏捷缓解风险
5.5.1　不完整的需求和范围改变
5.5.2　工具和技术没有像预期的那样工作
5.5.3　开发人员缺乏技能和专业知识
5.5.4　新软件有缺陷并且需要返工
5.5.5　参与项目的员工离职
5.6　小结
第6章　规划敏捷项目的预算
6.1　软件开发的预算
6.2　持续开发
6.3　按需编程
6.4　SWAT团队
6.5　子团队封装
6.6　特性权衡
6.7　分诊
6.8　范围研究
6.9　结合这些技术
6.9.1　主要的遗留系统
6.9.2　次要的遗留应用程序
6.9.3　主要的新系统
6.9.4　次要的新应用程序
6.10　敏捷离岸外包
6.11　小结
第7章　案例研究：再论计费系统
7.1　方法
7.2　初始阶段
7.3　范围研究
7.4　细化
7.5　构造
7.6　交付
7.7　结局
7.8　小结
后记
附录　敏捷宣言
术语表
参考资料