Rational Edge: OpenUP 精华OpenUP In a Nutshell

2011-05-25 作者：方法经理来源：IBM

两三年前，几个同事 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。

在此，我将展示 OpenUP 的精华。我将本文的原始版本献给 EPF，并得到 EPF 项目中许多成员的发展和改进。我尤其想对来自 Number Six Software 的 Brian Lyons, Nate Oster 和 Liz Carroll 所做出的贡献表示感谢。我的评论和注释以注释条的形式出现，表明了我的观点，并且特别针对那些已经对 RUP 产生兴趣的读者提供注释。

什么是 OpenUP ？

OpenUP 是一个精益的统一过程，它在结构化的生命周期中采用迭代和增加的方法。OpenUP 强调注重实效的、敏捷哲学，将关注重点放在软件开发的协作本性上面。它是一种不约束工具和拘泥于仪式的开发过程，可以被扩展到非常广泛的项目类型之中。

个人对于 OpenUP 项目的贡献被组织在微增量之中，如图 1 所示。这些表现了短期的工作单元可以产生出项目进展过程中稳定、可测量的步调（典型的是以小时数或者天数作为衡量标准）。该过程采用了加强型的协作，伴随着该系统被忠实而自组织的团队增量式的进行开发。这些微增量提供了极其短的反馈回路，使得在每一个迭代过程中都能够做出适当的决定。

什么是 OpenUP ？

图 1: OpenUP 层结构：微增量、迭代周期和项目周期

OpenUP 将项目划分为迭代：有计划的、有时限的迭代操作，通常以周为单位。迭代使团队注重以一种可预见的方式向涉众发送增长式的价值。迭代计划定义了在迭代期间应当完成哪些工作，其结果是一个可以演示的构造。OpenUP 团队将自组织如何实现迭代目标以及提交结果。团队定义和“牵引”工作条目列表中的任务。OpenuP 采用迭代生命周期（组织微增量是如何被应用的）来得到一个稳定的、复合系统需要的构造，从而逐步的向迭代的目标前进。

OpenUP 将项目生命周期分为四个阶段：启始、精化、构建和产品化。项目生命周期为涉众和团队成员提供可见度和决策点。这将更有效的进行管理，并且允许您在适当的时间做出是否继续的决定。项目计划定义了生命周期，我们得到的最终结果是一个发布的应用程序。

迭代生命周期

OpenUP 中的迭代使得团队通过提交完全测试的演示版本或者可改进的构造（产品增量），持续注重提供给客户增长的价值。这为创建了一个健康的关注涉众价值的方式，确保所做的工作都将他们的目标向前推进。决定的做出必须快速，我们没有时间进行无休止的争论。迭代开发关注生产工作代码、减少分析瘫痪的风险。经常性的展示工作代码提供反馈机制，从而允许根据需要进行必要的修正。

迭代计划、估算、和进展跟踪都以工作项为中心。迭代计划是通过选择顶部优先的工作条目被创建的。敏捷估算技术被用来理解有多少工作条目能够安全的适应规定时间的迭代，以及多少工作条目被筛选出来以确保团队提出的迭代目标可以被涉众接受。进展状况可以通过不断完成的许多小的工作条目被呈现出来。

正如项目经过一个生命周期一样，迭代经过一个生命周期时团队所关注的重点取决于是处于迭代的第一个还是最后一个星期。（请参见图2 10 ）。迭代也起步于时长为几个小时的迭代计划会议。最初的一两天关注进一步的计划和体系结构从而理解工作条目的依赖关系和逻辑顺序，以及体系结构的效果。迭代中的大多数时间用于执行微增量。每一个微增量都应该用测试过的代码来建造并且验证工具。附加的原则是，在每周末生产出稳定的构建。更多的注意力集中在确保该构造的质量以及问题的尽早处理，从而保证迭代的成功。迭代的最后一周或最后几天较之前几周将更加强调完善和修补漏洞，即使有新的功能添加进来也是如此。我们的目标就是永远保证质量不出现问题，从而确保在迭代结束时生产出一个高质量的可用的产品增量。在同涉众一起对成果进行评估后此次迭代方告结束，并且我们通过回顾能够懂得如何在下一个迭代中对过程进行改进。

