使用敏捷软件流程进行离岸开发

使用持续集成避免集成难题

我听说过一些关于跨站点团队集成工作出现问题的例子。即使在定义接口方面投入了大量精力，集成问题仍然很突出。这通常是因为很难正确指定接口的语义，因此即使所有签名都正确，您仍然会被关于实现将实际执行的操作的假设所困扰。

在 Thoughtworks 真正扎根的最早的 XP 实践是持续集成，我们已经习惯了它，以至于我们决心将其用于我们的离岸开发。因此，从一开始，我们就让每个人都使用同一个代码库，并运行 CruiseControl 来构建和运行测试。这样一来，无论身在何处，每个人都可以紧跟主线。

每个人都对它的效果感到高兴。它的主要好处是困扰其他团队的集成问题并没有发生在我们身上。持续集成和测试过程可以非常快速地发现许多集成问题，因此可以在它们变得难以找到之前修复它们。

CruiseControl 的网页允许所有站点查看国外正在发生的事情。您可以在早上第一件事查看 CruiseControl 网页，了解其他站点所做的更改。它提供了一种简单的方法来了解世界另一端发生的事情。

这确实需要良好的构建纪律，开发人员努力不破坏构建，并在构建被破坏时立即修复它。人们普遍接受的做法是，如果您将更改提交到主线，则在收到 CruiseControl 的电子邮件消息（说明您的更改导致成功构建）之前，您不应回家。当远程办公室使用相同的构建时，深夜构建失败会更加严重。

尽管全球持续集成非常受欢迎，但我们确实遇到了一些问题。通信管道不像我们希望的那样宽和可靠，因此许多源代码控制操作在远程站点可能会变得很麻烦。通常，我们将构建服务器与大多数开发人员放在同一个站点，但远程站点可能会发现从主线获取最新更新需要花费很长时间。通信线路越长，就越容易出现从故障到线路中断一段时间等任何问题。让存储库全天候可用会使将其关闭以进行备份变得很烦人。所有这些问题都可以通过集群代码存储库来缓解，但我们还没有尝试过任何类似的东西。

我们发现，某些源代码控制系统特别容易出现长时间且痛苦的签出过程，尤其是在配置不当的情况下。值得花时间寻找加快签出时间的方法，如果您的系统不适合远程工作，甚至可以更换源代码控制系统。

（有趣的是，人们认为这些通信问题是像印度这样的远程站点特有的问题，但我们发现西方国家的基础设施也经常出现问题。持续集成需要良好的连接性，通常比人们习惯的连接性更好。）

但是，即使连接性最好，如果系统需要被锁定在陆上防火墙内的服务，也会出现问题。您需要为这些服务构建良好的测试替身，以便可以在开发环境中有效地测试系统。

让每个站点都派遣代表到其他站点

正如我上面所说，敏捷方法强调面对面人际交往的重要性。即使每个人不能都在同一个地方办公，调动一些人显然也会有很大帮助。从一开始，我们就决定确保始终有一名来自美国团队的人员在印度，以促进沟通。这样的代表已经认识美国的人员，因此可以利用他的人脉关系来帮助每个人进行沟通。

我们现在已经将其扩展到多个级别。我们发现，将一名美国开发人员和一名美国分析师派往印度，在技术和需求层面进行沟通，这很有用。将印度的人员派往美国团队也很有价值。机票费用很快就会在改善沟通方面得到回报。

离岸团队中有一名面向业务的代表，其好处之一是，它有助于为离岸团队提供业务背景。仅根据需求列表构建软件会遗漏很多业务背景 - 开发人员被告知要做什么，而没有被告知为什么重要。为什么通常会对正确执行操作产生很大影响。

代表的一项重要工作是传达八卦。在任何项目中，都有很多非正式的沟通。虽然其中很多并不重要，但有些很重要 - 问题是你无法分辨哪些是哪些。因此，代表的部分工作是传达许多对于更正式的沟通渠道来说似乎不那么重要的信息。

