如何多团队大规模实施敏捷开发

Posted 2023-04-22

参考技术A 本场景描述的是针对多个Scrum团队/敏捷团队，开发同一款大型产品，或者大型项目的敏捷应用场景。Leangoo多团队大规模敏捷开发模板是基于大规模敏捷模型定义的，可以适配基于Scrum of Scrums, Scrum@Scale，LeSS和SAFe等模型。Leangoo多团队大规模敏捷开发模板，在团队级使用的是标准的Scrum模型。

Scrum是用于开发和维护复杂产品的一个框架。上世纪90年代，Scrum在全球已得到广泛应用,Scrum最初用于产品研发，目前已广泛用于软硬件开发、互联网、人工智能、学校、政府、市场、管理组织运营等诸多领域。随着技术、市场和环境的复杂度和不确定性持续增长，Scrum在处理复杂性方面的效用日益得到证实。

​Scrum of Scrums 简称SoS ，是一个跨团队协作的Scrum团队。这个团队由各个Scrum团队的Scrum Master组成。SoS需要召开每日例会（Scaled Daily Scrum，简称SDS）SoS拥有一个Scrum Master进行多个团队的协调工作。如下图所示：

​

对于大型互联网产品、企业级软件产品、大型项目或解决方案来说，通常需要多个团队协作进行开发，针对这种情况，我们可以在Leangoo中按照下图的思路创建Leangoo项目：

​登录Leangoo后，在企业中创建项目，项目类型选择“敏捷开发”， 项目模板选择“多团队大规模敏捷开发”。 创建后系统会默认创建6个Leangoo项目，一个整体产品规划和5个开发小组：

产品规划组

产品规划组用于管理整个项目的产品路线图，产品需求（Product Backlog），缺陷（缺陷看板），跨团队协作（Scrum of Scrums看板）等，项目中的所有内容整个团队可见。产品路线图，产品Backlog看板、缺陷看板由产品负责人负责管理。Scrum of Scrums看板由SoS Master负责管理。

开发小组01

Scrum团队自己的Sprint看板，每个迭代一个。

开发小组02

Scrum团队自己的Sprint看板，每个迭代一个。

开发小组03

Scrum团队自己的Sprint看板，每个迭代一个。

开发小组04

Scrum团队自己的Sprint看板，每个迭代一个。

开发小组05

Scrum团队自己的Sprint看板，每个迭代一个。

您可以根据您的团队数量增减开发小组的项目。创建新的小组时，项目类型请选择敏捷开发，模板选择空白项目，然后再创建Sprint就可以了。

多项目示例：

产品路线图是重要的产品管理工具。产品路线图是一个高层次的战略计划，它描述了产品在未来一段时间可能会如何发展和壮大。产品路线图确保整个产品团队持续关注产品的目标，帮助产品负责人把握产品的战略方向，调整产品的优先级和产品规划。通过Leangoo可以帮助您创建价值和目标驱动的敏捷产品路线图。

以下场景产品路线图规划是可选的 ：

已经进入稳定期，处在持续微调阶段的互联网产品、SaaS软件或平台

已经进入维护期的产品，如已经趋于稳定的银行、保险、运营商的业务支持平台

短期定制外包项目

短期小型项目

产品路线图规划的频率基于产品特征、产品规模和复杂度，以及产品推向市场的频率来决定。

市场变化较快，响应要求高的产品，可以按照月度进行规划，对于企业级大型产品或解决方案可以按照季度进行规划。

​

1、创建一个产品路线图

在Leangoo产品中，我们推荐使用共享的Leangoo脑图来进行可视化的产品路线图规划。打开一个Leangoo项目，点击“脑图”Tab页，可以创建一个产品路线图的脑图，下图是一个示例：

2、管理版本需求

在基于Scrum的敏捷开发模型下，我们通过产品Backlog（产品待办列表）来管理产品/项目需求。对于使用了版本规划的场景，我们需要为每个版本创建一个产品backlog看板。

​

产品Backlog是一个按照商业价值排序的条目化的需求清单，，在产品backlog中需求通常使用用户故事来表达。在Leangoo中提供的产品Backlog模板，根据需求的优先级和规划，把产品Backlog分为了五个列表，通过这五个列表将需求规划到迭代：

待梳理需求：放还没有经过细化和梳理的原始需求，或者还需要进一步澄清和分析的需求。

以后的迭代：放近一两个迭代不会开发的需求清单，清单中，越是上面的需求，优先级越高。

下个迭代：较高优先级，下一个迭代预计会着手开发的需求。

当前迭代：最高优先级，规划到当前迭代开发的需求。

已交付：以前的迭代已经交付的需求。

在这个产品backlog当中，越往右，优先级越高，越往上面，优先级越高。需求按照价值高低从左向右流动。

