在敏捷项目管理中,用户故事是怎样写的?

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

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

什么是用户故事?

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

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

用户故事描述公式如下:

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

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

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

故事描述

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

验收测试

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

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

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

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

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

常见问题点

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

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

独立的

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

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

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

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

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

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

可讨论的

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

问:为什么可以讨论?

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

对用户或客户有价值的

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

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

可估计的

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

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

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

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

小的

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

可测试的

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

我们做一些修改:

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

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

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

 

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

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

给作者打赏,鼓励TA抓紧创作!
2人打赏
评论
欢迎留言讨论~!
  1. 不太懂可测试和不可测试

    回复
  2. Thanks♪(・ω・)ノ

    回复
  3. 对啊,感觉收尾说收就收了,如果有改进的方案,通过用户故事来展开说明一下,会对用户故事的编写有更清晰的理解

    回复
  4. 写的比较有条理,对新人还是很有帮助的,相信很多人做产品都不知道有这样的方法论。美中不足的就是收尾太仓促了,其实还可以稍微深入一点。加油!期待更多好作品。

    回复
    1. 收尾涉及整个项目的用户故事迭代了,又是一大篇。。。

      回复