我们通常每隔几个月（在某些情况下每隔几周）轮换一次代表，因为如果代表在国外待的时间过长，他们就会失去与国内的联系。这使得代表们更容易接受，因为他们不想离开太久。它还允许更多的人通过担任代表来了解远程团队。在选择代表时，关注个人需求和偏好非常重要。有些人不想离家几千英里外待几个月，所以他们不应该成为代表。

我们还发现，项目经理花一些时间担任代表也很重要。项目经理的很多工作是帮助解决冲突并在问题变得严重之前将其消除。对于他们来说，体验在电话线的两端工作对于有效地做到这一点非常重要。

代表是跨地区建立信任和凝心聚力的重要组成部分。因此，尽早派遣代表至关重要。如果一个项目在没有代表的情况下运行了一段时间，就会出现误解和不良情绪，需要花费大量精力才能解决。代表可以降低这种风险，但需要尽早在问题开始出现之前就位。

通过接触访问建立信任

代表是半永久性人员，他们在“其他”地点工作几个月。这至关重要，但还不够。还需要进行更多的接触，让更多的人参与进来。这些访问有助于建立和维护远程沟通有效运作所需的关系。

您可以考虑两种类型的接触访问：播种访问发生在项目早期，旨在建立关系，而维护访问有助于保持关系。

播种访问应计划在项目早期进行，并且时间应该相当长 - 两周是最短的时间。对于播种访问来说，重要的是要进行工作访问，因为重点是让人们习惯于彼此合作，因此应该围绕一些联合任务安排访问。

• 派遣一些陆上客户和项目经理到离岸站点制定初始发布计划。
• 让离岸分析师到陆上参与早期的需求收集会议。
• 让一些陆上开发人员访问离岸团队，以便离岸团队在使用现有代码库进行第一次迭代时提供帮助。
• 让离岸团队访问陆上地点 - 特别是在客户站点时。

无论出于何种原因，请记住，访问的主要目的不是完成任务，而是建立工作关系。在这些事情中，一个常见的错误是，在访问中安排了太多任务，以至于几乎没有时间进行重要的人际沟通。因此，要保持轻松的工作节奏，不要害怕安排一些非正式活动，让东道主可以带领访客四处参观，并进行一些非正式的接触。晚餐和观光通常是访客与东道主进行的最有用的活动。

重要的是要尽早进行播种访问。如果没有良好的人际关系，您很可能会因沟通不畅和缺乏信任而遇到问题。这些问题将需要花费大量精力来修复，并且很容易对项目造成持久损害。因此，尽早播种以避免这些问题。

如果您从一开始就在多个站点上都有开发人员，那么播种访问的一个特殊变体就非常重要。在这种情况下，让开发人员（或至少是高级开发人员）聚在一起构建最初的几次迭代非常重要。正是在这些迭代中，将做出关键的架构决策，因此在此期间保持近距离非常重要。否则，您可能会遇到不同的团队做出不同的决定，或者一个团队做出的决定另一个团队不理解的情况。

播种完成后，应使用强度较低的维护访问来保持联系。这些访问可以更短，但应该更频繁，每隔几个月进行一次为期一周的访问是最短的。同样，它们应该侧重于必要的任务，其中一项很好的任务是回顾。如果您感觉到团队之间存在沟通问题或出现重大问题，请不要害怕使用更长时间和更频繁的访问。我们注意到，如果系统设计发生重大变化，进行更长时间的联系访问特别有用。

礼品，特别是那些有助于传播文化的礼品，总是值得携带的。我们特别喜欢人们带一些当地特产的小吃或糖果作为礼物。

不要低估文化差异

在组织中引入敏捷方法最困难的部分之一是它带来的文化变革。事实上，我们发现这是组织在采用敏捷方法时遇到问题的主要原因。许多公司采用命令和控制模式运作，这种模式假设上级做出决策，下级人员执行决策。为了使敏捷方法发挥作用，您需要执行者拥有更多的自主权和决策权。

我们发现这在西方公司是一个大问题，但在亚洲，这个问题被放大了，因为亚洲文化强化了对上级的顺从。（我从一家大型印度承包公司看到的一门培训课程将管理定义为“控制的科学”。）在这种环境中，人们常常被劝阻不要问问题、谈论问题、警告不可行的截止日期或提出对上级指示的替代方案。

