八招教你写好用户故事

什么是用户故事？

用户故事（User Story）是一段简单的功能描述，以用户或者使用者的角度，写下有价值的功能（Functionality／Feature）。与其说它是规格文件（Documentation），不如说它代表客户的一个需求而已。

用户故事的通用格式如下：

身为一个 {特定角色}，我希望能有 {特定功能} 以便能让我{得到某种价值}。

As a (role of user), I want (some feature) so that (some business value).

举个例子：

一个有最基本功能的购物APP，它的用户可能有以下几种：

买方

卖方

网站管理员

一个站在买家立场的用户故事：

作为一个买家，我希望能浏览所有同类商品的图片和价格，这样我能全面地比价并找到最适合我的商品。

一个好的用户故事应该遵循INVEST原则。

以下来自于Scrum中文网：

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

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

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

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

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

可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

如何写好用户故事？

以下8个小技巧或许能助你一臂之力。

1. 用户至上

用户故事是用来描述用户如何使用产品，一切内容要围绕用户的角度出发。比如，用户故事应该是围绕着“用户需要一个搜索功能来寻找他想要的产品”来描述，而不是“搜索需要联合几个数据库一起提供数据”。

2.利用用户角色（Persona）来发现故事

用户角色是根据目标群体设定的虚构人物，包括名字、行为习惯、目标等。根据用户角色的行为目标，寻找正确的用户故事。比如买家Amy是一个社交狂魔，那么就需要考虑到购物APP中，商品向各种社交软件的分享功能。

3.注意用户故事之间的协作

用户故事不是一个规格说明书，它是一个沟通与协作的工具。用户故事不能被单独地传递给开发团队用于交付，它存在于一系列的完整的设计之中。比如，购物APP中，用户故事1是买家能把商品添加到购物车，用户故事2是买家能添加／修改地址，用户故事3是买家能绑定支付方式，用户故事4是买家能在线支付——这才算完成了一个买家购买的功能。

4.简洁即美

用户故事要简明扼要，可读性高，避免使用模棱两可的描述。用户故事的模版就是一个很好的实践：As , I want ， so that .——我是谁，我想要什么功能，为什么。

5.不断完善

当我们把需求从Epic细化到Story时，有些功能范围放在哪个用户故事里，其实是可以商榷的。本着上述的INVEST原则，用户故事需要不停地调整、完善，直到就绪（用户故事清晰、可行、可测试）。

6.增加验收标准（AC，Acceptance Criteria）

AC是验收用户故事的标准，有了AC，用户故事的何时算完成，就有了更清晰的界定。一个比较普遍的AC的模版如下：Given在某种场景下 When发生了事件 Then导致了什么结果(简称Given, When, Then)。比如针对这个用户故事“作为一个买家，我希望能搜索到所有同类商品的图片和价格，这样我能全面地比价并找到最适合我的商品。”，那么相应的验收标准就是——设定用户想买一只钱包的情景下（Given），当他搜索钱包的的时候（When），他能够看到所有钱包的图片和价格（Then）。

7.可视化用户故事

可视化可以让每个人清楚用户故事的内容，便于团队更方便地将故事做分类、标记等管理，同时故事完成进度的横向流动，也便于让团队思考有哪些已经完成，是否有功能遗漏等。所以，无论是电子墙还是物理墙，可视化所有的用户故事，能让你事半功倍。

8.不仅仅依赖用户故事

用户故事只是需求与开发的沟通方式之一，有用，却不万能。它能能体现产品某些功能、特性，在产品设计还需要user journey map，在数据流上还需要data flow图，在用户体验上还需要原型设计等

总之，如果你想快速创建一个一次性的原型或模型来验证一个想法，那么撰写故事没有必要。然而，当你开发一个重要应用，编写用户故事是值得的，它不是记录需求的无用开销，而是能帮你快速启动并尽可能快地开发软件的工具。