内容


全球化软件开发与交付:趋势与挑战

Comments

插图本文是探究当全球化开发和交付(global development and delivery,GDD)应用于软件开发时,它的各种方面的系列文章中的第一篇。GDD 是跨多地点生成软件应用程序的开发活动的协调,以及跨越为那些应用程序所用资产的分布存储库的管理。“分布”是一个应用于一个或多个维度的宽泛术语,包括人、工件、平台,及所有权或决策权。

在本文中,我们分析了市场中的趋势及其潜在的动力,全球化交付模型中的好处,以及这样的模型所提出的挑战。最后,我们确定出全球化组织取得成功的一些关键因素。这些观测结果都来自于我们与 GDD 领域中的客户的合作经验,以及来自开发、市场、实现、服务和销售方面的其他的 IBM® 代表的贡献。

本文为即将到来的关于支持全球化分布团队技术解决方案的关键属性的文章打下了基础,并且为 IBM Rational® 产品如何实现那些需求并且为分布式团队的成功做出贡献的讨论打下了基础。我们还将提出一个可以应用于分布式组织来帮助形式化适当的技术基础架构和实现的参考架构。

背景

显而易见,全球化已经快速地成为跨许多行业的通用且重要的实践。制造业、汽车业、金融业、零售业和其它行业中都有这样的实例。高速的通讯、易达到的旅行、全球的机会和大量的其他科技的和社会的进步已经令许多公司的触角和拥有的财产扩展到全世界。

不令人惊讶的是,技术和软件开发公司也在这个运动中表现突出。软件团队不断地分布到全世界,跨公司内部协作及与合伙公司、子公司和外包服务提供者外部协作。

虽然公司已经暂时建立了分布的组织,但是它们这样做的动机,以及他们分配工作的方法都在继续演进。即使是在我们撰写本文的这段短暂的时间内,一些大型的公司已经对它们管理分布的团队的方法进行了重要的变更。在此我们将探究我们从过去的全球化中观察到的趋势。

就像我们将讨论的那样,“全球化”将带来许多好处。然而,分布的组织比集中的团队面临更多的挑战。我们将介绍那些挑战,并且提供一些解决它们的建议。最后,我们将评论我们所认为的确保全球分布的项目能够成功的关键因素。

市场趋势

公司继续在全世界扩展,它们通过各种各样的方式在全世界分布它们的团队,包括离岸、收购、合伙和外包。随着全球化更加普遍,许多公司正在演进它们的方法和实践,多半说明了分布的模型的成熟度。图 1 强调了一些全球来源中的变更,我们将更详细地讨论这些。1

显示新的趋势替代老的实践

显示新的趋势替代老的实践

图 1:全球化来源的趋势

从“在印度更便宜”到“人才到处都是”的演化

许多向全球市场的最初变迁包括将工作迁移到一个地点,经常是在印度,现在常常在中国或东欧。成本一般是主要的促进因素 —— 将工作迁移的决策是由技能劳动力在价格上比美国和西欧便宜得多所推动的。

企业日益在全球多个地点建立开发中心。虽然成本节省仍旧是一个因素,许多公司在亚洲和中欧维持着较低成本的中心,但是其他促进因素也已经开始起作用:

  • 有了更多的可用资源,公司可以更有效地为项目分配人员,并且从许多地方吸收人才。
  • 有了在不同时区的团队,公司可以利用经常被称为“跟随太阳”的开发来实现更长的工作日。
  • 东方的团队在一天的末尾将工作传递给较西边的刚开始工作的团队。
  • 在本地市场的出现可以有助于应用程序的本地化和国际化,以及营销。

向战略外包的演进

随着大量成长的外包提供者证明,外包已经流行了一段时间了。最初,公司经常在战术上外包项目,选择当时适合的供应商。公司可能也已经考虑到项目本身是否适合外包,或者它们也许单纯地根据什么项目缺少资源或资金而做出选择。

外包已经是更加战略性的:试验项目已经形成了企业级计划,而特别的工作已经形成了受治理的过程。外包现在被“rightsourcing”代替 —— 向具有合适技能的人分配业务过程和任务,不论那些人在地理上或组织上分布在内部或外部。公司目前分析它们的操作并有选择地在内部投入它们的核心力量,然后它们将其他服务外包给一个或更多长期的合伙人,并且与一些关键的供应商建立关系。

外包不再是仅仅为了维护

