用户故事

用户故事：

用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what

 

用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

一个完整的用户故事包含三个要素：

1. 角色（who）：谁要使用这个
2. 活动（what）：要完成什么活动
3. 价值（value）：为什么要这么做，这么做能带来什么价值

 

 

三、3C原则

用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。

（1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。

 

卡片的正面书写故事的描述，格式为：作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。

（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。确保各方对故事的理解正确。

（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。

 

分割用户故事

 

三，何为用户故事推荐写法：

结合最近参与的用户故事的编写经历，以下是总结出来的用户故事的写法：

前提条件：

APP 推送活动消息需求的用户故事编写；

用户故事内容：

用户故事标题：

  作为乘客，我想要系统推送最新的优惠活动给我，为了能够获取更大优惠活动；

用户故事内容：

1，需求表述清楚：

    作为乘客，我想要系统推送最新的优惠活动给我，为了能够获取更大优惠活动；  

   对于这一条需求，拆分需求如下：

 1.1，系统推送消息方式，采用极光推送，在APP打开的时候，系统可以采用极光推送消息至页头且3 秒消失并在app“消息”里面查看，在我APP关闭的时候，推送到手机的通知栏；

1.2，推送推送方式，采用短信推送，在用户>=15天未活动时，每隔15天或者节假日系统采用短息推送活动消息，来唤醒非活跃用户；短信包含短链接；

15天参数CMS运营可配置

1.3, 极光推送活动，跳转目的地是在APP的“消息”；

1.4，点击短信推送短链接导向打开APP，没有app安装的话，提醒安装APP；

1.5，极光推送和短信推送不叠加推送

2， 验收标准：

验收标准，写清楚各种验收场景；

  2.1，APP打开时候，可以在页面看到推送的活动，点击可以查看活动内容，不点击3秒消失，并且可以在"消息”查看。

 2.2，APP不打开，可以在手机通知栏看到推送消息，不点击一直存在；点击后跳转APP到“消息”

 2.3，非活跃用户，短信推送活动消息，可以收到手机短信，同时短链接可以点击，并且点击后的动作满足需求

3，前置条件

用户故事的前置条件，就是要完成这个用户故事，可能需要CMS后台和服务端如何配合完成这个故事验收

3.1 ，三方极光推送对接，短信通道开发

3.2，CMS服务端完成消息活动配置设计

4, 相关UI效果图和交互设计图

此处放置这个用户故事相关的UI效果图和交互设计图的链接；

---

四，拆分用户故事到任务（用户故事开发时）

用户故事是给用户可见的功能表述，在开发中，一个用户故事的完成，经常需要涉及到一个团队的工作。

任务就是这个时候出现的，在用户故事开发时，把一个用户故事拆分为多个任务，每个任务都可由一人完成。

用户故事存在于产品待办事项，任务存在于sprint待办事项表中；

用户故事包含了多种类型的工作，而任务则是受制于单一的工作。

---

最后，在实际项目中，传统的需求文档PRD和用户故事是并行准备的，我们的用户故事是给开发，测试等人看的，所以其中，还会加上具体的数据的要求和多种字段的类型要求；