“大团队”和“敏捷开发”，谁说不可兼得？

阿里妹导读：当小团队的产出跟不上业务须要，团队就面临规模化的问题。从1个团队到3个团队，仍能够经过简单的团队沟通保持高效协做。当产品复杂到须要5个以上团队同时开发时，咱们须要必定的组织设计来保证团队间的顺畅协做，使得多团队共同开发一个产品时仍能保持敏捷性。这时候的组织该如何设计？今天，咱们听听阿里敏捷教练怎么说。

一、保持小团队

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

一方面，经过保持专一：Do one thing and do it well，小团队能够聚焦于核心业务，摒除没必要要的干扰。有一款微处理器 ARM 比英特尔先作出来，团队的一个leader 说：“回过头来看，当时咱们决定作一款微处理器的时候，我认为我作了两个重要的决定。我信任个人团队，而且给了团队两件英特尔和摩托罗拉永远不会提供给他们员工的东西：第一是缺钱，第二是缺人。他们不得不保持简单”。[2] 相似的，创办于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 的工做是引导和支持信息流动和知识共享，而不会像传统职能经理那样负责分配工做。

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

三、无限制特性团队

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

不一样于围绕业务单元组建的特性团队，无限制特性团队没有相对独立的业务领域，多个特性团队共享一份产品代办列表（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 和阿里健康的案例，我相信多团队开发一个产品仍然能够保持敏捷。

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

原文连接 本文为云栖社区原创内容，未经容许不得转载。