Scrum等敏捷开发框架，最初都是为5到9人的小团队设计的。通过保持专注和合理利用新技术，在相当长的时间里小团队仍然可以支撑业务发展。

随着业务成长，小团队的产出可能跟不上业务需要，团队就会面临规模化的问题。从1个团队拓展到3个团队，仍然可以通过简单的团队间沟通保持高效协作。当产品复杂到需要5个以上团队同时开发时，我们需要一定的组织设计来保证团队间的顺畅协作，使得多团队共同开发一个产品时仍能保持敏捷性。

保持小团队

在初创企业或产品刚起步时，团队通常都不大。随着业务的发展，需求越来越多，产品越来越复杂，很多团队的第一反应都是加人。事实上，加人并不是唯一选择，也未必是最优选择。很多时候，小团队能交付惊人的业务成果。

一方面，通过保持专注：Do one thing and do it well，小团队可以聚焦于核心业务，摒除不必要的干扰。有一款微处理器ARM比英特尔先做出来，团队的一个leader说：“回过头来看，当时我们决定做一款微处理器的时候，我认为我做了两个重要的决定。我信任我的团队，并且给了团队两件英特尔和摩托罗拉永远不会提供给他们员工的东西：第一是缺钱，第二是缺人。他们不得不保持简单”。类似的，创办于2009年的WhatsApp于2014年被Facebook收购时，公司只有55名员工，全球活跃用户达到4.5亿人，日发送短消息达160亿条。

另一方面，随着开源运动、中台技术和云化技术的发展，很多非核心业务逻辑可以借助外力快速搭建，在业务高速发展的同时，继续保持一支精干的团队。例如，在阿里巴巴研发协同平台“云效”上，二十分钟就可以搭建一套Spring Boot web application的持续集成流水线，包含静态代码扫描、单元测试、编译、打包、部署、接口测试。不仅操作方便快捷，还省去了采购机器、部署和管理 build farm的开销。

业务单元特性团队

即便努力保持专注并用尽了技术红利，有时业务的发展还是远远超出预期，此时组建多个团队势在必行。

比较理想的选择是按照业务单元来组建特性团队。一个业务单元类似于一家小型创业公司，有自己的长期使命和愿景，有相对清晰的业务边界和盈利模式。人员方面，各业务单元有独立的业务、产品和研发团队。技术方面，各业务单元可以独立完成产品开发的全流程，包括业务决策、产品设计、开发、测试和发布，尽量避免业务单元之间的依赖。

作为一个超级app，手机淘宝分为几条业务线，同一条业务线内还分为几个独立业务。例如，微淘和淘宝直播都属于内容平台业务线，二者的内容生产、传播渠道、受众和盈利模式不同，因而是相对独立的业务单元。二者有独立的业务、产品和研发团队，业务目标也分开设定和衡量。

技术上解耦是各业务单元能够独立发展的前提。为了解决团队间的依赖，手机淘宝对架构做了容器化改造：一些必要的初始化操作放在common容器中，各业务在自己的bundle中。各业务bundle按需加载，只能依赖底层的common架构，不能相互依赖。这样各业务bundle可以并行开发，互不干扰。

按照独立的业务边界来组建特性团队，团队能独立发布新功能，迅速获得市场反馈，通过不断试错找到业务发展的方向。

全球第一大音乐平台、音乐流媒体公司Spotify也按照业务单元组建团队。在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds "[1] ，敏捷教练Henrik Kniberg详细介绍了Spotify模式。

Spotify的30多个“小分队”（squad）分布在全球的三个城市，每个squad负责产品的特定方向（例如搜索或radio）。每个squad相当于一个小创业公司，squad没有特定的主管，只有一位产品负责人（Product Owner）。PO负责业务方向，squad成员组成跨职能团队交付业务结果。PO帮助squad制定目标和管理优先级，也会定期维护公司层面的产品路线图并确保squad的目标与公司战略相匹配。squad被鼓励应用精益创业原则，例如先交付MVP（minimum viable product），并通过A/B测试来验证假设。此外，squad可以得到敏捷教练的帮助，敏捷教练引导squad持续改进并帮助团队移除障碍。

在squad之上，spotify还有两层组织架构：具有相关专业知识的人横向组成“分会”（chapter），工作在相似领域的squad组成“部落”（tribe）。此外，具有相同兴趣的人组成“行会”（guild）。

这套架构的主要目的，是促进全公司范围的信息和知识共享。员工向chapter lead汇报，在转换squad时汇报线不变。尽管看上去像普通的矩阵式组织，这个矩阵是向产品交付倾斜的。同一个squad的成员坐在一起，组成高度自治的跨职能敏捷团队，共同决定产品目标以及如何交付产品。横向的chapter维度只是为了更方便地共享知识、工具和代码。chapter lead的工作是引导和支持信息流动和知识共享，而不会像传统职能经理那样负责分配工作。

注：图片来自于

https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

与此类似，淘宝直播的业务、产品和研发团队也汇报给不同的职能经理。高度统一的业务目标把团队成员凝聚在一起，团队共同决定业务方向、业务目标以及如何达成目标。职能经理为业务发展提供支持和帮助，并帮助团队成员在职业道路上成长，并不会把主要精力放在具体的产品交付上。淘宝直播敏捷实践参见《阿里敏捷教练，全面解析淘宝直播敏捷实践之路》。

