下载掌阅APP，畅读海量书库
立即打开
迭代开发（iterative development）是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期（如三个星期）小项目，称为迭代（iteration）；每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。
迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。随着时间和一次又一次迭代的递进，系统增量式地发展完善，因此这一方法也被称为迭代和增量式开发（iterative and incremental development）（参见图2-1）。因为反馈和调整使规格说明和设计不断进化，所以这种方法也称为迭代和进化式开发（iterative and evolutionary development）。
图2-1 迭代和进化式开发
早期迭代过程的思想是螺旋式开发和进化式开发[Boehm88，Gilb88]。
示例
作为示例（而非解决方案），在项目开始为期三周的迭代中，可以用周一上午一个小时的时间与团队成员召开启动会议，明确本次迭代的任务和目标。其间，由一人对上次迭代的代码进行逆向工程，（使用CASE工具）制作UML图，并打印和显示其中重要的部分。在周一剩下的时间里，团队成员可以在白板上以结对的工作方式进行敏捷建模，画出UML草图并使用数码相机记录，然后写出一些伪代码和设计纪要。剩余的工作日对局部系统进行实现、测试（单元测试、验收测试、可用性测试等）、进一步的设计、集成和日常构造等工作。其他活动还包括与涉众进行演示和评估，以及计划下一迭代。
注意，在该示例中，既没有匆忙地编码，也没有进行长期的设计以试图在编程前完善所有设计细节。“少许”超前设计是使用粗略和快速的UML可视化建模来完成的；开发人员大概用半天或一整天的时间，以结对方式，在白板上勾画UML草图进行设计工作。
每次迭代都产生可执行的但不完整的系统，它不是已经准备好可以交付的产品。直到多次迭代（如10次或15次迭代）之后，系统才可能合格地用于产品部署。
迭代的输出不是实验性的或将丢弃的原型，迭代开发也不是构造原型。与之相反，其输出是最终系统的产品子集。
有一本讨论迭代开发的书，其副标题是 Embrace change [Beck00]。这一短语指出了迭代开发的一个关键态度：瀑布式过程是在实现之前，（失败地）企图全面和正确地规格化、冻结，以及“签署”需求集和设计，以此与软件开发中不可避免的变更进行抗争。与其相反，迭代和进化式开发抱以接受变更和改写的态度，并以此为真正本质的驱动力。
这并不是说迭代开发和UP提倡不受控制的、反应式的“特性蔓延”驱动的过程。后续几章会揭示UP在涉众明确了其构想或市场变化时如何平衡需求时，一方面认同和稳定一组需求，另一方面接受需求不断变更的事实。
每次迭代选择一小组需求，并快速设计、实现和测试。在早期迭代中，对需求和设计的选择对于最终期望来说可能并不准确。但是，在最终确定所有需求或经过深思熟虑而定义完整设计之前，快速地实施一小步的方式可以得到快速反馈——来自用户、开发人员和测试（诸如负载测试和可用性测试）的反馈。
这种早期反馈具有极高的价值。与“推测”完整、正确的需求或设计相反，团队可以从实际构造和测试的反馈中，挖掘出至关重要和实际的观点，并修改和调整对需求或设计的理解。最终用户将有机会及早看到部分系统并提出：“不错，这是我要求的；但现在我试过后，发现与我真正想要的有一些差异。”
这种“不错……但是”的过程并不是失败的标志，与之相反，早期频繁地在“不错……但是”中循环，正是改进软件和发现什么对涉众有真正价值的实用方式。然而，这并非是对开发者不断变换方向的无序和反应式开发的认可，作为一条中间路线是可行的。
除了明确需求之外，负载测试将验证局部设计和实现是否正确，或者是否需要在下次迭代中改变核心架构。最好及早解决和验证具有风险的、关键的设计决策，而迭代开发提供了完成这项工作的机制。
因此，工作是通过一系列有序的构造-反馈-调整循环向前进展的。无需惊奇，（对于最终的需求和设计而言）早期迭代中系统偏离“正确轨迹”的程度会大于后继迭代。随着时间的发展，系统将沿着这一轨迹收敛，如图2-2所示。
图2-2 迭代反馈和进化向预期系统的方向发展。需求和设计的不稳定性随着时间逐步下降
迭代开发的优点包括：
·减少项目失败可能性，提高生产率，降低缺陷率。对迭代和进化式方法的研究表明了这一点。
·在早期（而不是晚期）缓解高风险（技术、需求、目标、可用性等等）。
·早期可见的进展。
·早期反馈、用户参与和调整，会产生更接近涉众真实需求的精化系统。
·可控复杂性；团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。
·一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去。
大部分迭代方法建议迭代时间在2～6周之间。小步骤、快速反馈和调整是迭代开发的主要思想，迭代时间过长会破坏迭代开发的核心动机并增加项目风险。仅一周的迭代时间不足以获得有意义的产出和反馈；若迭代时间大于6周，则复杂性会变得不可控制，反馈将延迟。时间定量超长的迭代不符合迭代开发的观点。短时迭代为上。
迭代的一个关键思想是时间定量（timeboxed），或时长固定。例如，假设选择下一次迭代时间为3周，则必须依照时间表来集成、测试和稳定局部系统——推延时间则违约。如果看起来难以满足期限要求，那么建议从本次迭代中除去一些任务或需求，并将其分配在将来的迭代中，而不是推迟完成日期。