敏捷开发实践指南-Scrum+Kanban分团队规模

敏捷开发实践指南——Scrum/Kanban分团队规模

标签：敏捷开发|Scrum|Kanban|团队规模|项目管理|实践指南|看板|迭代

日期：2026年9月19日

一句话简介：按小团队、中团队、大团队三种规模，分别给出Scrum与Kanban的落地步骤、角色配置、会议节奏、

看板设计、度量指标、完整案例与避坑方法。

适用人群：敏捷教练、项目经理、研发负责人、产品负责人、ScrumMaster、团队负责人、技术管理者、产品经理。

文档类型：教程攻略类。

目录

一、敏捷方法与团队规模总览

1.1Scrum与Kanban核心差异

1.2团队规模划分标准

1.3方法选择决策树

1.4三种规模的核心挑战

二、小团队（1-5人）实践指南

2.1小团队特征

2.2小团队Scrum基础版

2.3小团队Scrum进阶版

2.4小团队Kanban基础版

2.5小团队Kanban进阶版

2.6小团队完整案例

2.7小团队工具清单

三、中团队（6-15人）实践指南

3.1中团队特征

3.2中团队Scrum基础版

3.3中团队Scrum进阶版

3.4中团队Kanban基础版

3.5中团队Kanban进阶版

3.6中团队完整案例

3.7中团队工具清单

四、大团队（16人以上/多团队）实践指南

4.1大团队特征

4.2大团队Scrum基础版

4.3大团队Scrum进阶版

4.4大团队Kanban基础版

4.5大团队Kanban进阶版

4.6大团队完整案例

4.7大团队工具清单

五、避坑指南

六、常见问题解答

七、关键词索引

一、敏捷方法与团队规模总览

1.1Scrum与Kanban核心差异

对比维度ScrumKanban

节奏固定迭代，通常1至4周持续流动，无固定迭代

角色产品负责人、ScrumMaster、开发团队无强制角色，可保留现有角色

会议Sprint计划、每日站会、评审、回顾可选每日站会、流动会议、复盘

变更迭代内尽量不变更，迭代间可调整随时可变更，按优先级拉取

度量速度、燃尽图、Sprint目标达成率周期时间、吞吐量、在制品数量

适用需求相对明确、需要固定节奏需求变化频繁、支持运维混合

起点从零建立团队节奏在现有流程上改进

看板Sprint看板，迭代结束后清空持续看板，列代表流程状态

WIP限制通过Sprint容量间接限制显式设置每列WIP限制

改进方式回顾会议驱动流动效率驱动

1.2团队规模划分标准

团队规模人数范围典型结构主要挑战

小团队1至5人单团队，角色兼任角色冲突、会议效率、需求来源单一

中团队6至15人单团队或多小组沟通成本、协调依赖、流程一致性

大团队16人以上或多团队多团队并行跨团队依赖、目标对齐、集成风险

1.3方法选择决策树

判断问题选择Scrum选择Kanban

需求是否相对稳定是否

是否需要固定交付节奏是否

是否存在大量紧急插入任务否是

团队是否支持运维、支持、开发混合否是

组织是否要求固定迭代评审是否

是否希望从现有流程渐进改进否是

团队是否少于5人且角色兼任可简化Scrum优先Kanban

是否多团队并行且依赖复杂可结合ScrumofScrums可结合多团队看板

1.4三种规模的核心挑战

规模核心挑战应对方向

小团队角色兼任导致优先级冲突明确一人一角色，减少并行

小团队会议时间被压缩站会控制在10分钟，计划会1小时

小团队需求来源多头指定唯一产品负责人

中团队沟通路径增多拆分小组，设置小组代表

中团队依赖等待时间长看板显示阻塞，设置解除阻塞责任人

中团队流程不一致统一DefinitionofDone

大团队跨团队目标不一致建立季度目标与ScrumofScrums

大团队集成风险高持续集成，每日合并

大团队依赖管理复杂依赖看板，提前识别跨团队依赖

二、小团队（1-5人）实践指南

2.1小团队特征

特征说明影响

人数少1至5人沟通快，但角色容易兼任

角色兼任产品、开发、测试可能同一人优先级冲突

需求来源集中通常一个业务方需求变更快

特征说明影响

流程简单无需复杂审批容易缺少纪律

交付周期短可快速发布容易忽略质量

