在大型机构中将敏捷性引入 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 版本为一个机构所裁剪的。
首先将您已经存在的用于较大型项目的被裁减过的 RUP 版本作为您最强大和结构化的版本。接下来，看一看较小型的 RUP 版本，例如 OpenUP，作为用于小型团队的最小化的完整的软件开发处理过程。我们的目标就是在您的强大版本中消除无用的和不必要的处理过程花费，使得面小较小型团队和工作努力的处理过程最优化。努力将图 2 中所描述的处理过程连续统一体从右侧移动到左侧，朝向“纯粹的敏捷性”。这是一项平衡的措施——敏捷性对规则性，您只需尽可能地在连续统一体上向左移动，而不会将项目风险增加到一个不可接受的程度。
我所采取的第一个步骤和 RUP 的初始化执行的策略相类似：分析什么将在盒外工作，什么将需要定制，以及什么将不会添加任何值并且能够被移除。 3 分析已经存在的角色、任务和产品，并且移除您所能移除的。请记住：这些处理过程成分能够由偶尔需要他们的团队重新添加回来。回顾残留的任务和产品，识别如何制作它们的简化版本。请注意：这不应当成为一个艰苦的和冗长的处理过程；它的目标是得到一个更小型的和更轻便的初始化处理过程框架，并且通过实际的工作努力验证该决定。请您从会议室中走出来，到实践中修改和完善您所学到的知识。
问题之二：工作团队过于庞大
我经常遇到这种情况：一支处理定义工作的团队被建立起来，会议被预定、里程碑被确定——机构就最终的目标达成了一致。这并不是一种敏捷的方法。尽管这类方法可能代表大多数公司的文化，但是它较之最适宜相距甚远，并且您应当努力避免这种反模式。更糟糕的是，团队经常会过于庞大，这是因为每一个领域都有可能使用新的、小型的处理过程框架潜在的增加工作量。这导致臃肿的团队很难就某件事情作出一致的决定。每个人都声称“自己是不同的”，并且每当作出变更时都会有人提出“这将不适合我们”。
一种被客户端反复地有效处理的方法就是，从整个项目中找到一个在这个“较小型的”范畴中所占比重最大的区域。一个客户端站点拥有一个开发区域，它专门关注一个频繁需要更新的面向外部的网络应用程序。令人惊愕的是，他们拥有一个轻量的处理过程，并且很高兴地同意协作定义一个最小化的处理过程，而这个处理过程的使用完全不会向他们的项目中引入一个不可接受的风险级别。我们能够用几周的时间裁剪一个更小型的、更敏捷的标准处理过程版本。这个版本并不是整个机构中的每个人所最终需要的东西，但是它为我们提供了一个基于实际结果的起步点。这一方法并不能一下子解决所有问题，但是它能够结束没完没了的会议和谈判。
问题之三：工作团队的成员缺乏近期的经验
被典型地分配到这些努力的代表通常都拥有“项目经理”或者“领导者”的头衔。这些都是具备丰富经验的高级人员。然而，大多数人却是在很长一段时间里没有从事过开发软件的工作了。他们的角色往往就是从一个会议到另一个会议，表现他们的功能区域以及汇报他们的进展情况、风险和问题。
其结果就是本应在几周内完成的事情现在却需要花上几个月的时间。由于他们不具备使用现已存在的处理过程的经验，所以即使是很小的细节都要在作出任何决定之前进行没完没了的讨论。最后的结果往往就是标准处理过程的一个略微小型的定制版本并没有在实践中为项目团队提供太多的帮助。我曾经看到过这种方法使得公司花费了大量的金钱，但是用户却只得到了很小的投资回报。
制作一个较小型的、更加敏捷的 RUP 版本的团队必须由项目的从业者所组成，这些人已经通过将其所在机构的标准版本的 RUP 使用在实际的项目中从而积累了经验和教训。这些人感到痛苦的原因就在于缺乏处理过程的最优化，以便使得他们能够向出资方提供高质量的、可使用的应用程序。对于一个近期的客户，我们能够选择一些参与过最初的 RUP 项目的团队成员作为我们在这一“领域”中的专家。他们对于处理过程在实际的项目中的管理费用是如何扼杀小型的工作量这一问题提供了深入的见解。某些我们最初在内部审计和依从代表方面所遇到的障碍都将迎刃而解。抽象的讨论一个问题是一回事，实际去做又是另外一回事。当人们亲身经历过现实生活中的痛苦之后，是很难用理论案例来战胜他们的实际需求的。
以上这些只是我所看到的一些机构在试图将敏捷性引入其“标准”的 RUP 的过程中所常见的三个问题。我将在后续的文章中继续展开关于解决/避免这三个问题的讨论。
地理上分布式的敏捷团队：使个体以及它同处理过程和工具之间的交互发挥作用
由 Julian Holmes 撰写
许多敏捷的技术和迭代的方法都将项目团队跨学科协作所提出的需求引入到软件开发之中。当我们考虑迭代计划和开发的实践时，当敏捷团队将文档的使用最小化为团队成员之间沟通的方法时，这种协作就变得尤其重要。
这是由于他们这种有效的协作，即小型的同处一地的团队采用每天例会的方法不断地将每个人的努力综合起来，相比地理上分布的团队来说能够更加成功地向客户交付连续的价值。
然而，不同的业务策略和压力能够导致一个机构没有能力以同处一地的方式处理每一个项目。我们可以举出许多这样的例子：
办公室空间的限制；
所需要的专业技术不能由本地所提供；
客户和项目位于不同的地方；
外包策略利用了第三方提供商所提供的特定技巧集；
海外发展策略打破了远和近的界限；
等等……
所以一个机构如何才能在分布式的情况下实现潜在的协作和敏捷技术呢？这个问题由于 Dr. Dobb's Journal 于 2007 年所撰写的 Agile Adoption Survey 而尤其引起关注。 4 他发现某些机构正在试图以分布式团队的方式变得敏捷；其中一些获得了成功，然而他们的成功率却低于同处一地的团队。
敏捷的实践为软件开发项目中所需要完成的工作提供了极好的结构化方法。然而，它们几乎都依赖于以一种一致的和高质量的方式执行实际软件开发工作的团队的经验和协作。一旦该团队被分散，保持团队工作的方法、交付、甚至其活动和交付之间沟通的一致性就会成为一个巨大的挑战。
