敏捷团队检查清单
免费下载
持续地改进
过程
具有
完成的定义
(DoD)
DoD在每个迭代内都是
切实
可行的
团队
尊重
DoD
基本条目
每个迭代(4周以内)交付
测试过
且可工作的软件
交付
业务最需要的
内容
每个迭代后举行
演示
(demo)
展示
测试过且可工作的软
件
收到来自利益相关者和PO
的
反馈
每个迭代结束后都举行
回顾
(retrospective)
产出具体的改进
提案
一些提案真正得到
实现
团队全员和
PO参加
团队拥有一个
迭代待办项列表
(sprint backlog)
高度
可视化
毎日
更新
完全地由
团队
拥有
举行
迭代计划会议
(sprint
planning meetings)
PO
参加
团队全员
参加
产出
迭代计划
(sprint
plan)
团队全员相信计划是
切实
可行的
PO
对待办项的优先级满意
PO展示
最新的产品待办项
列表
迭代长度
小于等于
4
周
总是
按时结束
团队
不被外部打扰或控制
基于时间盒的
迭代
PO 拥有一个
产品待办项列表
（
product backlog)
高优先级待办项是按业务
价值
排序过的
高优先级待办项是
估算过
的
PO理解所有待办项的
目的
高优先级待办项
粒度足够
细，可以放入一个迭代内
由团队进行估算
明确
产品负责人
(PO)
PO
有权
进行优先级排序
PO
有知识
进行优先级排序
PO直接
与团队接触
PO直接
与利益相关者接触
当PO是一个团队时， PO们
统一口径
团队成员
坐在一起
如果你做到了这些，就可以忽略检查清单的其
他部分。你的过程还不错
这些条目是Scrum的主要元素。没有它们，
你就不能称之为Scrum
Scrum
核心
PO的
产品愿景
体现在产品待办
项列表中
产品待办项列表和产品愿景
高度
可视化
团队全员参与估算
团队估算时PO
在场
团队成员
不会局限于特定角色
团队具备完成待办项的
所有技能
团队具有一个Scrum
Master(SM)
团队都知道最紧迫的1-3条
障碍
SM
具备应对策略
去解决紧
迫的障碍
SM
专注于
移除障碍
当团队不能解决时提交给
管理层
度量
速率
(velocity)
速率仅统计
完成
的待办项
PO利用速率来做
发布计划
(release planning)
团队拥有一个
迭代燃尽图
当前迭代内的待办项
拆分成任务
(task)
毎日重新估算
进行中的任
务
高度
可视化
毎日
更新
PO
每周至少参加几次
迭代计划内的所有待办项
都具有
估算值
SM
与团队坐在一起
每日站会
(daily scrum)每天举
行，固定地点和时间
迭代的任务是
估算过的
用
相对大小
(故事点)而不是时间
来估算
最长15
分钟
每个团队成员都
知道其他
人在做什么
大多数通常是需要的，但不是所有。尝试!
推荐但不完全是必须的
举行
每日站会
(daily scrum)
团队全员参加
暴露出问题和障碍
存在一个
首席产品负责人
(chief
PO)(如果多个PO的话)
相互依赖的团队举行Scrum of
Scrums
相互依赖的团队
每个迭代内进行
集成
扩大规模
快乐
! 热情饱满
很少加班
且自愿发生
对过程进行讨论、批评和
尝试
积极信号
Scrum
检查清单
http://www.crisp.se/scrum/checklist | Version 2.2 (2010-10-04)
非官方
Henrik
Kniberg
PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done
队通常能够
交付他们承诺
的内容
良好Scrum实施的主要信号。
任何扩大Scrum规模的努力都要具备的
最基本条件。
每个团队
最多
9
人
注定失败
的迭代趁早结束
简体中文翻译：
申健 JackyShen@UPerform.cn
窦涵之 Hanzhi.Dou@CugeSoft.com
这是什么？ 给谁用？
Scrum检查清单是一个简单的工具，帮助你启动Scrum，或评估
当前的Scrum实施状况。
注意这不是规则。它们是指导方针。两个人的团队可能决定不
举行每日站会，因为他们整天结对编程而无需一个单独的会议
去同步。好吧。他们故意地略过了一项Scrum实践，但确保了
Scrum实践的根本目的以另一种形式得到了满足。这是最重要
的！
如果你在实施Scrum，在回顾会议中让团队来逐条检查这份清
单可能会很有意思。作为一个讨论工具，而不是评估工具。
我该如何使用？
•
小周
:"“这次回顾会议，我带来一个有用的小清单。有哪些
事情我们没做到吗？”
•
小丽
:"“嗯，咱们来看看。哦，我们肯定漏掉了DoD，我们也
没有度量速率。”
•
小周
:"“哦，'DoD'列在'Scr um核心'之内，看起来非常重要。'
速率'列在'推荐但不完全是必须的'之内，那就让我们等一下，
先开始核心的事情。”
•
小丽
:"“看，我们还漏掉了'每个迭代(4周以内)交付测试过且
可工作的软件'。它列在'基本项目'之内！有道理，因为市场
部总是在抱怨这件事！”
•
小周
:"“或许'DoD'的概念能帮助我们在每个迭代都完成一小
部分，并且更频繁地交付？”
•
小丽
:"“好主意，让我们试一试。”
什么情况下不该使用？
•
大老板
:"“好了团队，该看看我们的Scrum实施得怎么样了？
请填一下这份检查清单。”
•
小周
:"“老板，我很高兴向你汇报我们所有事情都在做。好
吧，除了迭代燃尽图这一项。”
•
大老板
:"“烂，烂团队！这上面说你们应该做那些…呃…迭代
燃尽什么的！我想要它们！”
•
小丽
:"“但我们运行两周长度的迭代，而且几乎总能交付我
们所承诺的，客户也挺满意。迭代燃尽图目前不会增加什么
价值。”
•
大老板
:"“可这上面说你们应该做，别让我再逮到你们耍花
招，否则我会找些Scrum警察过来。”
这是官方的检查清单吗？
不是。它反映了我个人对Scrum重要事物的主观看法。我花了
好几年来帮助许多公司启动Scrum，并会见了数百位实践者、
培训师和教练；我发现如果使用得当，像这样的清单是有益的。
Scrum
检查清单
Henrik2Kniberg
www.crisp.se/sc r u m/ch e cklist, www.uperform.cn/scrum-check list-henrik -kniberg/
简体中文翻译：
申健 JackyShen@UPerform.cn
窦涵之 Hanzhi.Dou@CugeSoft.com
of 2
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论