毕特纳（Kurt Bittner），在IBM软件开发解决方案的策略部门工作。在其24年的职业生涯中，他成功地在多个行业和领域使用了软件开发的迭代方法。他是IBM关系统一过程原始开发团队中的一员，并与Ian Sperice合著了《用例建模》（清华大学出版社引进并出版）。
    思朋斯（Lan Sperice），是Ivar Jacobson咨询公司的首席科学家和首席咨询师，主要研究如何采用统一过程和它所推荐的迭代、用例驱动方法。他在软件行业有20多年的经验，其中包括10多年的参与和管理迭代项目的经验。目前他致力于下一代轻量级软件开发进程的研究工作。
    译者简介：
    罗景文，从1998年至今专注于UML、统一软件开发过程，以及Rational系列产品。对面向对象技术、软件工程以及交互式设计有深入研究。曾任职于IBM developer Works中国网站、Lvar Jacobson博士在中国开办的雅各布森软件（北京）有限公司，及CSDN《程序员》杂志。
    罗灿锋，多年专注于JavaEE领域开发，热衷于开源技术研究，曾担任项目经理职位，熟悉uP开发流程和敏捷开发，有实际的迭代式项目管理经验。现在主要致力于应用开源技术为企业IT化平台提供解决方案。
    张弘毅，多年来专注于需求开发与管理、架构设计与改进、迭代项目管理与控制方面的工程实践与研究。曾经为霍尼维尔技术研发中心、新加坡科技、华为、中兴通讯、中国工商银行、中国建设银行、中国银行等提供软件工程的咨询服务。曾任职于雅各布森国际。 
    其他责任者简介 ：
    陈庆春，超过12年软件开发和咨询经验的软件工程专家，目前专注于需求、敏捷等方向；从2000年起，开始参与软件工程的宣传和实施。作为顾问、讲师和项目经理，组织和参与多家知名公司的大规模软件工程变革，涉及软件工程的各个方面，并为超过百家的企业实施相关的服务和培训。对软件开发的全生命周期都很有研究，在用例、构件化开发、迭代开发等方面有专长。现任雅各布森中国咨询总监，曾参与Rational中国技术团队、IBM Rational中国服务团队的组建。

    迭代开发是一种较新的方法，它从20世纪80年代开始起步。到了20世纪90年代，采用该方法的公司发现它比旧方法能够更好地交付价值。事后看来，迭代开发的发展历程似乎一帆风顺，但实际上，迭代方法与其他技术进步一样，经历了一条坎坷不平的发展之路，其中一些方法如昙花般短暂地盛开后迅速凋谢了，有很多方法经试用后终被抛弃。留下的方法是吸收许多项目的经验的结晶，我们要向那些先驱管理者和坚持使用该方法的管理人员致敬，感谢他们给后来者留下了一套可靠的现代软件开发项目管理方法。

    任何情况下，均可在每一轮决定是否获得更多筹码来购买更多赢面概率信息，也可根据了解到的信息提前退出。
    与此类似，每个迭代都将更多资源注入项目以求取得成功，并由此获得更多关于项目成功机会的信息。如果项目成功完成迭代，且取得了客观的、可以评测的、已得到证明的增量效果，那么，赞助方的信心将随之攀升，会继续投资。如果在初始迭代期间，项目看上去已无法进行，面临非常高的风险级别，赞助方则会在未遭受重大损失前提前退出。从某种意义上讲，每个迭代的成本就像保单中的保险费’。您在迭代期问购买信息以免遭受巨大损失（项目失败）。这等同于标准的风险管理方法：通过购买保险来管理风险。
    如同将在第3章看到的，使用这种迭代方式来管理项目风险是成功应用迭代和增量技术的基石。
    与传统的瀑布开发方法相比，迭代和增量开发为企业提供了很多好处。这些好处包括：增加了可预见性、缩短了产品上市时间、提高了解决方案的质量、项目敏捷性和生产率。
    只有企业更主动参与项目和迭代，才能实现其中大多数好处。这将从根本上改变企业处理项目的方式，将影响需求捕获方式、进度评估方式以及至关重要的项目注资方式。
    1.3.3 站在管理团队的角度分析迭代
    前面介绍了在一系列迭代（专注于提供业务价值）中开展协作的业务团队和开发团队，您需要站在管理人员的角度分析迭代，并了解这种做法的重要性。
    首先，设想一个缺乏管理指导的软件开发项目（您可能亲身经历过这样的项目）的场景。这样的项目通常缺少中长期发展规划，进展方向随意而为，几乎没有哪个团队成员了解要去往何方。如果没有迭代计划，将无从了解项目将在何时结束，完成项目需要哪些资源，或者何时需要这些资源。没有估算系统来帮助判断项目成本，客户和投资方只会为最小的项目注资，人们几乎不知道项目如何发展，以便达到交付解决方案的目标。
    落入理想主义的陷阱将使我们认为，如果团队致力于实现目标，将会自行组织、履行对组织的所有承诺，并快速高效地交付高质量的软件。在现实中，即便是最优秀的团队也需要进行必要的监督才能确保日复一日的工作向着长期目标迈进。更重要的是，通过管理才能将团队拧成一股绳。
    缺乏管理往往是造成很多项目失败的根本原因加。人们（特别是那些非管理者）很容易误认为，管理基本上就只需要一些官僚主义，管理者的职责就是保持这种官僚色彩，而让其他团队成员去努力工作。实际上，许多平庸的管理者在一定程度上也确实是这样做的；如果管理者所做的就是这些，项目将很可能失败。
    管理不仅是做笔记、监督时间表和留意预算；领导力和工作方向是取得成功的基础。正确的管理为以下基本问题给出了清晰的答案。

