来自于 Rational Edge：本文介绍了被称为Scrum的灵活软件开发过程。作者阐述了软件开发团队在已有RUP环境中加入Scrum理念的技术。

正如你所知道的，RUP（Rational Unified Process，Rational 统一过程），是一种被广泛使用的软件过程框架。它可以很好地迎合你的软件开发过程的需要，还可以容纳其他技术。Scrum是一系列有趣的，用来包装灵活软件项目的项目管理模式。本文介绍了Scrum的一些重要特性，并阐述了可以让你在已有RUP环境中加入Scrum理念的技术。我在工具条内提供了关于Scrum和“灵活”的术语的词汇表，并且在下文中这些术语首次出现的地方用星号作了标记。

什么是Scrum？

Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。Scrum于1995年由Advanced Development Methodologies,Inc提出，并在2001年“敏捷联盟（Agile Alliance）”形成后受到了更多欢迎。这个轻量的过程可以作为包装器，也就是说你可以把Scrum与其它灵活的过程框架组合起来，比如说RUP。

这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来的重大变化。Scrum认为软件的开发不应使用和一般制造业相同的方法，也就是不应采用一种反复的模式。这种重复使得输入和输出参数更加容易预测和描述，但这并不是当今软件工程的有益目标。现代软件工程的主要挑战包括上市时间，投资回报，以及影响顾客的需要等。RUP和其他敏捷软件工程过程能够很好地迎接这些挑战。

Scrum如何工作

Scrum区别于其他开发过程之处是什么？假设你是一个Scrum项目的初次观察者，那么最显而易见的不同将是每天的短会，通常在每天的同一时间在同一个房间内举行。这个会议也叫Scrum，在会议中每个团队成员仅就以下三点发言：

• 自上次Scrum会议后你做了什么？
• 从现在到下次Scrum会议的时间里你准备做什么？
• 你在工作中遇到了哪些困难？

Scrum团队的组成

由于一个Scrum团队最多由7人组成，会议应当不超过15分钟。Scrum管理者*主持会议，并且对整个项目的成败负责。他倾听每个成员的发言并设法解决会议中提到的各种障碍。Scrum管理者在会上对障碍提出即时的解决方案或指导，使团队不断向着目标前进。Scrum会议不同于项目会议，对团队来说，它起到了快速简报的作用。如果问题得不到解决，团队成员应向Scrum管理者或大项目成员提出质疑。

只有团队成员可以在Scrum会议上发言，但是允许有旁听者。对于人数多于7人的项目团队，Scrum建议与其扩大团队规模不如将团队分组。分组可依据功能，结构主体，或者应用，包括子应用等进行。分组后各个子团队就可以并行工作了，而且Scrum管理者可以通过Scrum会议对各个子团队的工作进行同步。Scrum甚至可以兼顾在其他地方工作的团队成员。

Scrum团队不止是一个程序员队伍，它由各种背景下的不同角色组合而成，包括商业分析者，设计师，程序员和测试者等等。更多时候，成员可以身兼多职；正确的组合决定了团队的能力和效率。

项目规划

Scrum的迭代过程被称为“疾跑”，时间为30天。在RUP中，迭代过程通常在2至6周之间，每次“疾跑”都以获得可执行可测试的代码为结束。

产品拥有者持有产品订单，他控制并区分功能的开发次序，但是工作量的评估是由Scrum团队来完成的。产品风险的所有承担者，包括Scrum团队和产品所有者，共同检视订单，然后根据优先级次序决定先开发哪一功能。除去优先级，RUP的迭代规划过程也是基于风险的。

现在团队定义的“疾跑”目标已经成为了进展控制的指导。“疾跑”过程一旦开始，团队全部与外界的交流都必须经由Scrum管理者进行。Scrum管理者务必保证团队能够专心于既定目标而不受外界干扰。

Scrum团队持有自己的“疾跑”订单，上面记录了更多关于待实现目标的具体任务的细节。在团队对“疾跑”的作用有更多了解以后，团队成员就可以调整原始的产品评估，并将“疾跑”过程中获得的信息加入到产品订单中。这些做法对Scrum进度回溯都是有益的。

Scrum团队由每天的Scrum会议，每月的“疾跑”计划和“疾跑”审查会议紧密相连，鉴于此，整个组织必然存在一种纵向的透明度。这就使得组织上的问题和挑战清晰明显。由于团队成员都亲自观察整个项目，交流也就变得简短，迅速和有效。团队是自组织的，着眼于“疾跑”的目标，这样就最大限度发挥了每一个团队成员的作用。Scrum管理者充当一个问题和交流的“票据交换所”，而不是一个控制整个团队的老板。