西方团队需要警惕这种趋势，当他们感觉到东方团队被动地同意时，应该予以反驳。要注意，礼貌的接受往往是重要问题没有得到讨论的迹象。此外，西方团队需要注意不要显得过于权威——这会强化这种情况。

坏消息是，让团队变得更加积极主动是一场艰苦的战斗，而且不可避免地需要花费大量时间。你永远不能假设问题会被提出，即使它们被发现了。让人们习惯分布式控制的管理方式比你想象的要花费更长的时间。

但也有好消息。一旦人们意识到他们拥有做出决定的自由和责任，他们似乎真的很享受。我们印度团队的几个人告诉我，他们在其他公司的朋友无法相信他们被赋予了多大的自主权。这种自主权是一个巨大的动力，使人们能够提高工作效率，并能够承担更大的责任。离岸团队成员获得了做出决策的信任和理解，而不是等待在岸团队，这会导致很多延误。对我来说，我们将发现的最有趣的事情之一是这种文化影响的长期影响，无论是在亚洲还是在西方。

播种访问在这里起着重要作用。如果人们有良好的人际关系，他们就更有可能提出问题。

即使是谈论这些文化问题也会引起问题。一些看到这篇文章草稿的（西方）行业分析师说，这一节带有优越感和冒犯性。我们在班加罗尔的一位开发人员说我太温和了。另一位评论说这是一个问题，但质疑它是否比许多西方公司的情况更糟。但似乎有一种共识，即亚洲存在着强化命令和控制的文化力量，而这种情况正在发生变化。

（这对Thoughtworks来说是一个特别尖锐的问题。我们有一种明显的反权威态度，即使在美国也很引人注目。我们从一开始就决定在印度保留同样的文化。我很高兴地说，我们似乎确实成功了。）

使用维基百科包含通用信息

我们尝试了各种方法来保存公共信息，到目前为止，我们最喜欢的是维基。维基之所以好用，是因为它们易于使用，可以使用任何浏览器进行操作，并且易于设置。

任何常见的信息都可以放在那里，故事卡片、设计指南、构建说明、进度说明——任何需要写下来供团队参考的内容。我们发现使用许多维基提供的更改通知功能非常有用，这样页面更改就会通过电子邮件或 RSS 提要触发通知。

维基本质上是非结构化的，这种缺乏结构性是其优势的一部分。随着项目的增长，团队通常可以在维基上发展自己的结构。但这确实意味着需要有人充当园丁，以确保它不会过度生长。

使用测试脚本帮助理解需求

随着距离的增加，您需要在传达需求方面投入更多精力。我们已经能够做到这一点，同时仍然坚持我们在单站点开发中使用的许多技术。

我越来越多地发现，更成熟的 XP 团队使用验收测试作为传达需求的方式。这样的团队在迭代开始之前就编写出测试脚本，以帮助阐明需求并为开发团队提供一个具体的目标。一种行之有效的风格是，让美国客户编写一个简短的叙述（几页）来充实一个功能（XP 术语中的故事）。然后，印度的分析师/测试人员会为这个故事创建测试脚本。这可以用于自动化测试或手动测试，尽管我们非常喜欢自动化测试。在开发脚本时，美国和印度的分析师通过电子邮件和即时消息进行协调，并定期（每周 2-3 次）举行电话会议，以审查测试脚本。

我们发现，这非常有助于印度分析师和美国客户真正理解需求。编写测试迫使印度分析师真正理解需要什么，并在出现问题时向美国客户提出问题。开发人员发现向印度分析师提问比翻阅测试脚本更容易，因此拥有一名印度分析师/测试人员仍然很重要。搜索引擎很好，但人类通常更容易合作。

我们发现这种技术最大的问题是让客户人员参与进来。因此，在大多数项目中，我们都无法做到这一点——但当我们做到这一点时，我们发现这种方法很有价值。

使用定期构建获取功能反馈