图 2: 每个迭代在经历一个生命周期时，早期更加关注计划和体系结构，后期更加关注修补漏洞和稳定性。

如果团队成员能够自己决定做什么和如何去做，而不是仅仅被告知要做什么，那么他们会更加有效的开展工作。为了激励团队成员发挥出最高水平，请给予团队组织工作的能力和责任，让他们决定如何最好的完成他们的承诺。这同样有助于他们的协作，从而确保将正确的技巧应用于适当的任务。自组织系统涉及许多领域，包括如何制定计划和承诺（由团队而非个人做出），如何指派工作（团队成员做出而非被指派），以及团队成员如何看待其在项目中的角色（团队成员第一，工作功能其次）。

自组织需要完成一些工作：

透明度和承诺对于促进团队沟通和选出最棒的团队成员非常重要。启动关于与迭代生命周期相关的团队承诺以及与微增量相关的个人承诺的沟通，能确保及时发现执行中出现的问题，并安排合适的人员去解决它们。

训练对于团队团队的自组织和清除通向成功的障碍来说是必要的。假定项目经理就是教练。项目经理应该避免采用“命令-控制”的管理方式。这是过去二十年中管理书籍所一直给出的关键建议，但是某些项目经理仍没有据此做出改变。

微增量

个人对于 OpenUP 项目的贡献被组织在微增量中。微增量展示了几个小时至几天内，一个或者几个人为达到迭代目标而协作所取得的成果。微增量的概念有助于个体的团队成员将他们的工作划分为小的单元，从而向团队提供出一些可测量的价值。微增量提供了一个非常的短反馈回路，从而在每个迭代中驱动适当的决定。
微增量应该被良好的定义，并且您应当跟踪每一个微增量的日常进展。微增量依照工作条目指定和跟踪。变化集将物理成果表现为文件的形式，这些文件作为完成工作条目的一部分被修改。下面，我们来看一些示例微增量：
找出涉众。定义 Vision 是一项可能持续数周的任务，所以请确保您每天都取得进展、并将任务划分为小型的和良好定义的微增量。描述并且将涉众的要求放进 Vision 的文档中会收到很好的效果，这只需要几个小时或者最多几天，但是会展现一个合适的微增量。
开发解决方案增量。定义、设计、执行、和测试用例或者事件需要数周甚至更长的时间。为了确保持续的进展，您应该将工作划分为许多小的增量，每一个增量可以在两三天内完成。一个更合适的微增量也许只在一个场景下定义、设计、执行、和测试一个用例或者步骤的一个子流程。
赞同技术方法的持续性。赞同和接受您的技术解决方案也许会花费一些时间，所以您需要将任务细分为可以在一个短时间内定义和同意的。一种划分的方法就是依照您需要解决的问题，比如持续或者报告。这一微增量可能涉及定义需求、测量可用的资产、原型、和记录决定。
计划迭代。这一微增量可以包括为创建迭代计划设置一个汇合点，为这个汇合点做某些准备（比如回顾候选的工作条目），带领团队通过迭代计划汇合点，以及是迭代计划易于访问。最终的结果是一些事完成和可测量，从团队得到一个被布置的计划。
您的应用程序通过模拟许多工作条目的执行来演进微增量。通过每日团队会议和团队协作工具，公开的分享微增量方面的进展，您可以对其他人的工作有更为清楚和深入的了解，从而更有效的开展团队工作。同时，您也通过演进您的应用程序的一个微增量证明了持续的进展。
OpenUP 提供一整套活动。每一个活动包括一套任务、任务中的步骤、和指导。即使微增量没有在过程中明确的构造，您还是能找到如何执行一套相关的微增量的详细描述，这套微增量通常可以在该活动的项目中被找到。OpenUP 并不提供潜在微增量的完整的描述，每一个组织应当为常见的微增量添加自己的“处方”。
OpenUP 提供了一个强大的学习工具，并且当您想要执行不同的任务时可以很容易的通过查阅概要来找到相关的指导。这可以通过过程的可视化来完成，该过程在项目生命周期的上下文环境中为任务提供了一个基于时间的组织方式。举个例子，您想尽早的同意项目的技术方法。这并不意味着您不能在项目的后期做出技术决定。过程就像是地图：将其作为理解全局的参考，但是当实际情况与地图并不一致时，就要相信实际情况。

