大家好，我是来自IT修真院的一枚PM~~今天和大家来分享一下PM基本功之用户故事。

大纲:

一、用户故事在整个开发中的位置

二、用户故事是什么？

三、如何编写一个优秀的用户故事？

四、故事优先级

---------------------------------------------------------------------

一、用户故事在整个开发中的位置

用户故事是敏捷开发中一个十分重要的环节，他帮助我们高效的收集客户真正的需求。

用户故事是敏捷计划于估算的重要基础

是需求的基本形态

软件开发起始于需求收集与分析，如果一开始需求弄错了，软件的成功也无从谈起。

用户故事贯穿整个开发流程。首先产品负责人根据收集来的需求编写用户故事，放入产品代办事情集中。baclog

在迭代（sprint计划会议）中，团队成员讨论其中的一些用户故事，细化细节，确定验收标准，使用planning poker估算故事点。然后，将故事分成一些小的任务，并估算工作时间。最后，讲故事放入（sprint backlog）迭代待办事项中，并按优先级排序。任务完成后，将任务挪到done栏。

 团队尽可能的完成优先级高的故事。

---------------------------------------------------------------------

二、用户故事是啥？

用户故事包含：

一份书面的故事描述

有关故事的对话，用于细化细节

测试，用于确定故事何时完成

下面我们一个一个来讲：

1.书面的故事描述

ron jeffries提出3c - card/conversation/ confirmation

卡片记录的是客户/用户 需求而不仅仅是记录需求-也就是说：卡片包含故事的文字描述、然而需求细节需要在与客户的“对话”中获得，并在“确认”部分得以记录。

用户故事的表达形式：

三要素大法：as a ….(role)I want…. so that ...

2.用户故事的细节：

也就是颗粒度

以智联招聘为例：

1.用户可以搜索工作

2.公司可以发布职位

虽然求职网站的智能说到底就是这两大点，但显然这并不是一个好的用户故事，为毛呢？对于开发来说太庞大太模糊了，实际工作中没有任何知道意义。

那肿么办？

epic史诗故事

当一个故事很大的时候就称之为史诗故事，他可以拆成更多的小故事。举个栗子，“用户可以搜索工作”可以分如下：

1.用户可以通过地区、薪水范围、职位、公司名、发布日期等来搜索工作

2.用户可以查看搜索结果中每个工作的信息

3.用户可以查看发布工作的公司的信息

巴特！

拆分并不是没完没了的，不需要覆盖每一个细节。再举个栗子

“用户可以查看搜索结果中每个工作的信息”就很OK，不需要再拆成-

用户可以查看工作描述

用户可以查看薪水范围

用户可以查看工作地点

为毛不需要这么的细节，有人会觉得这样很好啊出来的效果就是我设计的那样啊不会有差别啊，我个人理解是 1）互联网产品迭代快，你永远无法精准的预知产品上线时（几个月后）的市场行情，与其有时间细化倒不如加快开发进程。毕竟很多时候，用户也并不知道自己到底需要什么==！  2）一个产品包含很多个功能，所以也有很多个细节。高效的做法是，当我知道这个细节变得重要时，再去和客户讨论。

3.“什么时候完成？”

其实指的是开发人员了解用户的期望，从而以验收测试的形式被记录下来。

比如：

用空的工作描述来试试

用缺少薪资来试试

用6位数薪资来试试

些测试描述是为了便于开发人员预估故事于什么时候结束。通过测试验收是否达到了客户的期望，变能知道什么时候完成了客户要求的功能。

就好像老师告诉我们什么时候交作业一样。

---------------------------------------------------------------------

三、怎么写好一个优秀的用户故事？

INVEST原则

一、独立的

不独立会造成什么后果？排列优先级的时候或者预估时间的时候会导致一定的混乱。

继续智联招聘的栗子，假设现在编写客户公司如何对发布职位进行付费的故事：

1.公司可以通过visa信用卡对发布职位付费

2。公司可以通过masteracrd卡对发布职位付费

3.公司可以通过美国运通卡对发布职位付费

这时候开发估计完成第一种信用卡的开发需要3天（未指明哪种信用卡），对第二第三种信用卡各需要1天，问题来了，到底应该给那种信用卡预估3他的时间？

出现这种问题，可以将这些相互依赖的故事进行合并。

此时，这三个故事就合并成：

1.公司可以用信用卡对发布职位进行付费

如何判断合并的颗粒度是否正确？就看这个合并后的故事的预估时间是否超过5天。如果超过了，就找别的维度。

二、可讨论的

用户故事是可以讨论的。用户故事的细节是在用户与开发团队的讨论中产生的。

这里需要注意的是，故事卡并不是需求本身，它是功能的简短描述，他的作用是提醒客户和开发在以后要进行关于需求的对话，这也就是为什么故事卡不包含细节，细节将在客户团队和开发的讨论中产生。另外，还有两点就是：细节过多时也会喧宾夺主让人们过多的关注细节；且给予开发一种不需要和客户讨论的错觉。

三、对用户或客户有价值的

！！“保证每个故事必须对用户有价值”

比如避免写一些只对开发人员有用的用户故事

所以用户故事最好是让客户来编写故事，也就是说pm必需做好需求分析

四、可估计的

主要针对开发而言。

五、小的

故事的大小很关键，过大过小都会拖累进度。

当故事过大时。。。分割故事？

比如之前智联招聘的例子，针对epic story“用户可以发布她的简历”，我们发现：

这个故事的主要行为“发布简历”包含以下几个点：

-简历包含的内容：教育背景、工作经历、薪资等

-用户可以将简历表为非激活状态

-用户可以有多份简历

-用户可以修改简历

-用户可以删除简历

那么针对这个epic我们可以这样拆分：

-用户可以创建简历，包含“教育背景、工作经历等”

-用户可以修改简历

-用户可以删除简历

-用户可以有多份简历

-用户可以激活简历，也可以让简历失效

如下的拆分方式就会过于细节化也就是过小：

-求职者可以在简历上输入每段教育背景的日期

-求职者可以在简历上输入每段工作经历的日期

-求职者可以在简历上添加照片

最终还是取决于对产品的了解以及技术实现方式

六、可测试的

通过测试开发人员才能证明确实实现了故事。

那是不是会有不可测试的故事？有，基本会是一些非功能性的故事比如。。。用户觉得这个软件很好用^^

---------------------------------------------------------------------

四、故事优先级-仍待探讨中...

法一：莫斯科法则，就是Must or Should， Could or Would not。在排用户故事优先级的时候，把用户故事按以下4种类别排优先级。

Must：这个迭代一定要做的。比如前面提到的“必需”的功能。

Should：应该做，但若没时间就算了。比如前面提到的“不太需要的”功能。

Could：不太需要的，但有了更好。比如前面提到的“几乎早期版本中不要”的功能。

Would Not：明确说明这个功能不需要做，切勿把功能放到Must，Should or Could里。

法二：

基本型需求

期望型需求

兴奋型需求