会议少站会即可同步容易缺少回顾

2.2小团队Scrum基础版

2.2.1操作步骤

第一步，确定角色。做什么：指定产品负责人、ScrumMaster、开发人员。怎么做：1至5人团队中，产品负责人可

由业务方或产品经理担任，ScrumMaster可由开发人员轮流担任。示例：示例公司4人小团队，张先生任产品负责

人，李女士任ScrumMaster，王先生和赵女士为开发人员。

第二步，建立产品待办列表。做什么：列出所有需求。怎么做：用表格或在线工具创建产品待办列表，每条包含编

号、用户故事、优先级、估算。示例：待办列表第一条为“作为用户，我希望用手机号登录，以便快速进入首页”，优

先级高，估算3点。

第三步，召开Sprint计划会。做什么：确定Sprint目标和Sprint待办列表。怎么做：从产品待办列表顶部拉取高优

先级条目，拆解为任务。示例：Sprint目标为“完成登录与首页”，拉取登录、首页、个人中心三个故事。

第四步，创建Sprint看板。做什么：可视化任务状态。怎么做：白板或在线工具画四列：待办、进行中、待验证、完

成。示例：把登录任务拆为“前端页面、后端接口、联调、测试”四张卡，贴入待办列。

第五步，每日站会。做什么：同步进展与阻塞。怎么做：每天固定时间，每人回答三个问题：昨天做了什么、今天做

什么、有什么阻塞。示例：张先生说昨天完成登录接口，今天联调，阻塞是测试环境未就绪。

第六步，Sprint评审。做什么：向业务方展示成果。怎么做：在Sprint最后一天演示可用功能。示例：演示手机号登

录、首页加载、个人中心查看。

第七步，Sprint回顾。做什么：改进团队流程。怎么做：团队讨论什么做得好、什么要改进、下个Sprint做什么改

进。示例：决定下个Sprint站会改为10分钟。

第八步，开始下一个Sprint。做什么：重复计划、执行、评审、回顾。怎么做：更新产品待办列表，重新拉取。示

例：下个Sprint目标为“完成订单列表与详情”。

2.2.2小团队Scrum会议节奏表

会议频率时长参与人输出

Sprint计划会每Sprint一次1小时全体Sprint目标、Sprint待办

每日站会每天10分钟全体进展与阻塞

Sprint评审每Sprint一次30分钟全体、业务方反馈

Sprint回顾每Sprint一次30分钟全体改进项

待办梳理每周一次30分钟产品负责人、开发待办列表更新

2.2.3小团队Scrum看板示例

列卡片示例WIP限制

待办登录页面、登录接口、首页布局无

进行中登录接口联调2

待验证登录页面2

完成需求确认无

2.3小团队Scrum进阶版

2.3.1操作步骤

第一步，引入用户故事地图。做什么：按用户旅程组织需求。怎么做：横轴为用户活动，纵轴为任务优先级。示例：

登录、浏览、下单、支付四步，登录下分手机号登录、验证码登录。

第二步，建立DefinitionofDone。做什么：统一完成标准。怎么做：列出代码评审、单元测试、集成测试、文档更

新、部署验证。示例：登录功能完成需通过代码评审、单元测试覆盖率70%、集成测试通过。

第三步，引入估算。做什么：用故事点估算相对大小。怎么做：用斐波那契数列1、2、3、5、8、13。示例：登录页

面3点，登录接口5点，联调2点。

第四步，使用燃尽图。做什么：跟踪剩余工作量。怎么做：每天更新剩余故事点，画折线。示例：Sprint开始20点，

第5天剩余12点，趋势正常。

第五步，引入结对编程。做什么：两人共同完成复杂任务。怎么做：一人写代码，一人评审，定时交换。示例：登录

接口由王先生和赵女士结对完成。

第六步，自动化测试。做什么：减少回归时间。怎么做：对核心接口写自动化测试。示例：登录接口自动化测试覆盖

成功、失败、验证码错误三种场景。

第七步，持续集成。做什么：频繁合并代码。怎么做：每天至少合并一次，自动构建。示例：使用示例持续集成工

具，每次提交触发构建与测试。

第八步，度量与改进。做什么：用数据驱动改进。怎么做：记录速度、缺陷率、周期时间。示例：Sprint速度从15点

提升到18点，缺陷率从5%降到2%。

2.3.2小团队Scrum度量表

