在IT行业一直流传着一句话，说“敏捷只适合小作坊式的公司”，支持这个观点的人认为，尽管敏捷方法可以很好的在小团队内部发挥其效应，但一旦团队上了规模，或者出现多个团队共同协作的时候，敏捷的各种实践便开始变的捉襟见肘了。小马哥在做敏捷咨询和交付的日子里也常常会被客户问到以下一些问题：
1. 30个人的团队到底要怎么开每日站会？会不会一开就是一个小时？
2. 跨部门、跨团队的敏捷到底要怎么做？怎么去制定和执行计划？怎么去管理进度和预算？
3. 人越多，是不是沟通的成本就会越高？怎么确保信息的一致和沟通的高效？
乍一看，似乎这些问题都很尖锐，也实实在在戳中了所谓敏捷“缺乏流程和规则”的痛点。但其实，只要用对了方法，敏捷也可以在大型团队和项目中发挥出它特有的优势和魅力。今天小马哥便会用5分钟的时间，给大家分享如何运用规模化敏捷的思想去做跨团队的高效沟通。
跨团队协作模型
想要做到高效的跨团队沟通，第一步便是要充分了解你的团队所处的状态。在敏捷语境下，我们通常划分出三种常见的协作模型:
Divided – 隔离模型
隔离模型是传统软件开发模式里最常见的一种协作模型，它往往试图将一个大型项目拆分成几个相对独立的模块，并让每个团队去处理单个模块。几种常见的拆分例子有：
通过团队功能进行拆分。比如前端团队、设计团队、后端团队、测试团队这种通过团队功能来进行拆分的方式；
通过产品模块来进行拆分。很多大型的IT公司都习惯于用产品端口来进行团队拆分，比如网页端团队，移动端团队，后端团队，数据库团队等。
采用这种拆分方式的项目，往往各个团队之间的交流都相对封闭的，基本遵循下图的模型：
在隔离模型里，团队之间往往不会有直接的交流，而是通过项目经理，或者PMO来进行统筹规划和协调。这种方式看起来减少了很多沟通的成本，让团队成员能够专注在自己的事情上，实际上却产生了很严重的部门墙，甚至在很多时候会由于信息的缺失误解直接导致项目的失败。小马哥自己便亲身经历过一个类似的例子。
当时小马哥参与了一个数亿澳元的大项目，有一百来人的移动端团队和50人+的数据库团队，而小马哥当时所在的团队则负责中间层API的搭建。这种诡异的拆分方式暂且不谈，当时整个大项目便是采用隔离模型的沟通方式。小马哥的团队夹在中间，所有的业务需求都是通过文档的形式从移动端团队发来，而我们设计的API又以文档的形式交给后端数据库团队。在这中间，除了每月一次的review会议之外，没有任何的团队间沟通，所有的沟通都是通过PMO来串接的。 我们一直被告知“一切都很顺利”，结果在上线前一个月，问题终于集中爆发了：
1. 联调发现了许多的问题，很多都是因为需求理解不一致，又没有及时沟通发现导致的；
2. PMO的计划大大延迟，API团队的进度远远快于移动端团队，导致很多场景无法及时测试；
3. 数据库团队进行了好几轮的系统优化和重构，但是并没有告诉其他团队，导致联调一测就挂，而我们浪费了数日的时间debug才发现原因…
聪明的你肯定已经发现，小马哥是非常鄙视这种沟通模型的。在我的眼里，隔离模型是非常落后且高风险的，它将信息集中在了一群或许不那么专业的管理者手里，信息滞后和缺失不说，还大大增强了我们所谓的“single point of failure”。 那除了团队拆分的方式，还有一个简单的方式来判断你的团队是否是隔离模型，那便是通过沟通的渠道。
隔离模型下的沟通渠道往往具有以下特点：
1. 团队得到的几乎都是二手信息，并且几乎没有双向沟通；
2. 即使能和其他团队建立联系，也往往停留在邮件或者文档层面；
3. 不同的团队几乎没有面对面的沟通，目标以及计划设立也相对独立
如果你不幸中招的话，是时候开始改变啦！
Work Closely – 紧密合作模型
其实很多的管理者们都能意识到隔离模型的缺陷，然而当小马哥问他们为何不尝试着做一些改变时，他们常常给我这样的回答：
“不是我不想，但是这个是组织架构和文化的问题，我只是一个项目经理，我又能做什么呢？”
确实，想要彻底打破部门墙、减少汇报线、实现扁平化这些不是在项目级别能够解决的问题，它需要企业架构的重构，更需要高层的支持和驱动。那这是不是就意味着我们便什么也做不了了呢？ 其实不然，至少在解决跨部门、跨团队沟通方面，解决80%的问题非常简单，只需要“加一根线”，就成了紧密合作模型：
这是一条神奇的线，没有它之前，不同的团队隔海眺望，互相抱怨；有了它之后，跨海大桥建立起来了，港陆人民也可以一起唱国歌了。其实道理非常简单，通过连接起各个团队的team lead，至少会有以下的好处：
1. 化二手信息为一手信息，更加准确
2. 直接建立起双向沟通的渠道，更快的反馈时间
3. 不同团队间信任的建立
那在敏捷语境下，又如何做到去画出这一条美丽的线呢？学术点讲，SAFe给我们提供了一个方案，那便是“敏捷发布火车”:
简单点说，通过引入发布火车工程师，系统架构师和产品线经理三大角色，在每个发布周期里串联起各个交付团队，以实现从目标设立，到交付计划、跨团队沟通调度等各方面的整合和规划。这很学术，如果你感兴趣，可以看看小马哥的文章：SAFe 101 – 规模化敏捷怎么做？
当然，这篇文章是要跟大家分享在5分钟之内解决问题的办法，所以小马哥也给大家简化一下，解决问题的方法就是（当当当当~）：
1. 设立周会甚至日会，把项目相关的各个team lead们叫到一起，剩下的就交给他们自己去讨论吧 （当然也可以提前收集每次的topic,不过小马哥好懒…）
2. 改善沟通，建立更多的及时通讯渠道，比如Skype, Slack，Google Chat甚至钉钉、企业微信等。如果你够牛逼，甚至可以让他们在物理上坐在一起（亲测非常有效）
3. 共享文档，让各个团队的TL们能够拥有其他团队的文档甚至代码权限
怎么样，是不是超简单？是不是又超不削？先不要慌着diss, 亲自去试一试，你会回来感谢小马哥的~
One Team – 大团队模型
紧密合作模型可以解决80%的跨团队、跨部门沟通问题，那它却依然有自己的痛点：
1. 信息高度集中在team lead们手里，一旦他们请假，便会造成blocker；
2. 每个团队的team lead需要知道团队大大小小的信息，这会占用他们大量的精力，让他们无法去关注交付质量与持续改进；
3. 有些时候依然无法避免二手信息的产生，因为team lead并不全知全能
于是，我们便有了第三种协作模型，那便是大团队模型（再加几条线）：
在绝大部分的情况下，我们都无法真正的实现大团队模型，因为它要求不同的部门或者团队真的像”one team”一样去运转。想要实现这一点，至少要满足以下的条件：
1. 公司架构的敏捷转型实现去部门化和扁平化
2. 从用户价值维度去拆分项目团队
3. 管理者们的支持 （去中心化的管理和足够的放权）
4. 团队必须具备足够的敏捷成熟度，否则会导致混乱和浪费的产生
如果你足够幸运，能够在你的项目上尝试这个沟通模型的话，小马哥最后可以给你一些小小的tips:
1. 尽量确保对外沟通之前团队内部先统一意见，尽量避免团队成员A和B告诉其他团队的人信息不一致的情况；
2. 可以邀请对方团队的key members参加己方的站会，这样对于统一信息有着非常大的帮助，也很高效；
3. 将双方的文档有依赖的地方通过加link等方式连接起来，如果有Jira,trello等开发工具更可将相互依赖的用户故事直接link起来，并保持沟通；
4. 能够清晰的去区分大事和小事，大事最好还是通过team lead来集中进行沟通，这样会最大限度的避免过多的无效讨论。
好了，5分钟到了，希望这篇文章对你有所帮助呀，最后：
如果你感兴趣的话，欢迎来小马哥的个人网站qio一qio: www.himateng.com
