一，何为用户故事：
用户故事是敏捷开发里面的叫法；
传统需求文档就是类似瀑布开发等的叫法；
要用敏捷开发，就要写用户故事。
二，何为用户故事的写法：
2.1 经典写法：
用户故事的经典写法是：作为（谁），，，，我想要（做什么），，，为了（为什么），，，。
1，“谁”就是用户故事场景里面的具体用户，也可能是上下游系统；
2，“做什么”就是这个业务场景的要实现的功能
3，“为什么“业务价值，只开发有业务价值的用户故事，
比如，作为乘客，我想要系统推送最新的优惠活动给我，为了能够获取更大优惠活动；
2.2 按照以上用户故事方法拆传统需求文档？
按照以上典型的用户故事写法，拆分传统需求文档，进入敏捷开发就可行吗？
首先，要明白敏捷开发“小步开发，反复验证”一个类似增量的开发模型；
从用户故事来说，敏捷开发过程就是一个产品或者业务目标拆分为若干个可体验的，可交付的的用户故事的过程；
每一个用户故事应该在几个星期或者是一个月可以完成交付的东西，完成交付意味着走完了软件开发的一个流程“需求分析，设计，开发，测试”；
其次，既然敏捷是类似增量的开发，那么用户故事编写就应该考虑到从最初的最小的业务闭环开始，慢慢的增量到更多需求的原则；而且每个用户故事都是可以交付验收的。
最后，用户故事要给开发测试，可能后续的运维来看，不但要描述具体需求，还要写清楚开发中需要注意的东西和验收标准；
三，何为用户故事推荐写法：
结合最近参与的用户故事的编写经历，以下是总结出来的用户故事的写法：
前提条件：
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和用户故事是并行准备的，我们的用户故事是给开发，测试等人看的，所以其中，还会加上具体的数据的要求和多种字段的类型要求；
此外，我们是在JIRA进行用户故事的编写，用史诗来串联相关的用户故事到一个大的场景；
PS: 用户故事排优先级， 用莫斯科法则。
莫斯科法则即Must or Should， Could or Would not。
Must：这个迭代一定要做的，是必须的功能。
Should：应该做，是不太需要的功能， 看时间的充裕与否。
Could：不太需要的，和should 差不多，优先级别稍低Should。
Would Not：明确说明这个功能不需要做，切勿把功能放到Must，Should or Could里。