度量指标定义目标用途

速度每Sprint完成故事点稳定或提升预测容量

燃尽图剩余工作量趋势按计划下降发现偏差

缺陷率缺陷数除以故事点低于3%质量监控

周期时间从开始到完成的时间逐Sprint缩短效率监控

Sprint目标达成率达成目标数除以总数高于80%目标管理

2.4小团队Kanban基础版

2.4.1操作步骤

第一步，可视化流程。做什么：画出当前工作流程。怎么做：白板画列：待办、分析、开发、测试、发布。示例：示

例公司3人团队画出五列，每列贴卡片。

第二步，设置WIP限制。做什么：限制每列同时在制品数量。怎么做：根据团队人数设置，如开发列WIP为2，测试

列WIP为2。示例：开发列已有2张卡，第三张必须等待。

第三步，制定流程政策。做什么：明确每列进入与退出标准。怎么做：写下规则贴在看板旁。示例：开发列进入标准

为“已分析且估算完成”，退出标准为“代码评审通过”。

第四步，每日站会。做什么：围绕看板同步。怎么做：从右向左看，关注阻塞与流动。示例：测试列卡片积压，团队

决定优先测试。

第五步，度量周期时间。做什么：记录每张卡从开始到完成的时间。怎么做：在卡片上写开始日期与完成日期。示

例：登录卡9月1日开始，9月4日完成，周期时间3天。

第六步，识别瓶颈。做什么：找到积压最多的列。怎么做：观察哪列卡片最多、等待最长。示例：测试列有4张卡，

开发列只有1张，瓶颈在测试。

第七步，改进流程。做什么：针对瓶颈采取措施。怎么做：增加测试资源、自动化测试、调整WIP。示例：引入自动

化测试，测试列周期时间从2天降到1天。

第八步，持续重复。做什么：持续改进。怎么做：每周复盘一次流动效率。示例：每周五下午复盘周期时间与吞吐

量。

2.4.2小团队Kanban看板示例

列进入标准退出标准WIP限制卡片示例

待办需求已记录已排优先级无登录优化

分析优先级高验收标准明确2登录优化分析

开发分析完成代码评审通过2登录接口开发

测试开发完成测试通过2登录功能测试

发布测试通过已上线1登录功能发布

2.5小团队Kanban进阶版

2.5.1操作步骤

第一步，引入服务类别。做什么：区分不同类型工作。怎么做：用不同颜色卡片区分需求、缺陷、运维、技术债。示

例：红色为缺陷，黄色为需求，蓝色为技术债。

第二步，设置服务类别策略。做什么：为每类工作设定不同WIP与优先级。怎么做：缺陷优先，技术债每周固定容

量。示例：缺陷WIP为2，技术债WIP为1。

第三步，使用累积流图。做什么：观察各列累积数量。怎么做：每天记录各列卡片数，画堆叠面积图。示例：测试列

面积变宽，说明瓶颈在测试。

第四步，度量吞吐量。做什么：统计每周完成卡片数。怎么做：每周记录完成数量。示例：第1周完成5张，第2周

完成7张。

第五步，引入类图与依赖标记。做什么：标记卡片之间的依赖。怎么做：用箭头或标签标记。示例：登录接口依赖登

录页面，卡片上贴“依赖登录页面”。

第六步，设置阻塞列。做什么：显式标记阻塞。怎么做：增加“阻塞”列或标签。示例：测试环境未就绪，卡片移入阻

塞列，写阻塞原因与责任人。

第七步，定期复盘流动效率。做什么：计算流动效率。怎么做：流动效率等于活跃时间除以总时间。示例：卡片总周

期4天，活跃2天，流动效率50%。

第八步，持续优化WIP。做什么：根据数据调整WIP。怎么做：若某列经常空，降低WIP；若某列经常积压，提高

WIP或增加资源。示例：测试列积压，WIP从2调到3，并增加自动化。

2.5.2小团队Kanban度量表

度量指标定义目标用途

周期时间从开始到完成的时间逐周缩短交付效率

吞吐量每周完成卡片数稳定或提升容量预测

WIP各列在制品数量不超过限制流动控制

流动效率活跃时间除以总时间高于50%等待分析

阻塞时间卡片处于阻塞的时间逐周减少阻塞管理

2.6小团队完整案例