同样地,被外包的软件开发工作的类型也在变化。现有应用程序的维护曾经是软件开发中主要的外包实践。应用程序测试目前快速成长,随后是新的应用技术或组件的革新。一些将应用程序开发看作是支持服务的公司将需求和验收测试之外的所有工作都外包出去。面向服务的体系结构(services-oriented architecture,SOA)的影响已经导致了具体的服务的识别和分布,不论是技术的(代码)或是业务的。

软件开发之外的其他领域的成长包括业务过程外包(business-process outsourcing,BPO)。举例来说,大型医药公司可能将药品试验的管理和经营外包出去。IT 基础结构管理和咨询也在成长。一个极好的实例是印度的 Tata Consulting Services(TCS),最近的 InformationWeek 文章中提出,2007 年第三季度,超过 50% 的收入来自咨询、BPO 和基础结构服务,初次的应用程序开发构成了不到一半的收入 2。(注意在同一篇文章中,TCS 提到,公司本身现在把来自印度的工作外包到人才竞争没那么猛烈的其他国家。)

新的标准

如果全球化开发和交付最初是一些先驱者愿意尝试来获取新的能力或便宜的劳动力的话,那么似乎可以安全地说趋势已经转变了,GDD 已经成为广泛采用的实践了。在一些估计中,现在 80% 的软件项目是全球的。GDD 已经成为大多数依赖于软件的公司经营的标准方式。

组织上分布的演进

公司组织正在转变成反应这些产品交付的新方法。许多全球的组织最初根据地点分配产品或项目所有权,令每个地方或分支负责交付其自己的应用程序或项目,并且各个地方独立工作。

随着公司在世界上出现的地方的增多,许多地方成为贡献于全球的交付链的“团队中的团队” 。每个团队可能都拥有一个它们用来自其他地点或公司的组件为集成交付的模块或组件,最终达到最后的应用程序或产品。这些团队可能属于同一个组织、部门、或公司,或者属于不同的组织、部门或公司。

我们将开始探讨完全的,全球组织的分布,其中许多地点协作完成一个组件,从而在链中交付该组件。各个地点可能非常大,或者,由于劳动力的灵活性,小到一个人。

在许多情况下,分布很大程度上归因于合并和收购。在例如电信、技术,和金融服务的行业中,公司通过收购获得市场份额、技术,或市场入口,而不是内部开发。形形色色的新的并入的业务部件必须集成到有效的组织和供应链中。

基础架构的演变

这些业务实践和组织的分布的变更明确地影响了支持软件交付所需的工具和存储库基础结构。

当各个公司开始在全世界建立许多主要的办公室或分支时,典型的基础结构选择是公司复制中枢:开发服务器位于每个地点,并且通过常规的复制进度进行连接,通常通过 LAN 用本地客户端访问本地副本。

随着地点的倍增,以及团队规模更加缩小,在每个地点的副本的硬件/软件和管理的成本逐渐引人注目。与此同时,网络带宽和可靠性提高了并且没那么昂贵了。“中心辐射”模型更吸引人,多个地区性的站点通过 LAN、WAN 或 Web 访问一些复制的服务器(网络中心)。

公司日益向着集中的基础结构变迁,从而进一步减少成本和管理开销。此拓扑结构包括一个或一些通过 WAN 或 Web 客户端访问的集中的服务器环境,并且可能在内部实现,或者作为寄存的服务由外部的公司提供 —— 外包的另一个实例。

遍及全球的不断普及的宽带连接,包括无线网络的蔓延,也令计算能力的好处可能投射到任何需要的地方。另一个新兴的方向是“社区风格”基础结构,它基于开源的访问模型,其中分布的团队成员利用 WAN 或 Web 客户端访问共享的团队服务器。支持的公司配置管理中枢成为软件交付链的运载体,将可交付件分阶段为解决方案集成、测试和交付。

当然,通过许多的合并、收购,及外包合伙关系,异构的开发环境已经成为标准,结合了不同的平台、工具,及网络拓扑,并且混合了商业和开源的产品。

好处和挑战

