级别： 初级
Vitalie Temnenco, 架构师, Sierra Systems
2008 年 5 月 15 日
阅读 IBM Rational 统一过程（Rational Unified Process, RUP）如何补充项目管理知识体系（Project Management Body of Knowledge，PMBOK），以及精通 PMBOK 的项目经理如何理解并使用 RUP 来支持其项目经理（Project Manager，PM）的角色。
来自 The Rational Edge.
为 了寻找答案，项目经理（project managers，PMs）一般会从架构师找到开发人员，从开发人员找到测试人员等等。由于经常得到项目管理专业人员（Project Management Professional，PMP）认证的授权，PM 发现他们逐渐依赖于具体领域的专家经验了。他们经常发现 IBM® Rational® Unified Process®，或 RUP®，是实现团队所选择的框架，因此他们必须根据 RUP 规程调整并重新思考他们所了解的东西。
本 文讨论了现代 IT 驱动的企业中的项目管理。本文探究了关于 RUP 作为项目管理工具的普遍误解，讨论项目管理知识体系（Project Management Body of Knowledge，PMBOK）标准如何与 RUP 交叉，并且阐述了减少或消除当把两个互补的过程框架联系起来时经常误以为存在的歧义的方式。最后，本文假定并探究企业 PM 角色的潜在价值。
根据我作为企业架构师的经验，本文还包含了一些项目管理的架构上的观点。IT 架构师为了了解项目经理的预期可以阅读本文，而 PM 可以阅读本文，从而了解更多关于 RUP 和 IT 架构的内容。
按 照流行的互联网百科全书上说的，项目是“创建带来有益的变化或增加的价值的独立产品或服务的临时且一次性的工作”。每个项目都需要资源 —— 包括人和资金 —— 并且项目管理（project management，PM）是试图用将产品或服务在分配给项目的范围、质量、时间，和成本界限内进行划分的方式组织和管理资源的规程。
虽 然项目管理风格常常粗略地对应正在应用的软件开发生命周期（Software Development Life Cycle，SDLC）方法规格，例如瀑布、迭代、快速应用程序开发（Rapid Application Development，RAD），或敏捷开发，但是每个项目都涉及一组公共的活动，包括：
- 计划、分析和设计目标
- 评估和控制风险
- 估算和分配资源
- 获得人力和物力资源
- 通过分配任务和指导活动来组织工作
- 根据所获得的价值分析结果
- 预测项目
- 管理质量
- 问题预防和解决
- 项目结束
- 项目沟通
- 追踪和报告进展
项 目管理协会（Project Management Institute，PMI）建立于二十世纪六十年代末，并且是项目管理领域中的世界领导组织。它的成员总数超过 220,000，包括超过 170 个国家中的 160,000 认证的成员。PMI 开发了最全面的 PM 框架之一（PMP），并且提供了许多等级的项目管理认证。
依据认证个人的数量来说，PMP 是世界最广泛认可的 PM 认证计划。它提供三个等级，包括 PM 助理、项目经理和规划 1 管理中的认证。
PMBOK 是被普遍接受为项目管理中最佳实践的标准的过程和知识资产的集合。它包含在大部分项目及在大多数商业领域（从建筑到软件工程）中复用的五个过程组（举例来 说，初始和计划）和九个知识领域（举例来说，范围管理和时间管理）。在 PMBOK 中，过程是根据输入工件、工具和技术来描述的。技术消耗并且生产工件，同时也使用工具。
在各种各样的管理角色中，只有一个拥有“项目” 修饰词。在当今的动态商业环境中，它已经远离了，因为它需要了解项目实体的独特性质，以及应用领域的管理规程的知识，这在软件开发的情况下是“迭代的”、“架构驱动的”和“减少风险的” 。
与 “项目”作为临时且一次性的工作的定义相对比，许多组织任务是重复的，每次重复都有相同的基本范围（不要将其与迭代的实现相混淆，迭代实现的任务重复但生 成不同的范围或细节）。一些实例是人力资源和库存管理功能，其中管理活动相当于确保充分地、每天地，及按部就班地执行任务。担任后一个角色的人可能担当各 种管理职位，并且执行各种标准的管理活动。
不 像其他的组织管理角色那样，明确规定 PM 角色是治理独立的任务的。因此，为了准时且在其他确定出的约束条件内交付产品或服务，PM 必须能够了解任务的范围并选择及应用最佳的管理过程。与需求结合来开始并结束项目对 PM 的工作是非常必要的，并且还令其区别于其他的企业管理角色。
项 目常常是在根本没有专门的 PM 的情况下开始的。极其普遍的情况是经验丰富的团队成员承担所有或一部分 PM 的职责。一般来说，虽然有某个临时或兼职管理项目的人比没有项目管理要好，但是长时间采用代理项目经理是很糟的实践，因为这令决策制定的连续性和一致性处 于危险中。此外，这个临时的 PM 角色常常是由缺乏重要的领域经验或者缺乏承担额外职责的动机的团队成员担当，这会导致未达到的预期，或令项目完全失败的最坏情况。
PM 担当解决方案架构师或技术领导角色是很常见的。虽然这常常是糟糕的实践，但是对较小的项目团队（通常少于十个成员）有效。团队中拥有技术项目经理的好处之 一是，在彻底了解了需求和/或设计的基础上，她可能能够生成可靠的项目计划。反过来，这可以帮助消除实现团队中的“沟通不畅”综合症。问题是她可能没有足 够的时间致力于项目计划，更不用说提供有效的项目覆盖和控制。
一 些项目采取超出它们管理能力的方式。典型的情况是引入分层的项目管理结构，包含顶层的“规划”和下面的项目。计划管理是非常特殊类型的项目管理，它整体地 处理项目，同时了解项目的个别表现。计划经理的主要职责包括将范围“分割为”可管理的块（项目），编制并管理它们的相关性，并且计划并进行扩大和委托。
现 代的组织是十分复杂的实体，其中在不设置为项目的情况下就可以常规地完成事情。一个实例是企业架构实现及其各种步骤，例如，远景开发、商业案例开发，和商 业过程分析。这些功能可能十分复杂，因而，如果没有以及时的方式将它们包含于固定的边界内就很难管理。主题专家，例如 IT 架构师、过程工程师，和顾问很少拥有执行正式的企业 PM 活动所需的技能。所有这些都规定需要企业项目经理（Enterprise Project Manager）角色，我将在下面详细阐述。
虽然一些 PM 好像比其他人更理性、见多识广、可信赖，或有经验，但是所有 PM 都对项目有相同的关注。最大的担心如下所介绍。
当 PM 接到的估算允许 20%、50%，或甚至 100% 的错误差数时，他们会对架构师感到失望。的确，许多行业已经达到了一个状态，在这种状态中，可能只根据标准术语、高层范围，和行业生产力量化、估算，并计 划项目 —— 而 PM 可能非常期望在软件开发中也一样。然而，这可能对 IT 期望太多了，从框架和平台到方法和工具中的每件事都是处于动态转变中，为了估算充分的准确性，需要彻底了解需求。
在今天的软件行业中，不能估计用适当的准确性进行大量工作，除非源于详细的、具体方法的结构化的需求 [4] 并且使用与前面成功地完成的项目相关的生产力比率，由差不多相同的团队（研究相同的技术）交付。架构师进行的估算常常与未结构化的需求（不足够好）相关，由实际的类似的过去的解决方案改编而来（坏的），或者根据从项目团队中获得的承诺（甚至更糟）。
作 为组织和项目团队之间的代理，PM 经常陷入要求和现实的困境中。这种隔阂常常显露出的一个区域是专用的资源和估算的成本之间的差异。在大多数情况下，问题归结为组织远在解决方案需求收集之 前就分配其预算了，更不用提很好地了解了。事实上，项目团队被任命了解在这些情况下可以合理地构建出什么。这令 PM 希望架构师在项目开始之前所进行的估算可以成为现实。
项 目的成功有赖于是否选择并遵照项目方法。与建筑或生产行业相对比，软件项目可以选择许多风格和味道的方法，从非常形式的，到非常敏捷的。PM 经常不开始选择项目的方法，但其适当的执行几乎总是 PM 的职责。因此，当决定要使用的项目方法时，PM 不得不注重实效且协作。
由 于工作的特性，大多数项目经理不能客观地判断架构和设计决策。他们必须依赖于团队中的某个人来进行这些关键的决策， —— 通常是架构师或领导的开发人员。不意外的是每个项目经理都希望它们的关系无暇地进行。用可交付件帮助项目经理的架构师应该了解 PM 的依赖关系的含义，并对此灵敏。
在 一些组织中，官僚主义和政治遮蔽了建设性的逻辑。如果项目团队和管理团队是有动机的，那就很好。在这种情况下，他们更可能选择“精益的”实现方法，将个人 问题的职责实际地散布在团队中。然而，如果缺少职责的透明性，那么 PM 会拥有明显的所有权和职责，也许是基于 RACI（Responsible Accountable Consulted Informed）模型的。与架构师和项目发起人之间的可信赖关系是良好的开端，但不能取代明确划分的职责。清晰的职责结构是项目经理的安全网，这也向项 目团队的其他成员提供了透明性。
在 与 PM 的经常的对话中，我听到了关于在 RUP 项目上应用项目管理任务的不确定性和犹豫。令我惊讶的是大部分人缺乏对 RUP 概念和原则的了解。每个人通常会快速地说出 RUP 是迭代的过程，然而，大部分 PM 没有完全了解并理解应用 RUP 所带来的必要质量和实际的好处。下面讨论我遇到的最大的误解 —— 以及我对其的分解。
令人悲伤的是，RUP 常常被认为与项目管理标准相竞争，比如 PMBOK。也许这种误解源于 RUP 的定义“在开发组织中提供分配任务和职责的规程化的方法” —— 看上去是项目管理任务。这个定义即没有代表性也非常令人误解。
尽 管 RUP 将项目管理列为其九个核心规程之一（参见下面的图 2），但是使用 RUP 的组织仍旧得益于使用固定的项目管理框架。RUP 项目管理规程详细描述 PM 方面的选择，这些方面与活动的计划及任务的执行，特别涉及迭代计划，相关。不像 PMBOK 那样，RUP 不将项目管理作为端到端的过程。RUP 还完全地忽略了一些与项目管理相关的重要活动，包括人员管理、资源计划和估算、扩大，和联系管理。
无 疑的是用例分析技术对于 RUP 是必要的，因为它支持 RUP 的关键原则之一 —— 减少风险的，迭代的实现。然而，将用例建模和分析等同于 RUP 是错误的，因为 RUP 允许其他的标识和技术，只要它们符合迭代生命周期中 RUP 的基本原则。用例分析技术特别有助于描述交互密集的软件应用程序，但是可能在其他解决方案或应用环境中没那么有用，例如当系统用户和系统之间的通信最小 时，或者当不需要重新获取流时，例如在 Commercial Off-the-Shelf（COTS）实现过程中。软件开发范围之外的用例的应用可能也是可行的，但是应用 RUP 作为最佳实践的过程框架和平台可能不错。
前面已经说过了，RUP 不仅是管理用例的容器，而且是可以用于迭代的及增量的项目交付的可定制的过程框架。在 IBM Rational Method Composer 支持的更广的企业组织方法环境中，RUP 引发的活动，以及来自其他方法和标准的活动可能用于装配适用于组织需求的自定义过程。
由 于既定的项目责任和理论的监督职责，项目经理的角色常被认为是强大的角色。虽然在十分专业的软件开发环境中，适当的管理授权对于任何项目的成功是至关重要 的，但是比起运输或大量制造的项目来说，管理的成功更对多个个人的专业技能要求多，因此在软件项目中应该对 PM 角色区别对待。RUP 不是项目管理过程，并且软件开发不是“命令和控制”环境。在 RUP 中，规程扮演者平衡的角色。
项目管理在 RUP 中扮演着关键角色，RUP 从 PMBOK 中得到 PM 规程。在参考的 RUP 生命周期中，项目管理活动在来自任意其他规程的活动之前开始。事实上，如图 2 所示，这些活动甚至在正式的 RUP 项目开始之前就可能开始了（见下面）。考虑到一些警告和需求驱动的范围，PMBOK 可以用作设置 RUP 迭代的固定过程，如图 1 所示。
图 1：从 PMBOK 延伸来的 RUP PM 规程
重要的是，RUP 不涉及官僚主义和政治 [2]，因此当项目管理过程没有用作“cover up”，“must have”，或“go，go”命令序列，而是组织并指导专业团队时，RUP 明确地帮助将注意力锁定在最重要的事情上。
然而，RUP 是不是问题的最佳解决方案是不同的问题。一些组织如此远离它们对 PM 标准的理解和应用，以至于我会问它们是否应该立即着 手 SDLC 方法，例如 RUP 来改善它们的业务。相反，要赶上行业，它们可能考虑利用结构化的企业架构框架（例如，Zachman Framework）屏蔽它们现有的过程、系统，和方法。这可能令它们更好地了解并编写 IT 架构的当前状态，并且可以之后遵照其进行通用标识的采用，例如 UML，和最终的 SDLC 过程，如 RUP [5]。
如果可以在实际中像理论中那样有效，也许瀑布方法会比 RUP 表示更简单的管理过程，主要因为没有采用重复的迭代计划和管理。然而，这只是理论上的。
举例来说，一般在工程中，特别是在软件开发中，没有人能够确保原始的设计，以及实现进度将长期完好，共不用提直到项目结束。事实上，通过许多项目已经证明了反面。增量的细化是工程中固有的，不像建筑或制造业一样，原始的设计没机会长期存活，而行业动力增加了额外的易变性。
另 一个错误的假设是用“大爆炸”方法可以有效地处理任何复杂性。通过实验（科学上的）已经证实，管理增加的复杂度需要指数上升的工作量，这反过来导致需要额 外的时间和更高的技能。相反，RUP 已经形式化为，通过将活动分为可管理的但重要的块来减少复杂度，每一块对项目涉众有一个表面值，并且每一块都实现了对用户需求的增量变更。拥有多个“伪项 目”，以及总体的迭代方法，被视为更加强的项目管理过程。虽然它更加强，但是还是更可靠的，并且因此是较便宜的实现方法。在实际中，迭代的方法通常增加工 程团队的可信度，并且减少项目的成本。
迭代环境中的项目管理被广泛认为是专业技能，这依赖于对增量的设计原 则，需求工程，和风险管理基础的很好的理解。像 PMBOK 的项目管理标准慢慢地围绕着软件工程的增加的特性，并且调整它们的活动和规则来考虑迭代管理的远景。而 RUP 试图帮助管理项目风险，提倡早期的干预和基于需求的项目计划，尽管似乎需要更多的项目管理工作，但这可以帮助交付具有较少风险的优秀的结果。
一些项目经理不清楚的是（以我的观察，其他经理也是）RUP 项目什么时候开始，以及较次要的，RUP 项目如何结束。PM 经常问到，在 RUP 生命周期中，PMBOK 初始活动，例如用战略目标连接范围的活动和保护项目基金的活动，是否发生。
值 得注意的是（再次）RUP 是解决方案实现方法，它不涉及为具体的商业问题开发解决方案的清楚地表达的需求。它用于处理在所选的组织区域中工作的所选的用户组的需求，这些用户一般只 利用整体商业过程的有限部分。因此，项目经理经常在 RUP 中寻找的活动存在于 RUP 之外，然而，组织通常在 RUP 项目的初始阶段中执行一些活动，通常作为商业分析规程的一部分。这种类型的架构计划可能被认为是企业架构“反模式”，并且还与 PMBOK 冲突，它期望接收这样的分析作为在初始过程中执行的决策制定过程的输入（参见图 2）。
图 2：RUP、PMBOK和企业规程（Enterprise disciplines）
如 今，许多组织仍旧没有能够通过将项目实现为所实现的解决方案的特性和组件，准确地追踪战略决策的企业架构团队。由像 The Open Group Architecture Framework（TOGAF）和 Catalyst 这样的框架支持的企业架构（Enterprise Architecture，EA）领域只会慢慢地在软件行业中被采用。在某种程度上由于 EA 框架相对低的采用率，而且由于围绕它们的目的的行业争议，EA 框架不能充分地描述从企业架构到解决方案设计的转变。项目组合管理（Portfolio Management）和变更管理（Change Management）过程和工具（它们是对各种管理难题的管理响应）不完全支持基于架构考虑的决策制定。
Rational Method Composer，作为根据完全的企业范围的生命周期过程的指导扩展 RUP 的方法，试图处理一些局限性，提供丰富的程序上的和信息的指南，可以有选择地利用这些指南创建支持方法阶段转变的裁剪过的过程。在 Rational Method Composer 中，存在同化商业目标的指南和商业架构分析（TOGAF，企业统一过程（Enterprise Unified Process，EUP），及其它）的结果，以及项目涉众的请求和使用需求（RUP，特性推动的开发（feature-driven development，FDD），Scrum）、资源管理（PMBOK），和现有的系统架构（Zachman）。参考过程用于最流行的企业治理模型（举 例来说，Department of Defense Architecture Framework（DoDAF）或 Capability Maturity Model Integration（CMMI®）），解决方案架构和实现模式（举例来说，面向服务的体系结构（service-oriented architecture，SOA），模型驱动的系统开发（Model-Driven Systems Development，MDSD）和 COTS），并且适用于任意规模的（使 RUP 分别适合于小/中/大型项目）。实现行业领先的过程的定制插件的数量在在增加（最近对于 TOGAF）。
许多项目经理抱怨 RUP 不生成估计值。这好像是正确的。RUP 是既不指导也不促进任何具体估算技术的过程框架，然而，他包含一些关于在哪如何估算的有用的指示。
早 期的 RUP 版本及其缺少估算指南。这随着 Rational Method Composer 的兴起以及许多估算模型 [3] 的成熟而改变了。在 Rational Method Composer 中，估算用两个过程内容表示，它可以包含于随需的定制过程中，以及作为瞄准不同项目排列的参考过程的一部分（举例来说，用于维护的 RUP 和用于资产开发的 RUP）。可执行的引擎也以许多定制的 Rational Method Composer 插件的形式出现，例如 Quantitative Software Management（QSM） Measurement 和 Estimation 插件。后面的插件定为在过程中关键的里程碑处，以及随需调用，从而进行估算。该插件允许利用环境、过程，和项目量度的极度的参数化。
目 前，核心的 RUP 包含一个库，该库含有对于功能点估算的指南，以及用例和宽范围的 DELPHI 技术。QSM 估算插件实现了精炼的 Putnam Lifecycle Model 并且接受功能计数（function count，FC）或软件代码行（software lines of code，SLOC）输入。不幸的是，Rational Method Composer 内容没有采用基于经验的且面向学习的方法，并且大规模地忽略了所有其他的技术，然而，这些技术可能仍旧在使用。
重点是 Rational Method Composer 对待估算与对待其他技术和最佳实践的方式相同，例如用力分析或单元测试。它迫使过程工程师和项目经理将估算认为是在最有意义的地方执行的可选的技术（然而重要），或者在特别的基础上，作为交付过程的预定义部分。
类 似于项目管理规程，受到其自己的标准和最佳实践治理，例如 PMBOK 和 Projects in Controlled Environments（PRINCE2），因此是审计实践。在核心的 RUP 中，这是配置和变更管理规程的一部分。像项目管理一样，变更管理活动在过程早期就开始了。它们包含配置管理、变更请求管理，和状态及度量，它们都可能直接 引起审计活动。
对于此问题的部分理由是在项目有利于属于需求、分析和设计，及实现规程的活动的过程中经常忽视 配置和变更管理任务，因为那些被认为对解决方案的交付更重要。对此，目光短浅的项目和组织最终要付出重大代价。因此，这取决于项目经理确保来自所有规程的 活动都及时切有效的运行。RUP 不缺乏关于什么时候需要完成什么的指导。
忘记迭代 —— 我见到的大部分项目将 RUP 用作胶棒，很少超出定义阶段并使用用例来描述前端和后端的交互。
要拥有多个项目迭代，每一个都要交付产品版 本，这对于 PM 来说是很难做出的决策，并且计划它们是 PM 工作中最挑战的部分之一。促使适当的迭代要用灵活性和信赖，以及主题领域和方法经验。然而，阶段似乎更容易理解，因为它们提供清晰的桶，PM 可以将任务放进去。在 RUP 中，每个阶段都结束于定义良好的主要里程碑处 —— 参考架构的基石，并且不论项目大小、类型，或复杂度，对于所有 RUP 项目来说都是一样的。然而结束于次要里程碑的迭代可能在项目与项目之间都不同。
里程碑允许项目经理“同步注视”其技术团队，并且向上司交付重要的更新。重要的是，它们与最关键的工件的交付一致，因此可以并且必须用于构建项目计划并作出“去/不去”的项目决策。
大部分主要的 RUP 里程碑大部分时间都存在于单个的迭代中，它们是：
- 生命周期目标
- 生命周期架构
- 初始的操作功能
- 产品版本
次要（但不是极其次要）的里程碑与主要的产品版本的交付相一致。
迭 代的概念无疑地对于作为过程框架的 RUP 来说比阶段的概念更重要。后者经常令人，包括 PM，想到精化阶段的需求获取、构建阶段的开发，和产品化阶段的部署，比起 RUP 这更令人想起瀑布方法。不幸的是 RUP 阶段感觉好像是从建筑行业的构建开发生命周期模型中推出来的。该行业的普遍过程模型本质上是顺序的，而主要的工程模型是循环的 [6]。
进 行 RUP 和 PMBOK 之间的映射不是必须的，然而，如果在项目过程中联合使用一些标准的话，就需要某种形式的映射。在高层次上，这种映射十分直接，但在实际中，每个项目都采用 稍微不同的模型。应该问的第一个问题是这两个标准中哪个应该用做基线。我强烈推荐 RUP，正如 PMBOK 通常作为固定的项目标准。理由是 RUP 代表更分立且更专业的软件工程领域，而 PMBOK 是基本上不分行业的项目管理方法。当创造并裁剪好定制的方法之后，基于 RUP 的且涉及 PMBOK 的交付过程可以作为内行的项目方法指南，这不太可能成为其他方面的东西。
如果要进行映射工作，那 么只应该着手于满足 PM 愿望的细节的程度。一些项目经理倾向于只要映射个别的任务和工件。我建议有关生命周期元素的映射原则的协议就足够了。坚持做 RUP 的项目计划建议会是更好的时间投入。下表总结了来自 RUP 的生命周期元素和 PMBOK 标准之间的映射。
表 1：匹配 RUP 和 PMBOK 元素
| RUP | PMBOK |
|---|---|
| 阶段 | 阶段 |
| 主要里程碑 | 里程碑 |
| 迭代 | 项目 |
| 次要里程碑 | 里程碑 |
| 规程 | 知识域 |
| 活动 | 过程组 |
| 工作产品（工件，可交付件） | 可交付件 |
| 任务 | 过程 |
当 使用混合的方式时，工件冲突和添加的冗余正好是过程工程团队或项目团队将要面对的一些潜在挑战。一个很好的实例是 PMBOK Project Charter 可交付件，像一些 PM 所指出的，在 RUP 中被 Business Case and Vision 工件“替代”。虽然混合的方法可能提倡混合使用来自两个标准的工件，但是出于支持可溯性的原因我强烈建议维护所有的 RUP 工件，而可以在一个个案例的基础上添加并由 RUP 工件导出 PMBOK 工件。
还导致 PM 的痛苦的事情是 RUP 允许一些其自己的工件，例如 Software Architecture Document，在项目阶段和迭代中演进，并且比与 PMBOK 相一致的时间更长的时间内处于部分完成的状态。重要的是要强调，RUP 限制工件不确定地演进，并且使用严格的原则和标准让其工件通过里程碑。最近 PMBOK 规范也通过应用“发展的精化阶段”的原则，考虑了增量的方法。
像 许多其他的 IT 项目参与者一样，项目经理经常把 RUP 认为是单个现成的过程。也许这种感觉源于其发展的早期，就是 RUP 是单独的过程，涉及小范围项目（主要是“绿屏”软件开发项目）并且缺少关于项目规模的足够灵活性（倾向于将所有项目当作大型的来对待）的时候。在那个时 候，RUP 还缺乏足够的叙述性的指导和定制能力。尽管在很久以前这些不足就被解决了，但是将 RUP 作为仪式的且呆板的过程的看法仍旧存在。
由 于 Rational Method Composer 的引入，情况发生了重大的改变。后面的 RUP 版本包含许多根据规模的分类（并且根据所涉及的仪式的量），包括“小型项目的 RUP”，“中型项目的 RUP”，和“大型项目的 RUP”。可以结合基础 RUP 裁剪专门的“插件”，例如“RUP for COTS”和“RUP for Business Modeling”，为了创建专门的适当规模的交付过程。除了现成的规范，可以根据组织内部开发的指导，以及其他方法、框架，和最佳实践，例如 PMBOK 或 Information Technology Infrastructure Library（ITIL®），还通过 RMC 插件调整定制的过程。
PM 经常期望 RUP 辅助他们的管理任务，例如获得资金批准或保护来自高级管理层的“补偿购入”。沿着这些思路，许多 PM 想要看到 RUP 初始阶段之间加上照顾这些问题的额外时期。然而，这种控制 RUP 生命周期的方法会违背其一些原则。
如 果用来扩展 RUP 初始阶段，那么这些活动将约束项目资源，这违背了 RUP 的 一致性和过程有效性规则。当不考虑基于需求的根据而做出重要的项目决策时，要么证明是完全肤浅的，要么交付有缺陷或不完全的解决方案。准确的项目计划只可 能根据结构化的需求来执行，这一般通过精化阶段得出。
如果目标是保证更多的时间用于商业分析或政治控制，那么 用 RUP 没什么用。也许，在 EA 领域中可以找到某种解决方法。EA 的要求比 RUP 的更广泛，并且 Rational Method Composer 中有它的指导，用于将企业愿景、商业案例和其它计划文档中包含的远景目标和商业方法转换为商业技术规范和解决方案提案。EA 方法包含对于企业过程和结构分析、目标和范围识别、资源估算、架构分析、解决方案确定及优先级化，和实现方法选择的指导。更多潜在的辅助存在于项目组合管 理的领域中。在进行着连续的项目组合管理过程的情况下，很自然的是项目选择和一般的检查都会是循环的功能，因而去掉对解决方案实现方法的任何偏见。
这些方法可能需要对组织中的项目管理的新观点，也许是企业项目经理角色的形式。我接下来将讨论这种可能性。
对于组织来说，设立企业 PM 角色值得吗？如果将企业的演进预想为单独长期的过程 —— TOGAF 和其它 EA 实现框架利用的东西，那么可能值得。
当 然，将 EA 实现映射为一个或多个项目会要求包含已知项目中完整的 EA 生命周期，或者一部分生命周期。虽然前者的方法是吸引人的，但不好，因为这可能导致非常长的项目。尽管通过减少与项目初始和结束相关的工作可能减少实现活 动的官僚主义负担，但是事实是可能花费数年来执行项目，这不实际（并且违背提倡有限项目的 RUP 的推荐）。
因 此，更可取的是在 EA 实现路径旁设立许多项目，项目的生命更合理地分布。举例来说，这些项目可能交迭一个或一些 EA 实现阶段。它们既可以同时也可以交迭进行。举一个 TOGAF ADM 的实例，将三个不同的企业项目设置为联合的远景（阶段 A），开发架构（阶段 B 到 F），并且提供解决方的案实现治理和变更管理（阶段 G 到 H）。
现在由组织决定是否需要专门的企 业 PM 来处理企业的事务，或者其成为企业架构师的附加职责 [1]。然后由企业 PM（或架构师）提出一个最佳的解决方案项目集合来实现 EA。这个决策必须考虑一些因素，例如组织的变更诱因，它的交付能力，在执行类似项目时组织原来的生产力，以及历史上的或预期的 EA 实现循环的持续时间。问题的历史暗示，企业架构师有其他要担心的事情（像架构问题），这可能形成了很难逾越的职责缝隙。
- 计划是控制多个项目的项目。
  |