背景：示例公司移动端小组共4人，负责一款内部工具应用。团队此前无固定流程，需求通过聊天工具口头传达，经

常出现遗漏与返工。团队决定采用Scrum，Sprint长度为2周。

数据：

Sprint目标完成故事点缺陷数周期时间（天）

Sprint1完成登录与首页1846

Sprint2完成订单列表与详情2025

Sprint3完成个人中心与设置2214

操作步骤：

第一步，第1周周一召开Sprint计划会，确定Sprint1目标为“完成登录与首页”，拉取三个用户故事，估算共18点。

第二步，创建Sprint看板，四列：待办、进行中、待验证、完成。把任务拆为卡片。

第三步，每天9:30开站会，每人回答三个问题，站会控制在10分钟。

第四步，第2周周五召开评审，向业务方演示登录、首页、个人中心。

第五步，评审后召开回顾，团队提出测试环境不稳定，决定下个Sprint提前准备测试环境。

第六步，Sprint2开始，引入DefinitionofDone，要求代码评审、单元测试、集成测试通过。

第七步，Sprint2评审后，团队发现订单详情页加载慢，决定Sprint3优化性能。

第八步，Sprint3结束后，团队速度稳定在20点左右，缺陷数从4降到1，周期时间从6天降到4天。

结果：团队交付可预测性提升，需求遗漏减少，业务方满意度提高。该案例可直接复制到1至5人小团队。

2.7小团队工具清单

工具类型工具名称用途零基础操作

物理看板白板、便利贴可视化任务在白板上画四列，贴便利贴

在线看板示例在线看板工具远程协作注册后创建看板，添加列与卡片

文档示例在线文档写用户故事创建文档，输入用户故事模板

聊天示例聊天工具日常沟通创建团队群，置顶站会时间

代码示例代码托管代码评审提交代码后发起合并请求

集成示例持续集成工具自动构建配置构建脚本，提交触发

测试示例测试工具自动化测试编写测试用例，定时执行

度量示例表格工具记录速度与缺陷创建表格，每天更新

三、中团队（6-15人）实践指南

3.1中团队特征

特征说明影响

人数中等6至15人沟通路径增多

角色专职产品负责人、ScrumMaster可专职协调成本上升

需求多样多个业务方优先级冲突

流程需要统一多人协作需要标准流程不一致导致返工

依赖增多前后端、测试、运维等待时间长

会议增多计划、站会、评审、回顾时间占用大

3.2中团队Scrum基础版

3.2.1操作步骤

第一步，确定角色。做什么：指定产品负责人、ScrumMaster、开发团队。怎么做：6至15人团队中，产品负责人

和ScrumMaster建议专职。示例：示例公司12人团队，张先生任产品负责人，李女士任ScrumMaster，其余10人

为开发、测试、运维。

第二步，建立产品待办列表。做什么：统一需求入口。怎么做：所有需求进入产品待办列表，按优先级排序。示例：

待办列表包含30条需求，前10条为高优先级。

第三步，召开Sprint计划会。做什么：确定Sprint目标与待办。怎么做：产品负责人讲解高优先级需求，团队估算并

拆解任务。示例：Sprint目标为“完成支付流程”，拉取5个故事，估算40点。

第四步，拆分小组。做什么：按功能或技术拆分。怎么做：6至15人可拆为2至3个小组，每组3至5人。示例：拆

为前端组、后端组、测试组。

第五步，创建Sprint看板。做什么：可视化任务。怎么做：四列：待办、进行中、待验证、完成。示例：支付流程拆

为20张卡。

第六步，每日站会。做什么：同步进展与阻塞。怎么做：按小组站会，每组10分钟，代表参加跨组站会。示例：前端

组站会后，李女士参加跨组站会同步依赖。

第七步，Sprint评审。做什么：向业务方展示。怎么做：演示可用功能，收集反馈。示例：演示支付成功、失败、退

款三种场景。

第八步，Sprint回顾。做什么：改进流程。怎么做：团队讨论，输出改进项。示例：决定引入自动化测试，减少回归

时间。

3.2.2中团队Scrum会议节奏表

会议频率时长参与人输出

Sprint计划会每Sprint一次2小时全体Sprint目标、待办

每日站会每天15分钟各小组进展与阻塞

跨组站会每天10分钟小组代表跨组依赖

Sprint评审每Sprint一次1小时全体、业务方反馈

Sprint回顾每Sprint一次1小时全体改进项

