内容


Rational Edge

在降低风险的情况下更快地交付系统:RUP 的宏观迭代维度

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Rational Edge

敬请期待该系列的后续内容。

此内容是该系列的一部分:Rational Edge

敬请期待该系列的后续内容。

插图IBM® Rational Unified Process® 或 RUP® 中内嵌的开发方法是沿着微观和宏观的维度迭代的。本文着重于宏观的迭代维度,介绍演进的概念,表现出多重,重叠地通过 RUP 生命周期。这种处理 RUP 的方法支持尽早且频繁地向生产交付系统的敏捷原则。就像每个迭代都减轻项目风险一样,每个向生产的演进版本都减少组织的风险。

扩展迭代开发的概念

迭代开发是基于 Barry Boehm1 在 80 年代末开发的螺旋模型。这些年来,图 1 中显示的 RUP 生命周期图已经成为表现 Boehm 的模型的 RUP 解释的传统方法。它显示出四个阶段 —— 初始(Inception)、精化(Elaboration)、构建(Construction)和产品化(Transition)—— 每一个阶段都由一至多个迭代组成。每个迭代 —— 和后续的每个阶段 —— 都包含构建和测试一些东西,不论它是商业过程模拟、架构上的原型、操作代码,或产品发布。迭代包含达到阶段里程碑所需的所有规程和活动2,定义了一个有时间限制的框架,在该框架中实现向该里程碑的增量前进。

图 1:众所周知的 RUP 生命周期图

RUP 生命周期图沿着能充分表现小项目所需的工作的微观迭代维度描述 RUP。虽然这没有描述的十分明显,但是 RUP 生命周期图表现出用于单个项目和完整的软件开发生命周期的环境3。组织一般根据项目会生成稳定部署的系统的前提来构建和投资项目。如果项目只需要通过软件开发生命周期一次来创建这样的产品,并向最终用户交付,那么足够将该工作分解为阶段中包含的一系列迭代4

然而,许多中型和大型项目很大地得益于多次经过 RUP 生命周期,这对成品软件和定制开发的软件来说都是事实。这些项目需要将迭代过程描述为一系列循环的,宏观的迭代维度5,这就是我所称的演进6

一次演进表示通过生命周期的所有四个阶段一次。这形成了有用的产品,但是对它的理解是该产品在通常的意义上没有“完成”。正在进行的演进将继续改善特性、架构,和前面的演进的代码。Bittner 和 Spence7 广泛地使用此概念来描述在单个项目环境中的并行开发工作,促使管理者从宏观的迭代角度观察发布计划迭代,并且通过一系列多重演进向最终用户交付特性。我将在下面分析此概念。

演进的力量

随着市场竞争越来越强烈,IT 项目处于向最终用户更快地交付能力的不断压力下。瀑布开发过程的设计是同时交付所期望的所有能力 —— 一种开发中到大型复杂系统的无效方法8更频繁地 交付较少量的功能是更有效且风险性更小的 —— 换句话说,要通过多次将产品发布生产。这是 RUP 的演进方法背后的基本前提。这还是敏捷、迭代的方法的宗旨,表现出就风险、成本、质量,和效率而言,在瀑布模型上的重大改善。

演进的好处

将 RUP 作为一系列演进提供了许多重要的好处9

  • 人们关注短期目标。交付日期作为激励因素,确保项目中的每个人都针对相同的目标。
  • 团队成员在早期获得满足感和有价值的学习经验。 团队成员马上获得了实际的工作产品 —— 以及评估其力量和弱点的机会。
  • 最终用户可以设置优先权。 组织及其最终用户团体可以决定他们马上需要什么能力,以及那些可以等到之后的版本10。他们很愿意的是知道他们想要最终实现的所有特性 —— 并且自己设置交付优先权。
  • 组织全面受益。 组织中的更多部分收到向生产发布的有益的版本,因为有更多的版本出现。
  • 管理者可以更好地利用固定的和矩阵模型的资源。 在典型的精化阶段,系统分析师、设计人员和架构师兴奋地工作着,测试人员只有少量的工作,因为他们要根据用例创建测试案例,而开发人员不是非常繁忙。如果您为多个演进进行计划,那么您可以通过确保使得所有组在任意时刻都充分利用的方式将活动分布到整个项目过程中。
  • 在开发和交付生命周期中,项目涉众仍旧充分参与。 在定义和创建所期望的解决方案时,项目经理可以利用并持续来自 IT 和业务贡献者的参与。那些有特殊的专家经验的人可以很容易地从一个演进移动至下一个演进,而他们心中的项目挑战仍旧是新的。一般,业务专家参与最多的是在初始和产品化阶段,系统分析师和架构师在精化阶段参与最多,而开发人员一般在构建阶段下手。如果您的非重叠的迭代之间有很大的时间空隙,那么您可能会冒将这些资源流失给其他项目的风险,并且可能需要引入在更早的阶段没有参与的新的参与者。演进的方法帮助维持项目的连续性和势头 —— 在短期生成高质量产品的关键需求。
  • 架构可以增量地演进。 团队可以不断地精练并增强架构,而不是试图一次性定义所有架构上重要的组件。
  • 管理员可以更好地了解并维护产品。 项目经理可以将应用程序管理员视为项目涉众,给予他们时间和机会来了解产品,将产品集成到生产环境中,并且有效地管理产品。在部署之后,他们还可以根据现实的经历和轶事证据,提供反馈,指导后来的演进。

