一张图掌握Scrum项目管理

万兴图示EdrawMAX

发布时间：2026年08月20日

分享文章：

Scrum不是每日开会加一块看板，而是一套围绕角色、待办、迭代和反馈建立的协作机制。这张纵向知识图把核心概念、角色分工、Sprint计划、任务卡、燃尽图与站会连接起来，适合产品经理快速建立全局认识。

建立Scrum的整体认识

图中先解释项目管理与敏捷开发，再用时间、成本、质量、功能等要素说明约束关系。随后介绍Scrum方法、常见优势和团队构成，最后进入Sprint、看板、任务卡、燃尽图及每日站会，阅读路径从概念逐步走向执行。

Scrum强调在较短周期内交付可检查的成果，并通过持续反馈调整方向。它不等于没有计划，而是把大计划拆成可验证的小步。产品经理需要关注价值顺序和验收条件，团队则共同决定如何在迭代内完成承诺。

长图适合知识培训，可借助AI信息图制作工具重新分组模块。定义、角色、过程和工具应使用不同视觉层级，避免所有内容都以相同字号出现，导致读者找不到主线。

• 概念层：项目约束、敏捷思想与Scrum定位。
• 机制层：角色、事件、待办和迭代目标。
• 执行层：任务看板、任务卡、燃尽图与每日站会。

理解角色与迭代计划

产品负责人负责价值方向与产品待办排序，Scrum Master帮助团队理解规则、移除协作障碍，开发团队共同完成迭代目标。图中的角色名称可以按组织习惯调整，但职责不能因为职称不同而消失。

Sprint计划应从产品待办中选择与迭代目标一致的工作，并评估容量、依赖和完成定义。图中给出多个迭代安排示意，实际使用时还要考虑团队人数、历史速度、假期和临时支持工作，不能只按理想工时塞满任务。

目标、范围和完成标准要在迭代开始前形成共识。需求若在Sprint中频繁增加，应先评估是否影响当前目标，再决定替换、延期或作为紧急事项处理。敏捷允许变化，但不等于任何变化都不付出代价。

使用待办、看板与任务卡

产品待办用于维护价值优先级，Sprint待办记录本轮承诺，任务看板则展示Backlog、ToDo、Doing、Test和Done等状态。三者服务不同层级，若全部混成一张表，团队会分不清长期候选项与当前执行项。

需要向管理者同步进展时，可以结合企业管理看板图展示完成趋势、阻塞和风险。看板列不宜过多，状态必须有明确进入和退出条件；例如“Test”应说明谁负责验证，以及未通过后回到哪个状态。

任务卡至少包括目标、负责人、验收标准、依赖和预计工作量。燃尽图用于观察剩余工作变化，但曲线偏离不必然代表团队低效，也可能来自范围新增、估算偏差或任务拆分过大。读图时需要结合事件解释。

在万兴图示中整理团队手册

整理团队版Scrum手册时，不必完整照搬长图。新人培训可保留概念与角色，项目启动可突出事件节奏和完成定义，执行看板则只展示状态与任务规则。根据读者删减信息，比把所有知识压在一页更有效。

若团队需要把敏捷实践与项目能力连接，可参考项目管理软件整理任务、进度和资源。万兴图示中可复制模块、替换角色名称、调整颜色并拆成长图或多页演示。

导出前应检查术语是否统一，例如产品待办、Sprint待办、完成定义和验收标准不要交替使用近义词。对于公司自定义流程，应明确哪些是Scrum原生概念，哪些是内部增加规则，避免培训时造成误解。

1. 步骤1：确定知识图面向新人、项目组还是管理者。
2. 步骤2：保留与读者最相关的角色、事件和工具。
3. 步骤3：替换团队术语、看板状态与会议规则。
4. 步骤4：检查概念边界并拆分过长页面。

识别敏捷实践中的误区

常见误区之一是把每日站会变成向主管汇报。站会应围绕迭代目标快速同步进展、计划和阻塞，复杂讨论会后另约。另一个误区是只看燃尽曲线而忽略交付质量，曲线漂亮并不能证明用户价值已经实现。

Scrum Master也不是项目经理的简单改名，其重点是促进团队自组织和移除障碍。产品负责人不能把优先级决定完全交给开发团队，开发团队也不应在缺少验收标准时自行猜测需求。

这张知识图适合建立学习地图，而不是替代团队实践。真正有效的敏捷需要稳定节奏、透明工作、可检查成果和及时调整。团队应从一个迭代开始验证规则，再依据复盘逐步优化。