初创企业的离岸敏捷

本文要点：

• 工具和流程很重要：敏捷原则并不强调工具和流程，但是它们在离岸敏捷中必不可少。
• 不要期待立竿见影：离岸敏捷需要度过登岸期。
• 不做纯粹主义者：敏捷流程需要调整，方能满足离岸的特定需求。
• 所有事情都关乎教练和沟通：你要真正帮助团队成员认识到敏捷工作实践的价值。
• 打造信任：提供纲领和指导，并尽最大可能保持公开和诚实。

随着通信技术的持续进步，与离岸伙伴一起工作变得更加快速、成本更低。只要知晓了离岸敏捷的限制因素，你就能在离岸团队中实现敏捷。尽管敏捷宣言中的一些原则难以在离岸团队实施，他们仍然可以作为离岸团队一起高效工作的指导。

Will Lord 是 EdPlace 的前任 CTO 和现任董事会顾问，他在 Agile Cambridge 2017 峰会上就离岸敏捷问题做了发言。InfoQ 以问答、总结和专题文章的形式报道此次峰会。

InfoQ 采访了 Lord，话题涉及如何找到合适的离岸伙伴、敏捷价值和原则是否适合离岸团队、离岸团队如何采用敏捷以及他们从初创公司敏捷团队学到了什么、何时应该采用离岸而何时不应该采用。

InfoQ：什么原因促使 EdPlace 采用离岸团队？

Will Lord：说起来这其实仅仅只是个务实的选择。我们做 5-16 岁儿童的在线教育，我们的创始人都非技术出身。他们想要快速、低成本地验证产品概念，而离岸团队提供了最佳选择。从那时候开始，我们一直在持续回顾我们遵循的流程、合作的团队以及技术需求，并且一直反过来利用离岸开发资源。对于注重经验和内容而不重复杂科技创新的初创企业，离岸是特别合适的选择，因为其他选择很少能够以较低成本提供敏捷性（以从业规划的角度而言）。

InfoQ：您是怎么找到合适的离线伙伴的？

Will Lord：我前面的回答说的离岸听着像是毫不费力的选择，但是离岸是个很复杂的过程，有着自身的难点。我依旧认为，离岸团队的整体成本要比自建团队低很多，但是你也不应该忽略寻找和管理离岸团队耗费的时间。对我们而言，确定离岸团队的过程可能是最困难的部分。我刚开始在 EdPlace 工作时，我接下了负责一个现有离岸团队的担子。但是很快我就发现，如果想要继续推进产品，我们就需要更换供应商。原先的合作伙伴位于印度，我们对于新的离岸团队的所在地秉持开放的心态 ，所以我们在更广的范围内寻找。在确定潜在伙伴的时候，我发现关注 3C 是很有用的：成本（Cost）、文化（Culture）和能力（Capbility）。

• 成本很显然——就算考虑到管理费用，一些国家（特别是印度）的成本也远低于本地或者近岸开发团队，而另外一些的成本却越来越高。爱沙尼亚就是一个很好的例子，他的软件开发行业庞大而优秀，但是其成本却跟英国或者其他西欧国家持平。
• 能力就是简单的看团队是否具备完成我们需求的能力和专注度。这可能指的是特定技术或特定领域的覆盖面。
• 最终，也是最重要的，需要考虑文化，当然包括语言因素，也要考虑对待客户、员工和技术的态度因素。后者将对能否与其长期合作产生重要影响。敏捷意味着要建立稳定的人际关系，所以你需要明白这些“化学反应”。

我花了几个月时间对潜在伙伴做了案头调研工作，寻找推荐对象、看看谁曾得奖、会见本地代表以及进行初步会谈。然后我定下了候选名单，并向候选名单团队发送了征求建议书（request for proposals ，简称 RFP）。最终我选择了印度的候选公司，然后动身和他们面谈。我认为这对于哪怕是最小的项目都是至关重要的。通过电话或者宣传材料来看，会觉得他们都挺不错的，但是你确实需要亲自去看看实际情况，然后才能做出正确判断。我见到的一家公司完全是在破败的建筑物里工作的，我立马明白了他们不适合我们公司。我最终找到了一个和我们的文化契合的团队，他们能力很强，而且在当地有着稳健的技术领导力。找到这一团队的关键之处在于真正了解我们的项目真正需要什么，然后找到与我们的价值观契合的公司。我也建议双方先合作完成一个小的实验项目。尽管这类小项目也往往是固定成本，而这很不敏捷，但是你还是会更好地理解他们的工作文化和行事方法。