待办梳理每周一次1小时产品负责人、小组代表待办更新

3.2.3中团队Scrum看板示例

列卡片示例WIP限制责任人

待办支付页面、支付接口、退款接口无产品负责人

进行中支付接口联调4后端组

待验证支付页面4测试组

完成支付需求确认无ScrumMaster

3.3中团队Scrum进阶版

3.3.1操作步骤

第一步，建立统一DefinitionofDone。做什么：所有小组遵循同一完成标准。怎么做：列出代码评审、单元测试、集

成测试、安全扫描、文档更新。示例：支付功能完成需通过代码评审、单元测试覆盖率70%、集成测试、安全扫描。

第二步，引入ScrumofScrums。做什么：协调多个小组。怎么做：每天或每周召开小组代表会议，同步依赖与风

险。示例：每天10:00召开15分钟跨组站会。

第三步，使用依赖看板。做什么：可视化跨组依赖。怎么做：列出依赖方、被依赖方、状态、预计解除时间。示例：

前端支付页面依赖后端支付接口，状态为“等待接口”。

第四步，引入迭代评审与系统演示。做什么：每Sprint展示集成成果。怎么做：在预发布环境演示端到端流程。示

例：演示从下单到支付成功完整流程。

第五步，建立质量门禁。做什么：代码合并前自动检查。怎么做：配置持续集成，代码评审通过、测试通过才能合

并。示例：支付接口合并前需通过自动化测试。

第六步，引入容量规划。做什么：根据历史速度预测下个Sprint容量。怎么做：取最近3个Sprint平均速度。示例：

最近3个Sprint速度为40、42、38，下个Sprint容量约40点。

第七步，建立风险与阻塞清单。做什么：跟踪阻塞。怎么做：每天更新阻塞列表，指定责任人。示例：测试环境未就

绪，责任人李女士，预计2天解除。

第八步，度量与改进。做什么：用数据驱动。怎么做：记录速度、周期时间、缺陷率、阻塞时间。示例：周期时间从

8天降到5天，缺陷率从5%降到2%。

3.3.2中团队Scrum度量表

度量指标定义目标用途

速度每Sprint完成故事点稳定容量预测

周期时间从开始到完成的时间逐Sprint缩短效率监控

缺陷率缺陷数除以故事点低于3%质量监控

阻塞时间卡片处于阻塞的时间逐Sprint减少阻塞管理

Sprint目标达成率达成目标数除以总数高于80%目标管理

跨组依赖解除时间依赖从提出到解除的时间逐Sprint缩短协调效率

3.4中团队Kanban基础版

3.4.1操作步骤

第一步，可视化端到端流程。做什么：画出从需求到上线的完整流程。怎么做：列包括待办、分析、开发、测试、预

发布、发布。示例：示例公司12人团队画出六列。

第二步，设置WIP限制。做什么：限制各列在制品。怎么做：根据小组人数设置，如开发列WIP为6，测试列WIP

为4。示例：开发列已有6张卡，新卡必须等待。

第三步，制定流程政策。做什么：明确每列进入退出标准。怎么做：写下规则，团队共识。示例：开发列退出标准为

“代码评审通过且单元测试通过”。

第四步，每日站会。做什么：围绕看板同步。怎么做：从右向左看，关注阻塞与流动。示例：测试列积压，团队决定

优先测试。

第五步，度量周期时间与吞吐量。做什么：记录每张卡时间。怎么做：卡片上写开始与完成日期。示例：支付卡9月

1日开始，9月6日完成，周期5天。

第六步，识别瓶颈。做什么：找到积压列。怎么做：观察哪列卡片最多。示例：测试列有8张卡，开发列只有2张，

瓶颈在测试。

第七步，改进流程。做什么：针对瓶颈。怎么做：增加测试资源、自动化、调整WIP。示例：引入自动化测试，测试

周期从2天降到1天。

第八步，持续复盘。做什么：每周复盘。怎么做：每周五复盘流动效率。示例：流动效率从40%提升到60%。

3.4.2中团队Kanban看板示例

列进入标准退出标准WIP限制卡片示例

待办需求已记录已排优先级无支付优化

分析优先级高验收标准明确3支付优化分析

开发分析完成代码评审通过6支付接口开发

测试开发完成测试通过4支付功能测试

预发布测试通过预发布验证通过2支付预发布

发布预发布通过已上线1支付上线

3.5中团队Kanban进阶版

3.5.1操作步骤

第一步，引入服务类别。做什么：区分需求、缺陷、运维、技术债。怎么做：不同颜色卡片。示例：红色缺陷，黄色

需求，蓝色技术债。

第二步，设置服务类别策略。做什么：为每类设定WIP与优先级。怎么做：缺陷优先，技术债每周固定容量。示例：

缺陷WIP为3，技术债WIP为2。

第三步，使用累积流图。做什么：观察各列累积数量。怎么做：每天记录，画堆叠面积图。示例：测试列面积变宽，

说明瓶颈。

第四步，度量吞吐量。做什么：统计每周完成卡片数。怎么做：每周记录。示例：第1周完成8张，第2周完成10

张。

第五步，引入类图与依赖标记。做什么：标记卡片依赖。怎么做：箭头或标签。示例：支付接口依赖支付页面，卡片

贴“依赖支付页面”。

第六步，设置阻塞列。做什么：显式标记阻塞。怎么做：增加阻塞列或标签。示例：测试环境未就绪，卡片移入阻塞

列。

第七步，定期复盘流动效率。做什么：计算流动效率。怎么做：活跃时间除以总时间。示例：总周期6天，活跃3

天，流动效率50%。

第八步，持续优化WIP。做什么：根据数据调整。怎么做：某列经常空降低WIP，某列积压提高WIP或增加资源。示

例：测试列积压，WIP从4调到5，并增加自动化。

3.5.2中团队Kanban度量表

度量指标定义目标用途

周期时间从开始到完成的时间逐周缩短交付效率

吞吐量每周完成卡片数稳定或提升容量预测

WIP各列在制品数量不超过限制流动控制

流动效率活跃时间除以总时间高于50%等待分析

阻塞时间卡片处于阻塞的时间逐周减少阻塞管理

服务类别分布各类工作占比符合策略工作平衡

3.6中团队完整案例

背景：示例公司电商平台团队共12人，负责订单、支付、库存三个模块。团队此前采用Scrum，但紧急缺陷和运维

任务频繁插入，导致Sprint目标经常无法达成。团队决定改用Kanban，保留每日站会和每周复盘。

数据：

周完成卡片数平均周期时间（天）阻塞时间（小时）流动效率

第1周882040%

第2周1061250%

第3周125860%

第4周144470%

操作步骤：

第一步，第1周周一，团队画出端到端看板，六列：待办、分析、开发、测试、预发布、发布。

第二步，设置WIP限制：分析3，开发6，测试4，预发布2，发布1。

第三步，制定流程政策，明确每列进入退出标准。

第四步，每天9:30站会，从右向左看，关注阻塞。

第五步，第1周周五复盘，发现测试列积压，决定引入自动化测试。

第六步，第2周，引入服务类别，缺陷优先，技术债每周固定2张卡。

第七步，第3周，测试周期从2天降到1天，流动效率提升到60%。

第八步，第4周，团队完成14张卡，平均周期时间4天，阻塞时间4小时，流动效率70%。

结果：团队交付效率提升，紧急插入任务不再打乱节奏，业务方满意度提高。该案例可直接复制到6至15人团队。

3.7中团队工具清单

工具类型工具名称用途零基础操作

在线看板示例在线看板工具可视化流程创建看板，添加列与WIP限制

文档示例在线文档写用户故事创建文档，输入用户故事模板

聊天示例聊天工具日常沟通创建团队群，置顶站会时间

代码示例代码托管代码评审提交代码后发起合并请求

集成示例持续集成工具自动构建配置构建脚本，提交触发

测试示例测试工具自动化测试编写测试用例，定时执行

度量示例表格工具记录周期时间与吞吐量创建表格，每天更新

监控示例监控工具系统监控配置告警，关注关键指标

四、大团队（16人以上/多团队）实践指南

4.1大团队特征

特征说明影响

人数多16人以上或多团队并行沟通路径呈指数增长

多团队每个团队5至9人跨团队依赖复杂

角色专职产品负责人、ScrumMaster、架构师专职协调成本高

需求量大多个业务方、多个产品线优先级对齐困难

集成风险多团队并行开发集成冲突、回归成本高

目标对齐各团队目标可能不一致需要统一季度目标

流程统一需要统一框架流程不一致导致协作困难

