Kevin Coleman讲述了他与某声称自己敏捷的离岸开发团队合作的故事，并提及其中的痛苦与烦恼，
敏捷了，而且还是离岸敏捷，是自找麻烦吗？
。该文章已经发布在Agile Journal的九月刊上。几位读者也用他们自己的经历证实了Kevin Coleman的说法。那么，就在现今的业务现实中，敏捷方法能够成功地用于离岸团队吗？其中，Kevin所述的一个重要的假设是：
大多数离岸开发组织以传统瀑布开发方法做为组织的标准开发方法；使用这种传统方法，就要定义一些需要很大规模才能完成的任务，是典型的组织化的项目。这些传统开发技术与敏捷的基本观念背道而驰。在这样的前提下，Kevin谈到一堆很常见（且昂贵的）问题：
离岸开发团队拿到一份清单，然后分析需求，评估其大小及复杂性，以及每个条目需要多少努力才能完成。基于这些评估以及在岸与离岸开发团队的规模，定义并推 敲哪些功能可以在这个Sprint中交付。一旦确认了这些交付物，开发过程就开始了。问题也就开始出现了…… 随着演示以及概念确认等这些敏捷过程中所说迭代式发掘过程，新需要也就不断被发现了。而随着重写代码、评估这些新需求，以及计划的变更，都会增加成本。但是
这种情况在好转。很多混合型（敏捷与传统）项目使用时间盒管理技术，并称之为“敏捷”。时间盒技术就是指在固定的时长中完成一件或一系列任务。一旦确定了 时间盒，开发人员将在这段时间里尽其所能进行工作。因此，与典型瀑布项目中那种一直工作到某（些）任务完成不同的时，此时离岸团队只工作某个固定时长（比 如说，五天）。而五天后，要么那些初始计划的工作被完成了，要么就被放回到Backlog中以后再完成，或者完成了那些替代了原有这个Sprint中所计 划的工作，管理资料
《敏捷了，而且还是离岸敏捷，是自找麻烦吗？》(http://meiwen.anslib.com)。之所以说这个Sprint结束了，是因为实现这些功能的成本已经发生了变化，需要由在岸团队重新评估。而
另一种混合方法就是使用功能演示代替了传统的Reviews。在工作过程中，离岸团队得到来自在岸团队、业务人员/SME和关键项目干系人的反馈。而这些 反馈要么被加入到这个Sprint中，要么会因明显增加工作量而推迟实现，将其放回Backlog中，等待在后来的Sprint中实现。如果这个反馈需要 在某个特定时间内完成，那么你只能猜测，并将其放到这个Sprint的任务列表中，对其进行评估，并安排其优先级，还要调整你的开发计划。根据Kevin所述，当一个敏捷团队与一个非敏捷的离岸团队合作时，几乎任何事情的成本都提高了，而其根源似乎是：很多离岸团队并非真正的敏捷。该文所有的评论者似乎都有相似的经历：
非常赞同“在两个公司合作完成一个或两个项目并建立信任之前，结合这两种方法的风险很大”这一观点。我还没看到过哪个传统瀑布型组织很顺利地完成敏捷项目。通常，你不得不决定采用哪些两公司各自所坚持的方法，从而创造出一种混合型过程。还有，
提醒那些使用敏捷方法的离岸开发者，你要确保开发人员认识到：离岸开发人员消耗的是你的事业、金钱和时间。当开发者开始干活时，全面的计划就要出台。而此时如果你被排除在外，还没有持续沟通机制的话，那么你的麻烦就来了。还有人提到，
此时此刻，我正遇到这个问题——很高兴我不是唯一的一个。InfoQ的读者，你有同样的经历吗？如果有，提醒您留意的是，该文中对于敏捷离岸开发的大部分内容是持肯定态度的。——这是个错误的信息呢，还是Kevin落到了不幸的少数派中？
查看英文原文：Agile and Offshore: Asking for Trouble?来自：http://www.infoq.com/cn/news/2008/10/agile-offshore