那些想要创建用户友好、透明、快速发展的企业应用程序的公司，往往会受到外包商的阻碍。以下是如何判断什么时候外包敏捷开发是正确的举动。
大约四年前，Medidata Solutions决定从传统的软件开发“瀑布”方法转向敏捷方法。Medidata以软件即服务的模式提供临床测试解决方案。研发高级副总裁安德鲁•纽比金(Andrew Newbigging)表示:“我们做出改变的原因都很平常。”“我们希望对客户的需求做出更积极的回应。”与此同时，Medidata的IT主管也在探索将公司的一些软件开发外包的可能性。尽管这在传统的瀑布世界中可能是有意义的，但他们认为这是一种错误的敏捷方式。
Newbigging表示:“我们进行迭代，获取反馈，然后再进行迭代。“这对我们来说很管用，我们担心，任何外包方式都会让我们失去响应能力，最终得到的是客户不想买的产品。”
这是许多行业专家的观点。“我们已经看到一些成功外包敏捷开发的案例。但他们是例外，而不是规则，”Gartner分析师肖恩•肯尼菲克(Sean Kenefick)表示。
他和许多其他专家认为，创建纯敏捷方法的最佳方法是将所有开发工作留在内部。外包敏捷开发的公司将不可避免地面临艰难的权衡:他们可能不得不放弃一些敏捷原则，以及一些通常与外包相关的成本节约。管理外包的敏捷项目可能比管理内部的敏捷项目更困难。
然而，越来越多的公司将不得不面对外包的挑战敏捷发展。在VersionOne对6000多名软件开发人员进行的一项调查中，超过80%的受访者表示，他们的公司已经采用了敏捷开发。VersionOne是管理敏捷项目的工具。
与此同时，越来越多的IT功能外包的趋势仍在继续。根据Gartner的《IT外包预测》(IT Outsourcing Forecast)，全球外包支出从2008年到2011年增长了8%，未来两年还将再增长6.6%。从这些统计数据来看，很明显，至少有一些敏捷开发项目将被外包。
反对敏捷外包的案例
为什么外包商很少成功交付敏捷开发?考虑到敏捷开发总是具有挑战性的，即使是在内部，每个人都在同一个位置。肯尼菲克表示:“这需要大量的纪律和文化变革，以及从最低级别人员到最高高管的大量支持。”
他补充说，即使是成功地使用敏捷的公司也可能发现很难维持。“这是一个非常微妙的平衡。我曾见过这样的情况:所有人都在大办公室工作，而开发商却想拥有自己的办公室。这种变化足以破坏敏捷流程。仅仅是把一个函数从房间的一边移到另一边，就会让一些困难的事情变得更加困难。如果你把它外包给另一家公司，你会让它变得更加困难。”
敏捷沟通
我们可以谈谈吗?
当东海岸的人早上9点到达办公室时，班加罗尔已经是晚上7点半了。在老式的瀑布式软件开发世界中，这可能不是一个大问题，但如果您使用的是敏捷开发，这需要开发人员、测试人员和软件的业务用户之间不断的沟通，让团队成员处于不同时区将是一个严重的挑战。你会做什么?以下是一些被证明对成功外包敏捷项目有效的策略:
1.写详细的需求。“当我们需要交换关于详细需求的信息时，时差是一个挑战，”Kelley Blue Book项目管理办公室的高级经理Rene Rosendahl指出。“我们正在通过提供更详细的书面信息来缓解这种情况。我们的目标是尽量减少我们遇到的问题。”
2.使用协作技术。Kelley Blue Book使用一种叫做VersionOne的工具来管理敏捷项目，并保持敏捷团队内部的沟通渠道畅通。这还不是全部。“我们是即时通讯和电子邮件的忠实用户，”罗森达尔说。“所以，如果有人晚上回家了，而海外团队成员需要从那个人那里获得信息，他们可能会通过电子邮件或IM获得信息。”
3.要求离岸工人配合你的时区。世界其他地方的许多开发人员通过工作时间来为美国公司进行敏捷开发，这对他们来说是很奇怪的。“我们大多数驻新德里附近的团队都在东部时间工作。这帮了大忙，”外包公司Tarika Technologies的首席信息官谢恩•奥贝尔(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的首席执行官亚历克斯•阿达莫普洛斯表示:“每个外包公司都有自己的软件开发方法，希望为所有客户使用。”“这未必是件坏事——他们希望找到最有效地管理公司的方法。但这让他们不太可能采用客户公司提供的任何方法。”
事实上，采用敏捷方法可能会大大降低外包公司的工作效率。“敏捷的好处之一是，为了更快地发布，你可以在开发过程中走捷径。然后你再回去重构代码，”Kenefick说。“但如果有第三方在编写代码，你该怎么做呢?”他们希望用正确的方式一次性完成。作为外部供应商，如果没有必要，我为什么要多次重写相同的代码呢?”
还有地理。许多外包安排涉及到与世界上劳动力比美国更便宜的地方的程序员合作。但如果将一个功能转移到另一个房间会干扰敏捷流程，那么将其转移到另一个海洋就更糟糕了。
“敏捷的一个基本方面是真正快速的反馈，”Kenefick说。“如果你的员工来自不同时区，你就不会经常进行必要的此类对话。我今天会写一些代码，但24小时内都不会得到反馈。”
他补充说，这就是为什么当所有团队都在同一个地方时，敏捷方法能发挥如此出色的作用的原因之一。“整合团队非常困难，但这是我在有效敏捷实践清单上要做的第一件事。”
如果把敏捷开发外包出去会使工作更具挑战性，那么把所有的敏捷开发都留在内部是不是更好的策略?对于越来越多的公司来说，答案似乎是肯定的。阿达莫普洛斯表示:“我们看到，过去进行外包的公司正转而选择投资于员工的技能和能力。”“聪明的公司发现，外包节省的成本并没有那么大。例如，与我们合作的一家保险公司将重点项目的更多开发工作带回公司内部，以便更好地留住员工，降低风险。他们的观点和我们在美国和欧洲的许多客户一样，认为传统外包商没有帮助他们将产品推向市场，速度不够快，效果也不够好。外包方的变化速度较慢，所以为了弥补这一点，他们正在提高自己员工的能力。”
团队增加
外包者作为团队成员
大约五年前，当提供软件即服务供应链管理工具的SciQuest决定转向敏捷软件开发模式时，该公司已经与印度的一家外包商建立了良好的关系。“我们的一大部分工作都外包出去了，”技术副总裁达里尔·布罗德(Daryl Broddle)说。外包公司是一家小型的创业公司，愿意改变自己的做法以适应新的方法。
所以SciQuest开始创建团队，就像典型的敏捷设置一样。布罗德表示:“创业伙伴扩大了我们的团队。“团队专注于策略，外包商的开发人员每两三天就会参加我们的日常站立会议。我们已经将它们整合到我们的流程中。我们不会写一堆东西给他们。”
SciQuest总部位于北卡罗来纳州，这两家公司通过调整他们的工作时间表来处理时差问题，Broddle说这是非常容易做到的。“他们上午9点或10点上班，一直工作到下午6点或7点，”他说。“我们最终会有三到五个小时的重叠。如果我们需要开会，需要进行长时间的讨论，那么我们会在早上7点到。”
为了进一步促进合作，外包商的一位开发人员全职在SciQuest现场工作。布罗德说:“他是我们一个四人团队中的四人之一。“我把他当成我的员工，但他也是我们的客户经理。例如，如果印度的一个开发商工作不顺利，他就会处理。”
布罗德指出，这种情况已经持续了五年多。他表示:“我们刚开始与他们合作时，他们的规模很小，刚刚起步。”“它们和我们一起成长，现在大约是我们刚开始时的四、五倍大。”
与外包商合作可以让SciQuest更快地实现向客户提供新功能的目标。Broddle说道:“我们每年都会发布三款主要的游戏，但在此期间我们会使用焦点小组。“在我们将新功能投入生产环境之前，我们会向他们展示新功能，并得到他们的反馈。通过外包商扩大我们的团队，我们可以在两周的sprint时间内完成一些事情，并准备在焦点小组面前执行。我们并不是在展示截屏，而是真正的代码。”
AA寻常Zetlin
这是Medidata去年做出的决定，当时该公司决定扩大其软件产品之一，并再次认真考虑外包敏捷开发。Newbigging说道:“我们决定雇佣并扩大内部开发团队的规模。“我们非常强烈地认为，我们最好让自己的开发人员来构建软件，并负责维护它，对任何问题都能迅速做出反应。他们能够理解软件，因为他们首先构建了它，如果最初的开发是在其他地方完成的，这就更难实现。你没有那么深的知识。”
以正确的理由外包
尽管将所有敏捷开发保持在内部可能是许多IT主管最希望的，但这并不是对每个公司或每种情况都可行的计划。随着技术技能短缺和IT预算压力的迫近，一些敏捷软件项目将不得不外包。