无限制特性团队

有时团队在业务发展时壮大了，但是经过了一段高速发展，原有的业务方向遇到了瓶颈，新的业务方向还在摸索中。此时，业务方向还不明朗，难以按照明确的业务单元组建团队，团队需要快速适应业务方向的变化。此时，要鼓励团队广度学习，避免局部优化。

不同于围绕业务单元组建的特性团队，无限制特性团队没有相对独立的业务领域，多个特性团队共享一份产品代办列表（Product Backlog），按照统一的优先级交付产品功能。无限制特性团队，并非所有团队都相同的无差别特性团队，每个团队还是可以有自己的特色和专长，只要多个团队组合起来能够按照Product Backlog的优先级交付特性即可。

2018年3月，我支持阿里健康互联网医疗业务线时，正遇到这样的情况：互联网医疗业务经过两年多的摸索，找到了一些可能的发展方向，但是还没有找到非常明确的盈利模式，多个方向都需要进一步尝试。研发团队包括服务端开发、H5开发、Android开发、iOS开发、测试等30多位同学。

在原有的资源池模式下，每月职能经理按照产品经理的输入，分配研发同学到各个项目中。由于业务的复杂性，产品涉及的核心应用有15个以上，除了电商平台的商品、库存、营销等基本功能，还包含互联网医疗特有的问诊、挂号等服务，并涉及到算法和AI。人员技能的瓶颈非常突出：部分核心应用只有一位同学特别了解。

2018年4月至5月，商品模块负责人和AI问诊模块负责人先后休假，相应模块的技术方案设计几乎停滞，严重拖累进度。为了平衡复杂的人员技能和项目需要，职能经理经常绞尽脑汁，仍然不免捉襟见肘，一线同学身兼多个项目非常普遍。多个项目都依赖同一位团队成员时，不得不串行等待。在多个项目间频繁切换也增加了上下文切换成本。

为了解决人员技能瓶颈的痛点，同时考虑到互联网医疗特定的业务发展阶段，尝试了无限制特性团队共同交付一个产品的协作模式：30人自由组合成两支特性团队。组队只需满足约束条件：人数均衡，核心应用在每个团队都有人了解，新老结合，男女搭配。组队成功后，两支团队从同一份Product Backlog里按照优先级领需求。如果某个团队无法独立完成当前最高优先级的需求，先由这个团队认领，另一个团队派师傅指导。师傅主要是培养徒弟，具体工作由认领团队的同学动手完成。

由于资源瓶颈的限制，2018年5月1日到6月14日需求交付的累计偏差（需求实际交付日期与计划交付日期的偏差累加）达到了151天。经过两个月的努力，两支特性团队都具备了完成各类需求的能力，团队可以完全按照Product Backlog的优先级领需求，既不需要团队成员并发支持多个项目，也不需要等待资源瓶颈的释放。6月15日到7月31日的累计交付偏差缩短到了3天。8月1日到8月31日继续保持准时交付，累计交付偏差为2天。团队成员的个人能力得到了充分锻炼，主动拓展技能承担重任的同学获得了晋升，得到了认可。团队的自组织能力也得到了发展，遇到问题和阻碍，团队成员会主动想办法解决，不再事事依赖职能经理。职能经理的角色从派活变成了辅导和帮助团队，减少了救火时间，有更多时间考虑团队的长远发展。

综上，无限制特性团队方案解决了业务需求等待资源瓶颈的痛点，不是让业务发展来匹配人员的技能，而是人员拓展技能匹配业务发展的需要。与此同时，团队成员的个人能力得到了锻炼，团队的自组织能力得到了发展，也解放了职能经理。

无论是业务单元特性团队，还是无限制特性团队，每个团队都要具有独立交付产品特性的能力。一个复杂的产品特性，通常都需要修改多个模块才能实现。多个团队修改同一个模块时，如何保证模块设计的一致性，并及时清理代码偿还技术债？

引入模块守护者通常是个有益的实践：每个模块最好有两位模块守护者互相backup，修改模块代码需要请模块守护者做code review，一些复杂的修改最好预先进行设计评审。模块守护者可以是兼职的，只要保证每周抽出一定比例的时间维护模块代码即可。

随着业务方向越来越清晰，业务模式逐渐稳定，无限制特性团队会逐步找到相对固定的分工合作模式，每个特性团队会逐步找到自己最擅长和最感兴趣的产品方向。明确的产品方向，为团队提供了长期深耕的条件，团队逐步成为某一领域的专家。此时，无限制特性团队就完成了向业务单元特性团队的过渡。

小结

通过手机淘宝、Spotify和阿里健康的案例，我相信多团队开发一个产品仍然可以保持敏捷。

在业务方向明确的情况下，按照业务单元组建特性团队是最理想的选择。在业务方向不明朗的情况下，可以先组建无限制特性团队，再逐步过渡到业务单元特性团队。无论采用何种组织设计，目的都是快速跑通业务闭环：持续地交付业务价值，并在真正的市场环境中检验假设，通过快速试错找到在一定的利润水平上为企业或终端用户提供产品和服务的可行方法。

参考文献：

[1] https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify