建设分布式敏捷团队经验分享

　　realestate.com.au(简 称REA)是澳洲最大的房地产垂直搜索和广告平台，它与ThoughtWorks西安一年半以前开始合作，迄今为止，已成长为规模上包括6个团队， 近50人，技术上涵盖Ruby/RoR, Java/Groovy， Android/iOS, 业务上囊括所有领域的大型团队与研发中心。

　　尽管REA同样是敏捷成熟度非常高的组织，ThoughtWorks与REA 的合作也历经一年多的摸索和调整才渐渐走上正轨。回头去看这一年中经历的困难和挑战， 很大一部分是分布式环境带来的，而团队规模则扮演了困难放大器的角色。

　　究竟哪些敏捷实践在分布式环境中比较脆弱，容易走样？如何解决？让我们用极限编程的洋葱圈模型来探讨这个问题。从内到外， 洋葱圈模型把敏捷实践划分成了个人、团队、组织3个层面。而据我的观察，分布式环境常常对组织和团队层面的敏捷实践产生直接或间接的影响：

　　无间断视频连接起来的完整团队

　　完整团队意味着在组织团队时尽量将所需的各种角色配置到团队中，起到减少交流壁垒、减小反馈周期、增加决策及时性与合理性的效果。我们团队的现状是界面设计 师、开发工程师、测试工程师和一部分业务分析师分布在西安，而产品负责人、客户代表等则分布在澳洲。分布式的开发环境造成了中、澳双方都无法建立完整团 队，大部分的工作都需要双方配合完成。随之而来的问题是：

• Email常常无人响应
• 问题需要来回多次才能得到确认，而时差和假日则常常把这段时间拉长为数日。
• 牵扯到多方参与的活动在时差的影响下非常难于计划和实施，比如验收测试、优先级调整、功能验收等。

　　就我的观察来看这是急事与要事博弈的结果。理论上要事应当优先，但事情的紧急性更容易感知，产生的短期压力也更大，所以体现在多数个体和组织上的行为方式往 往是急事优先。千里之外的中国团队主要通过邮件交流，邮件给人的感觉往往没有当面交流来的急迫和压力大，所以中国团队的问题没有被优先处理就不奇怪了。

　　能否创造一个易于谈论要事的环境？ 能否让中国团队的请求产生同等的急迫感和压力？ 通过不断的尝试我们发现利用 Skype建立无间断视频(Always On Video)对改善交流问题有非常好的效果。下图是我们用电视、Mac Mini和Skype建设的无间断视频设备:

　　中国和澳洲团队分别购置了大屏幕电视，摄像头，麦克风，注册了机器人帐号，将Skype设置为自动接听、自动打开摄像头，专门用于在上班时的不间断联系。

　　不间断视频让双方可以随时发现相关责任人是否在座位上，并随时就问题展开讨论，迅速得到确认，大大减小了确认问题花费的时间 。 除此之外不间断视频同时也成了团队建设的工具，双方见面机会多了，时常都会开开玩笑， 让团队成员之间更加熟悉和了解。

　　不间断视频的引入大大减小了距离产生的不便，让团队在分布式的环境下依然可以高效的交流，快速的反馈。

　　化整为零的成果展示

　　每个迭代后，团队都会给澳方的产品经理、客户代表进行成果展示，演示在当前迭代中团队都完成了哪些功能，客户代表和产品经理会对特性进行验收以及对产品本身 和团队的运作状况进行反馈。成果展示会议通常会持续1、2个小时，由于参与人数多，在时差的影响下会议时间非常难以协调，造成关键人物无法到场或者会议无 法按期召开，从而使开发团队积压了很多没来得及验收的功能，既影响开发进度又影响士气。

　　既然2个小时的成果展示会议难以预定，化整为零会怎么样？ 如果同时协调中澳双方的时间比较困难，引入在澳洲的代理人如何？

　　团 队在回顾会议后把这些想法提了出来，在后面的迭代中，团队在每个功能完成后立即向澳洲的负责人进行成果展示、收集意见，这样每次验收只需要10多分钟，在 无间断视频的帮助下，团队可以随时发现负责人是否在场，利用各种碎片时间召开会议。下图是团队利用Skype的共享桌面功能与客户进行视频演示的现场截图。

　　在迭代结束后，澳洲的负责人对各个特性已经心中有数，他再代表团队与所有相关人召开更大规模的成果展示会议，因为同样身在澳洲，组织会议就更方便、灵活。

