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

　　摘要

　　IBM Rational Unified Process®(或简称 RUP®)是一个完善的软件开发过程框架，它具有若干种即装即用的实例。源自 RUP 的过程范围很广，从满足短周期的小型项目需要的轻量级 RUP，到满足大型的、可能是分布式的项目团队需要的更加完备的过程。各种类型和规模的项目都已成功地使用了 RUP。本白皮书说明了如何在小型项目中以轻量级的方式应用 RUP。我们将要讲解如何在一个完整项目的上下文范围内应用极限编程(XP)技术。

　　引言

　　一个小故事

　　一天早上，一名经理找到我询问我是否可以花几个星期为一家公司刚刚启动的投资建立一个简单的信息系统。我正厌烦手头的项目而渴望新项目启动带来刺激，于是我为这个机会欢欣雀跃--我快速开始行动，为新的伟大解决方案进行开发，而摆脱我工作的大型机构的官僚和手续的束缚。

　　事情在开始阶段进行得很顺利。在头六个月中，我都工作很长时间并且自得其乐。我的工作效率不可思议，并且一些工作堪称是我职业生涯中的杰作。开发周期是快速的，而且我每隔几周就可以完成系统中一些新的主要部分。与用户的交互过程简单而直接，我们都属于一个紧密联系的团队，而且可以免除一些手续和文档。也没有什么正式的设计;代码就是设计，设计也就是代码。一切都是这样的完美!

　　这种完美只持续了一段时间。随着系统开发的进行，我们需要开展更多的工作。现有代码随着问题的变更而必须进行完善，而且我们也相应精化了所需工作的概念。我雇了一些开发人员帮助进行开发。我们就像一个单元一样工作，经常对一些问题互相讨论。这加强了沟通同时也免除了形式。

　　一年过去了。

　　我们还在增加开发人员。整个团队从 3 个人到 5 个人，然后是 7 个人。每次增加人员时，都要花很长的时间来学习，如果没有经验，那么就很难理解和解释整套系统，即使是一个概览。我们开始使用白板图来更加正式地展示系统的整体结构、主要概念和接口。

　　我们仍然在使用测试作为验证系统是否满足需要的主要手段。很多新来的开发人员都站在用户的立场上，我们发现项目早期非正式的需求和个人联系已经不能满足需要了。我们花费了更长的时间来计划我们要建立的目标内容。结果由于我们保留了讨论的文字记录，而不用频繁地回想已经做过的决定。我们还发现描述需求和使用场景有助于向系统的新用户介绍情况。

　　系统的规模和复杂度不断增加，意外的情况发生了--需要清楚地描述系统的构架。在项目初期，构架大部分存于我的头脑中，后来潦草地记在笔记或活动挂图中。不过，随着项目的人员越来越多，构架有些失控。由于不是每个人都和我一样富有经验，他们无法发现某些变更对整个构架带来的影响。我们不得不使用更精确的术语定义对系统构架的约束。任何可能影响构架的变更都需要团队进行商讨，并且最终获得我的同意。我们绕了一圈后才发现了这个问题，接受了一些重大教训之后，这在真正认识到构架的重要性。

　　这是一段真实经历。它只讲述了这个项目中的一部分困难经历。这些经历只在一个方面是不同寻常的：我们中的一部分人从开始的最后一直在一起，时间一年有余。开发人员经常在一个项目中半途而来，没等结束就已经离开，丝毫