【IT168 技术文章】
导言
反模式就是不做什么：有些行为、习惯或者方法似乎很有价值，但对于准备完成的事情来说却没有帮助。本文讨论了多种RUP反模式，收集来自Black Diamond Software指导RUP使用者在各种不同大小，人员组成技术环境和工业项目中的经验。本文讨论了每一种反模式的本质，以及怎样才能避免的措施。
反模式
1. 瀑布RUP
“我们目前的迭代是需求，下一次迭代才是设计”
对那些一直遵循严格的瀑布开发过程的人们而言，瀑布RUP是最容易犯的错误之一。瀑布RUP是反模式的原因很简单：它不能帮助降低风险程度，而降低风险是基本的RUP原则之一。RUP迭代式开发要求每次迭代应该是一个应用程序的“小型发布版”。每次迭代有小型的需求，设计，开发和测试环节，并且交出应用程序的一个可运行部分。使用这种方式，需求、设计、实施和测试的问题在每一次迭代中都得到“冲刷”，要求问题越早解决越好（问题越早解决其消耗的代价就越小）。
如果瀑布阶段没有转换成迭代，会怎样呢？功能块就会成为迭代，用例成为功能“片”的基础。通常RUP表明了用例的优先性，同时也说明了内在的风险决定用例怎样被划分到迭代中。
2. 准备-设置-RUP
“公司说每一个人都应该遵循RUP，所以让我们开始吧”
决定采纳RUP作为方法学通常源于高层领导。CIO、CTO或者其它的高层的技术领导决定所有新的项目必须遵循RUP。然后每一个部门决定怎样将RUP应用到他们的项目中，于是他们购买该方法学，并且相信他们已经做好准备。第一个项目组在接受某些RUP培训后热火朝天的开始实施。他们尽可能的严格执行该方法学的要求，但是这好像有些难以容忍－RUP太庞大了以至于他们深陷在disciplines, artifacts, milestones之中而迷失了。如果项目的完成日期迫近，而他们仍然陷入方法学的泥潭中，他们就会绝望，就会退回到他们原来知道的但是不是RUP的方式来解决问题。这个项目组从前有很好的意图，但是为了能够在最后日期前完成任务，最终退回到他们原来了解的最好的方式。
RUP是一种相当大的方法，而且独自解决它是项艰难的任务。对于已经适应不同于RUP方法学的组织，例如瀑布模型，第一个RUP项目是一个巨大的挑战，超出典型的项目挑战。当它被完全贯彻下来，你就会发现采纳RUP的原因，才会发现RUP的功效，所以退回到原来的处理的方法是不能被接受的。
那下一步应该做什么呢？下一步要做的就是在整个组织范围内贯彻RUP。尽力建立一个支持结构，目的是使项目组成员不要经常偏离他们努力的目标。你也许会发现你需要其他具有丰富RUP经验人的帮助，这意味着招聘一个具有RUP背景的雇员或者有从外部获取RUP帮助的渠道。其实你真正所需要的是决定怎样将RUP应用到特定的项目中，和怎样使用RUP的相关技术，例如用例开发等。有时一点指导会帮你少走很多弯路。
3. RUP－全部工具的总和
“我们拥有Rational的工具，所以我们已经做好开始的准备”
这是另一种“准备－设置－RUP”，是对工具的扭曲认识。在这种反模式里，项目组拥有RUP方法学和Rational的工具，他们已经准备好开始一个RUP的项目。问题是RUP不是所有工具的和。这些工具可以帮助方便实施RUP的很多活动，但是利用这些工具不能确保能够有效的实施RUP。你知道准备应用的这些工具是做什么的吗？你知道你怎样做才能适合软件开发过程吗？举一个例子，如果你使用Requisite ProTM来进行需求管理，那么你知道怎样保证需求信息被整个项目组共享吗？怎样将Requisite ProTM正在收集的需求信息反馈给用户呢？知道怎样利用Rational工具是很重要的，但是理解这些工具所支持的活动以及这些活动之间的相关性也是必须的。简单的说，实施RUP可能会驱使你使用这些工具，而不是因为有了工具而使用工具。
要熟悉RUP的理念。要思考这些理念与你以前熟悉的方法学的理念有什么相似和不同之处。要熟悉Rational Tool Mentor，这些指导为你使用Rational 工具来实施RUP提供很多宝贵建议。
4. IT是一座孤岛
“IT遵循了RUP，这就足够了，对吗？”
你所在的IT组织已经决定使用RUP实施一些项目了。项目组的成员都接受RUP的培训，而且拥有必需的工具，并且聘请了一位具有丰富RUP经验的专家，所以现在准备实施了，对吗？你是否考虑过IT外部因素对RUP实施的影响呢？RUP的每一步，系统需求都是利用用例来描述的，最好是根据直接用户提供的资料得到的。但是你的用户做好准备花费时间来建立和审查用例了吗？他们知道什么是用例吗？你的DBA曾经接受过RUP的培训吗？他们准备好用迭代的方法接受数据模型/表变化请求吗？所以要让所有相关的成员知道RUP是怎样影响他们，知道RUP怎样利于项目成功，是很重要的。
