Scrum与RUP的结合
现在使用RUP的软件项目可以很容易地从Scrum原则中获益，即使已经开始的项目也是如此。首先需要调研的是RUP过程模型，Scrum如何影响RUP最好的实践活动，四个阶段（初始，细化，构建和产品化），以及RUP的九个原则。RUP各阶段和原则之间的关系如图一所示。
图一：左边列出的是RUP的各个原则，与项目的四个阶段相关联。
尽管大多数原则与各个阶段都相关，上图表示出了在各个阶段中原则的不同的相关度。
RUP：软件开发的非常好的实践
让我们从RUP过程框架的六个非常好的实践开始吧。
迭代开发
Scrum项目强制执行迭代的开发过程，以30天为一个合适的开发时长。尽管在对“迭代”的定义上RUP更为灵活，30天的限定仍然经常被RUP使用，并且已被认为是一个有效的长度。工作总是按照30天的“疾跑”排列下来的，而不是定义一个RUP项目的一次迭代的长度。
管理需求
整个团队都可以管理需求，但是需求的控制权是由产品所有者掌握的。在RUP中，需求工程师对需求负责，但在Scrum中，这一责任属于产品所有者，通常表现为商业风险承担者。在RUP中，需求管理需要通过协作完成。
使用模块构建
体系架构是由公司的开发策略和指导决定的，或者由团队自身提出。RUP倡导的以体系架构为核心的方法导致了对各种应用结构的仔细考虑和选择。在Scrum中，这一定义较松，并决定于发布给团队的指导和标准。很多灵活的软件项目使用现代软件工具和编程语言，比如，模块构建占主导的技术。
可视化模型
RUP提倡可视化模型。甚至RUP框架本身就是可视的，有很多UML的外壳。和RUP一样，Scrum虽然不要求开发团队建构某一特定的可视化组件，但是委派Scrum团队完成这项工作。关于使用哪种组件，使用到何种程度和质量，取决于既定的“疾跑”目标。由于UML在工业界的广泛认可，很多工业专家都使用可视化技术，并且在RUP和Scrum中，可视化模型的使用都是很普遍的。
持续的保证质量
迭代，递增的开发已经为每个软件项目的质量和进展提供了很好的度量手段。Scrum团队完全集中于他们的“疾跑”目标，在30天的周期内必须展示工作成果。在这种方式下，功能是用一种重复的方式测试，度量和展示的。但是在大型组织中，质量控制是从各种角度观察的，而且需要更高质量管理的程序。Scrum可以从RUP的质量保证计划中获益，该计划由项目管理者控制，是成功的迭代开发的重要组成部分。
管理变更
在任何现代软件开发项目中都会出现变更（变化应该是受到欢迎的！），但是Scrum管理者不会为了引入发生在达成共识的目标上的变更而打断一个“疾跑”周期。他们抓住需要的变化，在本次“疾跑”结束时提出它们作为下一系列目标的一部分。这对Scrum的“疾跑”来说是最关键的。团队与外界隔离开工作，不予许变化影响当前的“疾跑”。否则，迭代开发的领域（“疾跑”的目标）的不断调整将会导致团队失去中心，不能很好完成疾跑伊始确定的功能目标。