当人们考虑敏捷方法中的需求收集时，他们往往看不到反馈回路的重要性。需求过程通常被视为分析师提供需求，开发人员去实施。在稍后的某个时间点，有人会检查开发人员是否实现了他们被要求的内容。在敏捷项目中，客户和开发人员之间的密切关系允许客户更频繁地监控进度，这使他们能够更快地发现误解。此外，部分开发的系统也可以教育客户，因为通常情况下，要求的东西和需要的东西之间是有区别的——而这通常在有一些可工作的软件之前是不明显的。

定期进行集成构建可以让美国客户下载昨晚的工作并进行试用。虽然这不像共同定位那样直接，但它仍然允许客户快速纠正任何误解；以及让他们改进自己对需求的理解。

为了使这项工作顺利进行，关键是要解决环境问题，以便您在大洋两岸正确地复制环境。没有什么比陆上人员下载构建版本、发现问题，而离岸人员由于环境配置问题而无法复制问题更糟糕的了。确保尽早解决环境问题，并确保如果出现任何环境问题，有人能够解决。

确保人们定期查看构建的内容，即使它只是部分功能。人们查看一项工作越快，就越能发现任何沟通不畅的地方。人们通常喜欢等到某件事完成后再向他人展示。然而，在这种情况下，等待是不值得的。

Scrum 一直主张开发团队在每次迭代结束时向客户进行演示。现在我们已经相当广泛地采用了这种做法——我们称之为展示。对于远程团队，我们喜欢进行远程展示，由离岸开发人员借助远程桌面软件展示软件中的新功能。让远程团队做到这一点是抓住一切机会在离岸和在岸团队之间，以及开发人员和客户之间建立联系的另一个例子。

定期进行简短的状态会议

敏捷方法提倡为整个团队定期举行简短的状态会议（Scrum 中的 Scrum，XP 中的站立会议）。将这一点延续到远程团队非常重要，这样他们就可以与其他团队协调。时区通常是这里最大的问题，尤其是在美国和印度之间，任何时间对某些人来说都很尴尬。在我们早期的项目中，我们发现每周两次的站立会议似乎运作良好，并提供了足够的协调。

在我们最近的项目中，我们更多地使用了维基，这减少了跨岸站立会议的需求。现在我们在一个海岸的团队内部进行站立会议，但在不同的海岸之间不进行。但是，我们每天都会举行跨岸会议，但这些会议不涉及整个团队——只涉及那些专注于跨岸协作的人员。然而，对于小团队，我们确实会进行跨岸站立会议。

我们发现，在电话会议开始时闲聊当地新闻是一个好习惯。最近当地的一些奇闻轶事——政治、体育、天气——有助于双方了解对方更广泛的生活背景。（在我看来，这对我们这些书呆子以外的任何人来说都是显而易见的——当人们高度以任务为导向时，很容易忽视我们所处的更广泛的环境。）

由于存在时区问题，双方在选择通话时间时都应该互相迁就。我们的一位客户只在他们的工作时间内接听电话，这迫使印度员工在非常尴尬的时间上班。将所有责任都推给一方去适应，不利于顺利合作。

这种缺乏了解或考虑的情况也出现在其他领域。一个项目安排在印度节日排灯节期间发布一个主要版本，这相当于要求一个美国团队在感恩节期间工作。幸运的是，我们说服他们更改了日期。即使在不太严重的情况下，也要记住，假期很少是共同的，所以你经常会遇到一个团队处于假期模式，而另一个团队处于正常工作周的情况。

使用短迭代

一般来说，敏捷方法使用的迭代周期比许多其他迭代方法要短。在 Thoughtworks，几乎所有项目都使用一到两周的迭代周期。一些经验丰富的印度开发人员曾在使用两到三个月迭代周期的地方工作过，他们报告说，较短的迭代周期要好得多。

几年前，我们的分布式项目团队倾向于选择两周的迭代周期，因为他们发现很难使用更短的迭代周期，但这种情况已经改变了。现在我们已经学会了如何在分布式项目中轻松地进行一周的迭代。

使用针对远程站点定制的迭代计划会议

在我们的大多数项目中，我们发现，在每次迭代开始时举行一次全体团队成员都参与的计划会议，确实有助于让每个人都协调好下一阶段的工作。我注意到，我们的大多数项目都根据当地情况，对迭代计划会议（IPM）进行了自己的调整。（这种自我调整是敏捷流程的重要组成部分）。

