级别： 初级 Per Kroll, 方法经理，IBM Rational, IBM
2007 年 11 月 15 日 
本文探究了 OpenUP 这一新近开发的软件开发过程架构，它将重点放在源自 Rational 统一过程的敏捷实践。作者使用注释条向 RUP-savvy 的读者解释 OpenUP。
来自 The Rational Edge。
作者注：本文谨献给 Brian Lyons（EPF 项目中 OpenUP 的领导者之一，Number Six Software 的共同创办者、CEO 和 CTO）。他在劳动节那天不幸死于一场摩托车事故。更多的信息请参见 http://www.eclipse.org/epf/general/blyons_tribute.php
两三年前，几个同事
1
和我一起开始思考如何创建一个精简版本的 IBM® Rational Unified Process®（RUP®），
2
或如何以一种敏捷的方式来使用 RUP，同时加入来自其他敏捷过程，例如 Scrum
3
和 XP 中好的东西。。
4
我们在 IBM 内部启动这项工作，但很快我们认识到需要从更广泛的人员那里汲取见识和经验。
这项工作是在 Eclipse Process Framework（EPF）
5
项目下为 Eclipse 设计的。我们同来自 12 个公司的近 20 名专家一起共同进行开发。我们其中的一些人完成了 RUP 的敏捷实现，其他一些人完成了 Dynamic System Development Method（DSDM）
6
或者创建了 Agile Model Driven Development（AMDD）；
7
其他人实践 Scrum，
8
并且某些是 Eclipse Way 背后的关键人物。我们注意到，许多协同工作由于一小组关于如何开发软件所普遍发生的概念，往往表现得各不相同。我们并不是从零开始创建一个新方法，而是尽力综合许多人和许多方法的成果。
上个月，我们终于发布了 OpenUP 1.0。
9
当然，现在的 OpenUP 还不是最终的产品，而仅仅是迈向期待中的 OpenUP 的第一步。OpenUP 将随着我们更多的了解什么工作、什么不工作而不断的发展和完善。同时，我们邀请所有人通过 EPF 项目来共同开发 OpenUP。
 |
