scrum-20210902
2021-09-06 15:44:43 17 举报AI智能生成
坚持一日一思维导图，加油！ 近期钻研主题：敏捷 参考链接：https://www.scrumcn.com/agile/scrum-knowledge-library/%e4%bb%80%e4%b9%88%e6%98%afscrum.html 最后，走过路过点个小赞 👍 ，谢谢！
作者其他创作
大纲/内容
定义
用于开发、交付和持续支持复杂产品的一个框架
一个增量的、迭代的开发过程
流程图
子主题
scrum框架
3个角色
产品负责人（Product Owner）
职责
将开发团队开发的产品价值最大化
管理产品待办列表的唯一负责人
是一个人
不是一个委员会
Scrum Master
根据 Scrum 指南中的定义来促进和支持 Scrum
帮助理解
Scrum 理论
实践
规则
价值
服务型领导
帮助交互
Scrum 团队之外的人
Scrum 团队
改变互动方式
最大化价值
服务于产品负责人
尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域
找到有效管理产品待办列表的技巧
帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项
理解在经验主义的环境中的产品规划
确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值
理解并实践敏捷性
按要求或需要引导 Scrum 事件
服务于开发团队
在自组织和跨职能方面给予开发团队指导
帮助开发团队创造高价值的产品
移除开发团队工作进展中的障碍
按要求或需要引导 Scrum 事件
在 Scrum 还未完全采纳和理解的组织环境中指导开发团队
服务于组织
带领并指导组织采纳 Scrum
在组织范围内规划 Scrum 的实施
帮助员工和干系人理解并实施 Scrum 和经验产品开发
引发能够提升 Scrum 团队生产率的改变
与其他 Scrum Master 一起工作，增加组织中 Scrum 应用的有效性
开发团队
组成
各种专业人员
由组织组建并得到授权
职责
每个 Sprint 结束时
交付潜在可发布并且“完成”
的产品增量
自组织
自己组织
管理他们的工作
特点
自组织
没有人（即使是 Scrum Master）有权
把产品待办列表变成潜在可发布的功能增量
跨职能团队
拥有创建产品增量所需的全部技能
无头衔
开发团队成员无任何头衔
不管其承担何种工作
都叫开发人员
无“子团队”
无关领域
如
测试
架构
运维
或业务分析
责任属于整个开发团队
不区分
特长
专注的领域
开发团队的规模
最佳规模
足够小
保持敏捷性
足够大
在 Sprint 内完成重要的工作
过小
遭遇到技能上的约束
无法交付潜在可发布的产品增量
超过 9 人
过多的协调沟通工作
太多的复杂性
变得无用
产品负责人和 Scrum Master 角色不包含在此数字中
除非他们同时也参与执行 Sprint 待办列表中的工作
3个工件
产品 Backlog（Product Backlog）
属性
表述
清晰地表述产品待办列表项
排序
对产品待办列表项进行排序，使其最好地实现目标和使命
排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节
优化
优化开发团队所执行工作的价值
进度
确保产品待办列表对所有人是可见、透明和清晰的
显示 Scrum 团队下一步要做的工作
深度了解
确保开发团队对产品待办列表项有足够深的了解
测试描述
将在“完成”时证明其完整性
分组
产品待办列表
一份涵盖产品中已知所需每项内容的有序列表
产品需求变动的唯一来源
永远是不完整的
随着产品及其应用环境的改变而演进
持续更新以反映出产品需要什么来保持其适用性、竞争力和有用
产品存在
产品待办列表也就同样存在
一个产品只有一个产品待办列表用于描述下一步产品开发工作
产品负责人
管理产品待办列表
内容
可用性
排序
产品待办列表精化
为产品待办列表项增添细节、估算和排序的动作
持续的过程
产品负责人和开发团队协同工作在产品待办列表项的细节上
产品待办列表项被重新评审和修改
精化的工作通常占用开发团队不超过 10% 的产能
产品待办列表项中那些即将会占用开发团队下一个 Sprint 大部分时间的项会被加以精化
监控目标实现的进度
产品负责人
跟踪剩余工作总量
比较这次的剩余工作量与之前 Sprint 评审会议时的剩余工作量
评估在期望的时间点达成目标的进度
对所有的干系人透明
不同趋势走向的实践
燃尽图（burn-downs）
燃烧图（burn-ups）
累积流图（cumulative flows）
Sprint Backlog
Sprint 待办列表
当前 Sprint 选出的产品待办列表项
交付产品增量
实现 Sprint 目标的计划
拥有足够细节的计划
开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测
至少包括一项在先前回顾会议中确定下来的高优先级过程改进
新工作出现时
开发团队需要将其加入到 Sprint 待办列表中去
计划中的某个部分失去开发意义
将其移除
Sprint 期间
只有开发团队可以改变 Sprint 待办列表
由开发团队全权负责
监控 Sprint 进度
在 Sprint的任何时间点都可以计算 Sprint 待办列表中所有剩余工作的总和
在每日 Scrum 站会时跟踪剩余的工作量
预测达成 Sprint 目标的可能性
在 Sprint 中不断跟踪剩余的工作量，开发团队可以管理自己的进度
产品增量（Increment）
产品待办列表项的总和
一个 Sprint 完成的所有
以及之前所有 Sprint 所产生的增量的价值总和
新的增量必须是“完成”的
必须可用
达到了 Scrum 团队“完成”的定义的标准
支持经验主义的可检视的
已完成的产品组成部分
5个事件
Sprint
Scrum 的核心
长度
一个月或更短的限时
这段时间内构建一个“完成”、可用的和潜在可发布的产品增量
Sprint 的长度保持一致
前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始
Sprint本身是一个事件
包括了如下4个事件
Sprint 计划会议
Sprint Planning Meeting
每日 Scrum 站会
Daily Scrum Meeting
开发工作
Sprint 评审会议
Sprint Review Meeting
Sprint回顾会议
Sprint Retrospective Meeting
Sprint 期间
不能做出有害于 Sprint 目标的改变
不能降低质量的目标
随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会澄清和重新协商
每个 Sprint
可以被视为一个项目
为期不超过一个月
长度太长
构建定义可能改变
复杂性可能增加
风险可能增加
至少每月一次
对达成目标的进度
进行检视和适应
实现可预测性
把风险限制在一个月的成本
完成某些事情
有一个要构建什么的目标
一份设计过和灵活的计划
指导如何做这些事、工作内容和最终产品增量
取消 Sprint
可以在 Sprint 时间盒结束之前取消
只有产品负责人才有取消 Sprint 的权力
Sprint 目标过时
公司发生改变
发展方向
市场上
技术上
对其所在环境来说失去了价值和意义
当取消某个 Sprint 时
评审
任何做完和“完成”的产品待办列表项
具有潜在可发布
接受这个成果
重新估算
所有未完成的产品待办列表项都会被放回到产品待办列表中
花在它们身上的工作会很快地贬值
Sprint 计划会议
Sprint Planning Meeting
做计划
整个 Scrum 团队共同协作完成
限时
最多 8 小时
较短的 Sprint
会议时间通常会缩短
Scrum Master
确保会议顺利举行
教导 Scrum 团队遵守时间盒的规则
每个参会者
理解会议的目的
话题
这次 Sprint 能做什么？
开发团队
预测
要开发的功能
产品负责人
讲解
Sprint 的目标
达成该目标所需完成的产品待办列表项
草拟一个 Sprint 目标
实现产品待办列表要达到的目的
为开发团队提供指引
使开发团队明确开发增量的目的
整个 Scrum 团队
协同工作
理解 Sprint 的工作
输入
产品待办列表
最新的产品增量
开发团队在这个 Sprint 中能力的预测
开发团队的以往表现
开发团队
自己决定选择产品待办列表项的数量
评估接下来的 Sprint 可以完成什么工作
如何完成所选的工作？
如何在 Sprint 中把选定功能构建成“完成”的产品增量
从 Sprint 中所选出的产品待办列表项加上交付它们的计划称之为 Sprint 待办列表
开发团队
从设计整个系统开始
到如何将产品待办列表转换成可工作的产品增量所需要的工作
挑选出足够量的工作
预估他们在即将到来的 Sprint 中能够完成
自组织地领取 Sprint 待办产品列表中的工作
领取工作在 Sprint 计划会议和 Sprint 期间按需进行
Sprint 目标
通过实现产品待办列表要达到的目的
为开发团队提供指引
使得团队明确为什么要构建增量
在 Sprint 计划会议中确定
所选定的产品待办列表项会提供一个连贯一致的功能，也即是 Sprint 目标
任何其他的连贯性来促使开发团队一起工作而不是分开独自做
Sprint 计划会议结束时
开发团队
向
产品负责人
Scrum Master
解释
如何以自组织团队的形式
完成
Sprint 目标
开发出预期的产品增量
每日 Scrum 站会
Daily Scrum Meeting
以 15 分钟为限
在 Sprint 的每一天都举行
为接下来的 24 小时的工作制定计划
优化团队协作和性能
检视上次每日 Scrum 站会
预测即将到来的 Sprint 工作
同一时间同一地点举行
检视
完成 Sprint 目标的进度
完成 Sprint 待办列表的工作进度趋势
优化
开发团队达成 Sprint 目标的可能性
会议的结构
由开发团队设定
专注于
达成 Sprint 目标的进展
示例
昨天，我为帮助开发团队达成 Sprint 目标做了什么？
今天，我为帮助开发团队达成 Sprint 目标准备做什么？
是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？
Scrum Master
确保开发团队每日站会如期举行
教导开发团队将每日 Scrum 会议时间控制在 15 分钟内
确保他们不会干扰会议进行
如果有开发团队之外的人出席会议
开发团队
负责召开会议
内部会议
优点
进交流沟通
减少其他会议
发现开发过程中需要移除的障碍
突显并促进快速地做决策
提高开发团队的认知程度
Sprint 评审会议
Sprint Review Meeting
在 Sprint 快结束时举行
检视
所交付的产品增量
按需调整产品待办列表
Sprint 评审会议中
Scrum 团队和干系人协同讨论在这次 Sprint 中所完成的工作
根据完成情况和 Sprint 期间产品待办列表的变化
所有参会人员协同讨论接下来可能要做的事情来优化价值
演示增量的目的是为了获取反馈并促进合作
是一个非正式会议
不是一个进度汇报会议
长度为一个月的 Sprint
最长不超过 4 小时
较短的 Sprint
会议时间通常会缩短
Scrum Master
确保会议举行
每个参会者都明白会议的目的
教导每位参会者遵守时间盒的规则
包含内容
产品负责人邀请 Scrum 团队和主要的干系人参加会议；
产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
开发团队演示“完成”的工作并解答关于所交付增量的问题；
产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）；
参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的 Sprint 计划会议提供有价值的输入信息；
评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；
为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
输出
一份修订后的产品待办列表
Sprint 回顾会议
Sprint Retrospective Meeting
检视自身并创建下一个 Sprint 改进计划的机会
时间最长不超过 3 小时
Scrum Master
确保
会议举行
每个参会者都明白会议的目的
教导大家遵守时间盒的规则
鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践
在下个 Sprint 中更高效更愉快
目的
检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
找出并加以排序做得好的和潜在需要改进的主要方面；
制定改进 Scrum 团队工作方式的计划。
Sprint 回顾会议结束时
Scrum 团队
明确接下来的 Sprint 中需要实施的改进
5个价值
承诺
愿意对目标做出承诺
专注
把你的心思和能力都用到你承诺的工作上去
开放
Scrum 把项目中的一切开放给每个人看
尊重
每个人都有他独特的背景和经验
勇气
有勇气做出承诺
履行承诺
接受别人的尊重
SCRUM理论基础
透明性
Transparency
保持透明
软件开发过程的各个环节
影响交付成果的各个方面
参与交付的所有人
管理生产结果的人
工件透明
优化价值和控制风险的决定都是基于所获知的工件状态
Scrum Master
和产品负责人、开发团队和其他相关人员一起合作
确保所有工件都是完全透明的
帮助每个人，让他们能够在遇到不透明的情况下采取最合适的实践
通过检视工件、嗅探模式、倾听周围的声音以及观察预期和实际结果的差异来发现不完全透明
和 Scrum 团队以及组织一起合作增加工件的透明化
包括学习、说服和改变
如
使用统一的术语
“完成”的定义
一致的理解
某个人在检验一个过程
确信某一个任务已经完成时
等同于他们对完成的定义
检验
Inspection
足够频繁地检验
及时发现过程中的重大偏差
适应
Adaptation
对过程或是材料进行调整
发现过程中的一个或多个方面不满足验收标准
并且最终产品是不合格的
调整工作必须尽快实施
减少进一步的偏差
检验和适应
Sprint 计划会议
每日 Scrum 站会
检验Sprint目标的进展
做出调整
优化次日的工作价值
Sprint 评审会议
检验发布目标的进展
做出调整
优化下一个Sprint的工作价值
Sprint 回顾会议
回顾已经完成的Sprint
做出什么样的改善
使接下来的Sprint
更加高效
更加令人满意
工作更快乐
“完成”的定义
有相同的理解
对完成工作
是开发组织的惯例、标准或指南
以此为最低标准
每个增量都添加至之前的所有增量上
并且经过彻底地测试，以此确保整合在一起的所有增量都能工作
参考链接
https://www.scrumcn.com/agile/scrum-knowledge-library.html
职业：本科
0 条评论
下一页
