将项目从瀑布式转为迭代过程

◆初始计划是什么以及为什么？
　　◆为什么RUP更有意义？
　　◆我们改变了什么？
　　◆哪些是我们要保留的相同内容？
　　◆结果是什么？
　　◆你应当在何时考虑使用RUP方法替代瀑布法？
　　◆你首先应当作的事情是什么？
　　◆结论

　　本文来自于 Rational Edge：通常，坚定地相信迭代化方法的软件开发者必须为那些出于各种原因而坚持使用传统的瀑布方法理念的客户服务。本文就是讨论如何帮助那些人改变观念，转为使用Rational Unified Process。

　　迭代开发技术的支持者——尤其那些花费了若干年掌握如何使用Rational Unified Process和相关的迭代方法进行软件开发的专业技术人员和顾问——他们经常批评传统的"瀑布"方法，甚至不理解为什么瀑布法仍然在软件开发公司中被广泛使用。为了拿出客户要求的IT解决方案的项目计划，我们会涉入到许多项目，它们最初都使用瀑布方法。这些解决方案包含开发新软件以及扩建新的基础结构。

　　我们有许多不错的使用瀑布方法的理由，包括：

　　﹡瀑布法在过去的使用中很成功
　　﹡我们可以重新利用其它瀑布项目的资源
　　﹡我们的团队（也就是我们客户的员工）感到使用瀑布法很方便
　　﹡我们的团队希望在进行开发之前完成全部的设计任务
　　﹡我们的团队也许和另外一只使用瀑布法的团队合作 （尤其是那些为我们的整体解决方案和建设基础结构的团队）

　　不论这些理由是什么，使用Rational Unified Process?或者RUP?进行项目开发比使用瀑布法更有意义。我们可以把项目计划和所有的方法转换为迭代方法。本文就是基于以上所述，带您体验这种方法。

　　初始计划是什么以及为什么？

　　初始计划通常包括许多设计阶段，在这些阶段中我们要概述客户的解决方案。因为这些项目将会有多个软件发布版本，所以初始的设计阶段包括了软件的整体设计。然后针对每个发布版本我们都会有一个设计阶段。随后的每个设计阶段将变得越来越具体，因为我们的客户逐渐清楚什么是他们所需要的，而此时我们的团队也可以开始动工了。

　　为什么RUP更有意义？

　　对于我们的许多项目，在与客户一起评审完我们的瀑布法计划后，就显示出来一个面向RUP的项目计划比我们的瀑布法计划更具加有意义，这里有很多理由，包括：
　　客户想要尽早获得成果。一些客户不愿等到我们大量的设计工作完成之后才进行开发。它们经常提出一些要求并且想得到应用程序的代码，然后就可以尽快地把它们拿给股东们看了。

　　在首次软件发布日期之前，客户不会提出所有高水平的要求。在进入到计划设计阶段尾声之前，一些客户不会提出全部的要求，或者是因为一些冲突或者其它的一些限制（例如，一个在今后某个时刻才能做出的决定）。

　　客户希望牢牢控制项目的周期和预算。 尽管项目会出现一些不确定的要求或者其它的不确定因素，但是客户依然想控制项目的进度。由于RUP项目的每一个阶段是一个时间箱，因此我们可以准确地描述项目的进度以及每个阶段所需的资源，还有每个阶段完成之后项目的开销。

客户和开发者都想尽快消除项目中的风险。尽早地为客户提供应用程序代码，可以减少由于应用程序没有按时交付所造成的风险。对于开发团队，尽早地发布项目中应用程序的部分内容，特别是与新技术有关的应用程序内容，可以有助于他们降低开发应用程序时遇到的风险。

　　在资金发生变化时客户想要终止项目。通过为项目提供高价值的功能，RUP可以使客户最大限度地灵活地花费他们的资金，并获得尽可能多的预算，以维持这项工程。如果我们使用瀑布法，就会出现当设计出许多出色的软件版本后，我们才发现资金仅仅够开发其中的一个软件。

　　我们改变了什么？

　　在从瀑布法到RUP的调整过程中，有许多需要改变的地方：
　　
　　﹡项目结构。改变项目结构是非常关键的一步。我们将从我们的瀑布法阶段，包括高层设计，总体设计，发布设计，构建，测试，部署，发布设计，构建，测试，部署－－转到RUP阶段，包括多个精化阶段，随后是多个构建阶段。我们可能重复这个过程，并且每个迁移阶段都会按照这个过程进行。

　　﹡时间框架。在我们开始之前，每个迭代都会被限制在一个时间框架中。如果我们认为在一个精化或构建迭代阶段没有足够的时间完成我们的工作，我们将把这项工作推延到下一个迭代中去。这个与我们在瀑布项目中处理的方法是不同的，在瀑布法中，为了完成设计，构建，测试或者部署，我们可能会扩展这个阶段。

　　﹡资源使用。在瀑布法中，我们在设计阶段拥有的资源在构建／测试／部署阶段时将不复存在。利用RUP方法时，我们可以保证资源贯穿于每一个阶段。在项目中，我们可让一个人在不同的阶段扮演不同的角色。

