想要创建用户友好、透明、快速发展的企业应用程序的公司，往往会受到外包商的阻碍。下面是如何判断什么时候外包敏捷开发是正确的。
大约四年前，Medidata Solutions决定从其传统的“瀑布式”软件开发方法转向敏捷方法。Medidata以软件即服务的模式提供临床测试解决方案。研发部高级副总裁安德鲁•纽比格金(Andrew Newbigging)表示:“我们之所以做出这样的改变，是出于一些常见的原因。”“我们希望能更好地响应客户的需求。”与此同时，Medidata的IT主管探索了外包公司部分软件开发的可能性。尽管这在传统的瀑布式开发中是有意义的，但他们认为这是一种错误的敏捷开发方式。
Newbigging说:“我们进行迭代，得到反馈，然后再迭代。”“这对我们来说很有效，我们担心，采取任何形式的外包方式，我们都会失去这种反应能力，最终生产出客户不想买的产品。”
这是许多行业专家都赞同的观点。“我们已经看到人们成功外包敏捷开发的案例。但它们是例外，而不是普遍现象，”Gartner分析师肖恩•肯菲克(Sean Kenefick)表示。
他和许多其他专家认为，创建纯敏捷方法的最佳方式是将所有开发工作留在内部。外包敏捷开发的公司将不可避免地面临艰难的权衡:他们可能不得不放弃一些敏捷原则，以及一些通常与外包相关的成本节约。而且管理外包的敏捷项目可能比管理内部的同一个项目更加困难。
尽管如此，越来越多的公司将不得不面对外包的挑战敏捷发展。开发敏捷项目管理工具的VersionOne对6000多名软件开发人员进行了调查，超过80%的受访者表示，他们的公司已经采用了敏捷开发。
与此同时，越来越多的IT职能外包的趋势仍在继续。根据Gartner的IT外包预测，从2008年到2011年，全球外包支出增长了8%，未来两年还将增长6.6%。从这些统计数据来看，很明显，至少有一些敏捷开发项目将被外包。
反对外包敏捷的案例
为什么外包商很少能成功地交付敏捷开发呢?考虑到敏捷开发总是具有挑战性的，即使是在内部，每个人都在相同的位置。肯尼菲克表示:“这需要大量的纪律和文化变革，还需要大量来自集团的支持，从最底层的员工到最高管理层。”
他补充道，即使是一个成功使用敏捷的公司也会发现它很难维护。“这是一个非常微妙的平衡。我看到过这样的情况，每个人都在候补室工作，而开发商想要自己的办公室。这种变化足以破坏敏捷过程。仅仅通过将一个函数从房间的一边移到另一边，就会使一些困难变得更加困难。如果你把它外包给另一家公司，你就会让它变得更加困难。”
敏捷沟通
我们可以谈谈吗?
当东海岸的人们早上9点到达办公室时，班加罗尔已经是晚上7点半了。在旧式的瀑布式软件开发世界中，这可能不是一个大问题，但如果您使用的是敏捷，它需要开发人员、测试人员和软件的业务用户之间的持续沟通，那么让团队成员在不同的时区会带来严重的挑战。你能做什么?下面是一些被证明对成功的外包敏捷项目有效的策略:
1.写详细的需求。Kelley Blue Book项目管理办公室的高级经理Rene Rosendahl说:“当我们需要就详细的需求交换信息时，时差是一个挑战。”“我们提供了比非离岸油田更详细的书面信息，以缓解这种情况。”我们的目标是尽量减少回到我们身边的问题。”
2.使用协作技术。Kelley Blue Book使用一个名为VersionOne的工具来管理敏捷项目，并保持敏捷团队内部的沟通渠道畅通。这还不是全部。“我们是即时通讯和电子邮件的忠实用户，”Rosendahl说。“所以，如果有人晚上回家了，离岸团队的成员需要从那个人那里得到信息，他们可能会通过电子邮件或即时通讯工具得到。”
3.要求海外工作人员配合你的时区。世界上其他地方的许多开发人员为美国公司采用敏捷开发，他们的工作时间对他们来说很奇怪。“我们在新德里附近的团队大部分都在东部时间工作。这很有帮助，”外包公司Tarika Technologies的CIO Shane Aubel说。他补充说，印度工人的工作时间是从上午11点左右到晚上7、8点。
凯捷公司(Capgemini)北美测试负责人凯文•奎克(Kevin Quick)指出，这有助于避免让任何人长时间上晚班。他说:“这是一件循环的事情，所以我们的员工可以很好地管理自己的生活。”“我们从惨痛的教训中认识到，如果让员工长时间上夜班，我们往往会失去他们。”
4.保留一些团队成员在国内。“我最大的建议是确保设计师、建筑师和工程师都在陆地上，”Aubel说。“我们做大量的架构、设计和需求，然后我们发送给团队的规格说明非常明确。这只是一个编码的问题。当你试图开始将设计和架构外包到海外时，挑战就出现了。”
但是一些行业专家对这种真正的敏捷方法持怀疑态度。“如果您正在进行瀑布式开发，有一个只知道J2EE的Java人员是可以的，”Hudson Crossing的常驻高管Max Rayner说。“在敏捷中，你希望开发人员像业务人员一样思考。他们会编程是不够的。他们必须参与并挑战需求，考虑结果而不是过程。所以很多外包程序员工厂的公司有一个问题，因为他们没有能够参与核心业务的人才，而仅仅是他们的代码写得有多好。”
5.买很多飞机票。视频会议、即时通讯、文档共享和远程scrum会议都有帮助，但最终，没有什么能比得上面对面的会议。因此，成功管理过离岸敏捷项目的IT领导建议经常访问——双向访问。Rosendahl建议:“你可以让你的部分在岸团队成员到海外去见离岸的scrum团队，并向他们介绍你的技术。”“你还可以计划让海外资源进入内地，以维持交易所的运转，并继续建立这些关系。”这并不便宜，而且需要努力和时间，但非常值得。”
AA寻常Zetlin
更糟糕的是，使用敏捷方法与大多数外包商的商业模式背道而驰。专注于敏捷和精益开发的it咨询公司Emergn的首席执行官Alex Adamopoulos说:“每个外包公司都有自己的软件开发方法，希望所有客户都能使用。”这并不一定是件坏事——他们想要找到最有效地运行他们组织的方法。但这降低了他们采纳客户公司提出的任何方法的可能性。”
事实上，采用敏捷方法可能会大大降低外包公司的工作效率。“敏捷的好处之一是，在开发时可以走捷径，以便更快地发布。”然后再回去重构代码，”Kenefick说。“但是，当第三方在编码时，你如何做到这一点呢?”他们想要以正确的方式一次性完成。作为一个外部供应商，如果没有必要，我为什么还要多次重写相同的代码呢?”
还有地理。许多外包安排涉及到与世界上一些劳动力比美国便宜的地方的程序员一起工作，但是如果将一个功能转移到另一个房间会干扰敏捷过程，那么将其转移到另一个海洋就更糟糕了。
Kenefick说:“敏捷的一个基本方面就是快速反馈。”“如果你的员工来自不同的时区，你就不会经常进行这样的对话。我今天会写一些代码，但之后24小时都得不到反馈。”
他补充道，这就是为什么敏捷方法在所有团队都在同一个地方时效果如此之好。“管理团队是非常困难的，但这是我列在有效敏捷实践清单上的第一件事。”
如果外包敏捷开发使工作更具挑战性，那么将所有敏捷开发都留在内部是不是更好的策略?对于越来越多的公司来说，答案似乎是肯定的。“我们看到一种趋势，过去进行外包的公司选择投资于自己员工的技能和能力，”阿达莫普洛斯说。“聪明的公司发现，外包节省的成本并不是那么大。例如，与我们合作的一家保险公司正将重点项目的开发工作更多地带回公司内部，以便更好地留住员工，降低风险。他们的观点——也是我们在这里和欧洲的许多客户的观点——是传统的外包商没有帮助他们把产品推向市场足够快或足够好。外包商方面的变化速度较慢，因此为了抵消这一影响，他们正在培养自己的员工。”
团队增加
作为团队成员的外包人员
SciQuest是一家提供“软件即服务”供应链管理工具的公司，大约在五年前，当它决定转向敏捷软件开发模式时，该公司已经与印度的一家外包商建立了良好的关系。“我们的一大部分工作都被外包了，”公司技术部副总裁达里尔•布罗德尔(Daryl Broddle)表示。这家外包公司是一家小型的创业公司，它愿意改变自己的做法以适应新的方法。
所以SciQuest开始创建团队，就像在一个典型的敏捷设置中一样。布罗德尔表示:“创业伙伴增强了我们的团队。”“团队专注于战略，外包商的开发人员每隔两三天就会参加我们的日常站立会议。我们已经将它们集成到我们的流程中。我们不会把一堆东西写下来发给他们。”
SciQuest总部位于北卡罗来纳州，两家公司通过调整他们的工作日程来解决时差问题，Broddle说这是非常容易处理的。“他们早上9、10点上班，工作到晚上6、7点，”他说。“我们有三到五个小时的重叠时间。如果我们需要开个会，进行一个长时间的讨论，那么我们会在早上7点进来。”
为了进一步帮助合作，外包商的一名开发人员全职在SciQuest工作。“他是我们四人团队中的四人之一，”布罗德尔说。“我把他当作我的员工，但他也是我们的客户经理。例如，如果印度的某个开发人员表现不好，他会处理。”
布罗德尔指出，这种情况在五年多的时间里一直运行良好。他表示:“我们最初与他们合作时，他们规模很小，刚刚起步。”“它们和我们一起成长，现在大约是我们开始时的四五倍。”
与外包商合作可以让SciQuest更快地为客户提供新功能。Broddle说:“我们每年发布三个主要版本，但在这期间我们使用焦点小组。”“我们向他们展示新功能，并得到他们的输入，而不是把一个新功能放到生产环境中。由于外包商扩大了我们的团队，我们可以在两周的sprint中完成一些事情并准备在我们的焦点小组面前实施。我们不会给他们看屏幕截图——这是真正的代码。”
AA寻常Zetlin
这就是Medidata去年做出的决定，当时该公司决定扩展其软件产品，并再次认真考虑外包敏捷开发。Newbigging表示:“我们决定招聘并扩大内部开发团队的规模。”“我们强烈认为，让我们自己的开发人员构建软件，同时负责维护，对任何问题做出快速反应，这样做会更好。”他们能够理解软件是因为他们首先构建了软件，而如果最初的开发是在其他地方完成的，这就很难实现。你没有同样深度的知识。”
以正确的理由外包
虽然将所有敏捷开发都保留在内部可能是许多IT领导的首选，但这并不是对每个公司或每种情况都可行的计划。由于迫在眉睫的技术技能短缺和IT预算压力，一些敏捷软件项目将不得不外包。