在后泡沫时代，IT 预算被大量削减，造成预算供不应求，于是经理们不得不寻求更具有成本效率的解决方案。在这样的情况下，流向新兴市场国家的外包软件开发（离岸开发）的趋势开始增强。经济驱动力并不是造成这种趋势的唯一动力。最近由通信基础结构的进步所带来的迅猛增长也发挥了重要作用。
无论是传统的分布式团队还是特别的离岸外包，都可使用 Internet 协议 (VoIP) 软件、即时通讯软件、电子邮件客户端和 wiki 更方便的进行在线通讯。而且，现在人们更加倾向于使用 wiki 等在线工具而不是进行个人通讯，因为这些工具不但能够传达信息，还有助于组织和存储信息。这些工具还可以有效地将信息分发给大量接收者。
这些可在全球范围内使用的快速 Internet 连接同样增强了其他工具的功能，这也是加速离岸外包的原因之一。通过建模工具，分布式团队更容易理解文档。错误跟踪器、源代码控制服务器、Web 门户和在线协作工具都有助于协调分布式项目。终端服务和虚拟机简化了远程测试和管理。
在Internet 的影响下，新兴市场国家也开始发展高科技。Internet 跨越了政治边界，在俄罗斯和中国等发展中国家，成千上万的年轻人可通过它来学习最先进的技术并提高他们的英语水平。这种通过在 Internet 上接受教育来成为软件工程师的新浪潮也加剧了离岸外包的趋势。
但是离岸外包的飞速增长也引起了政治辩论。这场讨论假设离岸开发的存在具有现实意义，而且我们将着眼于最大化外包聘用所带来的回报。政治因素不会影响我们的决定，不过我们会参考 McKinsey Global Institute 经研究后提供的资源列表，因为这里量化了外包为美国经济带来的益处，同时也驳斥了一些关于外包的神话。
敏捷软件开发趋势
现在来讨论一下国内的情况。在国内，很多经理和工程师都在深思现在出现的另一个趋势：敏捷软件开发。在当今不断变化的商业环境中，缓慢的“重量型”方法无法满足要求。现在需要用更少的投入产生更大的利润，而且官僚作风再也不是获得投资回报 (ROI) 的最佳方法。敏捷方法的优势在于它的协作、灵活性，以及它对软件的商业价值作出的贡献，这体现在“敏捷宣言”的核心原则中：在过程和工具的基础上独立工作和交互、在综合文档的基础上使用软件、在合同谈判的基础上进行客户协作以及在遵循计划的基础上对变更做出响应（请参阅资源）。
敏捷方法在很大程度上满足了基于 Internet 的新型创业（通常称作 Web 2.0）。某些新型创业通过敏捷软件开发可以付出更少、获利更多，而且可以通过小型团队以很小的预算完成大型项目。这种短迭代和工作软件原则反映在一种称为“不断测试”(constant beta) 的实践中，该名称源于一些 Google 产品（其徽标中包含了“beta”一词）。
然而，敏捷方法不是“通用型”的方法。该方法最适合小型的、同一地点的团队用来应对飞速变化的情况。
图 1. 点对点和服务总线集成
尽管在某些情况下应用敏捷软件开发会遇到问题（例如将其应用于使用离岸外包的分布式开发中），但是在过去的五年中，我成功地将敏捷开发的原理应用到了分布式团队中，这说明只要使用得当，这种开发方式也可带来巨大的回报。
图 2. 三个集成层
还有其他一些说明敏捷软件开发会带来问题的案例。这些案例是：大型开发团队（一个独立项目有 20 名以上的人员参与）、可预见性至关重要的系统（生命关键应用程序）以及官僚环境。我们不会在这里讨论这些案例，而且我们会假设公司已经将敏捷开发融入其企业文化之中，并且打算将这里列出的观点应用到不足 20 人的软件团队中（这里的 20 人是指某个特定团队或项目的人数，而不是整个开发团队的人数）。我们会讨论如何将敏捷方法应用到传统的分布式开发和特别的离岸外包。
结合趋势
离岸软件开发交易中存在各种不同的聘用方式，可从 rentacoder.com 雇用一个国外开发人员，也可与拥有海外分公司的美国公司进行上亿美元的交易。不过即使交易的某一方希望采用敏捷软件开发过程，某些交易也不会按照这样的过程来安排。
要执行敏捷过程，所选的外包模式应该鼓励通信和协作，具有灵活性，以及经常发布。能够在外包交易中采用的标准有很多，不过其中最值得关注的是定价模型。关于最常用的定价模式计划，请参阅图 1。
可预测的结果暗示了可预测的过程。图 2 中列出了按预测自适应等级进行排列的开发过程组。如果使用预测自适应标准和可预测模式（这更靠近等级的左端，请参阅图 1），则软件开发过程需要具有更大的可预测性；同时敏捷开发过程会处于软件开发过程整体的另一边。
可预测性因素与“固定范围-固定价格”的聘用方式密切相关。如果在外包交易中采用此类合约，则客户和供应商都只能采用可预测软件开发过程及其结果。因此这类合约不适用于敏捷软件开发。所以在制定外包聘用时，请记住鼓励采用时间和材料等的定价模型来应对变化，这既为客户和供应商提供了灵活性，也更适合进行敏捷开发。
处理这项交易时，需要考虑所选模式将如何影响通信和协作。敏捷开发过程需要开放的环境、联系紧密的合作团队、共同的目标、显而易见的商业价值和频繁的沟通。工程师、客户、用户、经理和其他股东之间的壁垒越多，进行敏捷软件开发就越困难，这意味着需要减少中间人以在团队之间最大化透明度和集成性。
重量级人物们通过在其他国家建立分支机构来处理这个问题，如果公司希望自己的海外开发中心拥有 100 名以上的工程师，这是很有经济意义的。工程师的确切数量在很大程度上依赖于其他国家的实际情况，例如该公司是否能轻易地在这些国家招募到人才。
考虑这个选择时，不要重复一些中小型企业的错误，例如低估高层管理时间、旅行预算、当地律师费和其他费用等隐性支出。另外，发展中国家经济的快速增长引起了人才短缺，这有可能给新到来的小型外国企业带来更大的压力。虽然本地企业更容易被本地人所接受，但是大公司的分支机构可通过知名品牌、更高的薪水和更完善的社会福利来弥补在这方面的不足。
不过对于只希望在海外聘用 15 个开发人员的小公司来说，几乎不可能实行这样的措施。成功的中小型企业往往使用专门的开发团队、离岸开发中心 (ODC)、建造 - 经营 - 移交 (BOT) 模式、虚拟办公室、虚拟团队等模式来克服远程办公费用过高所带来的困难。然而无论这些模式如何变化，它们都有一个共同点：海外供应商更强调向客户提供硬件、法律、IT 和人力资源基础结构，而不是直接参与开发过程。在这类交易中，客户和供应商都对项目交付负有责任。
要从这类交易中充分获利，必须向客户指派工程师，而且双方都必须拥有稳定的团队。供应商和客户之间的沟通必须完全透明，其中包括开发人员之间的沟通。所有人员都必须讲一种语言，而不需要翻译。
在成功的合作中，有时远程办公室中的人员尽管从供应商处领取工资，但是他们与客户的联系更为密切，而且他们共享供应商和客户的价值观和企业文化。
使用正确的实践和工具
成功的软件开发团队所使用的实践中，众所周知的有：共同的编码标准；源代码控制服务器；一键建立和部署脚本；连续集成；单元测试；错误跟踪；设计模式；以及应用程序块。与本地团队相比，分布式团队必须以更严格的标准应用这些实践。
以连续集成为例进行说明。如果操作人员与源代码控制服务器之间的距离非常远，那么使用源代码控制服务器来获得突破是非常困难的。对于在另一个办公室工作的人员而言，这也许没什么影响，但是对于追求工作效率和通信的分布式应用情况而言，这就有可能成为一个主要的问题。只要坚持在团队中进行连续集成实践并安装相应服务器（例如 Microsoft Team Foundation Server、CruiseControl.NET 和 CruiseControl），就可以最小化这种风险。
在 Microsoft .NET 平台上工作的团队可以使用 Microsoft Visual Studio Team System 提供的各种新功能。可获取带有说明的 Microsoft Solutions Framework for Agile Development 和支持工具。如果团队需要更多关于在分布式环境中进行敏捷开发的指导，则该产品会非常有用。对于有经验的团队而言，这是一个可提供优秀 ROI 的集成解决方案。
另一个为分布式团队带来巨大价值的 Microsoft 产品是 Windows SharePoint Services (WSS)。Wiki 能够有效地帮助分布式团队进行敏捷开发，而且 WSS 的下一个版本计划在其增强功能中提供 wiki。WSS 同样紧密集成了 Visual Studio Team System，这使得它成为团队的 Web 门户的最佳选择。
从 IT 基础结构的角度来看，我建议使用虚拟专用网络 (VPN)，这样团队就可平等的共享资源。该 VPN 环境不像公共网络那样严格，可在其中使用 Windows Live Messenger 的应用程序共享、视频和语音呼叫、远程协助和白色书写板。
通信、通信、通信
如果进行远程工作，小的误解也会迅速变成大问题。在分布式开发团队中，经理必须密切注意通信实践，他们有时会在本地开发中忽略通信实践而不会产生不良后果。要注意的内容包括定期（每日/每周）报告和状态更新会议，这样可使团队成员保持同步、讨论成绩和暴露问题。经理还应该通过介绍性会议、现场参观、团队建设活动和其它方式来在团队中建立个人人际关系。
在离岸外包交易中，开发经理应该关注由语言、文化和时区所带来的障碍，而且必须设法克服这些障碍。全球化在缓慢不断地消除专业环境中的文化差别，但有时文化差异仍然会带来混乱。这个主题中有很多特定于国家的问题，这里就不再详细讨论了。语言问题容易发现却不易克服。如果公司面临语言障碍，最常用也是最有效的方法是公司对员工进行语言培训。在大多数国家，从事离岸开发的专业人员都愿意学习英语，因此这些地方的专业人员通常都接受语言培训。
时区的变化会使开发过程更加困难。但是在外包产业比较发达的国家，软件工程师们通常都会调整他们的工作时间表，以便更有效地与国外同行合作。有两种策略可用来处理时区差异。第一种是按照不同的工作对团队进行分组；例如，质保和产品经理在国内工作，而开发人员在国外工作。该安排可进行循环作业，这样开发人员可在他们的同行休息时修正程序和实现新需求，反之亦然。当然，也应结合工作时间表（在工作日开始/结束之时）。第二种方法是把项目划分为多个块，将每个块分配给一个地点，给每个地点分配尽可能多的功能。第二种方法要求更有效的通信，因此也能更好的进行敏捷开发，但是两种方法都是可以的，有时没有选择的余地。
选择正确的模式同样很重要，但是这不能保证成功。在分布式环境中，强烈建议交易的双方中至少有一方具有敏捷开发的经验。如果缺乏面对面的沟通，那么由于时间、文化、语言的不同，需要付出更多的人力和财力才能获得预期的结果。拥有一个优秀的海外伙伴可带来很多益处，例如节约成本、按需补充人员以及进行与外包基础结构相关的任务等（这些益处可概括为“付出更少、获利更多”），这大大优于投资建立生产性关系。没有通过功能强大的通信基础结构（可在全球范围内通用）所构建的现代工具，就不可能达到这种积极的平衡。
关于作者
Andrew Filev (MCA, MVP) 是 Murano Software 负责离岸工作的副总裁。他建立了离岸开发中心，并领导和激发了团队。Andrew 是一名优秀的交流者，他消除了不同文化之间的差异，而且与客户建立了长久的合作关系。
文章来源于领测软件测试网 https://www.ltesting.net/
