作者 Henrik Kniberg 专长 Java 和敏捷软件开发，曾任开发人员、经理、敏捷教练和咨询师，目前在斯德哥尔摩的 Crisp 公司任职。本书介绍了实践 Scrum 的一些方法，英文版《Scrum and XP from the Trenches - 2nd Edition》可在 InfoQ 免费下载。

怎样编写 backlog

backlog 是一个：

• 需求（故事/特性/事项）组成的列表
• 按重要性排序
• 包含客户想要的东西
• 用客户的话语描述

通常包含这些内容：

• 2 到 10 个字符的名称，例如「查看自己的交易明细」
• 简介或备注
• 产品负责人提出的重要性数值
• 团队给出的初始估算故事点
• 演示方法

有时会包含其他内容：

• 类别/赛道：给故事大致分类，例如「系统优化」、「管理后台」等

让 backlog 停留在业务层次

如果一个 backlog 的内容是「为事件表添加索引」，试着找出真正的内在目标，例如「提高后台查询表单的响应速度」，尝试「如何」的技术思考可以记录在 backlog 的备注中。

怎样准备 sprint 计划

• 确保 backlog 存在
• 确保 backlog 中重要的条目按重要性排好序
• 所有人都可以添加 backlog，但只有产品负责人可以决定重要性
• 产品负责人需要知道每个故事为什么会出现

范围、重要性、估算

产品负责人首先概括希望在这个 sprint 中达成的目标以及他认为重要的故事，接下来团队从最重要的开始逐一讨论与估算时间，这时候针对范围提出的问题可能会使估算需要重新调整。

如果产品负责人无法参加 sprint 会议

• 说服产品负责人理解并参加
• 寻找一名全权代表，可以从团队中寻找，也可以由产品负责人推荐
• 换人
• 推迟 sprint 启动日期，拒绝承诺任何交付

内部质量 & 外部质量

• 外部质量：系统用户可感知的，例如用户界面
• 内部质量：系统的可维护性，例如设计一致性、测试覆盖率、代码可读性等

内部质量是一个常量

「既然你想尽早得到这个特性，那我们能不能把范围缩小一点？这样时间就能缩短，也许我们可以简化错误处理的功能，把「高级错误处理」作为一个单独的故事放到以后的 sprint。或者也可以降低其他故事的优先级。」

怎样制定 sprint 计划

Scrum 中的一切都有时间盒。一个典型的时间表是这样的：

• 13:00 - 13:30 产品负责人对 sprint 目标进行总体介绍，概括产品 backlog，确定演示时间和地点
• 13:30 - 15:00 团队估算时间，在必要时拆分 backlog，产品负责人在必要时修改重要性评分
• 15:00 - 16:00 团队选择要放入 sprint 的故事，计算生产率
• 16:00 - 17:00 为每日例会安排时间，把故事进一步拆分成任务

确定 sprint 目标

回答「我们为什么要进行这个 sprint？为什么我们不直接放假算了？」这个问题，而且只能使用业务术语。

• 挣更多的钱
• 完成优先级最高的三个故事
• 打动客户
• 发布 beta 版
• ……

产品负责人如何对 sprint 中放置的故事产生影响

产品负责人无法控制团队的估算生产率，如果需要故事 D 进入本次 sprint，他可以使用三种方案：

1. 提高 D 的优先级，把 C 挤出 sprint
2. 缩减 A 的范围，直到团队相信故事 D 在这个 sprint 里能分配到足够的资源
3. 判断出 A 中不那么重要的部分可以拆分出 A2，赋予不同的优先级

团队怎样决定把哪些故事放到 sprint 里

• 本能反应

如果 sprint 时间不长，小团队可以按照直觉评估

• 估算生产率

1. 得出估算生产率
2. 计算在不超出估算生产率的情况下可加入多少故事

$\text{Almost} \leqslant 0$，在敏捷软件开发的概念里，不能交付的故事价值为 0。

估算生产率可以看历史数据，没有历史数据时可以编一个，下次 sprint 如果团队和环境基本没有变化就有历史数据可供参考了。故事点差不多可以对应理想化的人日，但是完美、高效、不受打扰的一天是不存在的，需要引入投入程度表示「团队有多少时间可以放在当前承诺的故事上」。

通过索引卡展示故事

引用原书插图的索引卡，可以看到 sprint 会议开始前由产品负责人做了重要性评分