　　通过化整为零以及引中间人，团队有效的减少了无法验收的功能，加快了反馈的周期。

　　持续发布与自动化

　　尽快发布，尽早发布是REA在线业务的客观要求，也是REA与ThoughtWorks双方所相信的文化。尽管双方都希望能够每日发布，甚至按功能发布，然而现实的种种困难让双方不得不妥协为每两周发布。

　　发布是一个需要多方共同参与、协作的过程，在我们这个分布式的环境中，产品环境的管理、维护以及产品的部署是由澳洲的运营团队完成的。但部署过程往往不是一 帆风顺的，一旦出现技术问题则需要中国团队来排查和解决，有时甚至需要三方甚至四方会诊。 环境的不可控、远程定位问题的困难、高昂的交流成本， 三小时的时差都增加了频繁发布的痛苦，让双方妥协为每两周“痛苦”一次。

　　从根源分析，我们的痛苦来自于：

• 知识传递的困难：产品环境与测试、备份环境相比，复杂度更高也更敏感。学习这些知识是需要专门投入的长期过程，运营团队不放心把产品环境交给开发团队进行测试与部署。不了解产品环境又引起开发团队出现各种纰漏，比如遗漏更新部署脚本。
• 手工过程让运营团队成为瓶颈：最终的产品部署是半自动化半手工的过程，每次发布都都需要协调运营团队参与， 手工过程的费时费力让运营团队无法保证高频率的投入。
• 手工过程增加了交流成本：因为手工过程容易出错，一旦出现问题就需要双方在一起排查，时差和分布式的环境都增加了交流的成本。

　　我们能否把在发布中需要交流的内容内建、固化在自动化脚本里？从而降低交流成本，提高效率和正确性。我们能否让发布的过程无痛，从而能更频繁的发布？

　　经过摸索，团队使用了Capistrano、Chef通过Amazon的节点搭建出整套的部署环境，同时利用Go构建了持续发布的流水线：

　　在这个过程中，产品环境的不一致性被一一修复，运营团队把产品环境的维护策略固化在Chef脚本中，让开发团队可以很方面的使用。开发团队利用运营团队给出的脚本在Amazon上搭建出了模拟产品环境的测试环境，在尽量真实的环境中进行测试，来减少未来上线的风险。

　　我们目前的发布过程是：

　　1、单元测试、静态检查、覆盖率、打包

　　2、运行单节点上的功能测试.

　　3、通过Chef在Amazon节点上创造出最小集群环境，在其上运行集成测试。

　　4、将通过测试的产品包发布到库中，供后续的探索性测试以及更大规模的集成测试使用。

　　5、自动部署在产品备份环境中等待A/B切换。

　　同时我们做到了在任何时刻测试人员都可以用一条命令取下最新的发布包、构建出集成环境，展开探索测试。

　　现在从提交到发布就绪耗时约1小时， 而整个发布时间则不超过15分钟，做到了每日发布。

　　低耦合与高耦合

　　在合作初期， ThoughtWorks和REA都倾向于在中国开发比较独立的系统 ，减小分布式环境的负面影响。 独立系统与现有系统的低耦合性，意味着相关责任人少、交流成本低、集成难度低、目标清晰、责任明确，同时独立系统即便出错，影响的波及面也比较小、风险易 于控制。

　　随着合作的加深，独立系统的弊端开始显现。独立性使得双方的合作难于在更大的范围引发关注，缺乏了工作平台，就难于使众多的职能领导，如产品架构师、测试架 构师、运营团队等和开发团队形成强烈的责任感和团队意识，组织间多点对多点的关系因此很难建立，而集成点少、集成难度低意味着对于现有遗留系统的理解不 足，难于承担更复杂重要的工作 ，团队很难扩张。

　　在后续的项目中，双方注意到了上述问题，意识到与现有系统耦合度高的新系统对于加深双方的合作是有积极作用的，从而有意识的进行了投入。双方团队一起设定业务领域 的上下文、制定发布计划、确定技术路线，利用上文中提到的种种实践紧密的工作在同一个代码库之上。

　　这样的工作方式不可避免的增加了出现问题后影响的波及面 ，在我们团队的构建脚本中有个任务叫prePush，它会运行所有的单元测试和部分关键的功能测试。在工作一段时间后，中国团队认为对代码已经相当熟悉 了，就放松了要求，结果是构建失败后一下影响了澳洲3个团队无法提交代码。

