基本概念

迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期(如三个星期)小项目，成为迭代(iteration)；每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。

在迭代的过程中一步步增量式地发展完整系统，这种方法也成为迭代和增量式开发(iterative and incremental development)。

迭代的输出不是实验性的或将丢弃的原型，迭代开发也不是构造原型。与此相反，其输出式最终的产品子集。

早期反馈具有极高的价值。“不错……但是……”这种早期反馈并不是失败的标志，与此相反，早期频繁地在“不错……但是……”中循环，正是改进软件和发现什么对涉众有真正价值的使用方式。

迭代除了可以明确需求外，还将有助于及早地解决和验证具有风险的、关键的设计决策。

大部分迭代方式建议迭代时间在2~6周之间。短时迭代为上。

迭代的一个关键思想是时间定量，或时长固定。即必须严格依照时间表来集成、测试和稳定局部系统——拖延实践则违约。如果觉得难以满足期限要求，则应将本次迭代任务进行拆解，抽出一部分放到下一次迭代中完成，而不是推迟完成的时间。

不要让瀑布思维侵蚀迭代或UP项目。

进行迭代开发的步骤：

1. 在第一次迭代之前，召开第一个时间定量的需求工作会议，进行高阶需求分析，如仅仅确定用例和特性的名称，以及关键的非功能性需求。在高阶需求列表中选取10%具有架构意义、高业务价值的需求进行功能和非功能性需求的详细分析；
2. 在第一次迭代钱，召开迭代计划会议，从做好初步详细分析的用例中选择本次迭代的任务目标；
3. 在三到四周内完成第一次迭代，并严格遵守时间；
4. 在第一次迭代即将结束时，召开第二次需求工作会，对上一次会议的所有材料进行复查和净化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，用一到两天对其进行详细分析；
5. 于第一次迭代结束最后一天举行下一次迭代的迭代计划会议；
6. 以相同步骤进行第二次迭代；
7. 反复进行四次迭代和五次需求工作会，这样在第四次迭代结束时，可能已经详细记录了约80%~90%的需求，但只实现了系统的10%；
8. 大约推进了整个项目的20%，这是细化阶段。此时根据分析以及早期反馈、早期编程及测试，已经可以获取系统的概貌和各种风险，可以把握住开发并能估计出需要多长时间来结束；
9. 此后，一般不需要再召开工作会，需求已经稳定了，接下来时一些列为期三周的迭代。

UP提倡风险驱动(risk-driven)与客户驱动(client-driven)相结合的迭代计划。这意味着早期的迭代目标要能够识别和降低最高风险，并且能构造客户最关心的可视化特性。

敏捷宣言：个体和迭代，超越过程和工具；工作的软件，超越完整的文档；客户协作，超越合同谈判；响应变更，超越履行计划。

UP项目将其工作和迭代组织为四个主要阶段：初始，细化，构造，移交。