度量复杂多团队数据汇总需要统一度量口径

4.2大团队Scrum基础版

4.2.1操作步骤

第一步，建立多团队结构。做什么：按业务线或技术域拆分团队。怎么做：每个团队5至9人，设产品负责人和

ScrumMaster。示例：示例公司30人研发中心拆为订单团队、支付团队、库存团队，每队8至10人。

第二步，建立统一产品待办列表。做什么：所有需求进入统一待办。怎么做：由产品负责人团队共同维护，按季度目

标排序。示例：统一待办列表包含100条需求，按季度目标分为三组。

第三步，召开季度目标对齐会。做什么：确定季度目标。怎么做：各团队产品负责人与业务方共同确定季度目标。示

例：季度目标为“完成支付流程闭环”。

第四步，各团队召开Sprint计划会。做什么：各团队确定Sprint目标。怎么做：从统一待办拉取本团队需求，拆解任

务。示例：支付团队Sprint目标为“完成支付接口与对账”。

第五步，召开ScrumofScrums。做什么：协调跨团队依赖。怎么做：每天或每周召开各团队代表会议，同步依赖与

风险。示例：每天10:00召开15分钟跨团队站会。

第六步，建立依赖看板。做什么：可视化跨团队依赖。怎么做：列出依赖方、被依赖方、状态、预计解除时间。示

例：订单团队依赖支付团队接口，状态为“等待接口”。

第七步，集成与系统演示。做什么：每Sprint集成演示。怎么做：在预发布环境演示端到端流程。示例：演示从下单

到支付到库存扣减完整流程。

第八步，召开统一回顾。做什么：跨团队改进。怎么做：各团队回顾后，代表参加统一回顾。示例：决定统一引入自

动化测试。

4.2.2大团队Scrum会议节奏表

会议频率时长参与人输出

季度目标对齐会每季度一次4小时产品负责人、业务方、架构师季度目标

Sprint计划会每Sprint一次2小时各团队Sprint目标

每日站会每天15分钟各团队进展与阻塞

ScrumofScrums每天或每周15分钟各团队代表跨团队依赖

Sprint评审每Sprint一次1小时各团队、业务方反馈

统一回顾每Sprint一次1小时各团队代表改进项

待办梳理每周一次1小时产品负责人团队待办更新

4.2.3大团队Scrum看板示例

团队Sprint目标主要任务依赖团队依赖状态

订单团队完成下单流程订单创建、订单查询支付团队等待支付接口

支付团队完成支付接口支付接口、对账无无

库存团队完成库存扣减库存扣减、库存查询订单团队等待订单接口

4.3大团队Scrum进阶版

4.3.1操作步骤

第一步，建立统一DefinitionofDone。做什么：所有团队遵循同一完成标准。怎么做：列出代码评审、单元测试、集

成测试、安全扫描、文档更新、部署验证。示例：支付功能完成需通过代码评审、单元测试覆盖率70%、集成测试、

安全扫描。

第二步，引入架构runway。做什么：提前准备架构基础。怎么做：架构师识别跨团队技术依赖，提前完成基础组

件。示例：提前完成统一认证、统一日志、统一配置中心。

第三步，建立社区实践。做什么：跨团队实践共享。怎么做：成立社区实践小组，定期分享。示例：成立自动化测试

小组，统一测试框架。

第四步，引入持续集成与持续交付。做什么：每日合并，自动构建。怎么做：配置流水线，提交触发构建与测试。示

例：每个团队每天至少合并一次代码。

第五步，建立质量门禁。做什么：合并前自动检查。怎么做：代码评审、测试、安全扫描通过才能合并。示例：支付

接口合并前需通过自动化测试与安全扫描。

第六步，引入容量规划。做什么：根据历史速度预测。怎么做：取最近3个Sprint平均速度。示例：最近3个Sprint

速度为40、42、38，下个Sprint容量约40点。

第七步，建立风险与阻塞清单。做什么：跟踪阻塞。怎么做：每天更新阻塞列表，指定责任人。示例：测试环境未就

绪，责任人李女士，预计2天解除。

第八步，度量与改进。做什么：用数据驱动。怎么做：记录速度、周期时间、缺陷率、阻塞时间、跨团队依赖解除时

间。示例：周期时间从10天降到6天，缺陷率从5%降到2%。

4.3.2大团队Scrum度量表