参考资料：https://www.uperform.cn/scrum-core-practices-training-learning-ppt-slide-deck-for-free/
Scrum的3个角色
1.Development Team 交付团队的使命和特征
- 3 – 9 人
- 跨职能，具备不同的职能，没有子团队，“T” 型人才，通用的专才
- 全职投入， sprints之间方可换人，坐在一起
- 自组织：
没有管理者头衔
全员责任制
团队承担大部分微观管理工作 - 决定迭代的工作容量
- 每个迭代交付产品增量
- 对“怎样做”和交付质量负责
- 管理Sprint Backlog并跟踪进度
- 找到团队内部合作的最佳方法
- 与其他团队及相关方协作
- 持续自我改进
2.Product Owner 产品负责人的特征和职责
- “一”个人, 而非一个委员会
- 被授与产品（“做什么”）决策权
- 驱动产品走向成功
- 提供产品领导力
- 面向干系人代表团队
- 面向团队代表干系人
- 和所有人合作
- 理想情况下是真正的用户来担任
- 建立产品愿景
- 从“为什么”开始
- 定义产品功能（“做什么”）
- 确保迭代输入准备好
- 负责最大化投资回报
- 根据反馈，为最好地实现业务目标将产品Backlog排定优先顺序
- 决定版本发布日期和内容
- 愿意投入到合作中并且在需要时被团队找到
- 接受或退回工作成果
3.Scrum Master 团队敏捷教练的特征和职责
- 面向管理层代表团队
- 面向团队代表管理层
- 没有管理头衔和权力 – 不代表团队做出决定
- 更多是一个教练
- 被授权的‘牧羊犬’
- 团队和组织变革的代理人
- 听多于说
- 是一个具备影响力的仆人式领导者
- 向大家布道Scrum
- 彰显Scrum价值观、原则、实践和框架的模范
- 保护团队
- 移除障碍和浪费
- 教练和培养团队的实践，帮助持续改进
- 引导大家的协作
- 提升组织变革的效果
SM Candidate 候选者特征
开放心态，积极探索，愿意分享和帮助他人。经历过转型或至少了解组织政治生态，善用权力但不渴望权力。中等偏上的技术和产品知识水平。具备沟通能力和意愿包括影响力。从性格像限看，友善或表现型偏多
ScrumMaster常见的关注领域
- Team
引导仪式和会议
学习和团队发展 - PO
需求待办清单的梳理 - Tech
持续集成
解耦 - Organizational
跨团队协作
对管理层进行教练
提高透明性
Scrum的3个工件
1.产品Backlog
- 一份动态的有序列表，包含了符合产品愿景的各种功能
- 以及其他为用户带来价值的工作
- 一个健康的product backlog应当满足UPERFORM原则：
Unified, 唯一的
Pull-based, 拉动式
Emergent, 动态的
Revealed, 公开的
Feature-sliced, 纵切的
Ordered, 已排序
Refining, 持续精炼
Measurable, 可度量 - 对所有人开放但最终由PO维护
- 关注于“什么“带给用户最大的价值
- 最优秀的PO从“为什么”开始
2.迭代待办项列表
- 为本Sprint所选择的PBI以及交付所选PBI的工作计划之和
- 产品Backlog 的延伸和子集
- 为实现Sprint目标所要完成的工作集合
- 涵盖‘恰到好处’的设计
- 将大块的工作分解为更小的单元 (PBI -> SBI)
- 关注于“怎么做”的问题：如何在一个sprint内完成工作以交付价值
- 被开发团队拥有
- 团队从product backlog中选取他们可以承诺完成的项目并创建sprint backlog
- 协作完成，不是由ScrumMaster负责
- 一个可视化的工具让团队在sprint内部自我管理
迭代目标
- 迭代目标是本迭代中通过实现PB来达成的目标
- 向团队提供构建该增量的理由（why）
- 会议上产生
T- 给予团队一些在功能实现上的灵活性
可视化任务墙看板
- 任务板是一个常见的用于管理sprint backlog的可视化工具
- 自组织：团队成员或小分队自己领取工作
- 团队一起将PBI分解为SBI
- 团队决定合适的SBI颗粒度
- 没有一个人主导任务的分配
- 完成一项任务才认领另外一项任务
- 按照优先级，努力使一个PBI尽早完全完成
- 团队每天跟踪Sprint中剩余的工作
- 任何团队成员可以添加，删除或变更sprint backlog事项 (SBI)
- sprint内的工作有可能动态涌现
- 对全世界可见
- 随时更新
- 直观展示Sprint目标完成的进展
- 工作可视化管理的工具
迭代燃尽图
- 燃尽图是一个可选的可视化工件，用来管理Sprint Backlog，并帮助团队自己跟踪进度和暴露风险
- 随时更新
- 度量Sprint剩余工作的总量
- 燃尽图有不同思路
- 剩余工作量估算
- 跟踪已完成项
3.潜在可交付产品增量
- 当前Sprint所完成的PBI，以及之前所有Sprint的增量价值之和
- 潜在可交付，并符合完成的定义
- 必须是可用的产品，不管PO是否决定对外发布
Scrum的5个事件
1.迭代计划会
- 时间：1个月的Sprint最长8小时
- 第一部分 选择
内容：定义迭代目标，选择团队可以承诺完成的迭代待办项
参与者：PO/Team/SM（可选）
输入: 健康的产品Backlog
输入: 最新版本的增量
输入: 团队这个Sprint的速率
输出: 根据所选择的产品Backlog事项制定Sprint目标 - 第二部分 计划
内容：决定如何实现迭代目标，创建 Sprint Backlog，估算迭代待办项
参与者: Team/PO（可选）/SM（可选）
输入：团队这个Sprint所有人的工作容量
输出: 如何实现Sprint目标的工作计划(Sprint Backlog)
输出: 大家对Sprint目标形成共识
2.Sprint 迭代
- 项目由一系列“sprint”组成，借鉴了极限编程中的“迭代”
- 周期：不超过一个月的日历时间, 建议1~2周
通常是定长的，有利于产生更好的交付节奏
只有当时间盒到期时，Sprint结束 - 根据DoD定义，全部相关工作在sprint内完成
- 不去改变Sprint的目标
- 不改变当前运行中的Sprint的长度
- 出于业务需要，Product Owner可以取消Sprint
- 如果无法完成任何东西，团队可以和PO协商应对
- 重新做Sprint计划－所有还”未完成的工作”放回产品Backlog
- 罕有发生！
3.每日站会
- 时间：每日，15分钟，同一时间同一地点
- 方式：站立
- 参与者: Development Team（必选），SM（可选），PO（可选）
- 目的：为达致Sprint目标检视进展和调整计划
- 方式：每个人回答三个问题
昨天我完成了什么，以便帮助交付团队达成迭代目标？
今天我要完成什么，以便帮助交付团队达成迭代目标？
有什么障碍影响我的进度和迭代目标吗？ - 注意：
不讨论和解决具体问题
其他人可以受邀来旁听
只有团队成员，ScrumMaster和Product Owner可以说话
帮助避免其他不必要的会议
不是向ScrumMaster汇报状态，而是向所有组员的广播，属于自管理的一部分
4.迭代评审会
- 目的： 检视和调整产品和产品Backlog
- 花费时间：1个月的Sprint时间盒最长4小时
- 环境：非正式，不要用幻灯片，尽量不要准备
- 参与人员：全Scrum团队，邀请所有干系人及感兴趣的人士
- 做什么：团队展示Sprint的成果，PO应当尽早验收，产品负责人表明哪些“完成”的工作被接受了，哪些“未完成”的工作被退回了，经常以Demo新功能（及其依赖的架构）的形式，获取反馈和讨论接下来要做的工作，从而持续优化价值
- 输出：可发布的产品增量
5.迭代回顾会
- 目的：对我们如何工作(人、关系、过程、工具等)进行检视和调整, 对过程的持续改进
- 花费时间：每1周的Sprint花费45min
- 参与人员：全Scrum团队，同时也欢迎其他感兴趣的受邀人士
- 环境：在安全的环境中进行
- 做什么，三问：
开始做什么？
停止做什么？
K继续做什么？ - 输出: 下一个Sprint的改进行动计划，建立任务，有责任人，有预期完成时间。
