一、Scrum核心角色（职责边界必记）
Scrum角色分工明确，避免职责混淆是高频考点：
1. 产品负责人（PO）
- 核心职责：管理产品待办列表（优先级排序、需求澄清、验收标准定义），确保团队开发"正确的产品"。
- 关键动作：
- 与客户/干系人对齐产品愿景，将模糊需求转化为清晰的用户故事；
- 拒绝"直接安排开发任务"，所有需求变更需先更新产品待办列表；
- 需求未达预期时，优先与干系人沟通澄清，而非直接安排修复。
- 易错点：PO不负责技术实现细节，优先级决策权不可下放。
2. Scrum Master（SM/敏捷教练）
- 核心职责：移除团队障碍、保护团队自组织、引导Scrum流程落地，而非"管理者"。
- 关键动作：
- 团队抵触实践（如每日站会）时，通过开放式讨论引导思维转变，而非强制推行；
- 迭代中出现障碍（如缺少配件），协助团队解决，而非直接替代执行；
- 引导迭代回顾会，聚焦过程改进，而非产品功能讨论。
- 易错点：SM不分配任务、不做技术决策，避免"命令式管理"。
3. 开发团队
- 核心特征：自组织（自主分配任务、解决内部问题）、跨职能（具备交付完整功能的所有技能）、无层级。
- 关键动作：
- 迭代中不接受外部直接分配的新任务，所有工作来自迭代待办列表；
- 技术决策（如测试方式）由团队共同制定，而非个人擅自决定；
- 维护工作需计入团队速度，避免过度承诺新功能开发。
- 易错点：自组织≠无纪律，需对迭代目标负责，不擅自变更工作范围。
二、Scrum核心会议（目的+禁忌必背）
Scrum四大会议是高频考点，需明确"目的、参与方、时间盒、易错点"：
| 会议名称 | 核心目的 | 参与方 | 时间盒 | 关键禁忌 |
|---|---|---|---|---|
| 每日站会 | 同步进度、识别障碍、规划当日工作 | 开发团队+SM+PO（可选） | 15分钟 | 不讨论技术细节、不解决问题、不延长时间 |
| 迭代规划会 | 确定迭代目标、挑选待办项、分解任务 | 开发团队+SM+PO | 2小时/迭代周 | 不跳过需求澄清、不低估维护工作、不强制分配任务 |
| 迭代评审会 | 演示已完成增量、收集客户/干系人反馈 | 开发团队+SM+PO+客户/干系人 | 1小时/迭代周 | 不推迟会议、不演示未完成功能、不回避反馈 |
| 迭代回顾会 | 反思迭代过程、识别改进点、制定行动项 | 开发团队+SM+PO（可选） | 1小时/迭代周 | 不对人指责、不聚焦产品功能、不流于形式 |
易错点避坑
- 每日站会：仅同步"做了什么/要做什么/有什么障碍"，障碍会后单独处理；
- 迭代评审会：即使有微小工作未完成，也按计划召开，只演示已完成功能；
- 迭代回顾会：针对"过程改进"（如沟通效率、估算偏差），而非产品缺陷修复；
- 所有会议：时间盒不可随意延长，特殊情况需团队共识。
三、Scrum核心工件（待办列表管理是重点）
Scrum三大工件的管理规则是高频易错点，核心聚焦"产品待办列表"和"迭代待办列表"的区分：
1. 产品待办列表（Product Backlog）
- 定义：所有产品需求的唯一来源，包含用户故事、缺陷、技术债务、维护任务等，动态调整。
- 关键规则：
- 新需求/变更需先加入此处，由PO排序，再纳入迭代；
- 未完成的用户故事需退回此处，而非直接进入下一个迭代待办；
- 需求需符合INVEST原则（独立、可协商、有价值、可估算、小规模、可测试）。
2. 迭代待办列表（Sprint Backlog）
- 定义：迭代规划会上从产品待办列表顶端挑选的工作项，是团队当前迭代的承诺。
- 关键规则：
- 迭代开始后不轻易新增/删除项，紧急需求需PO与团队共识后调整；
- 仅包含团队明确"如何完成"的具体任务，而非模糊需求；
- 迭代结束后未完成的项，退回产品待办列表重新排序。
3. 迭代增量（Increment）
- 定义：迭代结束时交付的"符合DoD（定义完成）"的可工作产品片段。
- 关键规则：
- DoD需团队共识（如"代码评审通过、测试用例全过、文档齐全"）；
- 增量必须"潜在可交付"，即客户可直接使用或集成到产品中。
四、Scrum迭代执行关键原则（避坑核心）
- 时间盒不可破：冲刺长度（通常2-4周）固定，不因为未完成工作延长冲刺；
- 需求变更有序：新需求先入产品待办列表，由PO排序，迭代中不接受无共识的紧急变更；
- 透明化优先：迭代评审会如实演示已完成功能，不隐瞒未完成项；团队速度需包含维护工作，不高估产能；
- 自组织赋能：技术决策（如测试方式、技术选型）由团队共同制定，SM不干预；
- 持续改进：迭代回顾会的行动项需跟踪落地，避免"只说不做"。
五、常见问题与应对策略（高频场景）
1. 未完成用户故事处理
- 错误做法：直接纳入下一个迭代待办列表、延长冲刺时间；
- 正确做法：退回产品待办列表，由PO重新排序，下次迭代规划会再决定是否纳入。
2. 客户需求未达预期
- 错误做法：立即安排团队修复、用新功能弥补；
- 正确做法：PO与干系人沟通澄清需求，重写用户故事更新产品待办列表，按优先级规划迭代。
3. 团队抵触每日站会
- 错误做法：强制参加、停止召开、用一对一访谈替代；
- 正确做法：开放式讨论抵触原因（如时间过长、无价值），优化会议形式（如聚焦障碍），引导团队理解同步价值。
4. 迭代中出现紧急维护任务
- 错误做法：忽略维护工作、牺牲新功能开发；
- 正确做法：将维护任务计入团队速度，调整迭代待办列表，必要时与PO协商降低新功能目标。
5. 技术决策分歧（如新技术引入）
- 错误做法：个人擅自推行、回避讨论；
- 正确做法：在迭代规划会或专门研讨会上集体决策，制定试点方案，迭代回顾会评估效果。
六、补充核心知识（互联网必备）
1. DoD（Definition of Done，定义完成）
- 核心作用：避免"团队认为的完成≠客户认为的完成"，需明确、可验证；
- 示例：代码编写完成、单元测试覆盖率≥80%、通过集成测试、用户文档更新、PO验收通过。
2. 团队速度（Velocity）
- 定义：团队一个迭代内完成的故事点总和，用于预测产能；
- 关键：速度是团队内部参考，不跨团队对比；需包含维护、缺陷修复等所有工作耗时。
3. 燃尽图（Burndown Chart）
- 作用：可视化迭代进度，跟踪剩余工作与时间的关系；
- 解读：理想曲线呈下降趋势，若曲线上升可能是新增任务或估算偏差。
结尾
Scrum实践的核心是"流程纪律+团队赋能"，掌握以上知识点可覆盖考试80%相关考题。