把他们按重要性排布。一旦放置完成，具体的数据就不重要了，因为故事的重要性可以随着索引卡片的移动变化。

用即时贴去表示任务。

拆分与评估故事

使用计划扑克评估故事点：

• 0：很快就能完成
• 1/2，1，2，3，5，8，13
• 20，40，100：数字已经很大了，没有给出精确值的意义，考虑把这个故事拆分为几个小故事
• ？：没有概念没有想法
• 休息卡

如果两个成员对同一故事的评估差异过大，就需要进行任务分解重新评估。

如果团队的评估与产品负责人的预期差异过大，就需要完善故事卡片的描述，确定双方对故事范围的理解是一致的。

同样是「添加用户」故事，一个 web 界面可以对用户做增删改查需要 20 个故事点，而一个插入数据的 SQL 语句只需要 5 个故事点。

较大的故事点数可能导致承诺不足与过度承诺，这些故事基本都可以拆分，只要小故事依然可以交付业务价值即可。

怎样把故事拆分为任务

技术任务/非功能性条目

需要完成的不可交付物，和任何故事都没有直接关联，不会给产品负责人带来直接价值。

• 编写 CI/CD 配置
• 编写系统设计概览
• 重构代码
• ……

通常产品负责人会给予一个较低的优先级，原因显而易见。

• 试着把技术故事变为可以衡量业务价值的普通故事
• 试着把它变成普通故事中的一个任务
• 用投入程度与预估生产率的提高来与产品负责人协商

Bug

一种观点：修复 bug 不是 sprint 中的工作，它会把团队的投入程度拉低。

sprint 中的状态跟踪

任务板

怎样解读和使用燃尽图

• sprint 的时间是 8 月 1 日到 8 月 19 日
• 团队估算生产率是 70 个故事点
• 到了 8 月 16 日还剩 15 个故事点未完成

按照这个速度，在 sprint 结束时团队能够完成所有任务。

每日例会

• 团队成员简述自己昨天做了什么，今天计划做什么，然后更新即时贴的位置
• 如果任务的估时有变化，直接在便条贴上修改
• 例会结束后根据剩余工作的时间估计之和更新燃尽图

怎样制定发布计划

尝试回答「最晚到什么时候为止，我们可以交付这个新系统的 1.0 版本？」。可以读 Mike Cohn 的《敏捷估计与规划（Agile Estimating and Planning）》。

把重要性数字拿来用，比如：

• $\text{重要性} \gt 100$，必须在 1.0 版中发布，不然我们就完了
• $50 \lt \text{重要性} \lt 99$，应该在 1.0 版中发布，不过也许可以在 1.0 后的小版本中发布
• $25 \lt \text{重要性} \lt 49$，可以放到 1.1 版
• $\text{重要性} \lt 25$，不确定，也许这些东西永远用不到

对重要条目进行时间估算

• 让团队做估算
• 产品负责人要描述故事，回答问题
• 不要花太多时间做太多事，例如只需要估算前 20 个重要的 backlog 故事
• 时间估算不是承诺

调整发布计划

诚实并给客户做选择。

「嗨，我们目前比进度稍微慢了点，不过我们相信如果把 XX 特性去掉的花就可以在期限前完工，因为这个特性会用去很多时间。如果你同意的话我们可以在第一次发布后三周内的后续发布中增加该功能。」

ScrumMaster 检查单

开始阶段

• [ ] sprint 计划会议后创建 sprint 信息页
  • [ ] wiki 上创建从 dashboard 指向所创建页面的链接
  • [ ] 把页面打出来贴在墙上
• [ ] 给每个人发邮件声明 sprint 启动，包括 sprint 目标和相关链接
• [ ] 更新 sprint 数据文档，加入估算生产率、团队大小和 sprint 长度

每日清单

• [ ] 确保每日例会按时开始和结束
• [ ] 适当增删故事
  • [ ] 确保产品负责人了解故事的变化
• [ ] 确保团队及时了解 sprint backlog 和燃尽图的变化
• [ ] 确保问题和障碍及时解决，并报告给产品负责人和/或开发主管

结束阶段

• [ ] 开放式 sprint 演示
• [ ] 演示开始前一两天通知每个人
• [ ] 与整个团队开 sprint 回顾会议
• [ ] 更新 sprint 文档，记录实际生产率和回顾会议的结论