提示：本文共有 1419 个字，阅读大概需要 3 分钟。
今天芝士将以聚美优品的购物车流程作为用户故事例子。
什么是用户故事？用户故事描述对用户，系统或软件购买者有价值的功能。由以下2方面构成：
一个故事描述 验收测试用户故事描述公式如下：
作为XXX，我想XXX，以至于XXX。
标准写法是：作为聚美优品用户，我想将可能购买的商品放入购物车，以至于我可以随时付款。
由于原型已经构造出来，作为功能用户故事简写为：用户可以将需要购买的货物加入购物车。
故事描述
验收测试用来验证实现的用户故事是否符合客户团队的期望，有点类似于之前的需求描述，它的作用就好比检查蛋糕是否蒸熟了的牙签。故尽可能把所有满足此用户故事的情况考虑在内。
验收测试
作为一个功能用户故事要尽可能的小，大小是一天的开发工作量。
问：为什么是一天的开发工作量
答：为了更好的项目管理，每天开站立会议可以及时发现问题改正错误。工作量足够小，也就更容易解决问题。
注意：在一张纸上，正面写故事描述，背面写验收测试。
上面的用户故事对应聚美优品如下图蓝色方框圈出的功能：
常见问题点
用户故事编写注意以下六个特征INVEST：
独立的（Independent） 可讨论的（Negotiable） 对用户或者客户有价值的（Valuable to Purchasers or Users） 可估计的 Estimatable 小的Small 可测试的Testable 独立的我们要尽量避免故事间相互依赖。
发现有用户故事发生依赖可以采用如下方法解决：
将相互依赖的用户故事合并成一个大的独立的故事 用一个不同的方式去分隔故事问：我作为产品，怎么知道用户故事间是否依赖。
答：和开发人员一起讨论每个用户故事，是否有依赖。说多了都是海水，你做两个项目就知道了。
经验鉴赏：芝士做第一个项目时，功能用户故事都是芝士写的（芝士大学本科是计算机），没有和开发人员讨论，导致功能故事很多地方发生冗余，芝士在第四个项目学聪明了，和开发人员一起来细分模块，防止功能用户故事冗余。
可讨论的故事是可以讨论的，它不是签署的合约或软件必须实现的需求，细节处可以和开发人员以及客户团队讨论。
问：为什么可以讨论？
答：如果按照以前需求文档，大家感觉得到任务不管是对是错就开始开发，最后各种不满意，各种加班重构。
对用户或客户有价值的每个用户故事必须对用户有价值 ，这句话听起来很吸引人，可那是不对的。
比如 所有数据库连接要通过一个连接池 ，这只是对开发人员有价值，并不是对用户有价值，用户只关心实现后的结果，比如 我可以修改个人信息 。
可估计的一般有一下三个方面导致故事不可估计
开发人员缺少知识领域 开发人员缺少技术知识 故事太大芝士不想讲概念，直接说经验。
可以根据开发人员以往开发过的功能进行大概估计，或者把故事再拆分小一点。
小的合适的故事大小由团队，它的容量及所使用的技术决定。满足每个人一天的工作量就好。
可测试的用户决不需要花很长时间等待窗口出现 ，这就是不可测试的功能性故事。
我们做一些修改：
在95%的情况下，新窗口会在2秒内打开 ，这就可测试。甚至更好的是写一个自动化测试来验证它。
我现在放一下聚美的购物车的用户故事，聚美在购物车处做的不是很好，通过用户故事可以明显感觉到用户购买东西操作步骤太多，不能立即购买，必须进入购物车。
分享干货我们是认真的，更多干货尽在爱盈利！
关键词:看到此处说明本文对你还是有帮助的，关于“在敏捷项目管理中 用户故事是怎样写的？ – 爱盈利”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