项目生命周期

项目生命周期向涉众提供了监督、透明和指导机制，从而控制项目资金、范围、风险、价值以及该过程的其他方面。

每一次迭代都提供一个微增量，这使得涉众有机会更好的理解产生了哪些价值以及项目进展的如何。它同样使得开发团队有机会作出适当的改变以实现最优化的结果。

OpenUP 将迭代组织为一套阶段。每一个阶段完成后都到达一个里程碑，该里程碑的目标是提出并解决一系列对于涉众来说典型的至关重要的问题：

启始。我们是否赞同项目的范围和目标，该项目是否应该进行？
精化。我们是否赞同开发该应用程序将要使用的执行架构，我们是否发现距离价值的实现还很远，以及存在的风险可以被接受？
构建。我们是否发现我们有一个已经十分接近发布的应用程序，我们应当将团队首要的关注点转移到调试、完善和确保其成功展开？
产品化。该应用程序可以发布了么？

如果在阶段回顾中，对以上问题的回答是肯定的，那么项目就继续。如果回答是否定的，那么该阶段就被推迟（通常添加一个额外的迭代），直到得到一个满意的结果，或者涉众决定取消该计划。

项目生命周期的目标之一就是关注两个关键的利息相关者驱动：风险减少和价值创造。OpenUP 阶段使团队关注风险减少相关的问题（这些问题将在该阶段的最后被回答），同时跟踪价值创造，如图3所示。

图 3: 项目生命周期期间的风险降低（红色曲线）和价值创造（绿色曲线）

风险是指项目中发生的预期之外的事情，以及价值创造道路上的风险。风险的大小与估算的不确定性成正比。涉众希望尽早知道在规定的时间内项目可以取得多少价值。在多数情况下，您通过执行和测试最关键的性能来减少风险同时创造价值。然而，有些情况下风险减少和价值创造并不平均。我们来看一个例子。在精化阶段的最后，您希望尽可能的降低技术风险，并且提供一个稳定的体系结构。团队需要展示他们拥有一个可以执行的体系结构，在某些选定的情境下是可以被执行的，并且列出一份风险清单指明许多关键的技术性风险的缓解。这一风险减少需要同运行代码的价值相权衡。在一个项目中正确的权衡并不能代表在下一个项目中也是如此。

OpenUP —— 受到 Scrum、Eclipse Way、XP 和 RUP 影响

OpenUP 过程产品家族的目标定位于具有一套共同特点的各种各样的项目类型。以下是 OpenUP 的关键原则：

协作，从而协调利益和分享理解。
发展，从而不断获得反馈和提高。
尽早的关注体系结构，从而最小化风险，组织好开发。
平衡优先级，从而涉众的使利益最大化。

OpenUP 产品家族中的过程是作为扩展被写入核心的 OpenUP 过程的，它信奉实用和敏捷的哲学，关注软件开发所具有的协作的本性。这一核心的 OpenUP 过程是一种不限制工具和拘泥于仪式的过程，并且能够被扩展到各种各样的项目类型。

通过添加过程插件程序，可以在许多不同类型的开发中创建 OpenUP 的扩展，比如面向服务的体系结构（SOA），地理分布式，模型驱动的体系结构，以及嵌入式系统。可以添加工具和技术细节的指导，比如 Java 2 Enterprise Edition（J2EE）和多种开发工具的指导。某些扩展是十分适度的，比如仅仅向现存的任务添加技术细节的指导。然而另外一些扩展则非常全面，它们创建那些使用新的或者经过改动的工具、任务和角色从根本上扩展范围的过程。

如上所述，为了成为 OpenUP 家族的一员，扩展的方法必须遵循 OpenUP 的关键原则，并且作为扩展被写入 OpenUP 的核心过程。
扩展 OpenUP 能够：