下载掌阅APP，畅读海量书库
立即打开
这里的介绍可能会给人留下这样的印象，即编程前的分析和设计毫无价值，但这是与瀑布思维同样偏激的误解。迭代和进化式分析设计是中庸之道。这里有个简短的例子（而非解决方案），用以说明在运转良好的UP项目中，迭代方法是如何被运用的。这里假设在项目交付前，最终将有20次迭代。
1）在第1次迭代之前，召开第一个时间定量的需求工作会议，例如确切的定义为两天时间。业务和开发人员（包括首席架构师）需要出席。
·在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称，以及关键的非功能性需求。这种分析不可能是完美的。
·通过咨询首席架构师和业务人员，从高阶列表中选择10%列表项（例如，30个用例名中的10%），这些项目要具备以下三种性质：①具有重要的架构意义（如果要实现，我们必须设计、构造和测试的核心架构），②具有高业务价值（业务真正关心的特性），③具有高风险（例如“能够处理500个并发交易”等）。所选的三个用例可能被标识为：UC2、UC11和UC14。
·在剩下的一天半内，对这三个用例的功能和非功能性需求进行详细的分析。完成这一过程后，对10%进行了深入分析，90%进行了高阶分析。
2）在第1次迭代之前，召开迭代计划会议，选择UC2、UC11和UC14的子集，在特定时间内（例如，四周的时间定量迭代）进行设计、构造和测试。要注意的是，因为其中包含大量工作，所以并不是在第1次迭代中就要构造出全部三个用例。在选择了特定子集目标后，在开发团队的帮助下，将其分解为一系列更为详细的迭代任务。
3）在三到四周内完成第1次迭代（选择时间定量，并严格遵守时间）。
·在开始的两天内，开发者和其他成员分组进行建模和设计工作，在首席架构师的带领和指导下，于“公共作战室”的众多白板上，画出UML的草图（及其他的模型）。
·然后，开发者摘掉其“建模帽子”并带上“编程帽子”，开始编程、测试和集成工作并且剩余的时间均用于完成这项工作。开发者将建模草图作为其灵感的起点，但是要清楚这些模型只是局部的，并且通常是含糊的。
·进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试等。
·在结束前的一周，检查是否能够完成初始的迭代目标；如果不能，则缩小迭代的范围，将次要目标置回任务列表中。
·在最后一周的星期二，冻结代码；必须检入
、集成和测试所有代码，以建立迭代的基线。
·在星期三的上午，向外部涉众演示此局部系统，展示早期可视进展，同时要求反馈。
4）在第1次迭代即将结束时（如最后一周的星期三和星期四），召开第二次需求工作会，对上一次会议的所有材料进行复查和精化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，用一到两天对其进行详细分析。这项工作完成后，会详细记录下大概25%的用例和非功能性需求。当然，这也不是完美的。
5）于周五上午，举行下一迭代的迭代计划会议。
6）以相同步骤进行第2次迭代。
7）反复进行四次迭代和五次需求工作会，这样在第4次迭代结束时，可能已经详细记录了约80%～90%的需求，但只实现了系统的10%。
·注意，这些大量、详细的需求集是基于反馈和进化的，因此其质量远高于纯粹依靠推测而得出的瀑布式规格说明。
8）我们大概推进了整个项目过程的20%。在UP的术语里，这是细化阶段（elaboration phase）的结束。此时，可以估计这些精化的、高质量的需求所需工作量和时间。因为具有依据现实得出的调查、反馈结论并进行了早期编程和测试，因此估计能够做什么和需要多长时间的结果会更为可靠。
9）此后，一般不需要再召开需求工作会；需求已经稳定了（尽管需求永远不会被冻结）。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代计划会上选择适宜的下一步工作，每次迭代都要反复询问：“就我们现在所知，下一个三周应该完成的、最关键的技术和业务特性是什么？”
图2-5中描述了经过20次迭代的项目。
利用这种方式，经过早期探索式开发的几次迭代之后，团队将能够更准确地回答“什么、多少、何时”。