阿⾥敏捷教练：多团队开发⼀个产品的组织设计和思考
Scrum等敏捷开发框架，最初都是为5到9⼈的⼩团队设计的。通过保持专注和合理利⽤新技术，在相当长的时间⾥⼩团队仍然可以⽀撑业务发展。
随着业务成长，⼩团队的产出可能跟不上业务需要，团队就会⾯临规模化的问题。从1个团队拓展到3个团队，仍然可以通过简单的团队间沟通保持⾼效协作。当产品复杂到需要5个以上团队同时开发时，我们需要⼀定的组织设计来保证团队间的顺畅协作，使得多团队共同开发⼀个产品时仍能保持敏捷性。
保持⼩团队
在初创企业或产品刚起步时，团队通常都不⼤。随着业务的发展，需求越来越多，产品越来越复杂，很多团队的第⼀反应都是加⼈。事实上，加⼈并不是唯⼀选择，也未必是最优选择。很多时候，⼩团队能交付惊⼈的业务成果。
⼀⽅⾯，通过保持专注：Do one thing and do it well，⼩团队可以聚焦于核⼼业务，摒除不必要的⼲扰。，团队的⼀个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的⼯作是引导和⽀持信息流动和知识共享，⽽不会像传统职能经理那样负责分配⼯作。
与此类似，淘宝直播的业务、产品和研发团队也汇报给不同的职能经理。⾼度统⼀的业务⽬标把团队成员凝聚在⼀起，团队共同决定业务⽅向、业务⽬标以及如何达成⽬标。职能经理为业务发展提供⽀持和帮助，并帮助团队成员在职业道路上成长，并不会把主要精⼒放在具体的产品交付上。淘宝直播敏捷实践参见《》。
⽆限制特性团队
有时团队在业务发展时壮⼤了，但是经过了⼀段⾼速发展，原有的业务⽅向遇到了瓶颈，新的业务⽅向还在摸索中。此时，业务⽅向还不明朗，难以按照明确的业务单元组建团队，团队需要快速适应业务⽅向的变化。此时，要⿎励团队⼴度学习，避免局部优化。
不同于围绕业务单元组建的特性团队，⽆限制特性团队没有相对独⽴的业务领域，多个特性团队共享⼀份产品代办列表（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和阿⾥健康的案例，我相信多团队开发⼀个产品仍然可以保持敏捷。
在业务⽅向明确的情况下，按照业务单元组建特性团队是最理想的选择。在业务⽅向不明朗的情况下，可以先组建⽆限制特性团队，再逐步过渡到业务单元特性团队。⽆论采⽤何种组织设计，⽬的都是快速跑通业务闭环：持续地交付业务价值，并在真正的市场环境中检验假设，通过快速试错到在⼀定的利润⽔平上为企业或终端⽤户提供产品和服务的可⾏⽅法。
本⽂为云栖社区原创内容，未经允许不得转载。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。