第四招：贬低适应性、迭代式开发

在RUP的核心理念和非常好的实践(管理需求、迭代式开发、控制变更、校验质量、基于架构和构件的设计)中，迭代式开发的地位是最突出的。对于正从瀑布式价值观和实践上开始转变的组织而言，迭代式开发就像一场革命。事实上，在对待开发软件思考的许多层面上，如果向RUP转变的一个组织没有经历一场深刻甚至痛苦的变革，那么通常说明他们没有“把握”迭代式开发并真正地采用它。

错误一：信奉刚性和先断性观点

这种观点的含义即企图冻结需求和设计，而非拥抱变化；试图计划未来所有的迭代，而不是适应性地调整。瀑布模型对如何处理变化存在着尤为明显的偏见。在某种程度上，整个瀑布方法可以被视为大体上是反对变化的——一旦需求被“批准”(冻结)，即便后来发现某个需求是错误的，仍然需要特别费力地改变它。

错误二：颠倒迭代式开发的做法

项目经理似乎喜欢瀑布型生命周期那种表面上“明显”的稳定性和确定性，问题在于它们具有欺骗性——只有通过测试，才能评估对事物真伪的预先假定；只有通过实现，才能知道一个任务到底需要多少工作量。在项目当中，我们其实都在玩一个游戏——我们作出假设，猜想事物会是什么样子，解决方案将如何。然而事实上，我们的工作是基于不完善的信息。

聪明的项目经理通过设置许多检查点来验证先前的假定：布置了收集信息的任务，想方设法地抓住各种机会，利用新获取的信息来调整计划。迭代方法允许人们收集信息，通过迭代来改进计划，甚至改变方向。瀑布方法最大的错误可能在于，计划的制定脱离了现实，而且即使当收集到新的信息时，这种计划也不能被更新，改变计划被认为是预测未来行为的一种失败。然而调整计划并非预测的失败，相反是一次改进的机会。

错误三：没有让干系人了解迭代式开发的意义

客户认为转交了项目的需求，他们就可以袖手旁观，直到完整的产品被交付。管理者也已经习惯性地认为，他们可以期待在项目的第一天就能制定完美的计划，然后按部就班地执行，而且几乎不需要什么调查、试验编程或概念验证，就可以获得可靠的估算。如果一个项目失败了，他们会认为，不是因为计划错误，而是因为计划没有得到执行，或者是由不称职的计划或估算人员造成的，而这种思维恰恰是让管理者招致恶名的一个原因。

为了让迭代开发发挥作用，客户必须参与其中。迭代式开发的精髓是根据反馈进行及时调整，而不是预先揣测。如果客户不感兴趣，不积极参与以确保构建了他们要求和需要的系统，那么他们必将自食其果。软件开发最难的部分在于构建“对”的东西，让功能和易用性真实有效。开发人员很少是领域专家，他们需要获得帮助来理解解决问题需要些什么，以及如何来构建“对”的系统，而瀑布方法剥夺了开发团队与客户之间有意义的交流。客户应该在定义需要开发些什么的任务当中扮演积极的角色。非常好的的做法是在开发人员与用户/客户的协作之下，从理解需要解决的问题开始，并以一种演进的方式来探查问题(包括机遇和挑战)。迭代方法提供了对于这类开发来说非常关键的适应性反馈。

错误四：过度建模并创建了很多低价值的工件

RUP是一个能够解决许多不同问题的框架。然而，您不太可能在项目中使用RUP全部的内容。迭代式开发的观点是为了获得实际的反馈，当只获得一部分需求或设计时，就尽快开始编程，而不是停滞于对需求和设计的百般揣测。因此，一种有效的让RUP和迭代失败的方法是创建所有的RUP文档，并试图用最大的精度来细化它们，在编程之前至少画上N页的UML图。

RUP就像一个药箱或一家药店，我们大部分人可能不会走进一家药店，每一种药都买上一些然后全部服下，我们知道要谨遵医嘱，只服用我们需要的药。有人抱怨说RUP太庞大了，这就好比说药店里的药太多了。真正的问题在于：人们需要更好地了解如何知道自己需要些什么。把风险缓解作为判断依据是确定RUP究竟应该用多少的一个好办法：理解您面临的问题，然后挑选能够帮助解决这些问题的技术(药)。