共计 4691 个字符，预计需要花费 12 分钟才能阅读完成。
摘要：Scrum 等敏捷开发框架，最初都是为 5 到 9 人的小团队设计的。通过保持专注和合理利用新技术，在相当长的时间里小团队仍然可以支撑业务发展。随着业务成长，小团队的产出可能跟不上业务需要，团队就会面临规模化的问题。
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
作者：张迎辉，花名问菊，阿里巴巴敏捷教练，罗汉堂讲师，开发和讲授多门敏捷课程。先后支持手机淘宝、优酷、阿里文娱广告、阿里健康等多个部门的团队敏捷转型。亲身感受到敏捷给团队带来的改变，立志成为敏捷践行者.
阅读作者更多内容：
阿里敏捷教练，全面解析淘宝直播敏捷实践之路
敏捷团队的病与药——阿里健康 B2B 团队敏捷转型手记
打造真正的 One Team，持续快速交付价值——阿里文娱广告团队敏捷实践
阿里敏捷教练如何优化优酷需求分析流程？
本文作者：云效鼓励师阅读原文
本文为云栖社区原创内容，未经允许不得转载。