|
作者想要感谢 Jas Madhur、Mark Arshawsky，和 Francis Pring-Mill 的颇有见解的批注。在此表达的看法是那些作者的，不一定符合 Sierra Systems Inc 的。
[1] 阅读关于 TOGAF 和 RUP 一起使用的我的 Rational Edge 文章，了解更多关于企业架构和解决方案实现之间的一致性的更多内容：TOGAF 或非 TOGAF：在 RUP 之上扩展企业架构
[2] 这篇 Philippe Kruchten 写的极好的论文谈论了对于 PM 来说，从瀑布过渡到迭代开发之间的挑战：From Waterfall to Iterative Development
[3] 可以在此了解到一些关于企业估算的有用模式：企业范围的软件评估，第 1 部分
[4] 来自 The Rational Edge 的我们的文章介绍了更多关于结构化的需求的内容：企业范围的软件评估，第 2 部分
[5] 要了解相关的信息，请参见我的关于一起使用 Zachman、RUP 和 UML 的 Rational Edge 文章：UML、RUP 和 Zachman 框架：完美结合
[6] 这里有另一个关于预测迭代项目的有趣内容。
[7] 在此可以找到在对 PMBOK 和 RUP 之间进行形式映射的过程中用到的模板：Software Project Management -- A Mapping between RUP and the PMBOK
[8] 要了解关于将 PMBOK 映射为 RUP 的思想和分析，请访问：Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOK
[9] 还要咨询 Rational Method Composer 内容数据库，以获得指导和有用的建议。
- 参与论坛讨论。
- 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
- 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
- 全球 Rational 用户组社区
| ||
| | Vitalie Temnenco 是 Sierra Systems Inc. 的软件架构师，他在那里向 Sierra 的客户提供技术和方法咨询。之前，他是 Ontario（加拿大政府的 Workplace Safety and Insurance Board）的架构师，他在那里提供关于实现项目的架构指导，并且帮助团队接受 RUP 和企业架构（Enterprise Architecture）概念。他的经历包括为各种商业领域，例如银行业、金融、保险、零售，和电信，中的客户架构并构建解决方案，并且他教授用于商业 和系统分析的 UML 和 RUP，并结合到新系统中。您可以通过 vit@umlconsulting.com 联系他。 |
博文
没有评论:
发表评论