随着软件技术的发展、客户需求的变化越来越快、对应用软件项目的交付的要求也越来越要跟上市场的变化，RUP
非常适合这样的开发场景，在应用软件开发中已经成为最常用的开发模式。从项目管理的角度来看，RUP 的开发中对于迭代计划的开发和管理是保证成功交付项目的关键。好的迭代开发计划可以有效降低项目的风险，提高团队的协作，提高项目开发效率。笔者结合在以往项目中应用
RUP 迭代开发的实践，总结了两种开发迭代计划的方法，并对比两者的适用情况，以期对应用 RUP 的项目管理人员提供借鉴。
随着技术的快速发展和市场的快速变化，应用软件项目的交付越来越面临着需求不明确、交付进度紧、项目风险大、项目规模变大、项目团队协作困难、客户参与度高等问题。在这种情况下，RUP
的迭代开发的方法已经成为应用软件开发项目的主流的开发模式，并能够有效解决这些问题。但是本文不会完整讨论整个软件开发过程中
RUP 的贡献和如何应用 RUP。只是从项目管理和项目计划的角度探讨如何应用 RUP 的迭代方法开发项目计划。
笔者在多个项目中应用 RUP 进行软件项目的开发和管理，在本文中将结合实践阐述 RUP 迭代计划的两种开发方法，对于指导项目经理裁剪和应用
RUP 有实际的参考意义。本文还将与读者分享在实际项目中应用 RUP 如何开发迭代目标、如何开发迭代计划以及介绍了两种不同的迭代计划的模板参考示例。
迭代开发是 RUP 的核心思想，但是大家在刚开始使用 RUP 时你会发现这么多的并行工作流对项目管理同时也带来很大挑战和难度。因此使用
RUP 来完成项目，开发迭代计划是实施的主要难点之一。
迭代计划的特点：
- 一个迭代是总体项目计划的一个阶段
- 需要明确的交付目标（或可以运行的系统）
- 多个比较明确的角色的参与
- 可以串行也可以并行
- 体现了 RUP 架构驱动、关注风险的特点
- 实现快速交付，缩短大项目的交付周期
- 提高客户参与度和项目的可视化
迭代计划的开发考虑的因素：
- 总体项目计划
- 项目规模大小、周期
- 需求明确程度和技术风险
- 团队成熟度和规模
- 项目所处的阶段，在同一个项目的不同的阶段可以采用不同的迭代计划方法
上面提到迭代计划是实施 RUP 的难点之一，那么设置迭代目标就是解决这个难点的重点。
应用 RUP 开发项目的迭代目标主要是以项目开发周期中该迭代结束后所发布的交付物为主。 RUP 的迭代交付物通常以可以运行的系统，包括需求验证原型，架构验证原型，功能验证原型，测试系统，最终上线产品等。
通常在项目前期的迭代中以发布原型系统和原型架构为主，在项目的中期以发布的增量的功能Feature、业务模块为主，而在项目的后期以增量业务功能、测试系统、非功能需求、缺陷修改为主。当然，对于不同的项目类型，迭代的目标的设置也不同，比如系统软件产品的开发项目与应用软件开发项目，新软件产品开发与软件系统升级项目的差别就非常大。另外影响迭代目标的另外一个重要因素是项目的需求和架构的成熟程度，需求的明确程度，个性化需求和共性需求的比例，是影响项目风险和迭代开发目标的重要因素。还有就是采用的架构和技术，也是影响的重要因素之一，因此迭代目标的设置需要结合和考虑项目的总体目标和采用的不同的架构方法论，比如
IBM SO A项目的 SOMA（Service-Oriented Modeling and Architecture）面向服务的建模和架构。
概括来说，项目范围或需求、架构及决策、项目总体目标是设置迭代目标的重要的输入。比如原型迭代开发的迭代目标可以这样定义：
- 开发架构验证框架
- 完成 2 个关键业务用例的实现
- 完成对架构决策中 3 个关键技术的验证实现
RUP 的开发过程模型对项目管理和项目计划提出了更高的要求，迭代计划的好坏直接影响到项目目标的实现，项目风险和生产效率。如何更好地平衡和组织项目中众多的并行活动和分配不同的项目专业角色，对项目管理提出了很大的挑战。
根据笔者在众多的项目中应用和实践 RUP 中，总结出了两种迭代计划的开发方法。当然这两种方法并不是相互独立和分开使用的。在不同的项目或者同一个项目的不同的阶段，会交替使用甚至组合使用。
下面就分别介绍这两种方法的内容、区别和适用情况。
以时间为轴线的迭代计划
以时间为轴线的迭代计划也是使用 RUP 开发整体项目计划的主要的方法。根据项目的周期分为软件开发的初始阶段（Inception
Phase）、精化阶段（Elaboration Phase）、构建阶段（Construction Phase）和产品化阶段（Transition
Phase）。一般来说，这四个阶段作为项目开发生命周期的主要里程碑，而细化后的迭代阶段作为项目的二级里程碑。
迭代计划就是在每个里程碑下以时间顺序设置不同的开发迭代以满足里程碑的要求，达到里程碑的目标。比如在初始阶段一般有
1-2 个迭代周期，精化阶段一般会有 2-4 个迭代周期。当然迭代周期的个数要根据项目的类型、项目的规模和项目的特点不同来选择。一般对于需求不明确的应用软件的开发项目，往往精化阶段会有更多个迭代，而在产品移交阶段的迭代会比较少。而对于软件系统升级项目，往往在构建阶段的迭代会比较多。
迭代周期（Duration）也是制定迭代目标要考虑的因素，迭代周期也是根据项目整体的周期长短来确定合理的周期。一般来说
2 个周到 2 个月是比较合理的选择。迭代周期的长短在同一个项目中是可以不同的，但是一般经验来看，相对固定的设置从项目管理和项目团队的工作来看更适合，可以保持比较好的项目的工作节奏。
确定迭代个数和迭代周期，往往与设置迭代目标是相辅相成的。综合考虑，在完成了迭代目标、周期后，项目管理人员就可以开发项目的迭代计划了。
在以时间为轴线的迭代计划一般会将多个工作流（Work Flows）集成在一个计划中，项目团队内部有分工，但是不强调过于明显的分工。这种方法一般适合项目早期、人员较少的情况下。
在项目的中后期，往往会结合以软件工程流程和角色为轴线的计划方法。 在这种方法下，对于一个迭代开发周期中，更像一个小的瀑布模型。
各个迭代之间没有重合（Overlap），是串行执行的。 具体例子参照如下：
图 1. 以时间为轴线的迭代计划
图 2. 以时间为轴线的迭代计划示例
以软件工程流程或者角色为轴线的迭代计划
当项目规模比较大，团队内部角色分工比较明确的情况下，迭代开发的活动组织在一个计划中往往难以管理和监控。这个时候项目一般会采取以软件工程流程或者开发角色为轴线来组织迭代开发计划。
根据 RUP 的工程流程，项目中会有如下活动类型：
业务建模，需求分析，分析设计，实施开发，测试，部署，配置和变更管理，项目管理，环境。
理论上每种软件工程流程都会对应一个单独的计划，而且每个软件工程流程会定义自己的迭代周期和迭代次数。当然这个单独的计划只是相对独立的，一方面要与总体的项目集成计划保持一致，另一方面还要考虑与其他软件工程流程的计划的依赖关系。项目经理的非常重要的职责之一就是识别和管理这些依赖关系，使之保证项目开发的顺利进行。
对于如上九种软件工程流程，并不是一定要对应九个单独的子计划，在一般的应用软件的开发项目中，一般根据角色的团队的情况分为如下几个单独的计划：
- 业务需求开发计划
- 软件设计计划
- 软件开发计划
- 测试计划
- 管理和集成计划
软件开发计划可能还会存在多个，比如一个项目有多个子系统的开发，开发团队比较大，一般又会分为子系统 1
开发计划、子系统 2 开发计划，分别组织实施。在这种情况下各个迭代计划之间是有重合（Overlap）的，项目计划活动的执行是并行进行的。
具体的例子如下所示：
图 3. 以软件工程流程为轴线的迭代计划
图 4. 以软件工程流程为轴线的迭代计划示例
下表对比两种方法，总结不同的方法在不同的适用场景下的适用情况，作为项目管理人员选择和采用的依据：
表 1. 两种方法的对照总结
两种方法的对照总结
| 适合情景 |
时间为轴线的迭代计划 |
工作流程和角色为轴线的迭代计划 |
| 适合的项目规模 |
都可以 |
全部或大型项目 |
| 适合项目团队的大小 |
小团队 |
大团队 |
| 适合的项目阶段 |
全部或者项目早期 |
项目的中期 |
| 依赖 |
内部依赖，串行执行 |
造成团队之间或者计划之间的依赖，并行执行 |
| 管理难度 |
中低 |
高 |
综上所述，在一个项目中，项目经理和项目管理人员往往根据项目的具体情况和项目所在阶段来采用不同的迭代计划的开发方法。甚至将两者结合，制定适合项目的迭代计划，从而降低项目风险、提供项目团队的协作能力，提高生产效率，实现快速交付的目标。
学习
获得产品和技术
讨论
| 
