| UML软件工程组织 | |||
| |
|||
|
|||
敏捷 RUP：来自实战中的经验
2008-03-28 作者：Mark Lines,Joshua Barnes,Julian Holmes,Scott W. Ambler 来源： IBM
这三篇简短的文章是分别由 IBM Rational 思想领导者们所撰写的，它们描述了为什么 IBM Rational 统一过程或者简称为 RUP 不仅自身是正确的，而且包含了那些需要成功地度量敏捷技术的团队的许多指导方针。 由 Scott W. Ambler 所做的介绍这篇文章实际上是由三篇文章组合而成的。它们为在 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 确实能够在这些情况下帮助团队认识到所有的迭代并不是完全相同的。Walker Royce 将一个项目的开发周期描述为两个阶段。 2 第一个阶段大约占到整个开发周期的 20% 到 40%，它将其称之为 Engineering （工程）阶段。这个阶段是由统一处理过程（UP）的 启始和精化 阶段所组成的。工程阶段表现为项目所有方面的混合，例如：计划、需求、体系结构和代码。这是自然的，也是意料之中的，业务和技术出资方都努力去理解系统的解决方案是什么，以及如何将它实现。 Royce 将开发周期的第二个阶段描述为产品化阶段，它是由 UP 开发周期的构建和产品化 阶段所组成的。它负责使用在前面的工程阶段中被证明为有效的技术来执行剩余的需求（大约 60% 到 80%）。 在工程阶段期间，我们试图避免通过改变控制程序加重用户的负担。反过来，他们也应当严格遵守委托事项，直到团队实现了某些需求为止，因此得到了一个推断严格的委托事项的基本线。将这一行为始终铭记在心中，根据用户的需要（无条件的）在早期迭代中向栈中添加、改变、和区分需求的优先次序。 通过在精化 中增加同软件的风险方面相关的功能性，我们能够移除大量的和项目相关的不确定性，例如：理解和建立这些需求。同需求的不确定性相关的风险能够通过原型、图板、可视化建模、以及规则示范等技术被降低。关于范围和进度的委托事项统称在这个阶段的末尾被期待。这种方法的好处就是相对于传统的瀑布式方法来说，用户会在更晚的时候才被要求提交需求。他们有时间在我们进入严格的变更控制程序之前看到软件的进展情况，Scott Ambler 喜欢将它们称之为“变更防御”程序。 不好的消息就是有时我们仍然需要绷紧变更控制的严格性。不要不切实际的期望 IT 项目交付团队在需求范围不断变更的情况下还能够遵守进度和预算。 我指导团队将一个项目中的精化阶段看作“sandbox”时间。IT 团队利用这段时间指出什么是可行的，以及如何去做。同样地，用户也可以利用这段时间精确地指出他们所希望的是什么。 一旦精化“sandbox” 阶段结束之后，我们就将进入项目的产品化阶段。此时，项目经理需要绷紧变更控制或者无法按要求交付的风险。图 1 描绘了这一增长处理过程控制的概念。请注意：“变更控制的严格性”曲线并不一定如这张图表中所描绘的那样在构建阶段中如此快速地增长。这取决于您的机构核项目的独特方面。对于同用户的契约关系来说，在构建中较早地制定严格的变更控制程序也许是必须的。对于同用户的协作和信任关系来说，您可能将绷紧处理过程控制推迟到构建的后期，并且“变更控制的严格性”曲线也将会向右移动。 
图 1: 随着项目的进展，变更控制的严格性也在不断地加强。 不幸的是，许多“敏捷的 RUP”项目经理并不改变他们的行为，或者设置适当的期望，他们在整个开发周期中总是从一个迭代移动到另一个迭代。 用户通常没有接受过理解跨越 UP 阶段的变更重点的训练，Gary Evans 喜欢将它称之为项目的季节。他们明白在项目的早期他们拥有相当大程度的变更自由度，并且自然地假设这种自由度能够贯穿于项目的始终。我曾经向出资方展示过迭代后的演示模型，意在展示处理过程在向前移动到执行新的需求之前，首先会召开需求引出会议！项目经理有时会将比当前迭代中执行的需求更多的需求添加到未完成的工作单中！这确实是一种十分挫败的体验。 看起来许多接受过不是基于 UP 的敏捷性训练的项目经理并不能够充分地认识到对于增长的变更控制严格性的需要。他们以同样的方式管理每一次迭代，并且不能够设定完全符合用户的期望。 相反，接受过适当培训的用户和分析师能够理解在项目的前期逐出不确定的需求就是他们需要完成的工作，这是因为开发周期后期中的需求改变可能会需要更加严格的变更控制程序。 我经常会被问及我们应当在哪个时间点上回顾需求，并且使我们的用户服从正式的变更需求程序。同 RUP 的灵活性相一致，我们的答案就是“具体情况，具体分析”。理想情况下，在偏向于协作的环境中，答案是“从不”。对于偏向于契约安排的情况，我们需要一种更加正式的方法。尽管我们尽自己的最大努力，需求还是不会在精化结束时尽善尽美，还是将会在构建中发生改变。我对项目经理所提的建议就是当新的范围被添加到构建中的需求栈时，分配一个相对的功能“点”。这种方法同我在图 1 中的“变更控制严格性”中所描述的逐步增加的方式是一致的。在构建的前面几个迭代中，我们能够通过允许用户引入新的范围，直到他们耗尽了他们的偶然点，从而使用户不必受到过多的变更控制的束缚。 总之，我亲眼见证过一些花费了数百万美元的项目在最终实现时仍然距离它们最初的设想有很大的差距。这就是在开发周期后期不佳的处理过程控制，以及只把注意力放在本次迭代上面所造成的结果。请记住和纯粹的敏捷方法所不同的是，RUP 每次迭代并不是处理相同的内容。当我们在整个开发周期中前进的时候，我们需要使用一种适应的项目管理风格才能获得成功。 在大型机构中将敏捷性引入 RUP 的策略由 Joshua Barnes 撰写 更大型的采用 RUP 的机构首先关注它们最普通的项目类型（也就是在周期、资源水平、预算、对业务的危害程度等方面更大型的项目）。这些“更大型的”项目类型通常需要通过控制架构的详细审查，例如：Sarbanes-Oxley （SOX）或者 Control Objectives for Information and related Technology （CobiT 4.0，面向信息及其相关技术的控制目标）。这一处理过程的严格性通常是项目开发周期的一部分，无论它是添加值还是烧钱和时间。在采用 RUP 的早期阶段，这些更大型的项目并不被允许将处理过程优化为更加的敏捷，这是由于其自身的限制所决定的。我经常被问及的一个问题就是：在后期阶段“我们如何能够将更多的处理过程的敏捷性引入我们的项目中？” 根据我的经验，更大型的组织拥有诸如 Internal Audit（内部审计）、External Audit（外部审计） 和 Governance/Compliance （治理/法规遵循）的区域。达成创建一个更加敏捷的“标准”处理过程的版本的共识通常并不容易，并且涉及到哪种类型的工作努力将被准许使用它的问题。某些类别已经开始被典型地使用了，例如：少于‘X’小时的工作努力，或者少于‘Y’美元的预算。 就标准处理过程的一个敏捷版本达成协议的那一天是一个值得庆祝的日子。这些相对较小的工作努力能够将把您所渴望的敏捷性引入到机构中。您期望一旦更多敏捷性的价值得到证明，您就能够将所学到的知识综合起来，运用到使用“标准”处理过程的“更大型的”项目中。下面就是我所遇到过的三个最常见的问题：
您所要做的并不是重新创造车轮，也不应当仅仅是给一个已经存在的处理过程加上一个新的标题。图 2 中将处理过程描述为一个连续统一体，它是由强大的和传统的 RUP 版本为一个机构所裁剪的。 
图 2: 平衡敏捷性和规则性。 首先将您已经存在的用于较大型项目的被裁减过的 RUP 版本作为您最强大和结构化的版本。接下来，看一看较小型的 RUP 版本，例如 OpenUP，作为用于小型团队的最小化的完整的软件开发处理过程。我们的目标就是在您的强大版本中消除无用的和不必要的处理过程花费，使得面小较小型团队和工作努力的处理过程最优化。努力将图 2 中所描述的处理过程连续统一体从右侧移动到左侧，朝向“纯粹的敏捷性”。这是一项平衡的措施——敏捷性对规则性，您只需尽可能地在连续统一体上向左移动，而不会将项目风险增加到一个不可接受的程度。 我所采取的第一个步骤和 RUP 的初始化执行的策略相类似：分析什么将在盒外工作，什么将需要定制，以及什么将不会添加任何值并且能够被移除。 3 分析已经存在的角色、任务和产品，并且移除您所能移除的。请记住：这些处理过程成分能够由偶尔需要他们的团队重新添加回来。回顾残留的任务和产品，识别如何制作它们的简化版本。请注意：这不应当成为一个艰苦的和冗长的处理过程；它的目标是得到一个更小型的和更轻便的初始化处理过程框架，并且通过实际的工作努力验证该决定。请您从会议室中走出来，到实践中修改和完善您所学到的知识。 我经常遇到这种情况：一支处理定义工作的团队被建立起来，会议被预定、里程碑被确定——机构就最终的目标达成了一致。这并不是一种敏捷的方法。尽管这类方法可能代表大多数公司的文化，但是它较之最适宜相距甚远，并且您应当努力避免这种反模式。更糟糕的是，团队经常会过于庞大，这是因为每一个领域都有可能使用新的、小型的处理过程框架潜在的增加工作量。这导致臃肿的团队很难就某件事情作出一致的决定。每个人都声称“自己是不同的”，并且每当作出变更时都会有人提出“这将不适合我们”。 一种被客户端反复地有效处理的方法就是，从整个项目中找到一个在这个“较小型的”范畴中所占比重最大的区域。一个客户端站点拥有一个开发区域，它专门关注一个频繁需要更新的面向外部的网络应用程序。令人惊愕的是，他们拥有一个轻量的处理过程，并且很高兴地同意协作定义一个最小化的处理过程，而这个处理过程的使用完全不会向他们的项目中引入一个不可接受的风险级别。我们能够用几周的时间裁剪一个更小型的、更敏捷的标准处理过程版本。这个版本并不是整个机构中的每个人所最终需要的东西，但是它为我们提供了一个基于实际结果的起步点。这一方法并不能一下子解决所有问题，但是它能够结束没完没了的会议和谈判。 被典型地分配到这些努力的代表通常都拥有“项目经理”或者“领导者”的头衔。这些都是具备丰富经验的高级人员。然而，大多数人却是在很长一段时间里没有从事过开发软件的工作了。他们的角色往往就是从一个会议到另一个会议，表现他们的功能区域以及汇报他们的进展情况、风险和问题。 其结果就是本应在几周内完成的事情现在却需要花上几个月的时间。由于他们不具备使用现已存在的处理过程的经验，所以即使是很小的细节都要在作出任何决定之前进行没完没了的讨论。最后的结果往往就是标准处理过程的一个略微小型的定制版本并没有在实践中为项目团队提供太多的帮助。我曾经看到过这种方法使得公司花费了大量的金钱，但是用户却只得到了很小的投资回报。 制作一个较小型的、更加敏捷的 RUP 版本的团队必须由项目的从业者所组成，这些人已经通过将其所在机构的标准版本的 RUP 使用在实际的项目中从而积累了经验和教训。这些人感到痛苦的原因就在于缺乏处理过程的最优化，以便使得他们能够向出资方提供高质量的、可使用的应用程序。对于一个近期的客户，我们能够选择一些参与过最初的 RUP 项目的团队成员作为我们在这一“领域”中的专家。他们对于处理过程在实际的项目中的管理费用是如何扼杀小型的工作量这一问题提供了深入的见解。某些我们最初在内部审计和依从代表方面所遇到的障碍都将迎刃而解。抽象的讨论一个问题是一回事，实际去做又是另外一回事。当人们亲身经历过现实生活中的痛苦之后，是很难用理论案例来战胜他们的实际需求的。 以上这些只是我所看到的一些机构在试图将敏捷性引入其“标准”的 RUP 的过程中所常见的三个问题。我将在后续的文章中继续展开关于解决/避免这三个问题的讨论。 地理上分布式的敏捷团队：使个体以及它同处理过程和工具之间的交互发挥作用由 Julian Holmes 撰写 许多敏捷的技术和迭代的方法都将项目团队跨学科协作所提出的需求引入到软件开发之中。当我们考虑迭代计划和开发的实践时，当敏捷团队将文档的使用最小化为团队成员之间沟通的方法时，这种协作就变得尤其重要。 这是由于他们这种有效的协作，即小型的同处一地的团队采用每天例会的方法不断地将每个人的努力综合起来，相比地理上分布的团队来说能够更加成功地向客户交付连续的价值。 然而，不同的业务策略和压力能够导致一个机构没有能力以同处一地的方式处理每一个项目。我们可以举出许多这样的例子：
所以一个机构如何才能在分布式的情况下实现潜在的协作和敏捷技术呢？这个问题由于 Dr. Dobb's Journal 于 2007 年所撰写的 Agile Adoption Survey 而尤其引起关注。 4 他发现某些机构正在试图以分布式团队的方式变得敏捷；其中一些获得了成功，然而他们的成功率却低于同处一地的团队。 敏捷的实践为软件开发项目中所需要完成的工作提供了极好的结构化方法。然而，它们几乎都依赖于以一种一致的和高质量的方式执行实际软件开发工作的团队的经验和协作。一旦该团队被分散，保持团队工作的方法、交付、甚至其活动和交付之间沟通的一致性就会成为一个巨大的挑战。 这些团队所面临的大多数挑战都是和保持分布式团队之间的协作这一困难相关的，其中三个关键的挑战就是：
如果说同处一地的项目团队能够有助于培养协作精神的话，那么对于分布式的团队来说，就很难体会到这一点了。 工具的使用可以有助于我们对这一问题的解决。最明显的就是沟通援助，例如：即时消息、电话、视频会议和虚拟工作空间等。然而，这些工具所能提供的价值是有限的，除非每个终端的工作人员对于同其他人员的交流都感到非常舒服。 每个人都知道，如果以前曾经见过面并且建立起某种类型的联系的话，打电话同别人沟通是最容易的了。上面所提到的其他许多沟通工具也大概如此，它们建议一种相对并不明显的“沟通工具”——一种使得团队成员能够面对面交流的传输模式。 尽管到很远的地方出差无论从时间还是从预算的角度来说对于一个项目都是一笔非常大的开销，但是建立沟通、信任和知识共享的好处却是巨大的。然而，远距离的彼此交换也并不是正确的解决方案，所以说我们需要找到这两者之间的平衡点。 除了具有协作性的团队和有效沟通的文化之后，交付项目的工作就成为了下一个我们需要解决的问题。“个体和交互超过处理过程和工具”这一价值对于敏捷团队来说十分重要，一种定义好的处理过程语言和框架确实能够为分布式团队中的个体和交互作用提供帮助。 RUP 提供了一种软件开发语言的过程处理框架，一种标准的统一建模语言（UML）符号，以及一种将选中的处理过程实践和一支完整的项目团队连接起来的方法。在没有一种共同的软件开发语言的情况下，用于活动、交付或者角色的术语或者描述的局部变更将会导致团队成员在职责和期望上的困惑。正是出于这些原因，许多机构决定投资培训它们的员工，为他们提供这种共同的语言。可以通过多种方式达到这一效果。 简单的培训能够为员工提供基本的语言和符号知识，但是并不能提供使用和交流中所必不可少的技巧。供所有人所遵循和使用的额外的标准和模板能够提供一致性，但是无法鼓励交互作用。 最好的方法是请一位指导专家参与到项目之中，使用能够很容易地被项目的出资方和观察着所翻译和理解的共同语言来鼓励所有个体之间的交互作用。这位指导专家还将有助于将处理过程框架裁剪为同项目所涉及的其他机构一致的样子。 所以，如果我们要使用一种类似 RUP 的处理过程架构，就还需要根据环境进行裁剪。可以通过记录 RUP Development Case 中的一套一致性的方法来达到这一效果。但是通过 IBM Rational Method Composer 使用，这种处理过程裁剪能够以 HTML 被更加正式的描述和发布给任何一个团队成员。 尽管一个引入了共同语言和方法的被定义的处理过程有助于分布式团队的活动，但是需要执行的工作量和复杂度仍然是巨大的。特别是当分布式团队必须同时共享和处理同一个交付的时候更是如此。 一支团队无法实时对项目进行回顾和协作的缺陷也会影响项目的质量并且减慢处理过程。团队必须找到一些方式来确保他们的输出能够随时被其他团队成员访问到。或许这样会使分享工作同开发工作一样耗费精力，但是如果项目团队要做到协作、保持质量和快速的驱动处理过程，那么这就是唯一的一种方法。 达到这一效果的一种最简单的方式就是创建一个共同的中央文件库，每个人定期地将他们的工作上传到这里，同整个团队分享。当然这个库需要被很好的组织和管理，但是它确实起到了人员之间共享的作用。然而，由于每个人是分别执行活动来发布自己的工作，所以在花费时间开发之后，还存在其他人不那么自愿进行调整的问题。所以我们需要一种更聪明的加工方法。这就是 IBM Rational 解决方案为分布式的团队提供的极好支持的一个场景。其中包括这些例子：
这些解决方案都已经存在一段时间了，但是 Jazz 项目这种 IBM Research 和 IBM Rational 之间的协作又为分布式团队开发出了新的解决方案。Jazz 所交付的第一个方案就通过提供一个分布式的变更和配置管理解决方案，为项目工作产品的管理提供了机制。然而，Rational Team Concert 还将沟通工具、集成处理过程支持工具和从 Rational Method Composer 中所捕获的方法的处理过程设定的功能性综合在一起。 在分布式的但是敏捷的项目团队的帮助下，当我们已经建立处理过程和工具的需要之后，仍然存在一个问题：在这些解决方案中的投资成本、在它们使用过程中的潜在项目开销、以及项目协作和成功交付的风险，能否被证明对于那些分处异地的团队来说在业务层面上是值得的呢？ 通常的答案都是“是的”，这是因为同处一地的成本和问题都是十分严重的。（如果答案是“不是”的话，那么可能会需要某些严重的业务改变！）所以，上面所提供的联合处理过程和工具解决方案对于大多数机构来说肯定是很有帮助的。 分别思考世界上许多结构正在将一种敏捷的方法用于 RUP，这三篇文章为这种做法提供了很高的见解。尽管敏捷社区中的许多人不愿意承认这一点，但是 RUP 确实普及了许多概念，例如：迭代开发、在每一次迭代中交付工作软件、将测试贯穿于整个开发周期之中，等等。进一步地，RUP 全面地阐述了开发问题，其中包括为了开发系统您所必须解决的许多“小”问题。好的 RUP 就是敏捷的，不过，好的 Agile 就是……RUP 么？ 注释
参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
