分布式异地开发：GDD生命周期中的一天

分布式异地开发是一种能够使业务在位于不同地区、国家或时区的项目团队之间进行合作的软件开发模式。本文通过一个普通的场景举例说明了GDD 模式是如何在 24 小时周期中运行，这使得假定在印度班加罗尔和美国丹佛的团队协同工作成为一体。 

分布式异地开发（GDD）是一种快速的 IT 策略转换以及横跨或大或小的企业之间软件和系统的开发过程。GDD 包括广泛多样的场景，其中，与软件和系统开发项目有关的人员被扩展至超越常规的单一建筑物或校园环境。典型的 GDD 场景包括分布在不同地理位置的公司――全市范围的、地区的、全国的以及国际间的――同样包括合作伙伴关系以及各种外包关系。成功的 GDD 允许团队以更快的速度、更低的成本开发高质量的软件及系统，并能够得到增强的业务灵活性以及更强的处理全球化竞争压力的能力。 

然而，认识到这些竞争优势的挑战是十分重要的。这其中主要的是需要在由防火墙、距离、时区、国界线、语言及文化－－或是上述所有因素所带来的障碍之间进行准确而清晰的通信。由于管理所有软件开发生命周期多个纬度的需要，在一个分布式环境中通过一个可重复的过程，同时维护有效的安全性，这些问题被进一步地合并在一起 －－例如软件需求、变更及资产、测试、编码等等。 

本文第一部分介绍了GDD以及其业务需求，并展示了 IBM 软件开发平台是如何能够对一个成功的 GDD 策略提供支持得。第一部分同时还论述了核心战略的考虑，例如什么样的项目最适合于一个 GDD 解决方案。 

现在，在第二部分，我用一个示例场景举例展示了关于应用 IBM Rational 工具以支持 GDD 的一些可能性。 

GDD 的布局基础 

正如我在第一部分所讨论的，团队跨越时间以及空间的分布给整个软件和系统开发的周期内带来了挑战并增加了复杂性。而比协同位置团队（也就是，位于下一层或附件建筑物中的团队）的 GDD 场景更大复杂的问题是标准、方法、过程以及最佳实践的实现；组合管理；有效的需求管理；高效的知识及工作传递方法；以及健壮的软件变更管理。日益明显地，开发组织正在转向使用软件工具来帮助他们进行标准化并指导他们的过程，提高团队的协作；考虑到 GDD 场景的复杂性，这些工具的潜在价值就更加重要了。 

每个 GDD 项目中都包含着独特的业务以及涉众需求。这些需求依次定义了工作目标以及子任务职责所处的工作模式。例如，对于一个新系统项目而言，你在GDD环境中所选择的管理需求变更的方法，与关联于第三方的遗留维护合同的管理需求变更方的法将有很大的不同。这就是为什么GDD工具的实施不同于“一种尺寸适合所有需求”的解决方式。为了最优化地支持不同的业务需求，定制产品下层基础平台以及灵活的集成相关工作是必须的，因此GDD场景的支持工具需要是可配置的。 

但是虽然每个GDD项目是不同的，仍然存在着一些公共的部分。在许多GDD场景中，同时关联着本地以及远程开发资源。那些在本地能够最有效运行的规则以及任务有着高度的“面向客户”的活动，例如业务建模、需求定义以及可配置性。而能够高效地在远程执行的工作包括代码开发及测试－－规则主要与开发团队相关而不是应用客户。本地以及远程站点也许都需要他们自己的测试或集成以及变更管理规划。同时虽然总体的项目管理责任处于本地级别，但某些级别的项目管理也许场需要在远程进行。 

网络性能以及服务器基础结构也在很大程度上决定了是否能够良好的对一个GDD项目进行组织。GDD项目经理需要考虑： 

远程站点对数据库服务器的维护、数据存储复制以及类似工作的需求及能力。 

远程用户范围，例如在分开地点的小团队或是在家工作的个体开发者将需要建立、显示、更改以及删除各种不同的项目资产，从需求文档到用例模型，从代码到测试计划。 