“疾跑”审查会议持续半天。在会上，团队向项目的风险承担者展示完成的功能模块。团队按照既定的“疾跑”目标来演示完成的内容。

订单，“疾跑”计划和回顾，管理承诺，每日Scrum会议，进度回溯，以及其他Scrum技术都是基于主要用于软件项目管理的进程模式的。这些模式在过去的大小项目和不同商业领域中都获得了成功。如果你打算采用Scrum进程模式并与RUP结合起来，下面一部分将向你解释更多要点。

Scrum与RUP的结合
现在使用RUP的软件项目可以很容易地从Scrum原则中获益，即使已经开始的项目也是如此。首先需要调研的是RUP过程模型，Scrum如何影响RUP最好的实践活动，四个阶段（初始，细化，构建和产品化），以及RUP的九个原则。RUP各阶段和原则之间的关系如图一所示。

图一：左边列出的是RUP的各个原则，与项目的四个阶段相关联。

尽管大多数原则与各个阶段都相关，上图表示出了在各个阶段中原则的不同的相关度。

RUP：软件开发的最佳实践

让我们从RUP过程框架的六个最佳实践开始吧。

迭代开发
Scrum项目强制执行迭代的开发过程，以30天为一个合适的开发时长。尽管在对“迭代”的定义上RUP更为灵活，30天的限定仍然经常被RUP使用，并且已被认为是一个有效的长度。工作总是按照30天的“疾跑”排列下来的，而不是定义一个RUP项目的一次迭代的长度。

管理需求
整个团队都可以管理需求，但是需求的控制权是由产品所有者掌握的。在RUP中，需求工程师对需求负责，但在Scrum中，这一责任属于产品所有者，通常表现为商业风险承担者。在RUP中，需求管理需要通过协作完成。

使用模块构建
体系架构是由公司的开发策略和指导决定的，或者由团队自身提出。RUP倡导的以体系架构为核心的方法导致了对各种应用结构的仔细考虑和选择。在Scrum中，这一定义较松，并决定于发布给团队的指导和标准。很多灵活的软件项目使用现代软件工具和编程语言，比如，模块构建占主导的技术。

可视化模型
RUP提倡可视化模型。甚至RUP框架本身就是可视的，有很多UML的外壳。和RUP一样，Scrum虽然不要求开发团队建构某一特定的可视化组件，但是委派Scrum团队完成这项工作。关于使用哪种组件，使用到何种程度和质量，取决于既定的“疾跑”目标。由于UML在工业界的广泛认可，很多工业专家都使用可视化技术，并且在RUP和Scrum中，可视化模型的使用都是很普遍的。

持续的保证质量
迭代，递增的开发已经为每个软件项目的质量和进展提供了很好的度量手段。Scrum团队完全集中于他们的“疾跑”目标，在30天的周期内必须展示工作成果。在这种方式下，功能是用一种重复的方式测试，度量和展示的。但是在大型组织中，质量控制是从各种角度观察的，而且需要更高质量管理的程序。Scrum可以从RUP的质量保证计划中获益，该计划由项目管理者控制，是成功的迭代开发的重要组成部分。

管理变更
在任何现代软件开发项目中都会出现变更（变化应该是受到欢迎的！），但是Scrum管理者不会为了引入发生在达成共识的目标上的变更而打断一个“疾跑”周期。他们抓住需要的变化，在本次“疾跑”结束时提出它们作为下一系列目标的一部分。这对Scrum的“疾跑”来说是最关键的。团队与外界隔离开工作，不予许变化影响当前的“疾跑”。否则，迭代开发的领域（“疾跑”的目标）的不断调整将会导致团队失去中心，不能很好完成疾跑伊始确定的功能目标。

Scrum和RUP原则

为了在Scrum的上下文环境中讨论RUP的九个原则，我把它们分成了两类。第一类是关于“雨伞活动”的，它们间接的对系统开发或组织有益，比如“环境”，“项目管理”，和“配置和变更管理”。第二类是材料活动，包括“商业模型”，“需求”，“分析和设计”，“实现”，“测试”，和“部署”。

雨伞活动

雨伞活动是指Scrum团队上层的管理机制，应由外部的风险承担者处理，比如，项目管理。除了扮演项目经理角色的Scrum管理者，团队成员应该专注于对实现Scrum目标必要的活动，而不应陷于管理工作之中。

RUP的“项目管理”原则，特别是项目规划，为软件开发团队提供了体验Scrum精髓的绝好机会。从Scrum管理者开始项目起，对团队来说RUP项目就如同一个Scrum项目。内部的组织上，管理上，语言的，非语言的交流都应被Scrum团队消除，而应该交给Scrum管理者（在RUP中称为项目经理）处理。一个RUP项目规划对如下工作来说是最理想的：

