Scrum_004：Scrum 的三个文档

在 Scrum 中有三个文档是必须要写的，它们是：product backlog、sprint backlog、burn-down chart。

1. product backlog
product backlog 是整个项目的需求概要文档。由 PO 专职负责，一般每周更新一次，在项目的整个生命周期间存续。

用一句简短的、用户熟悉的语言表达的需求，是用户讲给开发人员的故事，不是开发人员讲给用户的故事。
用户故事一般用三段论式的方式描述：
As a XX, I want to XX, so that XX.
作为一个XX角色, 我想要XX功能, 以便于实现 XX 商业价值的目的。

例如：作为一个家庭主妇，我需要一个 30 平米的餐厅，以便于我招待 10 位朋友用餐。
例如：作为系统的合法用户，可以通过录入账号和密码登录到系统中。

PO 根据对客户、对最终用户的商业价值来划分用户故事优先级。
PO 通过和客户进一步调研，以及和团队成员沟通，确定和完善用户故事的验收标准。

用户故事 “3C” 原则

1. Card 可以写在卡片上
2. Conversation 用于对话
3. Confirmation 及时确认

至此，product backlog => 需求 + 优先级 => 用户故事 + 优先级 + 验收标准 => 用户角色 + 功能 + 目的 + 优先级 + 验收标准

前面说的都是功能需求，对于非功能需求怎么办？
如果能够明确到某个故事，就描述在故事的验收标准中；如果不能明确到某个故事，就单独写个“技术故事”，单独列出来这些非功能需求。

理想的用户故事具有“ INVEST”特点：
（1）独立性 Independent
尽可能避免故事之间存在依赖关系，否则会造成划分优先级的困难，在安排开发顺序时需要考虑故事之间的依赖关系。
（2）可协商性 Negotiable
故事是可协商的，故事是有弹性的，不是必须实现的书面合同或者需求。
（3）对客户有价值 Valuable
确保每个故事对客户有价值的最好方式是让用户编写故事。
（4）可预测性 Estimable
开发者应该能够预测故事的规模，以及编码实现所需要的时间。
（5）短小精悍 Small
一般一个故事在一个迭代周期内是可以实现的。
（6）可测试性 Testable
所编写的故事必须是可测试的，能够定义出验收标准。

用户故事是如何估算的？
用户故事的估算单位是故事点（Story Points），代表了开发用户故事所需的全部工作量，所以团队的估算必须考虑到影响工作量的所有因素。这可能包括：

• 工作的数量
• 工作的复杂度
• 工作中存在的任何风险或不确定性

故事点是一个相对值，一般用 Fibonacci 数列来表示：0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89。虽然可以分为 12 个等级，但一般只采用0、1、2、3、5、8、13 这 7 个等级。如果在预估中发现超过 13 的，一般把任务分割为两部分。

等待 PO 基于商业价值挑选完毕某次交付中应该包含的用户故事后，接下来，Team 就可以挑选在某次迭代中要实现的用户故事了。

2. sprint backlog
sprint backlog 是在 sprint planning meeting 上讨论确认的任务列表。每个任务以小时为单位，一般没有超过 16 小时的任务。
sprint backlog 由 Team 专职负责，每天更新一次，在 spring 生命周期间存续。

每个任务完成的标志是什么？

（1）Team 成员检测：所有的单元测试通过。

（2）PO 检测：所有的功能测试通过。

3. burn down chart
burn down chart 译为燃尽图，还是很形象的，显示当前 spint 中未完成的任务数目，是展示项目进展的一个指示器。

每天开完 15 分钟站立会议后，由 SM 负责更新燃尽图。

横坐标为工作日期，纵坐标估计剩余的工作量，每个点代表了在那一天估计剩余的工作量。通过折线依次连接起所有的点形成为估计剩余工作量的趋势线。另外还有一条控制线，为最初的估计工作量到结束日期的连线，一般用不同的颜色画上边的两根线。

对此图的研判规则如下：

（1）如果趋势线在控制线以下，说明进展顺利，有比较大的概率按期或提前完工。

（2）如果趋势线在控制线以上，说明有比较大的概率延期，此时需要关注进度了。

注意，趋势线并非一直下行，也有可能上行，即发生了错误的估计或遗漏的任务时。