总的来说,这些优势使 IT 组织可以向业务经理证明,可以快速有效地交付满足最终用户需求的高质量的产品。该方法通过在过度的文档之上提出工作代码,并且快速且频繁地将该代码交付生产的方式促进敏捷的实践。

重叠的演进:扩展宏观的维度

严格来说,在 RUP 中您采用各阶段的顺序是不可变的。在每个阶段中,您必须在下一个阶段开始之前,通过执行一个或多个微观的迭代来实现主要的里程碑。当您完成所有阶段时,您完成了演进 —— 宏观的迭代。

然而,如果您交错并重叠多个演进,那么您可以有效地操纵这些阶段。举例来说,您可以在开始另一个演进的初始阶段的同时处理一个演进的构建阶段。如果您在开始另一个演进的同时将产品发布到生产环境中,那么您可以将从一个演进的产品化阶段了解到的东西反馈到新的演进的初始和精化阶段。

演进可能最多重叠三个阶段,但不是四个,您不可能在完成前面演进的阶段之前开始一个演进的相同的阶段11。同样,重叠的演进包含风险,如果存在对后面演进中的架构和需求的重大变更,那么这些可能影响更早的演进。有效的变更管理过程可以帮助解决这种难题。

所有这些微观及宏观的迭代的主要优势是他们出现在单个投资的项目的环境中,提供简单且精制的过程,定义、构建,并交付信息系统。现在,RUP 需要的是一种可视化地表示迭代的宏观和微观的维度的简单,且精制的方法,使第一次见到它的观察者可以立即领会。

在现实项目中应用演进

最近,在领导团队对主要的 RUP 项目应用演进的方法的时候,我开发了三种可能的方法来描述 RUP 的两个迭代的维度。在做这个的时候,我应用了 Edward Tufte12 提出的原则,他是多元图形设计领域中的先驱。每种描述方法都有不同的强项和弱点。在观察每个之前,让我们开始对该 RUP 项目的简要描述,该项目是我所称的 Project X。

Project X 概述

为了在市场中的有竞争力,一家国家健康保险供应商想要为其两个客户市场创建基于 Web 的在线记帐支付系统:1) 个人和家庭成员,和 2) 向职工提供健康保险的商业客户(也就是,雇主)。管理层决定,为个人和家庭成员开发特性会比为雇主实现类似的能力要更容易。因此,他们计划为个人及家庭成员的市场进行第一个演进,后继的两个演进满足雇主市场的更复杂的需求。

中型项目包括 34 个用例,并且来自第一个演进的一些用例逻辑会在后面的演进中复用。然而,对于后面的演进的特性将主要需要新的代码。

虽然许多 IT 职员(通过外包进行补充)可以支持并行的开发迭代,但是业务专家和分析师供应有限。许多人有其他的委托,并且只有一小段时间。为了优化对这些专业人员的使用,管理层决定重叠演进,大于对一个典型项目,这可能重叠连续演进的产品化和初始阶段。

当一个特定的阶段在一个演进中结束时,同样的阶段在下一个演进中开始。在第 16 周的过程中,三个不同的阶段(精化、构建,和产品化)在三个演进中同时进行。

Project X 的螺旋视图

图 2 显示了一种描述我们所使用的宏观的迭代方法的方式。它显示了该项目的三个演进,用圆柱来表示迭代。注意到每个圆柱都包含于表示演进的螺旋中。