• 概括项目中应用的Scrum规则；
• 确定项目阶段标志；
• 描述正在进行中的“疾跑”目标；
• 呈现风险；
• 描述评估和评估使用的技术。

在Scrum中，Scrum管理者充当了管理和Scrum团队之间的协调人。管理者管理项目的使用域和功能，同内部和外部进行交流，但是并不参与更具体活动级别的管理。这些职责和义务的不同需要在项目规划中定义。另外，Scrum团队成员的角色通常是设计师。

在一个Scrum管理的项目中，RUP环境原则下的开发工程是不断进行调整和修改的。开发工程把强制性的和可选择性的组件罗列出来作为成功的指路标。但是由于Scrum团队是作为一个独立单位工作的，团队开发的组件应该都被称为“可选择性的”以反映团队在Scrum环境中的控制作用。另一方面，你也可以从开发工程去掉所有和Scrum团队相关的组件。RUP中的一般开发工程模板都可以完成这种需要。经过一段时间，随着Scrum团队在“疾跑”过程中规律性地获得有用的文档，真实的开发工程也就成形了。

收集素材

余下的六个RUP原则对软件工程有更直接的影响，它们为Scrum团队提供了一系列可选择的组件和活动。RUP过程框架可以作为指导，提供可供考虑的有用步骤和组件。在特殊情况下，团队可以对每一条原则做出变更和修改，只要这种变更和修改有助于实现“疾跑”的目标。新手和经验不丰富的软件工程师可以把RUP作为交流的指导和一个结构化的环境。

RUP项目的四个阶段体现了软件工程过程中的不同项目样式。尽管Scrum原则适用于项目的整个生存周期，消耗大部分项目资源的细化和构建阶段最宜使用Scrum方法。与初始阶段相比，在细化和构建阶段团队的工作更加独立和指向切实目标。Scrum的“疾跑”规划，审查，和每日会议在这两个阶段是非有用的手段。

如果在初始阶段，甚至在项目开始之前，项目团队中有各种商业分析人员，那么在初始阶段Scrum也是很有益的。为了更好地保证项目的成功部署，产品化阶段可以单独作为一个项目拥有Scrum 部署团队人员。对整个RUP项目来说，Scrum项目管理技术可能不是最理想的，但是它们可以在项目的不同阶段以不同形式被采用。项目规划反映了这些决定，而且阐述了在某些阶段不使用Scrum技术的原因。

使RUP适用于Scrum的工具

与IBM的 Rational Process Workbench 共用时，RUP作为进程框架体现了强大优势，而且是完全用户化的。Rational Process Workbench 产品包含了RUP模型设计，RUP组织和RUP构建。

RUP模型设计是修改和管理核心模型的可视化工具。过程工程师可以对现有RUP框架进行修改以引入Scrum概念。使用RUP模型设计工具可以很容易的管理Scrum的角色和组件之间的依赖性。过程工程师可以使用RUP组织工具描述修改后的Scrum工作流。这样做有助于项目团队成员更好的理解Scrum过程。为了共享组织内的过程变化，过程工程师通过RUP构建工具发布进程。该工具将过程，组件和描述文档集成起来，并创建一个网络导航。

结束语
Scrum和RUP可以通过很多方式相互加强。RUP过程框架可以迎合你的项目需要；RUP开发工程和软件开发规划反映了你对使用Scrum技术的决定。根据我的经验，Scrum团队会非常规律地进行开发活动，并完成最有效的开发工程。输出的组件可以作为组织内其它项目的输入文档。

概括来说，RUP通过引入结构化并已经证实的进程框架满足了组织上的需求，而且Scrum模式可以为项目加入更多动态特性。比如说，可以很容易地向你当前的或未来的RUP项目中加入Scrum管理模式。至于软件工程的社会效应方面，Scrum已被证实的过程模式可以即时地方便需求管理，变化控制以及项目管理提供。在RUP组件对开发过程和项目文档的指导下，Scrum团队成员，特别是新手或是经验不足者，可以避免陷入软件开发的陷阱。

参考

您可以参阅本文在 developerWorks 全球站点上的 英文原文。

Agile Alliance (2004) http://www.agilealliance.org/

Ken Schwaber 和 Mike Beedle, Agile Software Development with SCRUM Prentice Hall, 2002.

Scrum (2004). See http://www.controlchaos.com/ The diagram at http://www.controlchaos.com/about/ 的图表可以帮助你更直观的理解Scrum的项目迭代过程。

注意
¹ 参看Scrum的网页 http://www.controlchaos.com/
² 依据Merriam-Webster's Collegiate Dictionary, 11th Edition, Merriam-Webster, 2003。