Scrum 检查清单

PO = Product Owner

SM = Scrum Master

PBL = Product Backlog

DoD = Definition of Done

基本条目：

如果你做到了这些，就可以忽略检查清单的其他部分，你的过程还不错

• 每个迭代（4 周以内）交付测试过且可工作的软件
• 交付业务最需要的内容
• 持续地改进过程

Scrum 核心：

这些是 Scrum 的主要元素。没有它们，你就不能称之为 Scrum

• 明确产品负责人（PO）
  • PO 有权进行优先级排序
  • PO 有知识进行优先级排序
  • PO 直接与团队接触
  • PO 直接与利益相关者接触
  • 当 PO 是一个团队时，PO 们统一口径
• 团队拥有一个迭代待办事项列表（sprint backlog）
  • 高度可视化
  • 每日更新
  • 完全地由团队拥有
• 举行每日站会（daily scrum）
  • 团队全员参加
  • 暴露出问题和障碍
• 每个迭代后举行演示（demo）
  • 展示测试过且可工作的软件
  • 收到来自利益相关者和 PO 的反馈
• 具有完成的定义（DoD）
  • DoD 在每个迭代内都是切实可行的
  • 团队尊重 DoD
• 每个迭代结束之后都举行回顾（retrospective）
  • 产品具体的改进提案
  • 一些提案真正得到实现
  • 团队全员和 PO 参加
• PO 拥有一个产品待办事项列表
  • 高优先级待办事项是按业务价值排序过的
  • 高优先级待办事项是估算过的
  • 由团队进行估算
  • 高优先级待办事项粒度足够细，可以放入一个迭代内
  • PO 理解所有待办事项的目的
• 举行迭代计划会议（sprint planning meetings）
  • PO 参加
  • PO 展示最新的产品待办事项列表
  • 团队全员参加
  • 产出迭代计划（sprint plan）
  • 团队全员相信计划是切实可行的
  • PO 对待办事项的优先级满意
• 基于时间盒的迭代
  • 迭代长度小于等于 4 周
  • 总是按时结束
  • 团队不被外部打扰或控制
  • 团队通常能够交付他们承诺的内容
• 团队成员坐在一起
  • 每个团队最多 9 人

Scrum 检查清单：

推荐但不是必须的，大多数通常是需要的，但不是所有，可以尝试

• 团队具备待办事项的所有技能
• 团队成员不会局限于特定的角色
• 注定失败的迭代趁早结束
• PO 的产品愿景体现在产品待办事项列表中
• 产品待办事项列表和产品愿景高度可视化
• 团队全员参与估算
• 团队估算时 PO 在场
• 用相对大小（故事点）而不是时间来估算
• 团队都知道最紧迫的1-3 条障碍
  • SM 具备应对策略去解决紧迫的障碍
  • SM 专注于移除障碍
  • 当团队不能解决时提交给管理层
• 团队具有一个 Scrum Master（SM）
  • SM 与团队坐在一起
• 当前迭代内的待办事项拆分成任务（task）
  • 迭代的任务是估算过的
  • 每日重新估算进行中的任务
• 度量速率（velocity）
  • 迭代计划内的所有待办事项都有估算值
  • PO 利用速率来做发布计划（release planning）
  • 速率仅统计完成的待办事项
• 团队拥有一个迭代燃尽图
  • 高度可视化
  • 每日更新
• 每日站会（daily scrum）每天举行，固定地点和时间
  • PO 每周至少参加几次
  • 最长 15分钟
  • 每个团队成员都知道其他人在做什么

扩大规模

任何扩大 scrum 规模的努力都要具备的最基本条件：

• 存在一个首席产品负责人（chief PO）
• 互相依赖的团队举行 Scrum of Scrumns
• 互相依赖的团队 每个迭代内进行集成

积极信号

良好的 Scrum 实施的主要信号

• 快乐！热情饱满
• 很少加班且自愿发生
• 对过程进行讨论、批评和尝试