RUP就像一个药箱或一家药店，我们大部分人可能不会走进一家药店，每一种药都买上一些然后全部服下，我们知道要谨遵医嘱，只服用我们需要的药。有人抱怨说RUP太庞大了，这就好比说药店里的药太多了。真正的问题在于：人们需要更好地了解如何知道自己需要些什么。把风险缓解作为判断依据是确定RUP究竟应该用多少的一个好办法：理解您面临的问题，然后挑选能够帮助解决这些问题的技术(药)。
第五招：回避那些真正懂得迭代式开发的顾问
有一些所谓的专家顾问并没有真正领会迭代式开发以及RUP对瀑布型价值观和先断性做法的根本抛弃。他们所传达的RUP信息是错误的，而且通常夹带着瀑布思维。
为您的第一个RUP迭代项目组建这样一个团队：他们从来没有从事过基于短时间盒的适应性迭代式开发，尤其是那些项目领导者。找到那些执著于瀑布型观点和做法的人。坚决不要与知道如何进行迭代式开发的顾问签约。如果一位经验丰富的顾问不幸参加了这个项目，保证他只能扮演一个配角，对他的建议进行多番辩论、严厉质疑，最终让项目领导拒绝他的想法，而且还要不断奚落他。一定要找这样的人——他们曲解RUP，不露声色地叠加先断性的瀑布观点，例如，认为细化阶段就是为了详绘模型，然后在构造阶段进行实现，或者在项目一开始就计划和分配所有迭代的工作。
第六招：大张旗鼓地实施RUP
如果可能的话，在某一天向整个组织介绍RUP，然后要求所有的项目第二天就照办而不告诉任何人实施的细节。如果这条办不到，那么就对组织进行强制教育，而且只培训那些开发人员,而不包括经理或IT执行主管。如果所有人都必须参加RUP学习，那么尽量在RUP实施前6个月这么做，否则人们就会全然忘了它，然后只好再找一位RUP“导师”提供短期的1天培训来强化瀑布理念。如果必须在培训后马上实施RUP，那么至少应该在全组织内的所有项目上进行实施，同时让所有人立刻切换过来。
千万不要这样做：在一位有经验的教练指导下，通过一个小型的示范项目，尝试采用一批少量的、简单的RUP做法，从实践中学习，逐渐地增加实施内容，在取得第一个项目的基础上再启动第二个。如果某人提出相反意见，就立刻解雇他。请出那些怀疑RUP/迭代、支持瀑布型的人，让他们来负责管理RUP实施项目。
第七招：误解清单
为了确保取得RUP实施中的彻底误解和失败，我们向您提供以下检查清单(评分表)。得分越高，RUP的实施也就越失败：
* 您认为起始阶段 = 需求；细化阶段 = 设计；构造阶段 = 实现。
* 您认为细化阶段的目的是为了完整细致地定义模型，并在构造阶段将它翻译成代码。
* 您认为在细化阶段只需创建原型(事实上，应该在细化阶段针对高风险的架构元素编程实现具有产品级质量的核心子系统)。
* 您试图在开始设计或实现之前定义绝大部分的需求，或者在开始实现之前完成绝大部分的设计。
* 您认为一个合适的迭代长度只能以月为单位来计算，而不是周。
* 您认为编程之前的UML绘图和设计活动阶段是为了完整地、精确地定义极其详尽的设计与模型，认为编程只是简单、机械地把模型翻译成代码。
* 您企图从头至尾详细地计划一个项目，然后把工作分配到每一个迭代；竭尽全力地企图预测所有的迭代以及在每一个迭代中发生的情况。
* 一个组织在进入细化阶段之前，就要求获得可信的计划和估算。
* 一个组织认为实施RUP就意味着从事尽可能多的活动或创建大量的文档，把RUP当作一个有许多步骤需要遵循的规范过程来运用。
我们相信遵照并运用了以上的夺命七招，您的RUP和迭代开发项目实施必将一塌糊涂。
作者简介：
Craig Larman ，国际著名的对象技术顾问和软件过程专家，Valtech咨询集团首席科学家。其经典教材《UML和模式应用》和《敏捷与迭代式开发：管理者指南》已被翻译成多种语言在全球工业界和软件院校当中被广泛采用。
(T111)
