产品经理学习-用户故事上

目录：

使用用户故事的原因

用户故事的使用者

创建用户故事

使用用户故事的原因

用户故事是描述需求的最好方法。为什么会有这个结论？

这不得不说起目前主流的开发方法即传统瀑布流开发方法和敏捷开发。在瀑布流开发方法论中，可以采用需求说明书的方式描述需求

敏捷开发是一种方法，是在“以人为核心驱动”的复杂系统背景下，一个具有适应性的“经验性过程控制方法”

敏捷开发在日常的软件开发中使用越来越多，因为使用需求规格说明书带来了很多尴尬

这一篇重点介绍用户故事

用户故事与需求规格说明书PRD相比有哪些不同点

用户故事的使用者

产品开发的流程是迭代1开始==》迭代1进行中==》迭代1完成==》迭代2开始==》迭代2进行中

项目负责人PO，整理需求，编写，修改‘大用户故事’项目负责人PO对“迭代后的产品”负责，随时和项目干系人、客户、团队沟通，将需求映射成大用户故事，项目未开始前，PO可以随时调整大用户故事的内容，在每一个迭代开始后，PO都会和团队一起，验收该迭代的交付项目。

业务分析师BA负责拆分迭代的用户故事，并编写验收条件，验收完成的用户故事；拆分下一个迭代的用户故事并编写验收条件

业务分析师BA和开发团队负责将迭代中的用户故事细分，开发并交付，BA将在遭遇开发团队一个迭代前，将开发团队需要的用户故事细化完成，并编写验收条件，在迭代的开始BA会召集开发团队，对此次开发的所有用户故事给予讲解，在每一个迭代结束后，BA和开发团队一起向产品负责人演示此次迭代的可交付物。

创建用户故事

什么是用户故事？

简单来说就是：

用户故事有3个特点：①以卡片的形式描述一个事情，②简单描述完整的事情，引发讨论

③需要有确认方式（验收标准）

一个卡片写一个用户故事，内容简洁，保障了阅读的便利、方便人员之间问题的探讨。

在做项目过程中，比如APP，一个页面就是一个大用户故事，页面中的一个按钮是一个小用户故事

什么是验收标准

验收标准简称AC,帮我们补充了故事很多边界以外的信息，工作在故事卡上的所有角色需要产品经理、开发人员有共同的认知，对这个故事完成的目标达成一致，大家对完成的目标有共同的认识，交互的结果有一个明确的验收标准。

   只要我们对AC的认知是一直的，就避免了开发和产品经理之间扯不清的事情；

比如“我想用手机号登录系统”这个例子来编写验收标准，开发可能有很多疑问，外国的手机号可以使用吗？还需要用户输入摩玛吗？手机号码错误提示什么信息等

   验收标准可以作为QA的测试用例，但是是用”非技术“的语言写成的，“我想用手机号登录系统”这个例子来编写验收标准可能有：

1. 给定中国大陆运营商的电话号码
2. 当用户输入号码少于或多余11位，则出现“号码错误，请重新输入”的提示
3. 给定一个11位中国大陆手机号码，当用户点击‘获取验证码’的时候，后端系统给该手机号发送一个6位的手机号
4. 给定一个正确的手机号，当手机号码是错误的，或短信发送失败，则系统忽略此手机号的后续注册步骤
5. 给点一个正确的手机号，当用户将验证码输入，并且按‘注册’按钮，验证码匹配成功后，提示用户注册成功，并登录软件。

AC验收标准的模版：

前提条件：当存在这种前提条件下，我们才会有可能发生以下的验收标准

触发条件：用户操作什么触发，系统定时触发、特定事件触发、特定时间触发

期望结果：定义期望的结果