图 2:Project X** 的螺旋视图


**图 2、3 和 4 由 Erin King 说明,2007 年

每个圆柱的体积反应出根据个人时间的迭代的整体相对的工作水平(LOE)。圆柱的每个薄片表示不同的规程,根据 RUP 的最佳实践,所有的规程都包含于每个迭代中。每个薄片的厚度反映出该规程中不同角色的 LOE。这类似于图 1 中的驼峰跨迭代和阶段传送 LOE 中的,每个规程所需的变化所采用的方法。注意规程薄片在不同类型的迭代中厚度的不同13

在第一个演进中(I1),初始阶段是全面的(四个星期长)。它为整个项目确定了范围和被担保的项目涉众买进。随后的演进(I2 和 I3)中的初始阶段非常短。它们仅仅定义了它们各自的演进的范围和进度。注意到第三个演进有两个连续的构建迭代(C3 和 C4)。这是因为实现迭代 E3 中定义的需求所需的大量编码。

Project X 的泳道视图

图 3 显示了为 Project X 描述宏观迭代维度的另一种方法。它使用泳道代替螺旋来表示演进,并且用长方体代替圆柱来描述迭代。每个长方体的体积反应迭代的相对 LOE。也要注意时间轴上的迭代的位置与图 2 中的那些相对应。

图 3: Project X 的泳道视图

虽然图 2 指出,迭代可以并行处理,但是它没有表现出在演进中和跨演进的迭代如何彼此依赖。使用箭头,图 3 中显示出一个迭代的结果如何流入其他的迭代,因而,总的来说有助于完整、自动的解决方案。

在 Project X 中,迭代 E1 有六个星期长,并且生成了八个重要的用例。当团队达到了精化阶段里程碑时(也就是,系统该部分的架构和需求稳定了),迭代 E1 中涉及的架构师、程序设计人员,和测试人员成为迭代 C1 中的主导成员。在该迭代过程中,团队成员为 E1 中指定的特性构建最初的操作能力,为个人和家庭成员生成稳定的在线支付产品。迭代 T1 允许主题专家在产品向生产发布之前,在系统上实施用户体验测试并且停止活动。

在迭代 I1 中开发的项目计划指示会有三个产品版本 —— 并且因此有三个演进。然而,当他们在迭代 I2 中计划第二个演进时,业务项目涉众发现在缺少计划在演进 3 中构建的特性的情况下,部署演进 2 的结果是没有商业价值的。因此,他们决定投资并执行演进 2,通过产品化阶段(包括用户体验测试),但不将其发布为正式的产品版本。这就是为什么,如图 3,迭代 T2 是半透明的,并且有一个虚边。在此实例中,演进模型本身提供了很大价值,允许团队避免不必要的工作以及重复的工作。

Project X 的投影视图

虽然不像图 2 或 3 那样在图形上吸引人,但是图 4 传达了类似的信息,以及附加的参数:跨多个迭代的任意时刻所需的资源总数。每个长方形正面上的点表示该迭代中每个规程所需的相对资源数量。当这些点映射到总资源列(图的顶部)上时,结果是附加的。该图说明了一个非常真实且很少了解的风险:要在宏观层次迭代地开发系统,当演进重叠时,您必须预先考虑在最激烈且难于管理的阶段充足地供给项目所需的资源的数量和类型。注意当同时进行三个劳动密集的迭代的时候,在实现和测试规程中的资源数量如何在第 16 周最高。

这里是 Project X 有趣的地方。迭代 E3(为雇主的在线支付能力定义了后半部分需求)与迭代 T1(对于系统的个人和家庭成员部分的用户体验测试)和构建迭代 C2(实现雇主需求的前半部分)同时处于积极进行中。这表现出重大的人员供给难题:系统分析师如何在支持前面演进中所涉及的开发人员和测试人员的同时书写用例?测试人员如何能够仍旧参与需求启发活动,同时又浸入系统、集成,和用户体验测试?虽然有时候组织、人员供给、沟通,并跨并行的演进协作是令人迷惑的,但是这些好处 —— 加速投放市场的时间,并且最大化可用的商业资源 —— 大大地超过所需的努力。

图 4: Project X 的投影视图

Project X 结果:更快地投放市场的时间,最大化资源利用,更好的软件

