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