敏捷 RUP：来自实战中的经验

发布: 2008-10-31 16:14 | 作者: Mark Lines 等 | 来源: 测试时代采编 | 查看: 88次 | 进入软件测试论坛讨论

如何开发一个协作的团队文化

如果说同处一地的项目团队能够有助于培养协作精神的话，那么对于分布式的团队来说，就很难体会到这一点了。

工具的使用可以有助于我们对这一问题的解决。最明显的就是沟通援助，例如：即时消息、电话、视频会议和虚拟工作空间等。然而，这些工具所能提供的价值是有限的，除非每个终端的工作人员对于同其他人员的交流都感到非常舒服。

每个人都知道，如果以前曾经见过面并且建立起某种类型的联系的话，打电话同别人沟通是最容易的了。上面所提到的其他许多沟通工具也大概如此，它们建议一种相对并不明显的“沟通工具”——一种使得团队成员能够面对面交流的传输模式。

尽管到很远的地方出差无论从时间还是从预算的角度来说对于一个项目都是一笔非常大的开销，但是建立沟通、信任和知识共享的好处却是巨大的。然而，远距离的彼此交换也并不是正确的解决方案，所以说我们需要找到这两者之间的平衡点。

如何保持方法和交付的一致性

除了具有协作性的团队和有效沟通的文化之后，交付项目的工作就成为了下一个我们需要解决的问题。“个体和交互超过处理过程和工具”这一价值对于敏捷团队来说十分重要，一种定义好的处理过程语言和框架确实能够为分布式团队中的个体和交互作用提供帮助。

RUP 提供了一种软件开发语言的过程处理框架，一种标准的统一建模语言（UML）符号，以及一种将选中的处理过程实践和一支完整的项目团队连接起来的方法。在没有一种共同的软件开发语言的情况下，用于活动、交付或者角色的术语或者描述的局部变更将会导致团队成员在职责和期望上的困惑。正是出于这些原因，许多机构决定投资培训它们的员工，为他们提供这种共同的语言。可以通过多种方式达到这一效果。

简单的培训能够为员工提供基本的语言和符号知识，但是并不能提供使用和交流中所必不可少的技巧。供所有人所遵循和使用的额外的标准和模板能够提供一致性，但是无法鼓励交互作用。

最好的方法是请一位指导专家参与到项目之中，使用能够很容易地被项目的出资方和观察着所翻译和理解的共同语言来鼓励所有个体之间的交互作用。这位指导专家还将有助于将处理过程框架裁剪为同项目所涉及的其他机构一致的样子。

所以，如果我们要使用一种类似 RUP 的处理过程架构，就还需要根据环境进行裁剪。可以通过记录 RUP Development Case 中的一套一致性的方法来达到这一效果。但是通过 IBM Rational Method Composer 使用，这种处理过程裁剪能够以 HTML 被更加正式的描述和发布给任何一个团队成员。

如何管理共享工作产品的开发

尽管一个引入了共同语言和方法的被定义的处理过程有助于分布式团队的活动，但是需要执行的工作量和复杂度仍然是巨大的。特别是当分布式团队必须同时共享和处理同一个交付的时候更是如此。

一支团队无法实时对项目进行回顾和协作的缺陷也会影响项目的质量并且减慢处理过程。团队必须找到一些方式来确保他们的输出能够随时被其他团队成员访问到。或许这样会使分享工作同开发工作一样耗费精力，但是如果项目团队要做到协作、保持质量和快速的驱动处理过程，那么这就是唯一的一种方法。

达到这一效果的一种最简单的方式就是创建一个共同的中央文件库，每个人定期地将他们的工作上传到这里，同整个团队分享。当然这个库需要被很好的组织和管理，但是它确实起到了人员之间共享的作用。然而，由于每个人是分别执行活动来发布自己的工作，所以在花费时间开发之后，还存在其他人不那么自愿进行调整的问题。所以我们需要一种更聪明的加工方法。这就是 IBM Rational 解决方案为分布式的团队提供的极好支持的一个场景。其中包括这些例子：

IBM Rational ClearCase® 和 IBM Rational ClearQuest® —— Configuration Management （配置管理）和 Change Management （变更管理）库能够分布于多个站点，或者通过 HTTP 来访问，使得团队中每个成员能够访问所有工作产品以及他们进行创造和修改的原因。
IBM Rational Software Modeler 和 IBM Rational Software Architect —— 捕获单个模型中的 UML 图表，它同 ClearCase 的完全综合能够使同一个模型集中的并发的分布式工作变得有效。
IBM Rational RequisitePro® —— 管理一个共同库中的项目需求，可以追溯该模型，并且通过 Eclipse IDE 或者一个 HTTP 客户端对其进行访问。

这些解决方案都已经存在一段时间了，但是 Jazz 项目这种 IBM Research 和 IBM Rational 之间的协作又为分布式团队开发出了新的解决方案。Jazz 所交付的第一个方案就通过提供一个分布式的变更和配置管理解决方案，为项目工作产品的管理提供了机制。然而，Rational Team Concert 还将沟通工具、集成处理过程支持工具和从 Rational Method Composer 中所捕获的方法的处理过程设定的功能性综合在一起。

敏捷的、分布式的，并且是 RUP 的

在分布式的但是敏捷的项目团队的帮助下，当我们已经建立处理过程和工具的需要之后，仍然存在一个问题：在这些解决方案中的投资成本、在它们使用过程中的潜在项目开销、以及项目协作和成功交付的风险，能否被证明对于那些分处异地的团队来说在业务层面上是值得的呢？

通常的答案都是“是的”，这是因为同处一地的成本和问题都是十分严重的。（如果答案是“不是”的话，那么可能会需要某些严重的业务改变！）所以，上面所提供的联合处理过程和工具解决方案对于大多数机构来说肯定是很有帮助的。

分别思考

世界上许多结构正在将一种敏捷的方法用于 RUP，这三篇文章为这种做法提供了很高的见解。尽管敏捷社区中的许多人不愿意承认这一点，但是 RUP 确实普及了许多概念，例如：迭代开发、在每一次迭代中交付工作软件、将测试贯穿于整个开发周期之中，等等。进一步地，RUP 全面地阐述了开发问题，其中包括为了开发系统您所必须解决的许多“小”问题。好的 RUP 就是敏捷的，不过，好的 Agile 就是……RUP 么？