如我们前面所讨论的,公司现在采取 GDD,想要利用许多潜在的好处,包括:

  • 能够通过合并或收购另一个公司,在业务或地理市场的新的领域中获得市场份额、技术,或立足点。
  • 通过外包实践(随需要增加或减少)以及允许您用适当的价格找到适当的技能的不同的劳动力定价所获得的更大的灵活性和可变的人员配备模型。
  • 成本较低的劳动力,可以抵消预算削减和成本降低的,并且补充现有的团队,这样它们可以扩展它们的关注点。
  • 获得更多的技能工人。
  • 能够利用具有业务专长和经验的外包提供者来满足具体领域的新的需求或革新。
  • 在可能成为产品的新市场的地方涉足的可能性。
  • 一般来说,能够利用有技能但成本较低的人力资源、有经验的外包人员,及重叠时区来获得竞争力 —— 增加速度和减少成本。随着更多的公司采用全球的交付,不这样做就成为了竞争劣势。

知道了所有这些潜在的好处之后,似乎所有的公司都不假思索地选择全球地建立团队来开发软件。然而,如图 2 所提到的(列出了 GDD 的好处和挑战),Gartner Group 调查发现质问谁离岸或近岸外包项目的那些客户有一半没有期待实现预期的成本益处3

全球的开发和交付所生成的挑战的列表

全球的开发和交付所生成的挑战的列表

图 2:GDD 的好处和挑战

事实上,全球的开发有许多问题和疼痛点:

  • 团队之间误解的过程或不匹配的过程会导致工作传递中的错误、重复工作增加,和生产力增加。据估计,返工二到五次,GDD 项目的生产力会下降到 50% 以上,比集中的项目多。
  • 沟通问题会导致误解、遗漏、错误和返工。
  • 文化问题,例如语言障碍及工作习惯或沟通方式中的差异,会引起延迟,并影响工作关系。
  • 跨多个地点和时区的协调工作比集中的项目更耗费时间和成本。
  • 对在所有地点上的开发活动的可见性和控制是一个挑战,特别是当与其他公司或不同时区的团队合作时。
  • 从异构的基础结构、不同的过程,或公司安全边界获得的项目标准可能不一致或不同,这使得很难度量成功。
  • 在公司内部(害怕失去工作或不满远程地点的开销的组织)和在之外的国家或地区中的政治问题可能导致隐藏的议程和冲突的目标。
  • 组织可能不共享相同的目标,特别是当通过不同的管理链或不同的公司报告时。
  • 对安全性和 IP 保护的关注,特别是在 IP 法律较松的国家中外包的情况下,会限制基础结构和组织的决策。
  • 由于合并、收购和外包,基础结构和开发工具可能多种多样。即使在内部,许多较小的团队采用轻量的工具,这些工具常常来自于开源领域,并且经常支持新的过程,例如敏捷开发。

这些疼痛点随着维度的数量(举例来说,物理的、时间的、组织的和公司)和团队中分布的程度而增加。

GDD 的关键的成功因素

要迎接这些挑战并且实现全球的开发和部署的益处,公司可以做什么呢?如图 3 中强调的,我们提出了成功所需的五个关键因素:

显示了什么因素将令 GDD 取得成功

显示了什么因素将令 GDD 取得成功