打开产品Backlog上的故事卡，可以编辑和查看用户故事所有细节，如下图所示：​

针对如下场景：

1>已经进入持续调优阶段的互联网产品、SaaS软件或平台

2>已经进入维护期的产品，如已经趋于稳定的银行、保险、运营商的业务支持平台

3>短期定制外包项目

4>小型项目

通常不适用产品路线图规划，不存在多个版本规划的情况，一个项目只需要一个产品 backlog看板就可以了，产品backlog的结果和多版本规划情况是一样的。如下图所示：

Leangoo敏捷开发模板使用的是双层看板结构，第一层看板是产品Backlog看板，用于管理需求清单和需求规划，可视化展示需求的进展情况；第二场看板是Sprint（迭代）看板，用于管理当前Sprint的需求和开发任务，可视化展示每个Sprint的需求和任务进展情况，每个迭代一个迭代看板。两层看板结构如下图所示：

​

我们在产品Backlog中将需求规划到当前迭代后，我们就需要为当前迭代创建迭代看板，迭代看板每个迭代一个，在迭代看板上可以进行迭代计划和任务分解，基于迭代看板跟踪任务进展和进行团队任务协作。

针对于大型团队，分为多个开发小组，每个小组都需要创建自己的迭代，如果下图所示：

​

每个迭代看板上的需求引用自产品Backlog规划到本迭代的需求，如下图所示：

​

迭代看板的结构包括4个列表和多个泳道，每个需求（用户故事）一个泳道。

4个列表分别是：

用户故事：这个迭代计划完成的用户故事。

待办：用户故事分解得到的开发任务，处于待开发状态

进行中：正在进行的任务

完成：已经完成的任务和故事都放到这个列表

迭代看板示例如下图所示：

​

1、迭代进展跟踪

燃尽图是Scrum中的一个简单实用的团队进展跟踪的工具，能形象地展示当前迭代中的剩余工作量和剩余工作时间的变化趋势。一般在每日站会后团队会根据任务的完成情况对其进行更新。在迭代看板上，点击看板统计图标，即可打开燃尽图。如下图所示：​

2、版本进展跟踪

类似于迭代燃尽图，为了确保某个版本能够按计划准时发布，达成版本发布目标，我们需要跟踪这个版本的进展。在Leangoo中，我们可以通过发布燃尽图来进行跟踪，点击“产品Backlog – v3.1”的看板统计图标，即可打开版本燃尽图。如下图所示：

​

​

3、团队速度统计

团队速率是一个Scrum团队在一个Sprint中实际完成的工作量（通常使用故事点作为团队速度的单位）。每个Sprint结束时，Leangoo可以帮助团队自动记录当前Sprint完成的工作量，并且自动生成团队速率的可视化统计图表，方便团队了解团队效率变化的趋势，以及分析异常。

4、项目进度统计

在Leangoo项目中，系统也会根据项目需求的总体完成情况，统计项目的总体进度，并进行预计，严重延期的项目红色预警，进度偏差警告黄色预警。预警阀值可以进行项目自定义配置。

1、缺陷看板

在Leangoo的敏捷项目中，默认创建了“缺陷看板”，用来管理项目/产品缺陷，如下图所示：

​

当前迭代的缺陷，建议放到本迭代的迭代看板上，在迭代结束前修复完成。“缺陷看板”通常存放发布后遗留的缺陷，客户反馈的缺陷，生产环境发现的缺陷等。

您可以通过Leangoo看板自定义缺陷修复的流程，跟踪缺陷的修复状态，了解缺陷处理过程中是否存在等待和瓶颈，以便于及时调整，优化团队的工作效率。

2、缺陷卡片

在缺陷看板上，您可以通过缺陷卡片记录缺陷的详细信息，包括缺陷的类别，负责人，工作量，缺陷的截图，描述等等。您可以跟进需要自定义字段，自定义缺陷卡片需要记录的信息。

​

3、基于缺陷看板进行缺陷分布统计

Leangoo支持通过不同的维度对缺陷进行分布统计，如下图所示：

​

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

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

1、保持小团队

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

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

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

2、业务单元特性团队

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

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

作为一个超级 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

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

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，一些复杂的修改最好预先进行设计评审。模块守护者可以是兼职的，只要保证每周抽出一定比例的时间维护模块代码即可。

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

4、小结

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

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

参考资料：

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

[2] 

[3] 

作者简介：张迎辉，花名问菊，阿里巴巴敏捷教练，罗汉堂讲师，开发和讲授多门敏捷课程。先后支持手机淘宝、优酷、阿里文娱广告、阿里健康等多个部门的团队敏捷转型。亲身感受到敏捷给团队带来的改变，立志成为敏捷践行者。

你可能还喜欢

关注「阿里技术」

把握前沿技术脉搏