在第一个演进结尾,从项目开始不到五个月,个人和家庭成员的在线记帐支付应用程序已经部署到生产中。实际的交付日期比计划的更早,因为通过演进的迭代得到了效率。

不管您如何选择描述演进的方法,它缩短投放市场的时间的能力对项目的成功是不可缺少的。在这种情况下,它在商业团体中形成了信心,IT 组织可以快速地交付高质量的解决方案。它证明是将迭代开发和 RUP 引入该组织中的无价的方法,只要:

  • 尽早交付的工作系统达到一般的目标客户市场
  • 改进后续的架构和代码版本的能力
  • 在项目中最大化可用的资源

演进向团队提供了两全其美:在每个阶段中构建并生成一些东西的迭代,和多个生产版本。如果 Project X 只依照 RUP 生命周期中描述的微观的迭代方法,那么团队会连续地在一个生命周期中执行大约十个迭代,并且整体花费更多时间。在项目的结尾只会有一个版本,并且会消除了我们通过演进所取得的最重要的好处。

后续

虽然在 RUP 中没有得到正式地公认,但是演进为计划并开发增量地交付系统提供有价值的机制。在我看来,开发团队应该像对微观的迭代维度那样强调宏观的迭代维度。将较大的演进循环与较小的迭代循环组合形成了在减少组织风险的同时迭代地开发信息系统的极其强大且灵活的方法。

此方法尤其适用于某些类型的项目:

  • 那些受到快速地投放市场或者初始的产品展示需求约束的项目
  • 那些天生地需要打包到许多演进中的大型项目
  • 那些跨财政周期或其他区间分配投资的项目

学习 RUP 的学生对本文中的图顺利地给予响应,说三维的透视图帮助他们对并行的活动如何随时间进行,以及产品如何增量地交付生产有了概念。他们还感觉投影图强调出有效的资源管理对成功的演进项目有多重要,随着在跨多个演进的不同迭代过程中资源的加入,团队必须经常地重新分析优先级。

我的希望是这些插图将帮助 RUP 支持者、项目经理、指导者和参与者有效地与 IT 和业务专业人员沟通 RUP 的宏观的迭代特性,并且得到对交付一个以上的生产版本的概念的支持。随着这些提议在 IT 行业中得到讨论和观察,甚至更有用的图形表示可能出现,将最终在 RUP 中正式采用。

根据我大量的 RUP 项目经验,我相信将中型和大型的项目划分为多个演进来最大化资源分配,并且提供更早的交付生产的版本,反应出过程的最终价值。扩展 RUP 来包含宏观的维度将使其更敏捷,并且帮助区分它与其他方法不同的独特的迭代特性。

致谢

感谢 Peter Haumer、Rolf Reitzig、Bill Nazzaro、Karen Capers、Ben Lieberman、Stephanie Stone、Matt Kear、Jody Frank,和 Gene Teglovic 对本文各个方面的贡献和洞察。

注释

1 Barry W. Boehm,“A Spiral Model of Software Development and Enhancement”,IEEE Computer,vol. 21,#5,1988 年 5 月。

2 Barry W. Boehm,“Anchoring the Software Process”,IEEE Software,vol.13,#4,1996 年 7 月。

3 Philippe Kruchten,“Software Maintenance Cycles with the RUP”,The Rational Edge,2001 年 8 月。

4 Grady Booch,Object Solutions: Managing the Object-Oriented Project,Addison-Wesley,1995 年。

5Best Practices for Software Development Teams,Rational Software 白皮书,1998 年。

6 Kurt Bittner 和 Ian Spence,Managing Iterative Software Development Projects,Addison-Wesley,2007 年。

7 同上。

8 Per Kroll,“The RUP: An Industry-wide Platform for Best Practices”,The Rational Edge,2001 年 12 月。

9 同上,Bittner 和 Spence,2007 年。

10 Per Kroll 和 Walker Royce,“Key Principles for Business-Driven Development”,IBM developerWorks,2005 年 10 月。

11 同上,Bittner 和 Spence,2007 年。

12 Edward R. Tufte,The Visual Display of Quantitative Information,Cheshire,CT: Graphic Press,1983 年。

13 Philippe Kruchten,The Rational Unified Process: An Introduction,Addison-Wesley,2004 年。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=269771
ArticleTitle=Rational Edge: 在降低风险的情况下更快地交付系统:RUP 的宏观迭代维度
publish-date=11152007