这篇文章实际上是由三篇文章组合而成的。它们为在 IBM® Rational® Unified Process® 或者简称为 RUP® 团队上面应用敏捷策略提供了被证明为行之有效的建议。本文是由 Mark Lines、Joshua Barnes、以及 Julian Holmes 分别撰写的，它们都是 Unified Process Mentors （www.upmentors.com）的共同创办人。这三位已经通过书籍指导了全世界成千上万名软件开发方面的从业者，举办了几十场研讨会，撰写了多部著作，作为咨询顾问和用户组的主席人等。他们工作于遍及世界各地的机构中，将他们的处理过程理论付诸实践，通过实例引导并且通过结构的改变驱动成功。
我的经验是，好的 RUP 就是敏捷的 1 并且包含了许多成功地测量敏捷技术所需要的建议。第一篇文章“将规则引入到敏捷的生命周期之中”是由 Mark Lines 撰写的，它展示了 RUP 需求管理技术和风险驱动开发周期是如何将所需要的规则性水平引入到许多机构中的，并且还不失敏捷方法的特点之一：灵活性。作者认为您并不希望需求在开发周期的后期发生根本上的变更，而前期的一小部分投资能够从根本上减少您的开销、进度、以及整个项目所面临的风险。第二篇文章“在大型机构中将敏捷性引入 RUP 的策略”是由 Joshua Barnes 撰写的，它从一个相反的方向对待软件处理过程中的挑战。它提出了一些快速提高您的基于 RUP 处理过程的方法——许多项目是以头脑中固定的目标开始的，并且在此基础上进行刚性的调整，尽管实际情况是：该团队在项目进展到一半的时候意识到他们能够不再受到固定目标的束缚，因为该目标并不是固定的，而规则也并不是严格的。第三篇文章“地理上分布式的敏捷团队：使个体以及它同处理过程和工具之间的交互发挥作用是由 Julian Holmes 撰写的，它概述了在一个分布式的敏捷团队内部提高协作的策略。在一个项目团队内部完成有效的协作对于一个共处一地的团队是一项很艰巨的挑战，所以就更不用对于一个地理上分布的团队了。Julian 提出开发一个协作团队文化的建议，同时保持方法、交付和管理共享工作产品的一致性。
将规则引入到敏捷的生命周期之中
由 Mark Lines 撰写
敏捷性项目能够被无止境地迭代下去，只有当耗尽预算时该项目才会被结束。在早期迭代和不合理的需求混合中所执行的特性通常是麻烦的制造者。RUP 通过在早期逐出需求的不确定性将结构添加到一个敏捷方法中，并且随着项目的不断推进很自然地绷紧了处理过程的控制。
我在敏捷项目中所看到的一个不适宜的倾向就是项目从一个迭代到另一个迭代，几乎看不到尽头。某些项目经理（PM）好像是忘记了传统的 PM 对于“客户永远是正确的”这一敏捷法则的严格性。这导致从迭代到迭代的持续的需求变更。通常，随着需求条目从本次迭代中的执行栈中移除，相等数量的或者更大数量的工作条目就会被添加回这个栈中。时间和预算被快速地消耗殆尽，而大量待处理的需求依然被留在那里。
RUP 项目的两个阶段
RUP 确实能够在这些情况下帮助团队认识到所有的迭代并不是完全相同的。Walker Royce 将一个项目的开发周期描述为两个阶段。 2 第一个阶段大约占到整个开发周期的 20% 到 40%，它将其称之为 Engineering （工程）阶段。这个阶段是由统一处理过程（UP）的 启始和精化 阶段所组成的。工程阶段表现为项目所有方面的混合，例如：计划、需求、体系结构和代码。这是自然的，也是意料之中的，业务和技术出资方都努力去理解系统的解决方案是什么，以及如何将它实现。
Royce 将开发周期的第二个阶段描述为产品化阶段，它是由 UP 开发周期的构建和产品化 阶段所组成的。它负责使用在前面的工程阶段中被证明为有效的技术来执行剩余的需求（大约 60% 到 80%）。
适应项目期间变更控制的严格性
在工程阶段期间，我们试图避免通过改变控制程序加重用户的负担。反过来，他们也应当严格遵守委托事项，直到团队实现了某些需求为止，因此得到了一个推断严格的委托事项的基本线。将这一行为始终铭记在心中，根据用户的需要（无条件的）在早期迭代中向栈中添加、改变、和区分需求的优先次序。
通过在精化 中增加同软件的风险方面相关的功能性，我们能够移除大量的和项目相关的不确定性，例如：理解和建立这些需求。同需求的不确定性相关的风险能够通过原型、图板、可视化建模、以及规则示范等技术被降低。关于范围和进度的委托事项统称在这个阶段的末尾被期待。这种方法的好处就是相对于传统的瀑布式方法来说，用户会在更晚的时候才被要求提交需求。他们有时间在我们进入严格的变更控制程序之前看到软件的进展情况，Scott Ambler 喜欢将它们称之为“变更防御”程序。
文章来源于领测软件测试网 https://www.ltesting.net/