InfoQ：敏捷价值观和原则适用于离岸团队吗？

Will Lord：我认为，深究敏捷宣言（不论你的方法如何，我认为敏捷宣言依旧是适用的）背后的原则就能发现，只有很少的几个是难以适用于离岸团队的。敏捷宣言十分强调商业利益相关者和开发者之间的紧密协作，包括面对面谈话和自我管理。我在实践中发现，无论团队是否离岸、外包或者自建，单人或者小团队实际上都有责任理解商业需求继而传递给开发团队。有时候这需要产品负责人（Product Owner）或者项目经理（Project Manager）来完成，但是这其实是一套能够与离岸团队协作良好的体系，因为有时候沟通是有困难的，而明确的责任职责通常是白纸黑字写出来的。通常对方也会有项目经理，所以就存在开发者与商业利益相关者被割裂的风险。我的解决方法是，确保开发者至少能够和产品负责人或者项目经理直接沟通，这样在必要时能够直接澄清所有问题。我们建立了 Slack 频道，所有 EdPlace 的成员和所有的离岸伙伴都加入了，这样谁有问题都可以直接找到相应的人。

尽管我认为定期出差进行面对面会谈是物有所值的，但面对面的会议确实难以实现的。好在技术一直在进步，我发现 Slack 和 Zoom／Google Hangouts 对于实时文字交流、视频通话和屏幕共享已经足够了。毫无疑问，坐在开发者旁边一起解决问题是十分有益而且往往效果更快更佳，但是对于离岸团队来说，这是不现实的。

我发现挑战最大的是帮助离岸团队实现自我管理／自我激励。因为委托方／代理方模型（离岸团队及其管理层担心，因为期望不同而导致执行了不清晰的指令可能造成后续关系恶化）的缘故，这是难以避免的问题。对我而言，这完全关乎信任和建立稳固的关系。这有可能关乎打破代理方的内部系统。例如，大部分人由于经费缘故而关注时间进度，但是这会导致与敏捷不匹配的时间追踪心态。对我们行之有效的方法是，对双方进行期望管理，所以开发者在管理自身时间、工作量和问题解决方式方面都是明确的。其中一些是记录在案的，一些是随着时间逐渐显现的。例如，我们在我们的看板系统里为团队提供了如何划分优先级的书面指导原则（对员工进行如何撰写自身工作事项并排列优先级的内部培训），所以问题可以按照正确的顺序执行而无需 EdPlace 团队的干预。

InfoQ：你们如何让敏捷落地？

Will Lord：随着时间发展，我们采用了 Scrum 和看板两种方法，并在离岸团队采用了这两种方法。看板对于离岸团队十分易用，我们在产品支持任务（ production support tasks）上采用了看板。最初我们用的是 JIRA 里的基本看板模版，包含“To do”、“In Progress”、“Done”三栏。稍后我们增加了“Ready”一栏，表示某项任务已经有 EdPlace 团队成员批准运行；增加了表示 QC 和部署前的用户验收测试（UAT）的栏目。我们使用了不同的分类话题——关键人物、bug、客服要求等等。看板系统成功的关键在于清晰的纲领发展，伴随着以开发者选取的顺序进行演示。“Ready”状态只是离岸团队能够自主查看整个清单并选择 EdPlace 团队认为优先任务之前的权宜之计——而有时候这是非常重要的，尤其是你和离岸团队有着 5.5 小时时差的情况下。

Scrum 更加复杂。我们在特性开发中使用 Scrum，我们的实施方式可能应该称为 Scrum-lite，甚至是 Scrum-like。因为 Scrum 太形式化，所以不太合适远程团队。不过通过一些调整，我们很好地用起来了。我们用 Slack 的签到功能取代了每日的站会，并对 sprint 计划和回顾工作的方式做了一些调整。规划分三个阶段完成：