第1部分 迭代项目管理原理
第1章 什么是迭代开发
1.1 迭代与科学方法
1.2 迭代的含义
1.2.1 迭代是一个独立的微型项目
1.2.2 迭代有一组独特的活动
1.2.3 每次迭代的结果都在“发布版本”中
1.2.4 迭代开发的特点
1.3 迭代体验
1.3.1 站在核心开发团队的角度分析迭代
1.3.2 站在客户的角度分析迭代
1.3.3 站在管理团队的角度分析迭代
1.4 小结

第2章 迭代项目的特性
2.1 迭代开发：最大化项目成功的机会
2.1.1 定义项目成功标准
2.1.2 成功和迭代项目
2.1.3 成功与迭代：收集项目成功的证据
2.2 一个成功的迭代项目的主要特征
2.2.1 可验证的、可客观度量的过程
2.2.2 避免“特征蠕变
2.2.3 持续增加功能
2.2.4 不断提高质量
2.2.5 持续降低风险
2.2.6 控制变更
2.2.7 越来越精确的估算
2.2.8 越来越高昂的热情、士气、协作和团队工作
2.2.9 致力于一种正确的商业解决方案
2.3 小结

第3章 控制迭代项目
3.1 制约项目的变量：范围、质量、时间和成本
3.2 利益相关方：项目成功的真正驱动者
3.3 控制单个迭代
3.3.1 时间盒
3.3.2 范围盒
3.3.3 控制迭代指南
3.4 从总体上控制项目
3.4.1 阶段和里程碑的重要性
3.4.2 迭代、阶段和里程碑
3.5 统一过程阶段
3.5.1 初始阶段
3.5.2 精化阶段
3.5.3 构建阶段
3.5.4 移交阶段
3.5.5 阶段和里程碑的可选视图
3.5.6 对统一过程生命周期的常见误解
3.6 客观度量成果：在项目生命周期内控制迭代
3.7 度量和迭代：项目的反馈控制
3.7.1 度量和阶段
3.7.2 通过度量控制项目
3.8 小结