远程站点及用户使用“瘦客户端”的潜力，例如 Citrix、Windows Terminal Server（WTS），或是网络客户端。精简客户端可以给分布式团队更大的灵活性及可移动性，但是也许不能支持工具所有的本地接口特性。 

另外，例如网络拓扑以及安全策略会进一步使得配置及开发GDD工具变得更复杂。业务需求及基础结构性能将联合起来帮助对一个特定的GDD环境进行最优化的工具配置。 

一个GDD场景 

在这里所描述的GDD配置场景举例说明了今天 IBM Rational 工具对分布式团队支持方法中的一种。我们假定的用户是 Alcrohm 公司，一个财富1000 强的铝合金供应商。 

问题中的项目包括对一个企业级用户应用软件的正在进行中的维护以及重要的特性增强。关键任务应用是统一用于销售的客户关系管理系统、建议系统和合同管理能力，以及支持 Alcrohm 的所有三个部门（工业产品、客户包装以及自动化部分）中的团队。当前的版本是由一个大部分由C++编写的用户界面的传统桌面型客户/服务器应用软件。Alcrohm不得不在短期时间内继续维护代码。但是，与维护工作相比，Alcrohm计划实现一个新的应用软件版本，这个版本能够通过标准网络浏览器访问，加上Java语言的服务器端代码以及业务逻辑。这个新版本的开发将能够更有效的进行配置以及管理，因为它能够减小客户端安装以及升级的需要。它还将能够与Alcrohm跨越整体IT基础结构的包括面向服务的体系架构（SOA）的长期目标更好地进行吻合。 

这个项目使用每天24小时、每周7天（7×24）的分布式开发模型，包括两个独立的地理场所：位于美国科罗拉多州丹佛的 Alcrohm 中央办公现场内；以及位于印度班加罗尔的海外开发中心。我们称现场的场所为“Site A”，非现场的场所为“Site B”。 

这种GDD场景为 Alcrohm 提供成本以及时间计划上的优势，例如可变化的人员安排、减小国外劳动率，并通过保持项目能够通过“昼夜不停”（也就是说，当位于东半球的开发团队在家或睡觉时，西半球的开发团队是在办公室中工作的）的运作以减小上市时间。但是这些优点的出现同时也增加了风险。这个项目有着很重大的技术困难，这些难题也会检验协同位置的团队有效协作、理解需求、交付高质量成果的能力。Alcrohm 选择了来自 IBM Rational 的强壮的、集成的软件工具以解决这些问题，并支持成功的成果。 

建立任务 

Site A 的室内开发团队集中于新特性开发和相关的测试，同时也包括构建/部署。Site B 的远程转包商承担维护开发、对现存的客户/服务器应用软件进行单元测试任务。这个高层次的职责分解对于什么角色、任务以及最终工具将在每个地点如何运行具有关键的影响。 

在 Site A 执行的任务包括： 

捕获需求、创建需求文档和管理需求 

系统构架及建模 

业务分析及高层次系统设计 

新特性开发 

对预发布的新应用软件的构造进行组件、功能以及系统测试 

对当前应用软件版本的维护版本进行功能及系统测试 

所有构造以及部署活动 

项目和组合管理 

在 Site B 执行的任务包括： 

对当前客户/服务器版本的应用软件代码进行维护 

对代码维护过程中所修正代码的组件进行单元测试 

对维护阶段项目进行构造及修正需求 

在进行了成功的单元测试后是在Site B开发下面维护版本的运行，Site B将代码发送给Site A，Site A执行确认、功能以及系统测试。项目规约以及与现有应用软件的维护版本有关的需求变更、模型和图表在Site A及Site B之间进行通信。项目管理是在Site A处理的核心能力，所有Alcrohm应用软件的组件以及资源组合都在这里进行监控。 

这些强有力的任务划分允许Alcrohm以相对低的风险得到GDD的常规经验，特别是其非现场的合作伙伴。如果所有这些在次一级项目中都进行的很顺利，Alcrohm也许在未来会选择利用其它分布式开发模型，例如新特性组件开发。 