• EdPlace 的内部会议，划分最高优先级事项；
• 开发伙伴的团队会议，确认前述事项的问题并做出粗略估计；
• 我自己和团队之间的最终会议，讨论他们的问题并在必要时修订估计结果。

与通常的计划会议相比，这个过程显得有点冗长和杂乱，但它能得到更加准确的估计和预期。在 sprint 快结束时，我们一般不会演示
Demos。这在一定程度上是时间差异问题，也是沟通问题——大多数开发者似乎更愿意用简短的书面说明来展示他们完成的工作。

采用 Scrum 最难的部分大概就是处理预估结果了。委托方／代理方的关系和印度的工作文化二者似乎都导致了将开发者的首次承诺作为预估结果。在我觉得软件开发的预期调整是不可避免的、该欣然接受的情况下，我们的开发团队有时候会对调整预期缄口不言，更愿意加班到深夜以按照原定预期完成工作。我还是觉得这是信任和工作文化的问题。我明白了，我们的开发者很关心做很多显而易见的工作，这样他们就显得产出比较多。一旦我理解了这一点，我就能够把自己的期望更加清晰地传达给他们，并且告诉他们，我更关心结果和质量而非解决多少问题或者某人的工作时长。随着一次次持续重复这些内容，开发团队逐渐明白了，这些对我是重要的。显然这个过程不是立竿见影的。

InfoQ：你从初创企业的离岸敏捷中得到了哪些收获？

Will Lord：离岸敏捷是完全可以实现的。有时候人们在告诉别人他们的原型是由离岸团队完成或者他们的部分开发团队位于远程比如乌克兰的时候，他们会显得不太自在。我感觉人们的观点正在改变。本地招聘开发者的过程是极其漫长而昂贵的，人们已经开始意识到还有更加快速和省钱的方式来完成工作。随着通讯技术的发展，这一过程变得越来越简便了。所有类型和规模的企业活动都至少有一些工作是离岸完成的，但却不一定是以特别敏捷的方式完成的。作为初创企业的我们明白了，只要你理解敏捷的限制因素，你就可以在离岸团队实现敏捷。除非你能找到领域、市场或文化高度符合的团队，否则离岸产品或者用户体验设计仍是高风险和易出错的。类似的，期待离岸伙伴为你的技术战略负责也是错误的想法。他们当然可以为你指出正确的方向，但他们却受到自身商业需求的限制。你们公司的人还是需要能够充分理解真正采用的技术。如果你们不具备这样的理解能力，那就要么聘用一位负责团队战略和方法的团队负责人或 CTO，要么找一位至少能做一部分这类工作的技术顾问。

InfoQ：在采用离岸团队方面，你有什么建议？什么情况下不建议使用离岸团队？

Will Lord：如果你很清楚自己的产品要做什么、你想赚钱、你能够找到好的离岸伙伴（如果可以，能够有人推荐）并且可以管理离岸伙伴的关系，那我觉得你能和离岸团队一起完成很多有价值的事情。然而，如果你的产品或者项目有很高的技术不确定性或者技术本身就是产品，那我觉得最好同时采用本地办公团队和离岸团队。如果你寻找的是完全自主独立的团队，那离岸团队肯定不适合。因为就算你花了大量的时间精力来处理委托人／代理方的关系，他也还是不可能达到独立自主状态的。

受访者介绍：

Will Lord 是位于伦敦的教育科技初创企业 EdPlace 的前任 CTO 和现任董事会顾问。在加入 EdPlace 之前，Lord 在一系列慈善目的数字化项目工作，包括 Royal Horticultural Society、UNICEF、 the International Rescue Committee 和 War Child。他曾在赞比亚和津巴布韦居住数年，为慈善事业和行业客户从事设计和通信工作。他现在是一位全职爸爸，终于可以心安理得地不用整天都盯着电脑屏幕了。

阅读英文原文: Offshoring Agile When You Are a Startup

感谢薛命灯对本文的审校。