第4章 为迭代项目管理做好准备
4.1 交付价值：成功的关键之处
4.1.1 迭代专注于交付价值
4.1.2 用例：统一迭代开发方法
4.1.3 期望成果、风险、场景和迭代规划
4.2 迭代项目的团队建设
4.2.1 团队技能和态度
4.2.2 领导团队
4.2.3 架构的职责：奠定一个坚实的基础
4.2.4 与扩展团队一起工作
4.2.5 迭代态度和价值观
4.3 改变考虑规划的方式
4.3.1 传统规划理念
4.3.2 为什么将传统的规划理念应用到软件中是错误的
4.3.3 渐进规划理念
4.3.4 比较两种方法
4.3.5 成功的迭代项目经理的七个习惯
4.4 小结

第2部分 规划和管理一个迭代项目
第5章 采用分层方法规划和管理迭代项目
5.1 管理层次
5.1.1 项目群管理层
5.1.2 总体项目管理层
5.1.3 开发层
5.1.4 迭代层
5.1.5 各层次的职责
5.2 贯穿层次进行规划
5.2.1 定位统一过程生命周期
5.2.2 计划和里程碑分层
5.2.3 定位其他重要的管理工件
5.3 分配管理职责
5.3.1 重要管理角色
5.3.2 分配管理职责
5.3.3 以一个综合管理团队的方式工作
5.4 层次化管理
5.4.1 层次化容忍限度
5.4.2 层次化估算
5.4.3 监测和控制
5.5 小结

第6章 整体项目规划
6.1 计划演变和发布
6.1.1 在多个演变之间平衡风险
6.1.2 处理连续的演变
6.1.3 规划多个演变
6.1.4 影响演变数量的因素
6.1.5 整体项目计划的组成
6.1.6 整体项目计划的形式
6.2 生命周期计划的原则
6.3 将原理应用于整体项目计划
6.3.1 原理1：了解期望的结果
6.3.2 原理2：识别和评估风险
6.3.3 原理3：确定管理策略
6.3.4 原理4：创建基于成果的路线图
6.3.5 原理5：了解解决方案及其作用范围
6.3.6 原理6：评估和预估要完成的工作
6.3.7 原理7：针对项目计划的保证约定
6.3.8 原理8：协调执行计划
6.3.9 原理9：迭代地演化和质疑各项计划
6.4 小结

第7章 演变和阶段规划
7.1 演变中执行的操作
7.1.1 在各个开发阶段之间平衡宽度和深度
7.1.2 生成的发布版类型因开发阶段而异
7.1.3 跨越开发阶段的工作和时间安排
7.1.4 迭代持续时间和频率
7.1.5 增加迭代和延长开发阶段的推动力
7.1.6 遵守时间表
7.2 规划演变
7.2.1 逐步推进演变计划
7.2.2 演变迭代模式
7.2.3 逐步演化演变计划
7.3 使用规程和工件进行工作
7.4 估算和工作分解结构
7.4.1 估算工作量
7.4.2 配备员工级别和技能集合
7.4.3 改写和修订估算及计划
7.5 小结

第8章 迭代规划
8.1 认同迭代计划
8.1.1 评估项目风险当前的状态
8.1.2 认同迭代的范围
8.1.3 认同对迭代的评价标准
8.1.4 将所有工作汇集成一个简单的计划
8.2 计划迭代的执行
8.2.1 认同采取的办法
8.2.2 定义迭代里程碑
8.2.3 认同工作分配
8.2.4 认同评估发生的时间
8.2.5 将细节作为迭代计划的部分呈献
8.3 迭代模式
8.3.1 初始阶段的迭代
8.3.2 精化阶段的迭代
8.3.3 构建阶段的迭代
8.3.4 移交阶段的迭代
……
第9章 迭代、阶段和项目评估
第10章 管理迭代项目的可伸缩方法
第11章 开始实践迭代项目管理
第3部分 附录