【IT168 技术文章】

    软件项目管理者常常认为 Rational Unified Process（即大家所熟知的RUP），不适用于有限规模的软件项目。本文提供了在整个迭代开发阶段均遵循RUP，从而获益匪浅的两个小项目的典型示例。

    小型项目和团队的背景

    通常看来，如果被安排来管理一个小项目，也就意味你是新人或者你已经落伍了。大家都认为“一流的资源”应该被分配给大型的、企业级的、全特性的发布项目。这种认识是错误的，让我们来看一下市场，特别是2001年 .com 破碎之后，小型项目和敏捷团队的时机成熟了。公司在一个月、一个季度、或者一年之内完成的项目越小，那么，产生收益、减少成本、或者拓展品牌和价值的机会就越多。

    明确以下一些定义之后，我们继续这个话题的讨论：

    . 大型项目：预算超过$500,000，团队规模为十三人或者更大，项目进行时间超过一年。
    . 中等项目：预算$100,000-$500,000，团队规模为六到十二人，项目进行时间为六个月到一年。
    . 小型项目：预算低于$100,000，团队规模少于六人（包括在该项目和其他项目之间共用的团队成员，以及每日必须的人员）。项目进行时间少于六个月。
    . 变更请求：预算低于$50,000的所有任务都是被一个人在几周之内来完成。

    RUP同样适用于小型项目

    在 Michael Jordan、Greg LeMond、Tiger Woods之前，Bo Jackson统治着整个体育世界。19世纪80年代后期流行着这样一句话：“Bo 懂得篮球、足球、投资”。

    过去的三个多月里，在研讨会或课堂上，我引用Bo Jackson的例子来反驳RUP“不适”小型项目的错误观点。我认为RUP“适合”于所有类型的项目，这让很多人都感到惊诧。就我在过去几年使用RUP的经历而言，它能够用在所有大型、企业级项目，并且组织变更请求。它不仅仅是一个可有可无的方法论。
   
    下面是人们经常提起的用来说明“RUP不适用于小型项目”的两个方面，我将逐一解答这些问题，来证明他们的看法是错误的：

    1.敏捷方法考虑到迅速和紧密的增加或者阶段；减少开销；并且确保开发人员与客户之间的紧密联系。

    我的回答：敏捷方法以及类似的方法（SCRUM，Paired Programming）在软件构建中是革新的、有用的。然而，在RUP中也可以使用敏捷方法。那些轻量级的方法可以很好地在新系统的构建阶段、解决方案，或者程序中得到运用；但是仍然需要管理其它三个阶段的上游和下游活动，比如决定需要做什么（需求）以及操作环境将受到什么影响（发布管理）。RUP并不关注先启阶段、细化阶段、构建阶段和产品化阶段所有业务原则的使用，事实上，它是为这些活动提供了一个非常好的框架。

    2.RUP以及类似的指导，比如PMBOK, 软件工程协会(SEI)的集成的能力成熟度模型 (CMMI)，或 UK 的 IT Infrastructure Library (ITIL)标准给小型项目强加了一些不必要的过程。他们其实仅适用于一千万以上的大型项目。

    我的回答：方法、知识体系，或者成熟模型不会强加过程。他们只为估算需要做什么，以及如何做得更好而提供一定的基础。“如何做”这部分是由实施组织来决定的。

    PMBOK并没有规定2000版本中的39个过程或者2004版本中的44个过程在项目中都必须得到使用。它是一个知识体系，为项目管理者可能遇到的各种情况提供了一个起点。例如，它有助于定义组织的变更控制过程应该包括哪些内容。现在，项目管理专业人员（PMP?）在项目管理协会（PMI）监督之下，当然必须遵循PMBOK。PMI提供PMP资格认证，这样，聘用专业人员的组织机构就能够放心该专业人员懂得PMBOK。但是这并不意味着专业人员必须在每个项目中都使用到PMBOK的每一项知识。

    SEI的能力成熟度模型（CMM）和CMMI从五个级别来评估并验证某组织的成熟度。按照SEI的规定，很清楚地评估和验证一个组织做什么，以及在某种程度上，他们如何完成。然而，这并不是规定一个“可重复过程”（二级）必须利用过程、工具和组织角色来完成。
   
    相似地，“RUP的精髓”-- 以及已开发的许多实施RUP的工具 -- 培养逐渐细化的理念，即增量开发的本质。RUP的观点是组织应当设计并构建部分而不是全部解决方案，需求是已知的。现实中，验证某特色或者系统是“受人欢迎的应用程序”（比如，想法），还是“失败”（比如，Coca-Cola's New Coke，自1984）的一个最有效办法就是将产品交付给用户。

    应用RUP，探寻SEI CMM/CMMI评估，或者使用PMI PMBOK时，非常好的实践是成体系地使用这些向导。例如，你应该首先懂得业务需要（a.k.a 需求），从本质的用例开始，基于那些用例和UML的强大功能进行建模。在2004年《The Rational Unified Process Made Easy》一书中，Per Kroll和Philippe Krutchen很好地描述了这个方法：

    ．．．也许，人们采用RUP时最常出现的错误是使用太多工件或者做太多活动。过量使用RUP将会降低你的开发效率；RUP过程框架类似于自助餐，如果你还想保持健康和快乐，那么就不能吃光所有的饭菜。1