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