Scrum（五）过程详解

参考资料：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的改进行动计划，建立任务，有责任人，有预期完成时间。