数极客首页

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

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

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

t什么是用户故事?

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

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

t用户故事描述公式如下:

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

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

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

t故事描述

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

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

t验收测试

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

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

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

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

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

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

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

t常见问题点

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

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

t独立的

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

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

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

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

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

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

t可讨论的

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

t问:为什么可以讨论?

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

t对用户或客户有价值的

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

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

t可估计的

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

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

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

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

t小的

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

t可测试的

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

t我们做一些修改:

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

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

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

t分享干货我们是认真的,更多干货尽在

给大家推荐我国新一代大数据用户行为分析与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合分析用户行为数据和业务数据,可以自动监测网站、APP、小程序等多种渠道推广效果分析,是增长黑客们必备的互联网数据分析软件。数极客支持实时多维分析、漏斗分析、留存分析、路径分析等十大数据分析方法以及APP数据分析网站统计网站分析小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据分析模型,是用户行为分析领域首款应用定量分析与定性分析方法的数据分析产品

发表评论

评论已关闭。

相关文章