今天芝士将以聚美优品的购物车流程作为用户故事例子。

什么是用户故事？

用户故事描述对用户，系统或软件购买者有价值的功能。由以下2方面构成：

• 一个故事描述
• 验收测试

用户故事描述公式如下：

作为XXX，我想XXX，以至于XXX。

标准写法是：作为聚美优品用户，我想将可能购买的商品放入购物车，以至于我可以随时付款。

由于原型已经构造出来，作为功能用户故事简写为：用户可以将需要购买的货物加入购物车。

故事描述

验收测试用来验证实现的用户故事是否符合客户团队的期望，有点类似于之前的需求描述，它的作用就好比检查蛋糕是否蒸熟了的牙签。故尽可能把所有满足此用户故事的情况考虑在内。

验收测试

作为一个功能用户故事要尽可能的小，大小是一天的开发工作量。

问：为什么是一天的开发工作量

答：为了更好的项目管理，每天开站立会议可以及时发现问题改正错误。工作量足够小，也就更容易解决问题。

注意：在一张纸上，正面写故事描述，背面写验收测试。

上面的用户故事对应聚美优品如下图蓝色方框圈出的功能：

常见问题点

用户故事编写注意以下六个特征INVEST：

• 独立的（Independent）
• 可讨论的（Negotiable）
• 对用户或者客户有价值的（Valuable  to  Purchasers  or Users）
• 可估计的 (Estimatable)
• 小的(Small)
• 可测试的(Testable)

独立的

我们要尽量避免故事间相互依赖。

发现有用户故事发生依赖可以采用如下方法解决：

• 将相互依赖的用户故事合并成一个大的独立的故事
• 用一个不同的方式去分隔故事

问：我作为产品，怎么知道用户故事间是否依赖。

答：和开发人员一起讨论每个用户故事，是否有依赖。说多了都是海水，你做两个项目就知道了。

经验鉴赏：芝士做第一个项目时，功能用户故事都是芝士写的（芝士大学本科是计算机），没有和开发人员讨论，导致功能故事很多地方发生冗余，芝士在第四个项目学聪明了，和开发人员一起来细分模块，防止功能用户故事冗余。

可讨论的

故事是可以讨论的，它不是签署的合约或软件必须实现的需求，细节处可以和开发人员以及客户团队讨论。

问：为什么可以讨论？

答：如果按照以前需求文档，大家感觉得到任务不管是对是错就开始开发，最后各种不满意，各种加班重构。

对用户或客户有价值的

“每个用户故事必须对用户有价值”，这句话听起来很吸引人，可那是不对的。

比如“所有数据库连接要通过一个连接池”，这只是对开发人员有价值，并不是对用户有价值，用户只关心实现后的结果，比如“我可以修改个人信息”。

可估计的

一般有一下三个方面导致故事不可估计

• 开发人员缺少知识领域
• 开发人员缺少技术知识
• 故事太大

芝士不想讲概念，直接说经验。

可以根据开发人员以往开发过的功能进行大概估计，或者把故事再拆分小一点。

小的

合适的故事大小由团队，它的容量及所使用的技术决定。满足每个人一天的工作量就好。

可测试的

“用户决不需要花很长时间等待窗口出现”，这就是不可测试的功能性故事。

我们做一些修改：

“在95%的情况下，新窗口会在2秒内打开”，这就可测试。甚至更好的是写一个自动化测试来验证它。

我现在放一下聚美的购物车的用户故事，聚美在购物车处做的不是很好，通过用户故事可以明显感觉到用户购买东西操作步骤太多，不能立即购买，必须进入购物车。

如果喜欢芝士的文章就分享点赞吧！

作者：芝士  微信号：ly2315544  微信订阅号：知世说  欢迎分享交流。

本文由 @芝士 原创发布于人人都是产品经理。未经许可，禁止转载。