远程团队会增加自己的一系列限制，尤其是在时区问题尴尬的情况下。然而，尽管会议时间尴尬会带来痛苦，但我们仍然发现 IPM 非常有用。

在 IPM 之前，美国客户会发送每个计划功能（故事）的叙述，我们希望在 IPM 之前将其转换为测试脚本。在此期间，任何问题都通过电子邮件处理。就在 IPM 之前，开发团队将功能分解成更细粒度的任务。这些任务分解会与美国方面共享，以获得反馈。

所有这些前期工作都缩短了电话会议的时间，现在电话会议的重点是解决任务分解过程中出现的任何问题。我们发现，电话会议通常持续大约半个小时到几个小时。保持实际电话会议的简短非常重要，因为这种远程会议特别费力。

移动代码库时，从错误修复开始是个好方法

我们的两个项目涉及到采用一个大型（数十万行代码）代码库，并将代码库的大量开发工作转移到班加罗尔实验室。在这两个项目中，印度团队在开始添加新功能之前，都先进行了几次迭代的错误修复。

从错误修复开始，可以让印度团队在对代码库进行大量工作之前熟悉代码库，因为错误修复比更改代码涉及更多的代码阅读。虽然这样做效果很好，但有些人担心，更有经验的人可能会认为只做错误修复是一种耻辱。虽然有些人可能认为这是一个问题，但我认为，处理错误修复或非常局部的功能更改是熟悉大型新代码库的最佳方法之一。

错误修复的沟通性质也可以使其更容易与离岸团队合作。在岸团队可以花时间来详细说明错误，这些错误可以传达给离岸团队，并在在岸团队的夜间进行处理。然后，在岸团队可以在第二天审查修复结果。我必须强调的是，由于沟通困难，这并不比让现场团队修复错误更有效率，但这可能是与离岸团队合作的一种不那么复杂的方式。

按功能而不是活动划分团队

关于在岸/离岸边界的大多数传统想法都是基于人们所做的活动。因此，分析和设计是在岸完成的，构建是在离岸完成的，验收测试是在岸完成的。这显然非常符合瀑布模型。

我们发现，与此相反，当我们让离岸团队处理尽可能多的活动时，情况会有所改善。因此，我们更希望看到他们尽可能多地进行分析和设计，但要受制于需求来自在岸的限制。当我们确实将工作分配给在岸和离岸开发团队时，我们是根据功能而不是活动来进行划分的。我们将系统分解成广泛的模块，并让离岸团队处理其中的一些模块。然而，与大多数这样做的团队不同的是，我们并没有花大力气去设计和冻结这些模块之间的接口：持续集成和弱代码所有权允许模块接口随着开发的进行而发展。

其中一个重要部分是发展离岸团队的分析师部分。在开发者当地，了解业务的人越多，开发团队就能越有效率地进行开发。开发人员不必等到第二天才能得到问题的答案，而是可以立即得到答案，这就消除了进展的障碍。所有这些都意味着你必须专注于提高离岸分析师的业务知识。这需要时间，但本地知识是在岸业务知识的重要补充。

由此推论，不要按水平方向划分团队（一个团队做演示，另一个团队做数据库）。总的来说，我更喜欢职能型的人员组织--而远程团队会加剧按层级划分团队的问题。

这里要记住的最重要的事情是康威定律的主导力量--系统的结构将反映构建它的团队的结构。这意味着，重要的是将分布式团队按尽可能松散耦合的模块进行划分。

预计需要更多文档。

敏捷方法淡化了文档的作用，因为他们观察到很大一部分文档工作是被浪费了。然而，文档在离岸开发中变得更加重要，因为面对面的交流减少了。这项工作在某种程度上是一种浪费，因为如果整个团队都在同一个地点办公，就不需要这项工作。但考虑到离岸模式，你需要做这些--所以它们是离岸工作成本的一部分。这是一种成本，人们需要时间来编写它们，因为人们从文档中理解很多东西比较困难，所以需要更多的时间，而且当人们在使用它们时，也会产生一种挫败感的成本。