图 3:GDD 成功因素

  1. 确保所有地点的协调和监督。

    重要的是,通过计划您的组织将如何支持您想要的交付模型,从一开始就“考虑全球化”。设立角色和职责如何在地点间分布,包括管理和决策制定属于哪里。确定每个地点的团队将要使用的工具,并且决定令工具可用,以及能与其他地点的工具集成所需的基础结构。

    对远端的团队,特别是外包的团队的可见性是一个特别的挑战 —— 您如何能够用对整个项目和交付件的整体观察来确信您当前的实际状态?您如何能够可靠地度量并比较组件或项目?通过对每个团队的一致的度量(尽可能多)进行比较。预先确定为了追踪进度和状态将度量什么,并且与团队合作,以确保它们能够生成所需的标准。

    选择您能够客观度量的离散单元。举例来说,避免将工件度量为“完成 50%”,相反地,指明它们要么完成要么没完成。在可能的情况下,直接从您的开发工具中收集数据,这样您就可以消除人的错误和主观的偏见。(在某些文化中,团队成员可能更不愿说出坏消息。)
  2. 建立定义良好的且一致的工作流。

    为了避免对应该如何完成工作的误解,对将在所有地点执行的一致的过程进行定义、编制文档,并培训团队。

    期望所有团队都遵照相同的过程可能是不现实的,来自收购的不同的工具和技术、不同的业务需求,以及继承的过程和文化导致了不同的工作方式和方法。根据情况,一个组织中可能存在执行瀑布、迭代和敏捷方法的团队。理论上,单个项目中的所有团队会执行相同的过程,但在全球的供应链场景中,甚至那些团队可能是非耦合的,在某个自治级别上促成组件。

    从总的软件组织的角度看,最重要的是定义所有过程都必须满足的界限或参数,以便建立团队之间的一致的接触点和交付件。定义要生产的工件、要追踪的标准、成功的方法和提供监督和治理的机制。

    在已知的团队中,对要遵照的过程进行定义,编制文档,并培训所有成员。如果免责条款是必要的(举例来说,由于访问限制或工具差异),清楚地写出在哪里应用。

    清楚地定义权力和职责:谁做什么,向谁交付什么,以及要符合什么标准。您可能想要使用“RACI”矩阵的概念来对每个交付件或过程步骤确定谁 Responsible(负责)、Accountable(有责任)、Consulted(被参考),或 Informed(被通知)。

    团队或地点之间的传递经常引起问题。尽可能具体地使用术语,过程应该清楚地指出每次传递所需的交付件,以及预期的输入和输出。举例来说,通过为所需的工件提供模板,并且用对于进入和退出的客观的标准来定义控制门,来帮助确保清晰度。清楚地指出传递交付件和内容可以定义共同点,并且不管中间的步骤是什么,确保双方获得所需的内容。这在与遵照其自己的内部过程的外包供应者合作时尤其有用。

    考虑如何确保跨生命周期的变更追踪、可溯性,和责任,这样您就可以验证是否以及什么时候实现了特殊的变更,它对或将对其他任务或交付件有什么影响。

    在可能的情况下,将您的过程和工件工作流自动化,并且在工具中执行它们自己。工具应该令过程的遵守更容易,而不是背离过程,作为谚语的“胡萝卜”鼓励遵守,而不是作为“棍棒”。通过减少手工步骤,您减少了错误的机会,并且节省了团队成员的时间和工作。自动化还可以帮助克服由于时区差异造成的延迟。举例来说,自动的版本验证过程可以让印度的团队在不用等待美国的构建团队回来工作的情况下完成并测试缺陷修改。利用工具来制定过程还可以简化工具和过程的采用,并且帮助确保随着团队学习如何在团队中及跨团队更有效地工作的同时进行过程改进。
  3. 管理您的清单和信息。

    管理您的资产和工件。决定谁需要访问哪些工件,并确保它们能访问。这包括对网络访问及跨 WAN 或 Web 的资产可用性的考虑,执行适当行为的安全许可,以及定位工件(以及工件的正确版本)的简单能力。

    在可能的情况下提供相关工件之间的可溯性,这样那些过程中进一步的“下游”就能够了解它们在使用的工件的上下文。举例来说,允许缺陷和测试用例对需求和用例模型的可溯性能够帮助那些执行测试的人了解他们应该看到的结果是什么且为什么,以及测试是否充分地覆盖了预期的功能。

    对您的工件使用版本化机制,追踪变更,并确保不同工件的正确版本之间的可溯性。在确定的间隔获得资产的快照或“基线” ,例如在每个迭代或里程碑的末尾。每个基线包括一组完整的相关版本化的工件,它们被看作单元或单个资产,在团队间共享,并且用作参考点。将资产管理工具看作存储并管理这些相关的且版本化的工件的集合,且令其可复用的方式。
  4. 沟通、沟通、再沟通

    清楚且有效的沟通是最重要的成功因素,它无疑是构建任何可靠团队的关键。成功的项目促进协作,并且促进团队构建和社会网络。在集中的团队中,协作非正式地在走廊或“饮水机处”,以及面对面的会议中进行。对于分布的团队,您必须更努力地让每个人进入循环。

    设想一个沟通计划,定义您将如何让所有的团队成员消息灵通,并且为共同的共享目标工作。频繁且开放地沟通,并且构建团队成员间的信任。

    利用任意和所有可用的协作机制。许多标准的机制是众所周知且广泛使用的:电子邮件、电话会议,及内嵌入开发工具中的各种记录或文档工具。大多数人现在还熟悉聊天和即时通信、Web 会议,和屏幕共享。Wikis 及团队博客是最近蔓延的其他机制。建立“虚拟饮水机”(通过即时消息)、团队房间,或其他协作机制。

    在分布的团队中很难建立信任,人与人之间的联系可能是有限的。在中心位置创建在线的团队成员档案,包括照片甚至音频片段,这样其他人可以将面容及其他个人信息与名字及声音联系起来。如果预算允许,定期的面对面的会议提供用非言语沟通的好处建立关系的机会(虽然注意到文化的差异也会影响那些非言语模式的沟通)。

    很明显,您应该考虑团队位置的不同时区来安排团队会议。当不存在所有团队都方便的时间的情况下,轮流时间安排会议,允许团队在方便或不方便的时间依次参加。当安排会议和里程碑时,您还必须考虑不同国家和文化的假日安排。当一个地区有一个月的假期或重要的政治或宗教盛会时安排重大的里程碑可能会导致进度延迟及潜在的团队冲突。

    在可能的情况下,在所讨论的目标或工件范围内协作。使用 URL 引用通过电子邮件或聊天共享内容。直接对工件注释或评论,保存对工件的评论进行备案。清楚地记录沟通和决策,这样那些没参加的人能知道制定了什么决策,并且可以了解基本原理。对于其他时区的团队成员来说,这还节省了许多来回查询的时间,在这段时间中,当地球另一边的人回答您对特殊设计决策或基本原理的问题之前,可能一整天都逝去了。

    文本记录也可以帮助解决语言障碍。为了更好地理解决策和环境,那些不擅长口语的团队成员可以阅读(如果有必要可重新阅读)所写的文档。同样地,为语言沟通提供文本备份可能是有帮助的,举例来说,电话会议中的共享图表、文本标题,和聊天“备用频道”(注意这种备份还有助于听力有困难的人。)

    意识到组织中的多样性,以及多个地点中的文化和工作习惯的差异。举例来说,某些文化中的团队成员可能不愿当问题高手,其他人可能更对峙,并挑战权威。了解这些差异,并确保所有的团队成员也都了解它们,这样您就可以适应并啮合团队之间的工作方式。一些公司向人员提供多样性或文化培训,在其他情况下,您可能需要从经验中了解,或者问其他与类似团队合作过的人。
  5. 建立灵活、可适应的 IT 基础结构和架构。

    您的 IT 基础结构,包括您的网络和开发工具,应该允许您支持多种的分布的组织场景。确保您所选择的工具和平台提供支持您需要的拓扑结构所需的能力和灵活性,不论它们是复制的,中心辐射的、集中的,或某种聚合型。具体的考虑包括:

    • 客户端通过 LAN、WAN,或 Web 访问服务器
    • 安全性及随需要限制对工件的访问的能力
    • 在异构的操作环境中与其他工具和平台的交互及集成的能力
    • 支持团队协作
    • 支持必要的语言和代码页的能力

