【IT168 技术文章】
分布式异地开发是一种能够使业务在位于不同地区、国家或时区的项目团队之间进行合作的软件开发模式。本文通过一个普通的场景举例说明了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也许在未来会选择利用其它分布式开发模型，例如新特性组件开发。
