Scrum Master的分工核心，是把流程守护与障碍清除从业务职责中分离出来：Product Owner对价值与需求排序负责，开发团队对交付与自组织负责，Scrum Master对Scrum机制的有效运转、协作规则和障碍清除负责。本文给出一张职责边界表、五类活动的分工清单和三条协作机制，帮助团队把边界写清楚、把交接跑通。
要点总览（TL;DR）
- Scrum Master的分工核心是把流程守护与障碍清除从业务职责中分离：Product Owner对价值与需求排序负责，开发团队对交付与自组织负责，Scrum Master对Scrum机制运转、协作规则和障碍清除负责。
- 用一张职责边界表把三方在需求、计划、执行、评审、回顾五类活动中的决策权与交接物写清楚，出现争议时回到表中确认归属。
- 分工要跑起来需要三条机制：障碍分级与升级时限、会议引导职责、需求理解冲突的处理路径，每条规则都要有明确责任人。
- 分工是否生效可用检查清单核对：边界表是否三方确认、障碍是否按规则闭环、会议是否有引导和书面结论、冲突是否有处理记录。
- 出现Scrum Master替团队做技术或优先级决定、障碍长期无人推动等信号时，说明某条职责线被侵占或空缺，需要重新对照边界表调整。
先划清三条职责线：价值、交付与流程
分工混乱通常源于三类决策权混在一起：需求做什么由谁定、怎么做由谁定、流程规则由谁维护。把这三条线分开，Scrum Master的职责边界就清楚了。Product Owner掌握价值线，决定需求内容与排序；开发团队掌握交付线，决定如何实现、如何拆分任务、如何在迭代内完成工作；Scrum Master掌握流程线，维护Scrum规则、引导协作、清除障碍，对交付内容和需求优先级不作决策。
需要说明的是，流程线不等于管理权。Scrum Master推动规则被执行，遇到团队违反约定时通过回顾会和团队共识来纠正，决策仍归团队。以下表格可作为团队讨论的起点，按实际情况调整后由三方确认。
| 角色 | 核心职责 | 决策权归属 | 主要交付物 |
|---|---|---|---|
| Product Owner | 定义产品价值方向，管理需求池，明确验收标准 | 需求内容、优先级、验收口径 | 排好序的需求列表、迭代目标、验收标准 |
| 开发团队 | 把需求转化为可交付增量，自组织完成任务拆分与协作 | 技术方案、任务拆分、迭代内工作安排 | 可工作的产品增量、任务看板状态、估算结果 |
| Scrum Master | 保障Scrum机制运转，引导会议，识别并推动障碍清除 | 流程规则的解释与执行推动，无业务决策权 | 会议产出记录、障碍清单与升级记录、改进项跟踪 |
常见越位有三种：Scrum Master替Product Owner排优先级，Product Owner在迭代中途直接给开发人员派任务，开发团队绕过流程自行变更迭代范围。常见缺位也有三种：无人跟踪障碍导致问题反复出现，会议没有引导导致讨论发散，回顾会提出的改进项无人跟进。边界表的价值在于让这些情形有对照依据，出现争议时回到表中确认决策权归属。
按活动拆分工：五类协作场景中的角色动作
静态职责表解决“谁负责什么”，具体活动还需要明确“谁在什么时候做什么、交接什么”。以下按需求梳理、迭代计划、日常执行、评审、回顾五类活动展开，每类活动给出角色动作与交接物。
需求梳理
Product Owner主导，负责把需求写清楚、排好序、给出验收标准。开发团队提供估算输入和技术可行性判断，对需求的理解疑问当场提出。Scrum Master保障梳理会有固定节奏和明确产出，控制讨论不偏离需求范围，记录未决问题。交接物是进入迭代候选的需求条目及其验收标准。
迭代计划
Product Owner提出迭代目标和候选需求，说明优先级理由。开发团队确认容量、拆分任务、认领工作，对能否完成给出明确答复。Scrum Master引导会议流程，确认目标、容量和任务拆分都经过讨论，记录团队承诺的迭代范围。交接物是迭代目标、任务清单和团队确认的容量基线。
日常执行
开发团队每日同步进展，主动暴露阻碍。Scrum Master在站会中识别障碍信号，判断哪些团队可自行解决、哪些需要上报，并跟踪到关闭。障碍处理路径建议明确：团队内可解决的当天处理；涉及跨团队协调的由Scrum Master在两个工作日内推动；涉及组织级资源或决策的升级到管理层，并约定反馈时限。交接物是障碍清单及每条障碍的责任人和状态。
评审
开发团队演示可工作的增量，Product Owner对照验收标准确认接受或提出调整，相关干系人提供反馈。Scrum Master组织评审、控制时间、记录反馈和需求调整结论。交接物是评审结论和进入需求池的调整项。
回顾
全体参与，围绕协作过程而非个人展开讨论。Scrum Master设计回顾形式、引导讨论、推动形成少量可执行的改进项，并为每项改进指定负责人和检查时间。交接物是改进项清单及下次回顾的检查点。
| 活动 | Product Owner | 开发团队 | Scrum Master | 交接物 |
|---|---|---|---|---|
| 需求梳理 | 主导，排序与验收标准 | 估算与技术输入 | 保障节奏与产出 | 候选需求及验收标准 |
| 迭代计划 | 提出目标与候选需求 | 确认容量、拆任务 | 引导流程、记录范围 | 迭代目标与任务清单 |
| 日常执行 | 解答需求疑问 | 同步进展、暴露障碍 | 识别并跟踪障碍 | 障碍清单与状态 |
| 评审 | 确认接受或调整 | 演示增量 | 组织与记录结论 | 评审结论与调整项 |
| 回顾 | 参与讨论 | 参与讨论 | 设计形式、推动改进项 | 改进项与检查点 |
配套三条协作机制：障碍升级、会议引导与冲突处理
职责表写在文档里容易，跑起来需要规则支撑。以下三条机制覆盖分工中最容易卡住的环节，团队可按规模裁剪，但建议保留最小规则集。
障碍分级与升级时限
把障碍按影响范围分为三级：影响单个任务、团队内可解决的为一级，由提出人当天处理；影响迭代目标、需要跨团队协调的为二级，由Scrum Master在两个工作日内推动解决；影响多个团队或需要组织决策的为三级，升级到管理层并约定反馈时限。每条障碍登记时写明级别、责任人、期望关闭时间，超时未关闭的在站会或周会上公开提示。分级标准由团队共同确认，避免Scrum Master单方面判定。
会议引导职责
Scrum Master在会议中的动作包括：会前确认议题和参会人，会中控制时间盒、把跑题讨论记入待办、确保每个议题有结论，会后发出简短记录，写明决定、负责人和时间点。引导不等于替团队做决定，遇到需要业务判断的问题，交回Product Owner或团队处理。
需求理解冲突的处理路径
Product Owner与开发团队对需求理解不一致时，先回到验收标准逐条对齐，明确哪些是必须满足的条件、哪些是实现方式的选择。仍无法达成一致的，由Product Owner在约定时限内给出书面结论，开发团队保留技术风险说明。Scrum Master负责推动这个流程按时走完，记录结论和分歧点，必要时在回顾会上复盘冲突原因，调整需求梳理的颗粒度。
这三条机制落地的最小规则集可以概括为：每条障碍有级别、责任人和时限；每次会议有引导人和书面结论；每次冲突有处理路径和记录。规则数量不必多，关键是每条都有明确的责任人。
当团队规模扩大、跨角色协作增多时，障碍清单、会议结论和改进项需要放在同一处可查。ONES 敏捷研发管理解决方案覆盖产品负责人、研发工程师、测试工程师等职能角色，为需求管理、迭代规划、进度跟踪、迭代复盘等环节提供工具支撑；团队可以用工作项记录障碍并跟踪状态，用敏捷看板在站会中对齐进度与风险。ONES Project 支持按项目角色分配产品、项目、任务多层级权限，便于把上述职责边界对应到系统权限设置中。
示例：一个中型研发团队的SM分工落地
以下为演示情景，用于说明分工表和机制如何填写，不代表特定企业的真实案例。
某研发团队共12人，设1名Product Owner、1名Scrum Master、8名开发人员、2名测试人员，按两周一个迭代运作。团队在启动会上共同填写职责边界表，确认Product Owner对需求排序和验收标准有最终决定权，开发团队对任务拆分和技术方案自主决定，Scrum Master负责会议引导和障碍跟踪。
一次障碍流转示例：迭代第二周，测试人员发现测试环境不稳定，影响回归测试，在站会中提出。Scrum Master判定为二级障碍，登记责任人（运维接口人）和期望关闭时间（两个工作日内），当天协调运维排查。第二天环境恢复，Scrum Master在站会确认关闭并记录原因。若超过两个工作日未解决，则升级为三级，提交管理层协调资源。
一次需求冲突示例：开发团队认为某需求的验收标准中“响应时间可接受”表述模糊，无法估算。Product Owner在梳理会上补充为具体指标，开发团队据此重新估算。Scrum Master记录该分歧，在回顾会上提出需求描述应包含可验证指标，团队据此更新了需求模板。
这个示例体现的分工原则是：决策权归角色所有，Scrum Master推动流程但不替角色决策，每条障碍和冲突都有记录和关闭标准。
完成检查：分工机制是否真正生效
分工是否落地，可以通过以下清单逐项核对。建议每季度或在团队变动后检查一次，发现问题时回到对应章节调整。
- 职责边界表已由Product Owner、开发团队、Scrum Master三方共同确认，并在团队可见的位置存放。
- 需求排序和验收标准的决策权明确归Product Owner，迭代内未出现绕过其变更需求的情况。
- 任务拆分和技术方案由开发团队自主决定，Scrum Master未介入具体实现决策。
- 障碍清单中每条障碍都有级别、责任人和时限，超时项有升级记录，关闭率可查。
- 各类会议有明确引导人，会后有书面结论，写明决定、负责人和时间点。
- 角色冲突有处理记录，冲突结论在回顾会上被复盘，并转化为流程调整。
- 回顾会提出的改进项有负责人和检查时间，下次回顾能确认是否完成。
出现以下信号时，说明分工需要调整：Scrum Master频繁替团队做技术或优先级决定；Product Owner在迭代中途直接向个人派活；障碍长期停留在清单中无人推动；会议结论无人跟进；回顾会改进项连续多个迭代没有变化。这些信号指向同一类问题——某条职责线被侵占或空缺，此时应重新对照职责边界表，明确责任归属并更新协作规则。
常见问题
团队规模较小、角色由一人兼任时，这套分工还适用吗？
适用，但需要把兼任关系写进职责边界表。小团队中Product Owner可能同时承担部分需求分析工作，Scrum Master也可能参与开发，此时要在表中注明每个角色的兼任情况和决策权归属，避免同一人在不同场景下混用身份。关键规则是：涉及需求排序和验收口径的判断，以Product Owner身份作出；涉及流程规则和障碍升级的判断，以Scrum Master身份作出。兼任角色在回顾会上应主动说明哪些环节出现了身份混用，团队据此调整。
Scrum Master没有管理权限，遇到团队不遵守约定时怎么办？
Scrum Master推动规则执行依靠的是团队共识和透明机制，而非管理权。可行做法包括：在团队成立或每个季度初共同确认协作约定，把约定写进职责边界表；站会和看板上公开障碍状态与超时情况，让问题可见；在回顾会上把反复出现的违规作为过程问题讨论，由团队决定调整规则或明确后果。若问题涉及组织级资源或跨团队协调，按障碍升级规则提交管理层，由管理层作出决策。Scrum Master的角色是推动这个过程按时走完并留下记录。
障碍升级到管理层后迟迟没有反馈，如何处理？
升级时限应在机制建立时就与管理层约定，包括反馈时限和超时后的处理方式。实际操作中可以这样做：三级障碍登记时写明期望反馈时间；临近时限时由Scrum Master在站会公开提示；超时未反馈的，在周会或项目例会上列为待决事项，并说明对迭代目标的影响。若多次超时，应在回顾会上复盘升级路径本身是否合理，例如升级对象是否选错、障碍描述是否缺少决策所需信息，据此调整升级规则，而不是让障碍停留在清单中。
Product Owner在迭代中途提出需求变更，开发团队应该怎么应对？
先区分变更性质：属于验收标准澄清或表述修正的，由Product Owner与开发团队对齐后更新需求描述；属于新增需求或范围扩大的，应进入需求池重新排序，由Product Owner决定是否替换当前迭代中的其他需求。替换需要开发团队确认容量影响，双方达成一致后更新迭代范围并记录变更原因。Scrum Master负责推动这个流程走完，把变更记录带入评审和回顾，用于评估需求梳理的颗粒度是否合适。迭代内绕过流程直接向个人派活，属于边界表中所列的越位情形，应在回顾会上提出。
如何判断分工机制需要调整，而不是团队执行不到位？
可以从两个方向判断。一是看规则本身是否可执行：障碍分级标准是否清晰到不同人都能作出一致判断，会议结论是否包含决定、负责人和时间点，冲突处理路径是否有时限。规则模糊导致的执行偏差，应先改规则。二是看同类问题是否反复出现：如果某个角色越位或缺位在多个迭代中重复发生，说明边界表对该情形的描述不足或未被三方真正确认，需要重新讨论职责归属。建议每季度或在团队人员变动后对照检查清单核对一次，把调整结论更新到边界表和协作规则中。