确定资产位置及访问 

现在让我们来看什么资产是在两个站点都需要的。Alcrohm的关键目标是能够在两个站点间引用资产。哪些工具要被使用以及他们如何进行配置将很大程度上取决于关键的开发资产在哪里创建以及他们又将在哪里被使用。 

对两种版本应用软件的需求在Site A被本地的捕获。Site A因此需要对需求的读/写访问，同时包括业务模型以及用例图。对需求特性的更新以及大部分对需求的更改也都将在Site A发生。Site B也需要对需求的读/写访问。因为他们随着时间对现存的应用软件进行维护，Site B的团队将需要增加需求，对现存需求进行修正，对需求文件添加辅助信息，并分配属性，例如优先级、难度以及状态。Site B的团队成员还将需要在需求间跟踪关系的能力，这样，他们可以测量改变的影响。 

虽然两个团队将在不同分支上进行工作，然而两个站点都将需要对共享代码库进行访问。两个站点还需要浏览、创建以及修正变更请求，增加需求以及缺陷报告。 

为了达到这种高等级的共享访问，两个站点需要在本地服务器上对关键数据进行复制。 

配置IBM Rational工具 

当确定了什么资产是在每个站点上都需要的，Alcrohm需要找到一种分配他们的方法。IBM Rational工具为在两个Alcrohm站点间进行通信与协作提供了一个范围广泛的可能。实际上，在这个GDD项目中所使用的产品与很多企业，例如Alcrohm，已经使用的保证在他们更传统的、协同位置开发项目中的高质量产品的工具是相同的： 

IBM Rational Unified Process，或称作RUP － 支持健壮的、迭代的过程。对很多GDD项目来说，包括本场景，最好的方法是首先在规程间建立工作流程，然后配置工具基础来帮助自动化这个工作流程。RUP包括了最佳实践，并提供了支持标准的、集成的以及迭代过程的指导，所有这些对一个分布式团队的成功来说都是极为关键的。RUP也定义了一个共享的词汇表和一个清晰定义的项目任务与责任，所有这些都促进了一个跨越分布式团队的公共视图。并且由于它是基于网络的，RUP很容易支持分布式工作。于是RUP成为使用其它工具的基础。 

IBM Rational ClearCase ―― 用于安全的资产管理以及整体过程控制。没有健壮的、安全的资产管理能力，大部分GDD项目都会承担很大的风险。资产管理保证了只有被授权的人可以浏览或改变项目资产；它还提供了可靠的对被授权用户错误操作事件的恢复能力，例如对源代码文件的意外删除或该写。资产管理进一步为更改控制、审计、重新构建以及从可执行代码或者版本到需求、变更请求等的可回溯追踪性提供了基础。GDD团队需要对资产以及对资产的更改在分布式环境中无缝的协作。同时需要能够在一个项目的不通分支同时工作的能力，通过24×7开发模型加速部署。 

在类似于Alcrohm的GDD场景中，每个分布式开发团队拥有一个数据存储，IBM Rational ClearCase MultiSite为分布式资产管理提供了一个健壮的、可扩展的解决方案。Alcrohm 将利用 Rational ClearCase MultiSite 与 Rational ClearCase 的结合以可靠的复制并同步包括二进制或文本对象的数据存储，从需求至代码、可执行应用以及其中的任何东西。每个站点中的团队成员用他们自己本地的数据存储的副本进行工作，因此WAN或企业内部网性能问题被最小化。特性的分支和合并简化了在多于一个位置中对相同文件所作改变的同步，因此有效地支持了24×7的开发工作周期。多个项目资产副本的存在同样帮助最小化停工、返工以及其它服务器的损耗带来的影响或灾难。IBM Rational ClearCase MultiSite还提供了一个基于浏览器的接口，以允许管理员从他们自己的本地站点管理所有的副本。 

原文转自：http://www.ltesting.net