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

　　你能够在每一个迭代中发现并更正缺陷。这会生成健壮的架构和高质量的应用。你甚至能够在早期的迭代中而不是在项目末期的大规模测试阶段发现缺陷。你能够在性能瓶颈没有破坏你的计划之前发现它。

　　它能够更好的利用项目的人员资源。很多开发组织使用一种管道式的组织方式来匹配他们的瀑布型开发方法：分析人员将被完成的需求发送给设计人员，设计人员将被完成的设计发送给开发编程人员，编程人员再将他们开发的组件发送给集成人员，集成人员将组件集成起来发送给测试人员测试。这种多次的传递不仅容易产生错误而且应用造成误解;这种方式也会使人们感觉他们对最终的产品有很少的责任。迭代开发过程鼓励在项目的各个环节中团队成员参与范围更加宽广的活动，允许团队成员扮演多种角色。项目经理能够更好的利用可得到的项目人员并其可以消除有风险的传递。

　　团队成员能够沿着项目的道路进行学习。工作在迭代开发的项目中的开发人员在软件开发周期内有很多的机会从他们所范的错误中吸取教训，并能够从一个迭代到另一个迭代的过程中增进他们的技能。通过评估每一个迭代，项目经理能够为团队成员发现培训的机会。相反，工作在瀑布型开发方法中的开发人员典型的被限制在狭窄的技术专长上，并且仅仅有机会从事设计、编码或者测试之一方面的工作。

　　你能够沿着项目的道路改进开发的过程。迭代末尾的评估不仅能够从产品或者计划方面揭示项目的状态;他们也可以帮助项目经理分析在下一个迭代中如何改进项目的组织结构和过程。

　　一些项目经理反抗采用迭代的开发方法，将迭代开发视为一种没有尽头的、不可控的形式。然而，在 RUP 中，这个项目是能够被很好的控制的。迭代的次数、周期和目标被仔细的计划;并且项目参与者的任务和角色被良好的定义。此外，进展的客观量度应该能够被获取。虽然团队要从一个迭代到下一个迭代中重做一些事情，但是这个工作也是可以被仔细的控制的。

　　回页首

　　转化的四个步骤

　　多数的瀑布型的项目将开发工作划分为阶段或者时期;我们也可以将这个划分视为向迭代方法转换的第一步。但是为了实现向迭代开发方法的过渡，我们要使用下面四个步骤来应用不同的过程原则：

　　尽早的构建功能原型。

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

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

　　采用迭代式的和风险驱动的管理过程。

　　让我们来更进一步的解释每一个步骤。

　　步骤 1 ：尽早的构建功能原型

　　作为向迭代开发转换的第一步，在需求和设计阶段考虑一个或者更多的功能原型。这些原型的目标是减少主要的技术风险和澄清项目涉众对系统应该做什么的理解。

　　通过识别最重要的三个技术风险和最重要的三个有必要澄清的功能部分开始。技术风险也许与新技术、对整个方案影响很多的未决定的技术选择或者你知道的很难满足的技术需求有关。功能上的风险也许与项目涉众为关键的功能性提供了模糊的需求或者几个需求对项目系统都是核心的有关。

　　对于每一个重要的技术风险，拟订你要原型化什么以减少风险。考虑一下下面的例子：

　　技术风险: 项目需要将一个已存在的应用移植到 IBM WebSphere Application Server 上运行。用户已经开始抱怨应用的性能，并且你所担心的是移植后也许性能会更加的慢。

　　原型: 构建一个架构的原型来找出移植你的应用的不同方法。要求一个专家级的 WebSphere 架构师来帮助你。评价结果并编写架构的和设计的指导方针为开发团队提供什么 应该做和什么 不应该做。这将增加你移植的应用的性能是足够好的以避免在项目后期返工的可能性。

　　技术风险: 你正在为安排和估计软件项目构建一个新的应用。你知道对于这个应用和购买的软件的关键区分将是如何能够很好的支持迭代计划。然而，这也是在你的需求说明中最模糊的部分之一。

　　原型: 基于你关于如何支持迭代项目计划的设想构建一个功能原型。通过向不同的项目涉中演示原型，你将可以鼓励他们更加注意项目的计划，并且他们能够告诉你他们对你的哪些设想是赞同的、哪些是不赞同的。原型将帮助你澄清计划的需求，也能够为你提供关于用户体验和对于你的应用的外表和感觉的有用的信息。这个原型甚至能够产生一些可重用的代码。

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