总结

组织的分布和全球的开发和交付成为大家通用的。外包和 rightsourcing 是将会继续成长、演进,并成熟的实践。对于许多公司来说,全球的团队不再是选择,而是企业策略和经营方式。

全球的软件团队的好处是重大的,包括成本节省、灵活性、重要技能和经验的获得,以及更快的交付市场。然而,仍然存在许多逆向影响实现那些好处的能力的挑战,包括文化、沟通,和过程问题。

实现这些关键的成功因素:

  • 全球的协调和监督
  • 定义良好的过程和工作流
  • 清单和信息管理
  • 清楚且可理解的沟通
  • 灵活且可适应的开发基础结构

可以帮助您克服全球的软件开发的挑战和缺陷,并且实现成功的全球交付的好处。

本系列的下一篇文章将介绍 GDD 的软件解决方案的关键属性,并且详述如何构建您的团队取得成功所需的灵活的,可适应的基础结构。

注释

1 Bernstein Research,“Future of IT Services”,2006 年 5 月 22 日。Gartner Group,“Gartner on Outsourcing”,2005 年 12 月 14 日。Forrester Research,“Future of Outsourcing”,2006 年 10 月 24 日。

2 Weier,Mary Hayes,“Tata Earnings Show Offshore Outsourcing Moving Beyond Software Development”,Information Week,2007 年 10 月 15 日。http://www.informationweek.com/story/showArticle.jhtml?articleID=202402971

3 Gartner Group,“Gartner on Outsourcing”,2005 年 12 月 14 日。

关于本系列

Rational 开发组织的解决方案架构师 Kathryn Fryer 和 Mats Gothe 开发了基于客户的场景,用 Rational 工具将最佳实践文档化,并且确定出未来的解决方案增强的机会。本系列文章基于他们最近的针对 GDD 方法和 Rational 对分布的开发的支持的工作。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=290166
ArticleTitle=全球化软件开发与交付:趋势与挑战
publish-date=02152008