【落叶99】“老兵聊测试”之教你如何写好用户故事

文/秋之川

【目录】

这是《落叶》文集里第 99 片落叶，希望你能喜欢，不为别的，只为这份坚持。

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. 

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

什么叫用户故事？就是从用户的角度来描述用户渴望得到的功能，英文叫做 User Story。

一个完整的用户故事应该包括以下三个要素：

角色、活动、商业价值。

一个好的用户故事应该遵循INVEST原则，包括以下六大特性：

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

独立性（Independent）：

要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖关系会使得制定计划、确定优先级和工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）：

一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）：

每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可估算性（Estimable）：

开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）：

一个好的故事在工作量上要尽量短小，最好不要超过10个人日的工作量,至少要确保的是在一个迭代或 Sprint 中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）：

一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。所以一个好的用户故事，还需要定义 DoD（Definition of Done）。

其实不仅仅只有功能需求才能被转化为 User Story，并加进 Product Backlog 里，很多相关的需求，都可以转化为 User Story，比如：代码重构、架构优化、性能需求、安全需求、上线需求等等。

很多 PO 在写用户故事或者在维护 Product Backlog 的时候，经常会把 User Story 和Task 混淆起来，或者说 Scrum Master 和团队在沟通时，有时候也会分不太清 User Story 和 Task 到底有什么区别？

我就基于我的经验和理解来阐述一下 What's the Difference Between a Story and a Task：

1、概念：

User Story 的定义是用户想要得到什么样的功能。

Task 的定义是描述功能怎么被实现。

2、承接对象：

User Story 因为包含的是一个完整的功能，所以承接对象一般来说就是开发和测试，也有可能会分为接口开发、后端开发、前端开发、UI 设计师和数据库设计师等等。

Task 因为指的就是一个单一的任务项了，所以承接对象就是一个人。

3、颗粒度：

User Story 是通过若干个任务共同实现的，所以说它其实就是一个 Multiple Tasks 的集合。

4、生命周期：

User Story：源于用户，载体就是 Product Backlog，贯穿于整个 Release 的始终。

Task：源于 User Story，载体就是 Sprint Backlog，贯穿于每个 Sprint 里 User Story 的开始到结束。

从这几个维度上是不是能够较为清楚地理解 User Story 和 Task 的区别了？

作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵

【目录】