这是鼎叔的第四十二篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。
第四个文章专辑《外包和远程项目的敏捷管理》启动了，现在开始第一篇。
随着全球化和信息技术的发展，以及疫情的助推，多地点 “分布式研发” 成为新常态，给项目管理者带来很大的新挑战。即使团队分布在多个不同的地点，各种经典敏捷实践活动都是适用的。
本文参考了 Craig Larman 和 Bas Vodde 的观点，他们是《精益和敏捷开发大型应用实战》的作者。
Erran Carmel 在《全球软件团队》中指出了多地点开发团队遇到的五种离心力，它们破坏了团队和角色的协作，并削弱了绩效：地理位置的分散，团队性的丧失，沟通丰富性的丧失，协调的分崩离析和文化的差异。
围绕这些离心力的思考，我们（敏捷教练）可以进行如下改良实践，总结出成功的解决方法。
1 减少研发站点数量。敏捷教练和利益相关方（管理层）进行充分沟通，使他们意识到研发站点的爆发增长带来的负面影响，并且可能导致项目失败。
注意：即使团队坐在一栋楼的不同楼层，他们也可能是 “分布式研发团队”，因为平常都是线上联系，没有互相走动。
多地点研发对于项目交付效率肯定是有影响的，离心力很强大，据行业调查，多地点开发的开发耗时是同地开发的两倍。所以，任何公司，如果能把团队布置到一个地点，这都是优先选择。
对于大型分布式开发团队，每个站点的团队最好都是数个完整的特性团队，因此是 “分而不散”，单个特性团队并不会跨地域工作。每个站点中的特性团队，都是卓越人员组成的小型团队在工作，而并非由平庸人才组成的大型团体。
2 针对产品而非站点来创造迭代。多地点研发团队创造一份潜在可交付的产品增量作为共同的挑战，不能每个站点设置一个独立的迭代。
要做到这点，当然需要持续集成的基础设施，共享大规模测试自动化和同一个代码库。
3 避免以组件或职能来组织站点。比如，把测试组集中放在站点 A，把架构组放在站点 B，这种组织形式因为沟通阻碍会把协作依赖变得错综复杂。一个特性的完成会牵扯到远在天边的组件团队的联调和延迟。如果每个特性团队自给自足，不需要太多和其他团队的协调来完成特性，多地点开发就变得非常简单了。
4 如果团队不得不分散，那不同情况下的分散的负面影响是不一样的。语言、文化和时区是否相同，过去是否在同一地点工作，是否互相信任，是否经常视频等，都会导致负面影响的程度不同。
当一个新站点被加入到现有产品团队时，对产品的知识和能力会存在问题。这是应该尽量用同步工具沟通，来鼓励团队性，如视频会话，IM，共享桌面编程等。这种方式下，分散式团队最好有大部分重叠的工作时间，时区差距不大。最好试着把所有分散团队的成员组织在同一个站点工作几个迭代，建立真正的信任关系。
5 逐步向同地点 Scrum 特性团队模式转变。把团队结构的改变集中在最高优先级的待办条目上，这样改变的投入产出效率最高。
一个新的特性团队就从原有团队中建立起来，它通过实践验收测试驱动开发，以及自动化特性测试，就不再依赖远程的测试团队，仅仅是通过视频会议获得远程专家的评审意见。远程测试团队更多地关注于在持续集成系统中编写全面自动化测试。
新特性团队通过和其他站点的组件专家进行分布式结对编程，代码审查，学习如何在不熟悉的组件上工作。
新特性团队要和某需求区域的产品负责人在同一地方工作，一起参加 scrum 活动。注意：需求区域是从客户角度对产品主要特性集的认知，它和产品组的工作地点和组织架构没有必然关系，所以不用刻意围绕产品负责人的地点来安排研发团队站点（能在一起当然更好）。
总之，尽可能在现有站点学习需要的新知识，而不是增加新的站点。相关的外地专家可以飞过来指导，审查，结对编程或者远程视频研讨。
6 多地点团队的协调诀窍
多地点开发团队的成熟阶段，应该是各站点从根本上平等合作，参与对产品愿景和架构的驾驭，积极性和互动质量充分提高。
多地点开发团队共享同一个代码库，跨地域持续集成所有代码，采用编译构建耗时更短的工具。
百闻不如一见，视觉对于建立关系和丰富沟通时非常重要的。
进行大型团队视频研讨会议时，采取发散 - 聚合循环的议程，让各个站点单独进行讨论活动，再让所有站点现身说法，通过视频展示成果。
多地音视频会议时，建议每次都说出自己的名字。一旦听不清对方，就立即告知。不要长时间讲话，定时询问对方是否听到并理解。积极倾听对方的发言并尝试理解观点。当会议室开始一个本地讨论时，要向其他站点人员进行现场解释。
多地团队故事点估算时，主持人可以利用在线 WIKI 或共享表格，整理对方输入的回答，而且所有站点可以实时访问，还可以同时进行投票。还可以准备实体计划扑克（大卡片），写上粗大的字体，通过摄像头可以看清楚。
异花授粉：即安排负责人访问其他站点，参与 scrum，花上很长时间和当地团队紧密工作在一起。注意访问者不能成为两个站点的中间人，而是牵线搭桥，帮助当地人员建立和其他站点人员的直接关系。有些站点对于到访的关键访问者会公开欢迎介绍，以便周知来者的背景以及来访目的。
建立多地点的实践社区（CoP)。在多地点 CoP 的环境中，异步沟通工具更为重要，比如 WIKI，博客，网站推送等。一个受到正式承认的 CoP 组织以及一些积极的社区协调员会特别有帮助。一个大型项目的共享平台 WIKI，建议安排管理员，让无组织无纪律的 WIKI 保持半结构化，修剪杂乱内容。
对于 Scrum 的回顾会议,除了最低层次的单团队回顾，以及完全的多地点产品级回顾，在两者之间还有中间层级的联合回顾是值得尝试的。比如：所归属的需求区域级别的回顾，或站点级别的回顾（聚焦关注工作环境，物质和文化）。
7 注意多地点交流的文化和规范。通过共享的词汇和概念来创造基本的共通文化。对于不同国家的团队，理解不同文化下的管理者权力和个人主义的差异。
8 工具。
推荐可多地点会话的音频视频工具，并可录制回放。推荐使用手写屏电脑，方便把手绘草图保存为共享文档。不建议购买专门在视频室使用的昂贵系统，而是用简单的视频软件和投影机等解决方案。
不推荐使用商业 “敏捷” 工具，因为工具越花哨，越专业，就让人把关注点吸引到工具上，而不是人们之间的互动上了。敏捷教练鼓励在研讨会上使用简单而有形（实物）的协作工具。对于协作软件工具，要挑选极其简单的免费工具，这也是建立跨站点通用工具的便利方法。
商业工具可能会拖慢多地开发，比如为新人和新站点花费时间申请使用许可。而工具需要接入公司网络以获取访问许可，这也会影响本地化离网开发。公司预算限制也会延误商业工具购买。
多地点开发的挑战不在于工具，而在于人员和观点。