　　这件事情发生后我们才发现代码库远比想象的复杂，我们对遗留系统的理解确实不到位，分布式环境会大大增加修复构建的难度和压力。这迫使团队在执行集成实践时更具纪律性，严格执行失败构建不过夜。为了让问题早发现，早处理，团队还开发了基于Jenkins的插件来让构建结果更醒目：

　　对于结果特别重视的团队还用上了指示灯：

　　对错误的及时响应，一方面缩短了故障时间，规避了开发高耦合系统的弊端，另一方面很好的建立了双方互信的关系。

　　隐喻

　　分布式环境也会增加建立隐喻(Metaphor) 的难度。所谓隐喻是指在项目中的每一个人都使用相同的表达方式来解释同一个概念，表达方式可以是语言或者图表，概念可以是项目目标，架构或者业务概念。譬 如“成为中国的谷歌”就可以是一个项目目标的隐喻，它往往通过牺牲概念的精确性来增加概念的流通性。

　　对 隐喻的学习常常是在使用中进行的，通过反馈、矫正和调整与他人保持一致。譬如在星巴克点咖啡， 中杯代表着最小的杯子，我们往往通过与咖啡师交谈或者点错了杯的经验会促使我们在下次使用正确的隐喻，然而分布式环境较高的交流成本以及不同的文化、语言 背景往往会形成多套不同的隐喻，让交流变的很困难。在团队刚建立时，我们的团队成员有的用滑动图（Sliding Image），有的用大图指代首页上的一张图片，结果澳洲团队常常困惑于中国团队在谈论什么问题，后来我们发现它的术语叫做主图(Hero Image)。

　　类似的问题不仅仅存在于用户界面的组件和元素中，而且在技术词汇更为通用的项目架构，部署模型，持续构建流水线中，也会出现隐喻不一致的情况。 这些不一致的隐喻不仅会增加团队沟通的开销、它也会体现在代码和设计中，以错误的命名，不合理的抽象等形式降低设计的表现力。

　　通过摸索，我们发现术语表和可视化是是一个比较经济有效的解决思路：

　　有了术语表不论我们和澳洲的用户体验设计师沟通界面设计、和架构师讨论技术架构，或是和运维人员商量部署方式，因为系统隐喻不一致互相不理解的情况大大减少。利用术语表上的术语来进行命名，也让数据库表结构和代码的表现力更强、更容易理解。

　　除此之外，REA经常邀请中国团队在澳洲工作4～6周，在浸入式环境中快速掌握系统隐喻，中国团队也不断邀请REA的团队来到中国，更高效的达成共识。最近 我们开始尝试“101视频”：由澳洲的资深工程师给每个复杂系统录制一段5分钟的视频，进一步减低交流的成本、统一词汇、提升学习的效果。

　　为了让双方能更好的合作，让团队对业务领域有更多的了解，双方还设计了很多其它活动，比如把REA的内部活动Townhall（向所有员工公布上一段时间公 司经营状况，未来发展方向的活动）搬到西安，我们称之为mini-Townhall，帮助中国团队及时更新业务上下文；有的团队会每周留出半天进行骇客 日，团队在澳洲的负责人会把有趣的创新成果纳入到迭代计划中，最终成为产品的一部分，做到产品发展思路集体共有，通过上述种种活动尽量减少信息孤岛、减少 分布式环境对于团队产生的影响。

　　修复XP

　　回顾与REA一年的合作，我们经历了这样几个阶段：

　　●试水：通过高度独立性的系统建立信心以及明确初步的合作关系和合作方式。

　　●扩张：通过紧密的合作与一些开创性的实践从6人发展到45人。

　　●沉淀：从边缘技术与系统向核心技术与系统转移。

　　在这个过程中，REA和ThoughtWorks一起面对和解决了很多困难，摸索出一些手法让敏捷实践在应用场景更具生命力和适应性，譬如无间断视频、化整 为零的成果展示、同一代码库等。未来REA 与ThoughtWorks还将致力于延续信任关系，积极的一起发现问题，探索解决方案。

　　总结下来，我们所作就是XP的另一核心实践：修复XP。没有哪种方法是保证成功的，从简单的方式开始探索、及时真实的给出反馈、保持交流的开放、尊重差异、有勇气去面对困难，推动变化，这是我们学到的最重要的一课。

　　感谢在写作过程中我的同事索勤、刘尧、崔力强所给予的帮助，同时也对帮我审稿的诸多同事一并谢过。