从瀑布型开发到迭代型开发的转变(3)

　　步骤 2 ：划分详细设计、实现和测试阶段到不同的迭代中。

　　很多项目团队发现在他们知道项目是真正关于什么的之前划分一个项目成为有意义的迭代是困难的。但是，当你已经进入了详细设计阶段时，你通常对需求是什么和系统的架构看起来象什么样子有了很好的理解。这是我们试验迭代开发的时候了!

　　你能够使用两个主要的方法来确定你应该在什么样的迭代中作些什么事情。让我们从正反两方面讨论一下每一个方法。

　　方法 1 ：同时开发一个或者多个子系统。让我们假设你有九个子系统，每一个都有数量日益增加的组件。你可以划分详细设计、实现和测试阶段到三个迭代中，每个迭代瞄准实现九个子系统中的三个。如果在不同的子系统之间存在有限的依赖这将工作的相当的好。例如，如果你的九个子系统的每一个都为用户提供良好定义的一系列能力，你可以在第一个迭代中开发优先级最高的子系统，其次重要的子系统在第二个迭代中实现，以此类推。这种方法有很大的优点：如果你的进度落后了时间计划，你仍然可以交付可运行的具有最重要能力的部分系统。

　　然而，如果你有一个分层的体系架构，在上层的子系统依赖于底层子系统的能力，这种方法将不能够很好的工作。如果你必须要在一个时间内构建一个子系统，这样的体系架构将迫使你首先构建底层的子系统，然后构建越来越上层的子系统。但是为了构建在底层子系统的正确的能力，你通常需要在上层的子系统上进行大量的详细设计和实现的工作，因为他们决定了什么是你在底层子系统中需要的。这产生了 “catch-22”的现象;第二个方法解释了如何解决这个问题。

　　方法 2 ：首先开发最重要的场景。如果你使用方法 1 ，你一次只能开发一个子系统。使用方法 2 ，你将重点放在了重要的场景上，或者使用系统的关键方法上，然后再添加更多的不是那么重要的场景。这与方法 1 有什么不同呢?让我们来看一个例子。

　　假设你正在构建一个新的应用，这个应用将为用户提供管理缺陷的能力。这是一个分层的应用，被构建在 WebSphere Application Server 上，使用 DB2 作为底层的数据库。在首先的迭代中，你开发了一系列重要的场景，比如输入一个简单的缺陷。在第二次迭代中，你为这些场景添加了复杂性 — 例如，你也许使缺陷能够被一个工作流来处理。在第三次迭代中，你通过为非典型的用户提供完整的支持，比如保存部分的缺陷条目然后返回到这个条目中的能力等等。

　　使用这种方法，你在 所有的迭代中完成 所有的子系统的工作，但是在第一个迭代中你仍然关注最重要的场景，而将不是非常重要的或者最小难度的场景留到最后的迭代中实现。

　　如果你正工作在一个良好定义的体系架构的系统中时，方法 1 是更加适合的 — 比如，一个已存在系统的增进或者开发使用简单体系架构的新应用。多数构建复杂应用的项目应该使用方法 2 ，但是他们应该以这样的方式来计划迭代，这种方法能够削减后来迭代的范围以弥补可能的时间推延。

　　步骤 3: 在项目的早期基线化一个可执行的架构。

　　你可以将这个步骤看作是更加正式和有组织的完成步骤 1 ( 尽早的构建功能原型)的方法。但是什么是“可执行的架构”呢?

　　可执行的架构是系统的部分的实现，它被构建以演示架构的设计所支持的关键的功能。更重要的是，它能够证明设计能够满足对于性能、生产能力、容量可靠性、可测量性和其他方面的需求。构建一个可执行的架构允许你在稍后的阶段中在一个坚实的基础上构建所有的系统功能性的能力。这个可执行的架构是一个 进化的原型，它的目的是当系统的架构成熟时，保持已经被证明的特性并保证他们最大可能的满足系统的需求。换句话说，这些特性将是交付系统的一部分。与你在步骤 1中构建的 功能原型相比，这个进化的原型覆盖了架构问题的所有方面。

　　生成一个进化的原型意味着你要设计、实现和测试一系统的个框架结构或者架构。在应用的角度上，系统的功能还没有被完成，但是大多数的构建模块之间的接口已经被实现了，你能够(并应该)在某种程度上编译并测试架构。指导初始的负载和性能测试。这个原型也会反映你的关键设计的决定，包括技术、主要组件和他们之间接口的选择。

　　但是你将如何为这个进化的原型提出系统的架构呢?关键是将重点放在最重要的百分之二十到三十的用例上(系统为用户提供的完全的服务)。这里是一些决定什么用例是最重要的方法。

原文转自：http://www.ibm.com/developerworks/cn/rational/r-iterative/