你的用户故事，是“用户”故事么？

在敏捷开发过程中，我们经常会听到，用户故事（user story），我们也会用用户故事的方式来拆解细化需求，我们是否有想过，为什么用用户故事，什么样的用户故事才算是用户的故事？

为什么要有用户故事

你是不是遇到或听说过这样的场景，用户想要A，产品经理理解为B，开发同学理解为C，各自讨论达成一致之后，最终我们得到了一个完美无缺的D，什么缺点都没有，就是不是用户想要的东西。因此，我们需要一个叫用户故事的东西，作为基础，我们可以一起讨论，讲需求从每个人的头脑中可视化出来，从而更好的达成一致。

什么是好的用户故事

好的用户故事有他的标准在，3C原则，INVEST原则。

01 3C原则

• 卡（Card）：用户故事卡，在一张卡片上能够描述出主要需求，谁要做什么，产生什么价值

• 确认（Confirmation）：有验收，有测试，有完整的验收表征能确认这个故事被正确的交付，价值得以实现

• 交谈（Conversation）：用户故事作为交谈的基础，必须所有细节面面俱到，大家一起聊并达成一致，才是目的

图片

02 INVEST原则

• 独立（Independent）：每个用户故事都是可以独立交付的一个功能点，理想状态下不依赖于任何别的功能，不过也有例外，在一些非常长的流程性功能下，一定是先做第一步操作，才有第二步，因此独立也是相对的。这里的独立，是独立开发，独立验收，一些情况下，独立交付。

• 可讨论（Negotiable）：用户故事不是BRD，写啥是啥，面面俱到，结合3C原则，用户故事是为了达成一致，不是为了定义标准，可以根据具体的技术实现一起讨论，最终达成一致的交付结果。

• 有价值（Valuable）：不用多说，任何一个功能点如果找不到对应价值，我们就应该思考他存在的意义了，因此价值，是做一切的先决条件。

• 可估算（Estimable）：作为开发的依据，以及排期管理依据，他一定是可以被估算的，能估算的前提是我们有范围（上面提到），可沟通，达成一致，估算才有意义

• 足够小（Small）：小到可以在迭代内流转，不会一直停留在迭代的某一个泳道，小是相对的，需要平衡价值和独立。

• 可测试（Testable）：场景需要相对完整，流程也需要有完整节点，这样才能够满足测试。只有能够测试，才能确认功能的交付。

他们的顺序并不是INVEST，从价值的角度依次为VTSINE。

怎样写一个合格的用户故事

所谓好的用户故事总是相似的，不那么好的用户故事各有各的特色。在我们日常最多的用户故事中，看到最多的其实是INVEST中的T（testable），在As a, I want to, so that后面，跟着的是验收标准（Acceptance Cretirial）, 有了验收标准，才是可执行的用户故事。因此，在说什么是好的之前，我们先说说什么是不好的，一起乐呵乐呵，切忌对号入座。

需求：物品加入购物车
案例1：开发文档拆写类
AC1: 物品展示页下发展示 加入购物车按钮，点击后物品被加入购物车，数量加1
AC2: 点击购物车按钮，展示购物车页面，展示加入物品
AC3:加入失败，展示通知：加入失败请重试
AC4: 场景：浏览物品，搜索结果，首页
案例2：论文类
AC1: 用户可以看到加入购物车的按钮
Given：用户在浏览物品详情页面
When：用户看到最下方
Then：用户可以看到一个黄色的按钮上面写着加入购物车且在页面的右下角
AC2:如果用户点击了加入购物车按钮，则商品可以被加入购物车
Given:用户在物品详情展示的页面停留
When：用户想要加入购物车并点击了加入购物车按钮
Then：用户看到物品被加入到购物车病情购物车数量加1
AC3:加入失败，展示通知：加入失败请重试
Given:网络不稳定或者其他不稳定因素出
When：用户想要加入购物车并点击了加入购物车按钮
Then：用户会看到一个通知，通知告诉他加入失败请重试，他可以点击知道了关闭页面，也可以点击关闭关闭通知
案例3：混合类
案例1 和 案例2 任意组合出来

上面三种用户故事，是我见到最多的用户故事，他们也能准确的表达出要实现的内容（当然，实现内容都说不清楚的，就不在这里列了，大概率例子列不下），但是他们是用户的故事么？从案例的名字其实就能看出来，案例1 其实就是拆分写了下需求文档，它并不是一个用户故事，案例2是用户故事，是一个啰嗦的用户，抓不住重点的用户。

那，到底如何判断？那到底什么才是一个好的用户故事？先举个例子，当然，当然也只是个例子，并不是毫无破绽的例子。

需求：物品加入购物车
As 消费者
I want to将物品加入购物车
So that 可以让我在购物车看到我想购买的东西，支持后续的合并付款
AC1:消费者可以看到加入购物车按钮
Given: 我在商品列表/商品详情页/商品搜索结果页
When：我查看商品
Then：我会看到加入购物车按钮 （见设计图）
AC2: 消费者可以将物品加入购物车
Given：我查看商品并看到加入购物车按钮
When：我点击按钮
Then: 我可以看到
1. 商品被加入购物车
2. 购物车商品数量加1
3. 购物车页面有这个商品
AC3: 失败处理
Given:网络原因或其他原因导致加入失败
When：消费者点击加入购物车按钮
Then：消费者可以
1. 看到消息：“加入失败，请重试”
2. 点击关闭/知道了按钮 关闭消息

看完这个例子，我们再来说说，什么样的用户故事，能算是一个相对合格的用户故事呢？为了满足管理，范围，估算，沟通的诉求，合格的用户故事，需要具备什么样的特征呢？

01 用户视角

用户故事，说白了，就是用户自己在讲故事，既然是用户讲故事，他关心的一定是，我在什么条件下，做了什么操作，得到什么结果，给我带来什么好处。因此，用户故事一定是站在用户的角度来思考功能的。所以，用户，是这个故事里的第一主语

02 简单

简单，用户故事描述的用户的故事，帮助开发，用户，产品达成一致。更多的是一个沟通依据，大家在这个用户故事的基础上进行讨论。大概没有人喜欢，在讨论前，看讨论话题看10分钟，理解话题10分钟。因此，能单词说明的不用句子，能短句的不用长句。再简单点，每句话别超过文档页面的1/2长度。

03 重点突出

用户故事，是功能描述，也不全是，不需要在用户故事里面描述颜色，字体，字号，大小，排布等，要知道，这个世界上有一个东西叫做设计图，有一类工具类似zeplin，清晰的可视化一切。因此，用户故事的重点在功能上，而不是页面设计。

最后，用户故事，不是说了什么样，看明白了就知道怎么落地了，需要反复的练习和打磨，没事儿的时候回头看看自己的用户故事，当你产生了不想看或看不懂的情绪和场景的时候，就说明，那个故事，不是一个好故事。

作者：兔小吱 ；公众号：冬眠小记