除了文档之外，你还需要更多更积极的协作工具：维基、问题跟踪工具等等。总的来说，似乎通常情况下，支持结构较少的工具会更好，这样团队就可以更好地将它们融入到他们想要的工作方式中（这也是维基能够如此有效的原因之一）。

我总是建议团队将他们的文档签入版本控制系统，这样人们就可以很容易地获得最新的资料。当你在进行远程工作时，这一点尤为重要。

无论是文档还是其他任何东西，请记住，别人的模板对你来说是行不通的，而且你也不会在开始的时候就想出正确的方案。确保对文档的形式以及它们的效果进行充分的沟通。随着你了解到什么对你的团队最有效，要准备好对文档的结构进行改进。

在敏捷项目中，成功的文档有两个关键。第一个是找到 "足够 "的文档点。这很难确定，而且会因项目而异。幸运的是，敏捷开发的迭代性质允许你进行实验，直到找到合适的文档点。成功的敏捷文档的第二个关键是不要执着于它，也不要对保持更新抱有不切实际的希望。创建文档必须是为了服务于特定的目的，而当它服务于这个目的之后，你们所有人可能都有比更新文档更重要的事情要做。这似乎有悖常理，但在下次明确需要文档时，重新制作一份新的文档往往更好。每次需要记录项目的一部分时都要重新开始，这样做的好处是，它能极大地激励你保持文档的效率！

-- [Simons]

尽早建立多种沟通方式

不同的沟通工具适用于不同类型的问题。至少要确保你有一个维基、即时通讯和良好的电话连接。

即时通讯适用于快速问答，但即时通讯的一个特别优势是，它可以告诉你人们什么时候在办公桌前。你确实要养成保持即时通讯状态新鲜的习惯，但这些信息总是很有用的。我们看到在重叠时间段内的沟通激增，当这些重叠时间很短时，这一点尤其有价值。

现在很多公司都屏蔽了即时通讯，认为这是一种干扰。这对我们来说总是很伤脑筋，因为它阻止了 ThoughtWorker 向其他项目的同事提问。这对离岸项目尤其不利，因为它消除了非正式的一对一联系。

如果超过了几条简短的信息，那么最好改用电话。确保很容易就能拿起电话。人们不应该因为担心电话费而却步，打个电话通常可以节省因误解而造成的损失。

我们发现视频演示有很多价值。关于项目背景的简短讲座可以录制下来并发送给远程团队。这些通常比文档更容易准备，更容易让人坐下来听（如果它们不长的话），而且至关重要的是，它们还有助于个人联系，因为从视频中比从文档中更容易全面了解一个人。它们不适合用来了解细节，但对了解大局更有帮助。

电子邮件往往是喜忧参半的。特别是我们发现，最好不要鼓励个人对个人的电子邮件，而应鼓励使用广播新闻组或邮件列表。因为这样很容易导致信息没有传达到需要它的人手中，或者无法找到它。通过在新闻组中发布消息和请求，每个人都可以看到这些消息，而且很容易搜索。人们发现，跳过自己不感兴趣的主题很容易。

使用实时工具也可以实现多播而不是一对一的通信。有几个团队报告说使用Campfire效果很好。(IRC 也可以以类似的方式使用，尽管我还没有听说过有人提到它)。

也许最棘手的事情是如何传达大局--项目的愿景。大多数的沟通和关于沟通的讨论都集中在日常的细节上。把这些细节做好很重要，但这样做有一个危险，那就是在关注日常事务的同时，没有人关注整体愿景。

这可能会造成伤害，因为很多人会根据他们对大局的理解做出习惯性的小决定。这些小决定加在一起，所以如果没有对大局的沟通，问题就会悄悄地找上门来。

这个问题对于传达项目的业务背景尤为重要。远程沟通往往过于关注战术细节--本周需要构建什么。但许多技术决策需要更广泛的战略背景--因此，远程团队必须对项目和业务想要采取的方向有一个更广泛的了解。

这种沟通在现场项目中往往是缺乏的，尤其是在业务和技术之间存在很多组织障碍的情况下。远程开发团队加剧了这个问题--正如分布式开发加剧了大多数沟通困难一样。