【IT168 技术文章】

    这三篇简短的文章是分别由 IBM Rational 思想领导者们所撰写的，它们描述了为什么 IBM Rational 统一过程或者简称为 RUP 不仅自身是正确的，而且包含了那些需要成功地度量敏捷技术的团队的许多指导方针。

    由 Scott W. Ambler 所做的介绍

    这篇文章实际上是由三篇文章组合而成的。它们为在 IBM? Rational? Unified Process? 或者简称为 RUP? 团队上面应用敏捷策略提供了被证明为行之有效的建议。本文是由 Mark Lines、Joshua Barnes、以及 Julian Holmes 分别撰写的，它们都是 Unified Process Mentors的共同创办人。这三位已经通过书籍指导了全世界成千上万名软件开发方面的从业者，举办了几十场研讨会，撰写了多部著作，作为咨询顾问和用户组的主席人等。他们工作于遍及世界各地的机构中，将他们的处理过程理论付诸实践，通过实例引导并且通过结构的改变驱动成功。

    我的经验是，好的 RUP 就是敏捷的 1 并且包含了许多成功地测量敏捷技术所需要的建议。第一篇文章“将规则引入到敏捷的生命周期之中”是由 Mark Lines 撰写的，它展示了 RUP 需求管理技术和风险驱动开发周期是如何将所需要的规则性水平引入到许多机构中的，并且还不失敏捷方法的特点之一：灵活性。作者认为您并不希望需求在开发周期的后期发生根本上的变更，而前期的一小部分投资能够从根本上减少您的开销、进度、以及整个项目所面临的风险。第二篇文章“在大型机构中将敏捷性引入 RUP 的策略”是由 Joshua Barnes 撰写的，它从一个相反的方向对待软件处理过程中的挑战。它提出了一些快速提高您的基于 RUP 处理过程的方法——许多项目是以头脑中固定的目标开始的，并且在此基础上进行刚性的调整，尽管实际情况是：该团队在项目进展到一半的时候意识到他们能够不再受到固定目标的束缚，因为该目标并不是固定的，而规则也并不是严格的。第三篇文章“地理上分布式的敏捷团队：使个体以及它同处理过程和工具之间的交互发挥作用是由 Julian Holmes 撰写的，它概述了在一个分布式的敏捷团队内部提高协作的策略。在一个项目团队内部完成有效的协作对于一个共处一地的团队是一项很艰巨的挑战，所以就更不用对于一个地理上分布的团队了。Julian 提出开发一个协作团队文化的建议，同时保持方法、交付和管理共享工作产品的一致性。

    将规则引入到敏捷的生命周期之中 

    敏捷性项目能够被无止境地迭代下去，只有当耗尽预算时该项目才会被结束。在早期迭代和不合理的需求混合中所执行的特性通常是麻烦的制造者。RUP 通过在早期逐出需求的不确定性将结构添加到一个敏捷方法中，并且随着项目的不断推进很自然地绷紧了处理过程的控制。

    我在敏捷项目中所看到的一个不适宜的倾向就是项目从一个迭代到另一个迭代，几乎看不到尽头。某些项目经理（PM）好像是忘记了传统的 PM 对于“客户永远是正确的”这一敏捷法则的严格性。这导致从迭代到迭代的持续的需求变更。通常，随着需求条目从本次迭代中的执行栈中移除，相等数量的或者更大数量的工作条目就会被添加回这个栈中。时间和预算被快速地消耗殆尽，而大量待处理的需求依然被留在那里。

    RUP 项目的两个阶段

    RUP 确实能够在这些情况下帮助团队认识到所有的迭代并不是完全相同的。Walker Royce 将一个项目的开发周期描述为两个阶段。 2 第一个阶段大约占到整个开发周期的 20% 到 40%，它将其称之为 Engineering （工程）阶段。这个阶段是由统一处理过程（UP）的 启始和精化 阶段所组成的。工程阶段表现为项目所有方面的混合，例如：计划、需求、体系结构和代码。这是自然的，也是意料之中的，业务和技术出资方都努力去理解系统的解决方案是什么，以及如何将它实现。

    Royce 将开发周期的第二个阶段描述为产品化阶段，它是由 UP 开发周期的构建和产品化 阶段所组成的。它负责使用在前面的工程阶段中被证明为有效的技术来执行剩余的需求（大约 60% 到 80%）。

    适应项目期间变更控制的严格性

    在工程阶段期间，我们试图避免通过改变控制程序加重用户的负担。反过来，他们也应当严格遵守委托事项，直到团队实现了某些需求为止，因此得到了一个推断严格的委托事项的基本线。将这一行为始终铭记在心中，根据用户的需要（无条件的）在早期迭代中向栈中添加、改变、和区分需求的优先次序。

    通过在精化 中增加同软件的风险方面相关的功能性，我们能够移除大量的和项目相关的不确定性，例如：理解和建立这些需求。同需求的不确定性相关的风险能够通过原型、图板、可视化建模、以及规则示范等技术被降低。关于范围和进度的委托事项统称在这个阶段的末尾被期待。这种方法的好处就是相对于传统的瀑布式方法来说，用户会在更晚的时候才被要求提交需求。他们有时间在我们进入严格的变更控制程序之前看到软件的进展情况，Scott Ambler 喜欢将它们称之为“变更防御”程序。

    不好的消息就是有时我们仍然需要绷紧变更控制的严格性。不要不切实际的期望 IT 项目交付团队在需求范围不断变更的情况下还能够遵守进度和预算。

    我指导团队将一个项目中的精化阶段看作“sandbox”时间。IT 团队利用这段时间指出什么是可行的，以及如何去做。同样地，用户也可以利用这段时间精确地指出他们所希望的是什么。

    一旦精化“sandbox” 阶段结束之后，我们就将进入项目的产品化阶段。此时，项目经理需要绷紧变更控制或者无法按要求交付的风险。图 1 描绘了这一增长处理过程控制的概念。请注意：“变更控制的严格性”曲线并不一定如这张图表中所描绘的那样在构建阶段中如此快速地增长。这取决于您的机构核项目的独特方面。对于同用户的契约关系来说，在构建中较早地制定严格的变更控制程序也许是必须的。对于同用户的协作和信任关系来说，您可能将绷紧处理过程控制推迟到构建的后期，并且“变更控制的严格性”曲线也将会向右移动。

    教育我们的出资方是一个关键问题

    不幸的是，许多“敏捷的 RUP”项目经理并不改变他们的行为，或者设置适当的期望，他们在整个开发周期中总是从一个迭代移动到另一个迭代。

    用户通常没有接受过理解跨越 UP 阶段的变更重点的训练，Gary Evans 喜欢将它称之为项目的季节。他们明白在项目的早期他们拥有相当大程度的变更自由度，并且自然地假设这种自由度能够贯穿于项目的始终。我曾经向出资方展示过迭代后的演示模型，意在展示处理过程在向前移动到执行新的需求之前，首先会召开需求引出会议！项目经理有时会将比当前迭代中执行的需求更多的需求添加到未完成的工作单中！这确实是一种十分挫败的体验。

    看起来许多接受过不是基于 UP 的敏捷性训练的项目经理并不能够充分地认识到对于增长的变更控制严格性的需要。他们以同样的方式管理每一次迭代，并且不能够设定完全符合用户的期望。

    相反，接受过适当培训的用户和分析师能够理解在项目的前期逐出不确定的需求就是他们需要完成的工作，这是因为开发周期后期中的需求改变可能会需要更加严格的变更控制程序。

    我经常会被问及我们应当在哪个时间点上回顾需求，并且使我们的用户服从正式的变更需求程序。同 RUP 的灵活性相一致，我们的答案就是“具体情况，具体分析”。理想情况下，在偏向于协作的环境中，答案是“从不”。对于偏向于契约安排的情况，我们需要一种更加正式的方法。尽管我们尽自己的最大努力，需求还是不会在精化结束时尽善尽美，还是将会在构建中发生改变。我对项目经理所提的建议就是当新的范围被添加到构建中的需求栈时，分配一个相对的功能“点”。这种方法同我在图 1 中的“变更控制严格性”中所描述的逐步增加的方式是一致的。在构建的前面几个迭代中，我们能够通过允许用户引入新的范围，直到他们耗尽了他们的偶然点，从而使用户不必受到过多的变更控制的束缚。

    总之，我亲眼见证过一些花费了数百万美元的项目在最终实现时仍然距离它们最初的设想有很大的差距。这就是在开发周期后期不佳的处理过程控制，以及只把注意力放在本次迭代上面所造成的结果。请记住和纯粹的敏捷方法所不同的是，RUP 每次迭代并不是处理相同的内容。当我们在整个开发周期中前进的时候，我们需要使用一种适应的项目管理风格才能获得成功。