精益（Lean）：从精益制造的概念受到启发，我们同样强调高质量的结果、消除浪费、处理变化和关注客户的价值。
敏捷哲学（Agile philosophy）：OpenUP 遵从 Manifesto for Agile Software Development 的原则，请参见 www.agilemanifesto.org。
扩展的（Extended）：IBM 是我所期望的计划提供延伸扩展的众多组织之一。我们目前正努力重构 RUP 使其为 OpenUP 建立一套扩展。这将意味着您能够以一个小型的、开源程序作为开始，然后根据需要添加内容，从而创造出多种多样的 RUP 和其他方法。
微增量（Micro-increments）：XP 谈论蹒跚学步。Scrum 通过其迭代积压发展着类似的方式。
|
|
在此，我将展示 OpenUP 的精华。我将本文的原始版本献给 EPF，并得到 EPF 项目中许多成员的发展和改进。我尤其想对来自 Number Six Software 的 Brian Lyons, Nate Oster 和 Liz Carroll 所做出的贡献表示感谢。我的评论和注释以注释条的形式出现，表明了我的观点，并且特别针对那些已经对 RUP 产生兴趣的读者提供注释。
什么是 OpenUP ？
OpenUP 是一个精益的统一过程，它在结构化的生命周期中采用迭代和增加的方法。OpenUP 强调注重实效的、敏捷哲学，将关注重点放在软件开发的协作本性上面。它是一种不约束工具和拘泥于仪式的开发过程，可以被扩展到非常广泛的项目类型之中。
个人对于 OpenUP 项目的贡献被组织在微增量之中，如图 1 所示。这些表现了短期的工作单元可以产生出项目进展过程中稳定、可测量的步调（典型的是以小时数或者天数作为衡量标准）。该过程采用了加强型的协作，伴随着该系统被忠实而自组织的团队增量式的进行开发。这些微增量提供了极其短的反馈回路，使得在每一个迭代过程中都能够做出适当的决定。
图 1: OpenUP 层结构：微增量、迭代周期和项目周期
|
迭代（Iterations）：所有敏捷的过程都是迭代的。
自组织（Self-organize）：自组织结构是 Scrum 的关键部分。
迭代生命周期（Iteration lifecycle）：迭代周期来自 Eclipse Way。
项目生命周期（Project lifecycle）：许多管理者现在都在抱怨对于许多敏捷的项目，他们都没有打理好。我们认为，明确的管理里程碑是解决这一问题的关键。
|
|
OpenUP 将项目划分为迭代：有计划的、有时限的迭代操作，通常以周为单位。迭代使团队注重以一种可预见的方式向涉众发送增长式的价值。迭代计划定义了在迭代期间应当完成哪些工作，其结果是一个可以演示的构造。OpenUP 团队将自组织如何实现迭代目标以及提交结果。团队定义和“牵引”工作条目列表中的任务。OpenuP 采用迭代生命周期（组织微增量是如何被应用的）来得到一个稳定的、复合系统需要的构造，从而逐步的向迭代的目标前进。
OpenUP 将项目生命周期分为四个阶段：启始、精化、构建和产品化。项目生命周期为涉众和团队成员提供可见度和决策点。这将更有效的进行管理，并且允许您在适当的时间做出是否继续的决定。项目计划定义了生命周期，我们得到的最终结果是一个发布的应用程序。
迭代生命周期
OpenUP 中的迭代使得团队通过提交完全测试的演示版本或者可改进的构造（产品增量），持续注重提供给客户增长的价值。这为创建了一个健康的关注涉众价值的方式，确保所做的工作都将他们的目标向前推进。决定的做出必须快速，我们没有时间进行无休止的争论。迭代开发关注生产工作代码、减少分析瘫痪的风险。经常性的展示工作代码提供反馈机制，从而允许根据需要进行必要的修正。
|
产品增量（Product increment）：不幸的是，太少有 RUP 客户能够在其迭代的最后阶段生产出完全测试好的产品，所以我们希望使其变得更加明确和清楚。
工作项（Work items）：按照一件事来区分优先次序会使得生活更加简便，而不应对于不同类型的需求、缺陷和改进要求等使用不同的优先次序区分方式。
敏捷估算（Agile estimation）：敏捷的团队较之其他团队进行更多的估算工作。许多不够敏捷的人并没有认识到这一点。敏捷地开发是有着严格纪律的。
稳定的构建（Stable builds）：避免了一个常见的问题，那就是开发团队在迭代的最后阶段并没有生产出任何高质量的产品。测试驱动开发使得这一工作变得相对简单，当然往往仍然会不够充分。
|
|
迭代计划、估算、和进展跟踪都以工作项为中心。迭代计划是通过选择顶部优先的工作条目被创建的。敏捷估算技术被用来理解有多少工作条目能够安全的适应规定时间的迭代，以及多少工作条目被筛选出来以确保团队提出的迭代目标可以被涉众接受。进展状况可以通过不断完成的许多小的工作条目被呈现出来。
正如项目经过一个生命周期一样，迭代经过一个生命周期时团队所关注的重点取决于是处于迭代的第一个还是最后一个星期。（请参见图2
10
）。迭代也起步于时长为几个小时的迭代计划会议。最初的一两天关注进一步的计划和体系结构从而理解工作条目的依赖关系和逻辑顺序，以及体系结构的效果。迭代中的大多数时间用于执行微增量。每一个微增量都应该用测试过的代码来建造并且验证工具。附加的原则是，在每周末生产出稳定的构建。更多的注意力集中在确保该构造的质量以及问题的尽早处理，从而保证迭代的成功。迭代的最后一周或最后几天较之前几周将更加强调完善和修补漏洞，即使有新的功能添加进来也是如此。我们的目标就是永远保证质量不出现问题，从而确保在迭代结束时生产出一个高质量的可用的产品增量。在同涉众一起对成果进行评估后此次迭代方告结束，并且我们通过回顾能够懂得如何在下一个迭代中对过程进行改进。
图 2: 每个迭代在经历一个生命周期时，早期更加关注计划和体系结构，后期更加关注修补漏洞和稳定性。
|
团队成员（Team members）：对比丰田是如何对汽车制造进行革命性的改进，使得团队成为如何建造汽车的中心。团队建造汽车，并且分享最终成果的所有权。每一名团队成员都被要求帮助改进工作完成的方式。
自组织系统（Self-organization）：自组织系统和迭代生命周期是今天尚未被 RUP 解决的两个实践。如果您想在一个敏捷的方式中采纳 RUP，那么您应当考虑将这两种实践添加到许多迭代 RUP 实践中。
|
|
如果团队成员能够自己决定做什么和如何去做，而不是仅仅被告知要做什么，那么他们会更加有效的开展工作。为了激励团队成员发挥出最高水平，请给予团队组织工作的能力和责任，让他们决定如何最好的完成他们的承诺。这同样有助于他们的协作，从而确保将正确的技巧应用于适当的任务。自组织系统涉及许多领域，包括如何制定计划和承诺（由团队而非个人做出），如何指派工作（团队成员做出而非被指派），以及团队成员如何看待其在项目中的角色（团队成员第一，工作功能其次）。
自组织需要完成一些工作：
- 透明度和承诺对于促进团队沟通和选出最棒的团队成员非常重要。启动关于与迭代生命周期相关的团队承诺以及与微增量相关的个人承诺的沟通，能确保及时发现执行中出现的问题，并安排合适的人员去解决它们。
- 训练对于团队团队的自组织和清除通向成功的障碍来说是必要的。假定项目经理就是教练。项目经理应该避免采用“命令-控制”的管理方式。这是过去二十年中管理书籍所一直给出的关键建议，但是某些项目经理仍没有据此做出改变。
微增量
|
短反馈环路（Short feedback loop）：敏捷来发的目标之一就是缩短反馈环路。我经常发现有些团队成员工作了数周，却从不适当的分享彼此都做了什么，从而导致了低效率。Scrum 通过 Daily Scrums 处理这一问题。OpenUP 则既允许您用哪种方式处理，也允许您利用通常的基础构造来管理工作条目。
开发解决方案增量（Develop solution increment）：理想情况下，在您开发解决方案增量时使用 Test-Driven Development。
|
|
个人对于 OpenUP 项目的贡献被组织在微增量中。微增量展示了几个小时至几天内，一个或者几个人为达到迭代目标而协作所取得的成果。微增量的概念有助于个体的团队成员将他们的工作划分为小的单元，从而向团队提供出一些可测量的价值。微增量提供了一个非常的短反馈回路 ，从而在每个迭代中驱动适当的决定。
微增量应该被良好的定义，并且您应当跟踪每一个微增量的日常进展。微增量依照工作条目指定和跟踪。变化集将物理成果表现为文件的形式，这些文件作为完成工作条目的一部分被修改。下面，我们来看一些示例微增量：
-
找出涉众。 定义 Vision 是一项可能持续数周的任务，所以请确保您每天都取得进展、并将任务划分为小型的和良好定义的微增量。描述并且将涉众的要求放进 Vision 的文档中会收到很好的效果，这只需要几个小时或者最多几天，但是会展现一个合适的微增量。
-
开发解决方案增量。
定义、设计、执行、和测试用例或者事件需要数周甚至更长的时间。为了确保持续的进展，您应该将工作划分为许多小的增量，每一个增量可以在两三天内完成。一个更合适的微增量也许只在一个场景下定义、设计、执行、和测试一个用例或者步骤的一个子流程。
-
赞同技术方法的持续性。 赞同和接受您的技术解决方案也许会花费一些时间，所以您需要将任务细分为可以在一个短时间内定义和同意的。一种划分的方法就是依照您需要解决的问题，比如持续或者报告。这一微增量可能涉及定义需求、测量可用的资产、原型、和记录决定。
-
计划迭代。 这一微增量可以包括为创建迭代计划设置一个汇合点，为这个汇合点做某些准备（比如回顾候选的工作条目），带领团队通过迭代计划汇合点，以及是迭代计划易于访问。最终的结果是一些事完成和可测量，从团队得到一个被布置的计划。
您的应用程序通过模拟许多工作条目的执行来演进微增量。通过每日团队会议和团队协作工具，公开的分享微增量方面的进展，您可以对其他人的工作有更为清楚和深入的了解，从而更有效的开展团队工作。同时，您也通过演进您的应用程序的一个微增量证明了持续的进展。
|
微递增（Micro increments）：也许这是一个今后增强 OpenUP 的机会。
对应关系（Map）：太多的人以太过书面的方式处理过程问题。应该依靠共有的感官，将这些过程用于学习和启发。
|
|
OpenUP 提供一整套活动。每一个活动包括一套任务、任务中的步骤、和指导。即使微增量没有在过程中明确的构造，您还是能找到如何执行一套相关的微增量的详细描述，这套微增量通常可以在该活动的项目中被找到。OpenUP 并不提供潜在微增量的完整的描述，每一个组织应当为常见的微增量添加自己的“处方”。
OpenUP 提供了一个强大的学习工具，并且当您想要执行不同的任务时可以很容易的通过查阅概要来找到相关的指导。这可以通过过程的可视化来完成，该过程在项目生命周期的上下文环境中为任务提供了一个基于时间的组织方式。举个例子，您想尽早的同意项目的技术方法。这并不意味着您不能在项目的后期做出技术决定。过程就像是地图：将其作为理解全局的参考，但是当实际情况与地图并不一致时，就要相信实际情况。
项目生命周期
|
涉众（Stakeholders）：是一个广义的概念。它包括执行者和其他决定策略方向的人。项目生命周期应当为他们提供特定的决定点，使得他们能够对项目如何继续作出判断。
阶段（Phases）：这些阶段取自 RUP，并且回过来作为 Barry Boehm 介绍到其螺旋模型中的里程碑。
|
|
项目生命周期向涉众提供了监督、透明和指导机制，从而控制项目资金、范围、风险、价值以及该过程的其他方面。
每一次迭代都提供一个微增量，这使得涉众有机会更好的理解产生了哪些价值以及项目进展的如何。它同样使得开发团队有机会作出适当的改变以实现最优化的结果。
OpenUP 将迭代组织为一套 阶段。每一个阶段完成后都到达一个里程碑，该里程碑的目标是提出并解决一系列对于涉众来说典型的至关重要的问题：
-
启始。我们是否赞同项目的范围和目标，该项目是否应该进行？
-
精化。我们是否赞同开发该应用程序将要使用的执行架构，我们是否发现距离价值的实现还很远，以及存在的风险可以被接受？
-
构建。我们是否发现我们有一个已经十分接近发布的应用程序，我们应当将团队首要的关注点转移到调试、完善和确保其成功展开？
-
产品化。该应用程序可以发布了么？
| |
取消（Cancelled）：所有敏捷的过程都在每一个迭代的最后阶段提供某种程度的可见性。在 IBM 里，我们在每一个项目里程碑出做出明确的决定，每一项市场、服务、销售、部署、财政、法律的等等都进行表决。
|
|
如果在阶段回顾中，对以上问题的回答是肯定的，那么项目就继续。如果回答是否定的，那么该阶段就被推迟（通常添加一个额外的迭代），直到得到一个满意的结果，或者涉众决定取消该计划。
项目生命周期的目标之一就是关注两个关键的利息相关者驱动：风险减少和价值创造。OpenUP 阶段使团队关注风险减少相关的问题（这些问题将在该阶段的最后被回答），同时跟踪价值创造，如图3所示。
图 3: 项目生命周期期间的风险降低（红色曲线）和价值创造（绿色曲线）
|
风险（Risk）：我的观点是，大多数敏捷的过程并没有给予风险的降低以足够的重视，至少是没有对其充分的明确。我们中的大多数人需要做出合理的预计，从而允许更广泛的组织能够有效的进行操作。预计总会有某种程度的不准确，但是其价值就在于更早的而不是更晚的使其精确。
OpenUP：在本阶段，OpenUP 家族拥有两个成员。一个是基本的 OpenUP 过程，另一个是具有某些来自 DSDM 的扩展的基本的 OpenUP 过程，也被称作 OpenUP/DSDM。许多组织正在计划进行其他的扩展。
|
|
风险是指项目中发生的预期之外的事情，以及价值创造道路上的风险。风险的大小与估算的不确定性成正比。涉众希望尽早知道在规定的时间内项目可以取得多少价值。在多数情况下，您通过执行和测试最关键的性能来减少风险同时创造价值。然而，有些情况下风险减少和价值创造并不平均。我们来看一个例子。在精化阶段的最后，您希望尽可能的降低技术风险，并且提供一个稳定的体系结构。团队需要展示他们拥有一个可以执行的体系结构，在某些选定的情境下是可以被执行的，并且列出一份风险清单指明许多关键的技术性风险的缓解。这一风险减少需要同运行代码的价值相权衡。在一个项目中正确的权衡并不能代表在下一个项目中也是如此。
OpenUP —— 受到 Scrum、Eclipse Way、XP 和 RUP 影响
OpenUP 过程产品家族的目标定位于具有一套共同特点的各种各样的项目类型。以下是 OpenUP 的关键原则：
- 协作，从而协调利益和分享理解。
- 发展，从而不断获得反馈和提高。
- 尽早的关注体系结构，从而最小化风险，组织好开发。
- 平衡优先级，从而涉众的使利益最大化。
| |
类型（Types）：正如介绍中所提到的，IBM 计划提供一套扩展，以真正构成一个 RUP 的未来版本。
|
|
OpenUP 产品家族中的过程是作为扩展被写入核心的 OpenUP 过程的，它信奉实用和敏捷的哲学，关注软件开发所具有的协作的本性。这一核心的 OpenUP 过程是一种不限制工具和拘泥于仪式的过程，并且能够被扩展到各种各样的项目类型。
通过添加过程插件程序，可以在许多不同类型的开发中创建 OpenUP 的扩展，比如面向服务的体系结构（SOA），地理分布式，模型驱动的体系结构，以及嵌入式系统。可以添加工具和技术细节的指导，比如 Java 2 Enterprise Edition（J2EE）和多种开发工具的指导。某些扩展是十分适度的，比如仅仅向现存的任务添加技术细节的指导。然而另外一些扩展则非常全面，它们创建那些使用新的或者经过改动的工具、任务和角色从根本上扩展范围的过程。
如上所述，为了成为 OpenUP 家族的一员，扩展的方法必须遵循 OpenUP 的关键原则，并且作为扩展被写入 OpenUP 的核心过程。
扩展 OpenUP 能够：
注释
1 OpenUP，Basic Unified Process 的先驱，主要由 Bruce MacIsaac, Ricardo Balduino 和 Per Kroll 开发。
2
http://www.ibm.com/software/awdtools/rup/
3
http://www.scrumalliance.org/
4 Beck，K., Andres，C. Extreme Programming Explained: Embrace Change，第 2 版，Addison Wesley，2005 年。
5
http://www.eclipse.org/epf/
6 DSDM Consortium，DSDM。请参见 http://www.dsdm.org/products/
7 Ambler，S.W. The Object Primer 3rd Edition: Agile Model Driven Development with UML 2。Addison Wesley， 2006年。
8
The Eclipse Way 在若干个地方通过 JAZZ 项目可以得到：
http://www.jazz.net
9
http://www.eclipse.org/epf/downloads/openup/openup_downloads.php
10 请参见 http://Jazz.net 获取 Eclipse Way。
参考资料 学习
讨论
关于作者 | 
| | Per Kroll 是 RUP 及 IBM Rational Method Composer 的开发经理，并且是 Eclipse Process Framework Project（以软件实践为中心的开源项目）的项目领导。他负责 IBM Rational 过程领域的策略。Per 在供应链管理、电信、通信和软件产品开发方面有二十年的软件开发经验。他是书籍 Rational Unified Process Made Easy -- A Practitioner's Guide，Kroll 和 Kruchten，以及 Agility and Discipline Made Easy -- Practices from OpenUP and RUP，Kroll 和 MacIsaac 的作者。Per 在许多会议上演讲，并且写过许多关于软件工程的文章。 |
对本文的评价
| 
