第三招：忽视对象技术技能
RUP的直接目标在于开发面向对象系统。多年来，我们观察到许多对象技术项目失败或遇到严重的挫折，一个普遍的问题是缺乏真正地能以对象方式思考，熟练掌握对象设计、对象模式和面向对象编程的人员。拥有技艺精湛的OT开发人员是一个绝对优先的关键成功因素，而采用RUP或其他过程则相对次要。正如Grady Booch所言，“人远比过程重要”。
因此，如果要让RUP实施真正失败，就可忽视聘用或培养那些拥有出色对象技能的人员。真正有实效的OT培养并非指先有一个星期的Java技术课程，然后是一个星期的面向对象分析设计课程，而是需要向软件工程师提供半年内大至八周的、有老师精心指导的培训，之后还需要一年左右的专家辅导巩固期。
对象技术开发技能绝非小菜一碟，成功的对象设计与编程需要受过良好训练的开发人员。确保项目失败的绝好办法可以是：不必大量投入来聘用或培养熟练的对象技术人才，或者让技能生疏的工程师勉强过关以减少这方面的投入。我们还要强调加强对象设计与设计模式技能和培养的必要性，不能仅仅关注对象编程。
第四招：贬低适应性、迭代式开发
在RUP的核心理念和非常好的实践(管理需求、迭代式开发、控制变更、校验质量、基于架构和构件的设计)中，迭代式开发的地位是最突出的。对于正从瀑布式价值观和实践上开始转变的组织而言，迭代式开发就像一场革命。事实上，在对待开发软件思考的许多层面上，如果向RUP转变的一个组织没有经历一场深刻甚至痛苦的变革，那么通常说明他们没有“把握”迭代式开发并真正地采用它。
错误一：信奉刚性和先断性观点
这种观点的含义即企图冻结需求和设计，而非拥抱变化；试图计划未来所有的迭代，而不是适应性地调整。瀑布模型对如何处理变化存在着尤为明显的偏见。在某种程度上，整个瀑布方法可以被视为大体上是反对变化的——一旦需求被“批准”(冻结)，即便后来发现某个需求是错误的，仍然需要特别费力地改变它。
错误二：颠倒迭代式开发的做法
项目经理似乎喜欢瀑布型生命周期那种表面上“明显”的稳定性和确定性，问题在于它们具有欺骗性——只有通过测试，才能评估对事物真伪的预先假定；只有通过实现，才能知道一个任务到底需要多少工作量。在项目当中，我们其实都在玩一个游戏——我们作出假设，猜想事物会是什么样子，解决方案将如何。然而事实上，我们的工作是基于不完善的信息。
聪明的项目经理通过设置许多检查点来验证先前的假定：布置了收集信息的任务，想方设法地抓住各种机会，利用新获取的信息来调整计划。迭代方法允许人们收集信息，通过迭代来改进计划，甚至改变方向。瀑布方法最大的错误可能在于，计划的制定脱离了现实，而且即使当收集到新的信息时，这种计划也不能被更新，改变计划被认为是预测未来行为的一种失败。然而调整计划并非预测的失败，相反是一次改进的机会。
错误三：没有让干系人了解迭代式开发的意义
客户认为转交了项目的需求，他们就可以袖手旁观，直到完整的产品被交付。管理者也已经习惯性地认为，他们可以期待在项目的第一天就能制定完美的计划，然后按部就班地执行，而且几乎不需要什么调查、试验编程或概念验证，就可以获得可靠的估算。如果一个项目失败了，他们会认为，不是因为计划错误，而是因为计划没有得到执行，或者是由不称职的计划或估算人员造成的，而这种思维恰恰是让管理者招致恶名的一个原因。
为了让迭代开发发挥作用，客户必须参与其中。迭代式开发的精髓是根据反馈进行及时调整，而不是预先揣测。如果客户不感兴趣，不积极参与以确保构建了他们要求和需要的系统，那么他们必将自食其果。软件开发最难的部分在于构建“对”的东西，让功能和易用性真实有效。开发人员很少是领域专家，他们需要获得帮助来理解解决问题需要些什么，以及如何来构建“对”的系统，而瀑布方法剥夺了开发团队与客户之间有意义的交流。客户应该在定义需要开发些什么的任务当中扮演积极的角色。非常好的的做法是在开发人员与用户/客户的协作之下，从理解需要解决的问题开始，并以一种演进的方式来探查问题(包括机遇和挑战)。迭代方法提供了对于这类开发来说非常关键的适应性反馈。
错误四：过度建模并创建了很多低价值的工件
RUP是一个能够解决许多不同问题的框架。然而，您不太可能在项目中使用RUP全部的内容。迭代式开发的观点是为了获得实际的反馈，当只获得一部分需求或设计时，就尽快开始编程，而不是停滞于对需求和设计的百般揣测。因此，一种有效的让RUP和迭代失败的方法是创建所有的RUP文档，并试图用最大的精度来细化它们，在编程之前至少画上N页的UML图。
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和迭代开发项目实施必将一塌糊涂。
