在小型项目中使用RUP: 极限编程剖析

看不到他们的所作所为带来的后续影响。

　　这个项目本该使用一些过程进行管理。过程太多会误事，但是不使用过程会带来新的风险。就像投资高风险股票的人仅仅看到高回报一样，几乎不使用过程 的项目组忽略了项目环境中的关键风险，其实是在"期望得到最好的结果，但是没有为最坏的情况做打算"。

　　概述

　　本文讨论了如何将过程应用到例如上文所述的项目中。我们的目的是为了得到使用过程的"恰当级别"。了解开发团队所面对的挑战以及其所处的来务环境，可以得出过程使用的恰当级别。如果我们理解了这些挑战，就可以使用刚好足够的过程来降低风险。不论是轻量级的还是其他，"一刀切"过程是不存在的。在以下内容中，我们来研究这一思想，即过程的恰当级别可以作为一个风险的函数。

　　我们集中讨论如何通过使用两个流行的方法得到过程的恰当级别：Rational Unified Process 或简称 RUP 以及极限编程(XP)。我们展示如何在小型项目中使用 RUP 以及 RUP 如何处理 XP 没有涉及到的领域。二者融合为项目团队提供了所需的指南--减少风险同时完成交付软件产品的目标。

　　RUP 是由 IBM Rational 开发的过程框架。它是一种迭代的开发方法，基于六个经过行业验证的最佳实践(参见 RUP 附录)。随着时间的推进，一个基于 RUP 的项目将经历四个阶段：起始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)、交付阶段(Transition)。每个阶段都包括一次或者多次的迭代。在每次迭代中，您根据不同的要求或工作流(如需求、分析和设计等)投入不同的工作量。RUP 的关键驱动因素就是降低风险。RUP 通过数千个项目中数千名 IBM Rational 客户和合作伙伴使用而得到精化。下图展示了一个典型迭代过程的工作流：

　　典型迭代流

　　作为风险如何影响过程的一个例子，我们应该考虑是否需要为业务建模。如果由于对业务的理解中没有考虑到一些重大风险，将导致我们所构建的系统是错误的，那么我们就应该执行一些业务建模工作。我们需要正式进行建模工作吗?这取决于我们的涉众--如果一个小团队将非正式地使用结果，那么我们也许只进行非正式的记录就可以。如果组织中的其他人也将使用结果或者查看结果，那么我们可能就要投入更大的努力，并且确保该结果的正确性和可理解性。

　　您可以定制 RUP 使其满足几乎任何项目的需要。如果没有满足您特定需要的即装即用的过程或路线图，您可以轻松地创建您自己的路线图。路线图描述了该项目如何计划使用过程，因此代表了该项目的特定过程实例。这就意味着，RUP 可以按需要变得简单或复杂，我们将在本文中详细解释。

　　XP 是一个用于小型项目中的以代码为中心的轻量级过程(参见 XP 附录)。它来自 Kent Beck 的创意，在大概 1997 年 Chrysler 公司的 C 3 工资单项目中得到软件界的关注。如同 RUP 一样，XP 也是基于迭代的，并且体现了诸如小规模发布、简单设计、测试以及持续迭代几项实践，。XP 为恰当的项目和环境引入了一些有效的技术;不过，其中也存在隐藏的假设、活动和角色。

　　RUP 和 XP 具有不同的基本原理。RUP 是过程组件、方法以及技术的框架，您可以将其应用于任何特定的软件项目，我们希望用户限定 RUP 的使用范围。XP，从另一方面来说，是一个具有更多限制的过程，需要附加内容以使其适合完整的开发项目。这些不同点解释了软件开发界的一个观点：开发大型系统的人员使用 RUP 解决问题，而开发小型系统的人员使用 XP 作为解决方案。我们的经验表明大部分的软件项目都处于两者之间--尽力找寻适用于各自情况的过程的恰当级别。单纯地使用两者之一是不充分的。

　　当您在 RUP 中融合了 XP 技术时，您会得到过程的正确量，既满足了项目所有成员的需要