　　﹡早期开发。我们几乎是立即着手开发应用程序，甚至是精化迭代和设计还未完成。而利用瀑布法设计，开发在设计完成之前是不能进行的，利用RUP的项目，我们通过迅速开发部分项目来降低了风险并且获得了好处。尤其是项目开发的最初几周，也就是我们着手开发用户界面的阶段。迭代法可以使我们周期性地提供应用程序的进展，让我们的客户感到满意。迭代法还帮助我们在客户的要求问题上与他们达成一致。它还可以让我们持续地检验应用程序的品质（例如，让我们开发的应用程序满足客户提出的要求）。它还可以通过让开发团队使用新技术来降低风险（例如，使用从未用过的永久性构架技术）。

　　哪些是我们要保留的相同内容？

　　从瀑布法到RUP，尽管我们改变了许多，但是我们并没有全部摒弃传统的设计方法。

　　对其它活动的关联。当我们将项目开发从瀑布法转到RUP方法时，有许多支持项目和子项目也在同时进行。在我们初始的瀑布法项目中，我们有了一个关键路径，将我们的项目中的关键活动与其它项目中的关键活动关联在一起。当把我们的项目转为RUP后，我们会记录下其它项目中关键活动的日期，然后在我们的项目中创建出与那些活动紧密相关的新活动。

　　角色与资源。在项目中我们扮演着同一个角色并且保持同样的资源，尽管项目的结构已经发生了变化。我们仍然想用相同的人员类型得到相同的设计、开发和测试量。还有，一些与应用程序开发无关的角色（例如，基础结构的开发）也被保留下来。

　交付物以及其它文档。我们希望在瀑布项目中计划产生的文档在RUP项目中仍旧产生。不管我们使用什么方法，顾客仍然想要关键可交付物（例如，主测试计划），而不管我们的方法是什么。同样地，我们创建了一个文档，让团队为每个项目准确地创建基础结构，如何配置服务器、软件，等等，无论是瀑布法还是RUP方法，我们都要做这一步工作。

　　所需工作量。尽管由于从瀑布法到RUP方法的改变导致了构建解决方案的方法发生了变化，但是无论使用哪一种方法，完成相同的工作所需的工作量并没有改变。

　　结果是什么？

　　当从瀑布法改为RUP方法后，我们发现：

　　﹡RUP帮助我们管理客户的需求，尽管客户也许还不清楚他们最初提出的每一个需求。我们需要牢牢地管理变更并且增加额外的阶段用于满足新的需求。时间箱和多个迭代帮助我们管理变更。在精化阶段，多个迭代意味着如果因为时间箱而无法在一个迭代中完成任务，但客户仍旧想要进行这个任务，我们就要把它转移到另一个迭代中去。同样地，在精化阶段，如果我们发现项目中包含了比计划还要多的任务，我们就将把一些任务转移到其它迭代中去。我们甚至可以增加额外的迭代，如果客户觉得这样做是值得的。如果客户被预算所限制，他们将不会再继续增加迭代，因为他们已经从完成了的迭代中获得重要的价值。　
 
　　﹡在构建阶段中的多个迭代也会帮助进行需求管理。通过使用迭代进行应用程序的开发，我们可以让客户确认他们在每个迭代中的要求。如果应用程序没有和当初设想的一致，我们还可以在下一个迭代中将它改变。这对我们的管理也有所帮助。

　　﹡RUP帮助我们自始至终中地保证质量。因为我们在每一个迭代结束后都发布代码，所以RUP让测试变得简单，并且降低了在项目的后期发现重大问题的概率。

　　﹡可视化建模帮助客户发现什么是他们想要的以及帮助我们了解什么是客户想要的。间接地，它还帮助我们拉近了与客户之间的关系。客户觉得可以更进一步参与到应用程序的开发中去，应用程序能够如期完成并且包含全部他们想要的东西，这些都让客户感到非常得满意。

　　﹡采用组件架构使我们可以交付独立的、功能性软件用于较早的测试。它在帮助开发团队进行任务分解和分配工作时也显得十分有用。

　　你应当在何时考虑使用RUP方法替代瀑布法？

　　以下是在何时用RUP方法替代瀑布法的一些建议：
 
　　1、使用瀑布法无法满足客户时。例如，客户对要花费很长时间才能看到结果感到不满时。或者客户抱怨他们需要更加灵活的应用程序，或者他们想在开发的早期就可以解决风险问题。或者当客户想在项目的开发初期就看到它的组成部分，不是简单的原型或者证实可行的概念，而是即将成为全部应用程序一部分的实际项目代码，RUP 就为以上这种开发方式提供了框架。

　　2、客户当前已经普遍使用一个或多个Rational工具。如果真是如此，那么他们应经看到了IBM Rational软件的价值以及这种迭代方法所带来的好处了。你可以告诉客户，在不久的将来使用RUP可以使这些工具变得更加有价值。 

原文转自：http://www.ltesting.net