敏捷开发（Scrum 指南）
2022-03-09 16:54:50 48 举报AI智能生成
关于Scrum指南最详细的拆书讲解，一篇思维导图带你走进敏捷开发的世界！
作者其他创作
大纲/内容
Scrum 定义
Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同
时也能高效并创造性地交付可能最高价值的产品。
时也能高效并创造性地交付可能最高价值的产品。
特点
轻量的
易于理解的
难以精通的
组成
Scrum 框架由 Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个
部分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。
部分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。
规则
Scrum 的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。
Scrum 应用
1. 研究与识别出可行的市场、技术和产品能力；
2. 开发产品和增强功能；
3. 产品和增强功能，频率高到一天发布多次；
4. 开发与支持云（在线、安全、按需）和其他运行环境来提供给产品使用；
5. 支持和更新产品。
Scrum 理论
基于经验主义－经验性过程控制理论
三大支柱
透明
过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些
关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理
解。
关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理
解。
检视
Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要
的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤
勉地执行时，效果最佳。
的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤
勉地执行时，效果最佳。
适应
如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接
受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进
一步的偏离。
受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进
一步的偏离。
四个事件
Sprint 计划会议
每日 Scrum 站会
Sprint 评审会议
Sprint 回顾会议
Scrum 价值观
承诺
勇气
专注
开放
尊重
Scrum 团队
PO（product owner）
职责
将开发团队开发的产品价值最大化
管理产品待办列表的唯一负责人
清晰地表述产品待办列表项；
对产品待办列表项进行排序，使其最好地实现目标和使命；
优化开发团队所执行工作的价值；
确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做
的工作；
的工作；
确保开发团队对产品待办列表项有足够深的了解。
PDT（Product Development Team）
组成
开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的
产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能
创建增量。
产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能
创建增量。
特点
是自组织的
是跨职能的团队
不认可开发团队成员的任何头衔
不认可开发团队中所谓的“子团队”
开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队
规模
（3，9]
SM（Scrum Master）
服务型领导
最大化 Scrum 团队所创造的价值
服务于产品负责人
确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域
找到有效管理产品待办列表的技巧
帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项
理解在经验主义的环境中的产品规划
确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值
理解并实践敏捷性
当被请求或需要时，引导 Scrum 事件
服务于开发团队
作为教练在自组织和跨职能方面给予开发团队以指导
帮助开发团队创造高价值的产品
移除开发团队工作进展中的障碍
按被请求或需要时，引导 Scrum 事件
在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队
服务于组织
带领并作为教练指导组织采纳 Scrum
在组织范围内规划 Scrum 的实施
帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发
引发能够提升 Scrum 团队生产率的改变
与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性
Scrum 事件
作用
使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要
在 Scrum 中的每个事件都是用来进行检视和适应的正式机会
Sprint
Sprint 是 Scrum 的核心，[2周,4周]，长度保持一致
构成
Sprint 计划会议
每日 Scrum 站会
开发工作
Sprint 评审会议
Sprint 回顾会议
要求
不能做出有害于 Sprint 目标的改变
不能降低质量的目标
随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可以加以澄清
和重新协商。
和重新协商。
每个 Sprint 都可以被视为一个项目
Sprint 的长度限制在一个月内
取消 Sprint
在 Sprint 时间盒结束之前取消
只有产品负责人才有取消 Sprint 的权力
某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消
由于 Sprint 的时间都很短，所以取消 Sprint 通常是不太合理的
评审重估
造成重创
Sprint 计划会议
是由整个 Scrum 团队共同协作完成的
是有时间盒限定的
作用（回答以下问题）
接下来的 Sprint 交付的增量中要包含什么内容？
产品负责人讲解 Sprint 的目标以及达成该目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。
Sprint 会议的输入
是产品待办列表
最新的产品增量
开发团队在这个 Sprint 中能力的预测
开发团队的以往表现
草拟Sprint 目标
要如何完成交付增量所需的工作？
Sprint 待办列表
选出的产品待办列表项
如何交付它们的计划
预估工作量
规划工作
自组织地领取
产品负责人能够帮助解释清楚所选定的产品待办列表项，并做出权衡
解释如何完成
Sprint 目标
在当前 Sprint 通过实现产品待办列表要达到的目的
为开发团队提供指引
为开发团队在 Sprint 中所实现的功能留有一定的弹性
所选定的产品待办列表项会提供一个连贯一致的功能
如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商Sprint 待办列表的范围。
每日 Scrum 站会
期间每天15min
检视昨日成果
汇报今日计划
提出遇到问题
作用
会上不解决
Sprint 评审会议
在 Sprint 快结束时举行
作用：用以检视所交付的产品增量并按需调整产品待
办列表
办列表
演示增量
时长：≤4h
包含内容
参会者包括 Scrum 团队和产品负责人邀请的主要利益攸关者
产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”
开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的
开发团队演示“完成”的工作并解答关于所交付增量的问题
产品负责人讨论当前的产品待办列表的情况
参会的所有人就下一步的工作进行探讨
评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变
为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场
输出
修订后的产品待办列表
阐明很可能进入下个 Sprint 的产品待办列表项
为了迎接新的机会而进行全局性地调整
Sprint 回顾会议
是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会
发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前
时长：≤3h
目的
检视前一个 Sprint 中关于人、关系、过程和工具的情况如何
找出并加以排序做得好的和潜在需要改进的主要方面
制定改进 Scrum 团队工作方式的计划
Scrum 工件
以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机会
产品待办列表
是一份涵盖产品中已知所需每项内容的有序列表
永远是不完整的
列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更新：描述、次序、估算和价值
会成长为更大和更详尽的列表
可能需要使用能够对产品待办列表项进行分组的属性
产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作
排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节
开发团队负责所有估算工作
作用：监控目标实现的进度
Sprint 待办列表
是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划
至少包括一项在前次回顾会议中确定下来的高优先级的过程改进
拥有足够细节的计划
在 Sprint 期间，只有开发团队可以改变 Sprint 待办列表
作用：监控 Sprint 进度
增量
是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和
在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准
增量是在 Sprint 结束时支持经验主义的、可检视的和已完成的产品组成部分
增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用
工件透明
Scrum 依赖于透明
Scrum Master 必须和产品负责人、开发团队和其他相关人员一起合作，以确保所有工件都是完全透明的
Scrum Master 的职责就是和 Scrum 团队以及组织一起合作增加工件的透明化
“完成”的定义
当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么
指导开发团队了解在 Sprint 计划会议时能够选择多少产品待办列表项
如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有 Scrum 团队都必须遵守它，以此为最低标准
如果增量“完成”的定义不是开发组织的惯例，那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义
随着 Scrum 团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量
结束语
Scrum 的角色、事件、工件和规则是不可改变的。虽然只实施部分的 Scrum 是可能的，但这样就不是 Scrum 了。Scrum 只以整体形式而存在，唯其如此才能作为其他技术、方法和实践的容器运作良好。
本思维导图由作者阅读《Scrum 指南™Scrum 权威指南：游戏规则》一书编写而成
收藏
0 条评论
下一页
