Scrum与Kanban的差异，落到团队日常最容易感知的两处，就是角色怎么设、协作怎么组织。Scrum规定Product Owner、Scrum Master和开发团队三类角色，并以Sprint固定节奏推进；Kanban不设必备角色，靠可视化工作流、限制在制品和拉动式流转来协作。本文按角色设置与协作方式两个维度对照，并给出选择条件；ONES可作为承载角色职责与工作项流转的协作工具之一。
要点总览（TL;DR）
- Scrum在框架中规定Product Owner、Scrum Master和开发团队三类角色，分别承担价值排序、流程守护和交付职责；Kanban不设必备角色，职责按流程环节分配或由团队共担。
- Scrum以Sprint固定周期组织协作，计划、站会、评审、回顾按时间盒重复执行；Kanban靠可视化工作流、WIP限制和拉动式流转组织协作，协作节点按需设置。
- 工作项进入方式不同：Scrum从Product Backlog按Sprint选取并在周期内保持相对稳定，Kanban按队列持续流入、随时调整顺序。
- 改进依据不同：Scrum看Sprint目标达成与回顾会改进项，Kanban看周期时间与流动效率。
- 需求能在一个周期内收敛、需要明确角色边界和固定评审节奏时适合Scrum；任务持续流入、优先级频繁变化、希望渐进改进时适合Kanban；两者可组合，但角色职责不能悬空。
Scrum与Kanban的角色设置差异
Scrum的角色是框架规定的一部分，三类角色各自承担不同的决策与流程职责，缺一不可。Kanban的框架定义里没有规定必备角色，团队按流程环节设置职责，或由成员共同承担。这是两者在角色设置上最直接的差别。
Scrum的三个角色及其职责
Scrum框架明确了三个角色，每个角色对应一类不可替代的职责：
- Product Owner（产品负责人）：负责产品待办列表的排序，决定做什么、先做什么，对交付价值负责。价值排序权集中在这一个角色上，避免多人同时决定优先级。
- Scrum Master：负责Scrum流程的正确运行，组织并引导计划、站会、评审、回顾等协作节点，清除团队遇到的障碍。这个角色守护的是流程，不直接承担交付任务。
- 开发团队：负责在每个Sprint内交付可用的产品增量，自行拆解任务、认领工作。团队是自组织的，任务分配由团队内部完成。
Kanban的角色安排
Kanban不规定必备角色。常见做法有两类：一是按流程环节设置职责，例如为每个列或每个阶段指定负责人，关注该环节的在制品是否超限、流转是否顺畅；二是由团队共同承担流程维护，谁发现阻塞谁推动解决。服务交付类团队（如运维、支持）常采用前一种，把“流动管理员”式的职责分散到各环节。
是否可兼任、是否必须专职
Scrum框架要求三个角色都存在，但并未强制每个角色由专职人员担任。小团队中Product Owner由产品经理兼任、Scrum Master由团队内成员兼任的情况很常见，此时需要留意兼任带来的职责冲突：兼任Scrum Master的成员在站会上既要推动流程，又要汇报自己的任务，容易弱化流程守护的独立性。Kanban没有角色规定，兼任与否完全取决于流程需要，通常不构成问题。
角色缺失时的处理方式
Scrum中缺少Product Owner，待办排序会失去唯一决策点，Sprint目标容易反复；缺少Scrum Master，协作节点容易流于形式、障碍无人推动。这两种情况通常被视为框架执行不完整，需要补齐角色或明确代行职责的人。Kanban没有“角色缺失”这一说，流程环节无人负责时表现为工作项在某列堆积，处理方式是补上该环节的负责人或调整流程设计。
| 对照项 | Scrum | Kanban |
|---|---|---|
| 角色构成 | Product Owner、Scrum Master、开发团队 | 框架不规定，按流程环节或团队共担设置 |
| 核心职责归属 | 价值排序、流程守护、交付分别归属三个角色 | 职责随流程环节分配，无固定归属 |
| 是否必需 | 框架规定必需 | 非框架规定，按需设置 |
| 常见兼任方式 | 小团队中PO、SM可由成员兼任，需注意职责冲突 | 职责分散到环节负责人或全员共担 |
| 角色缺失的影响 | 视为框架执行不完整，需补齐或代行 | 表现为环节堆积，通过补人或调流程解决 |
角色职责落到工具里，通常体现为工作项的类型、负责人字段和流转规则。ONES Project为研发团队中的产品、研发、测试等角色构建，适配需求管理、任务管理、缺陷管理与迭代管理等场景；ONES敏捷研发管理解决方案把需求提出方、产品经理、研发、测试等角色连接在同一条需求到交付的流程上。团队可以把Product Owner的排序动作、开发团队的任务认领、Scrum Master关注的阻塞项分别对应到工作项字段和看板列上，让角色职责有可见的承载位置。
协作方式差异：节奏驱动与流动驱动
Scrum用固定周期组织协作，所有协作动作围绕Sprint展开；Kanban用工作流和WIP限制组织协作，协作动作跟着工作项的流动走。前者靠节奏产生可预期性，后者靠限制在制品暴露瓶颈。
Scrum的固定协作节点
Scrum以Sprint为固定周期，一个Sprint内包含几类固定协作节点：Sprint计划会确定本周期目标与选取的工作项；每日站会同步进展与障碍；Sprint评审会向相关方展示增量并收集反馈；Sprint回顾会检视协作过程并确定改进项。这些节点的时间盒和产出在框架中有约定，团队按周期重复执行。固定节奏的价值在于让计划、检视、调整成为规律动作，而不是临时发起。
Kanban的可视化与拉动
Kanban把工作流画成列，每个工作项以卡片形式在列间移动，每一列设置WIP上限。成员完成手头工作后，从上游队列拉取下一项，而不是由人把任务推给成员。WIP限制的作用是让队列堆积和环节瓶颈直接可见：某列满了，上游就不能继续流入，团队必须先把该列的工作推进。协作节点按需设置，站会、复盘都可以有，但不由框架规定频率和形式。
工作项如何进入流程
Scrum中工作项从Product Backlog按Sprint选取，进入Sprint Backlog后在一个周期内保持相对稳定，周期中途变更需要与Product Owner协商并评估对Sprint目标的影响。Kanban中工作项按队列持续流入，优先级变化可以直接反映在队列顺序上，新工作项随时可以进入待办队列，由WIP限制控制同时在手的数量。
度量与改进依据
Scrum主要看Sprint目标是否达成、增量是否可用，回顾会围绕本周期协作过程找改进项。Kanban主要看周期时间（工作项从进入到完成的耗时）和流动效率（实际工作时间占周期时间的比例），改进依据是流动数据暴露的等待与阻塞。两种度量回答的问题不同：前者问“这个周期交付了什么”，后者问“工作项在流程里等了多久”。
| 对照项 | Scrum | Kanban |
|---|---|---|
| 协作节奏 | Sprint固定周期，节点时间盒有约定 | 持续流动，协作节点按需设置 |
| 工作来源 | 从Product Backlog按Sprint选取 | 按队列持续流入 |
| 任务获取方式 | 团队自组织认领，周期内相对稳定 | 完成后从上游拉动下一项 |
| 在制品控制 | 通过Sprint范围约束 | 通过每列WIP上限约束 |
| 改进依据 | Sprint目标达成与回顾会改进项 | 周期时间与流动效率 |
这些协作动作在工具中体现为看板列、工作项状态和迭代容器。ONES敏捷研发管理解决方案支持团队成员围绕迭代需求拆解任务，并通过敏捷看板管理任务状态；每日站会中可以借助看板可视化对齐迭代进度与风险。对于按流动方式协作的团队，工作项状态与流转规则同样可以在看板上配置，让队列和阻塞位置保持可见。
同口径差异对照
把两个框架放在同一组维度下横向比较，可以更清楚地看到哪些差异来自框架规定，哪些属于团队常见做法。下表统一按角色设置、协作节奏、工作来源、计划方式、改进机制五个维度对照。
| 维度 | Scrum | Kanban | 差异性质 |
|---|---|---|---|
| 角色设置 | 三个角色，职责分别归属 | 无必备角色，按环节或共担设置 | 框架规定 |
| 协作节奏 | Sprint固定周期与固定节点 | 持续流动，节点按需 | 框架规定 |
| 工作来源 | 按Sprint从待办列表选取 | 队列持续流入，拉动取任务 | 框架规定 |
| 计划方式 | 周期开始时集中计划，周期内相对稳定 | 持续排序，随队列变化调整 | 框架规定为主，具体排序频率属常见做法 |
| 改进机制 | 回顾会检视周期协作过程 | 依据周期时间与流动效率持续调整 | 框架规定改进方向，具体度量工具属常见做法 |
| 角色是否专职 | 框架未强制，小团队常见兼任 | 不涉及 | 常见实践 |
| WIP上限的具体数值 | 不涉及 | 由团队按环节容量设定 | 常见实践 |
需要说明的是，表中“框架规定”指该做法写在Scrum指南或Kanban方法的通行定义中；“常见实践”指团队普遍采用但框架未作强制要求的部分。例如Scrum并未规定回顾会必须使用哪种引导方式，Kanban也未规定WIP上限的具体数字，这些都属于团队自行决定的范围。把两类差异分开看，可以避免把某种团队习惯误当成框架要求。
适配场景与选择建议
选择的关键不在哪个框架更先进，而在团队的任务形态和职责结构是否与框架的协作机制匹配。下面按条件给出判断依据，并说明组合使用的情形。
适合Scrum的条件
- 需求可以在一个周期内收敛到可交付的范围，团队能对Sprint目标作出承诺；
- 需要明确的角色边界，尤其是价值排序需要集中到一个决策点；
- 相关方需要固定的评审节奏来获取反馈，团队也需要固定的回顾节点推动改进；
- 团队愿意接受周期内范围相对稳定，变更走协商而非随时插入。
适合Kanban的条件
- 任务持续流入，难以按固定周期切分，例如支持、运维、持续交付类工作；
- 优先级频繁变化，需要随时调整队列顺序；
- 团队希望在现有流程上渐进改进，先让瓶颈可见，再逐步调整；
- 角色职责已经按环节自然分布，不需要额外设立流程守护角色。
组合使用的常见情形
Scrum与Kanban并不互斥。常见做法是在Scrum的Sprint内使用看板管理任务状态，用WIP限制约束并行任务数量；也有团队在Kanban流程中保留周期性的计划与回顾节点，形成固定检视节奏。组合时需要注意的是角色职责不能悬空：如果采用Scrum角色又按Kanban方式流动，Product Owner的排序职责和Scrum Master的流程守护职责仍需有人承担，否则两套机制的优势都会削弱。
选择前的试运行验证
在正式采用前，可以用一段有限时间试运行并观察协作摩擦点：
- 选一个周期或一段工作流，按候选框架的角色与协作节点实际运行；
- 记录摩擦出现的位置：是排序决策反复、协作节点流于形式，还是工作项在某一环节长期堆积；
- 对照摩擦点判断：排序反复说明需要明确的价值决策角色，堆积说明需要WIP限制或流程调整；
- 试运行结束后与团队一起复盘，确认角色职责是否有人实际承担、协作节点是否产生了有效信息；
- 根据观察结果决定采用、调整或组合，而不是一次性全面切换。
试运行阶段可以借助工具把角色和工作项流转先落地，减少口头约定带来的模糊。ONES敏捷研发管理解决方案覆盖需求管理、迭代规划、进度跟踪、迭代复盘等Scrum关键环节，并支持通过看板管理任务状态；团队可以先用它把角色对应的字段、工作项状态和看板列配置出来，在试运行中观察职责是否落实、流转是否顺畅，再据此确定最终采用的协作方式。
常见问题
小团队人手有限，Scrum的三个角色可以由同一个人兼任吗？
Scrum框架要求三个角色都存在，并未强制每个角色由专职人员担任，小团队中由成员兼任是常见做法。需要留意的是兼任带来的职责冲突：兼任Scrum Master的成员如果在站会上既要推动流程、又要汇报自己的任务，流程守护的独立性会被削弱。可行的处理方式是把价值排序的决策点明确到一个人，流程守护职责尽量由不直接承担该周期交付压力的人承担，或在团队内轮换并公开说明。
团队已经在用看板，还需要补设Scrum Master这类角色吗？
取决于团队采用的协作机制。如果团队按Kanban方式运作，框架不要求设置流程守护角色，流程维护可以由环节负责人或全员共担。如果团队在看板之上引入了Sprint节奏和Scrum角色，那么Product Owner的排序职责和Scrum Master的流程守护职责就需要有人实际承担，否则固定节奏容易流于形式。判断标准是看这些职责有没有明确的承担者，而不是看角色名称是否齐全。
Scrum和Kanban组合使用时，最容易出问题的地方在哪里？
常见问题出在角色职责与流动方式不匹配。例如团队保留了Scrum角色，却按Kanban方式让工作项随时流入，Sprint目标就难以成立，Product Owner的排序决策也会被不断打断；反过来，团队采用Kanban的持续流动，却保留了形式化的计划会和回顾会，协作节点产生不了有效信息。组合时需要明确哪些机制保留、对应职责由谁承担，并在试运行中观察摩擦点。
试运行多久才能判断团队更适合哪种框架？
没有统一时长，通常以能观察到一个完整工作循环为准：采用Scrum候选方案时至少跑完一个Sprint，采用Kanban候选方案时让一段有代表性的工作流完整流过。判断依据是摩擦出现的位置——排序决策反复说明需要明确的价值决策角色，工作项在某一环节长期堆积说明需要WIP限制或流程调整。试运行结束后与团队复盘，确认角色职责是否有人实际承担、协作节点是否产生了有效信息，再决定采用、调整或组合。
Kanban没有规定角色，是否意味着团队不需要任何分工？
不是。Kanban不规定必备角色，但流程仍需要有人维护：每个环节的在制品是否超限、阻塞是否被推动解决、队列顺序是否合理，这些工作需要有承担者。常见做法是按流程环节指定负责人，或由团队共同承担、谁发现阻塞谁推动。区别在于这些职责由流程需要产生，而非框架预先规定，团队可以根据环节数量和成员情况灵活安排。
