如何讲好这个“用户故事”

当你需要说服客户买你产品时, 当你需要因某事向老板申请资源时, 你要怎样做, 才能更好的达到你的目的呢?

其实这两个问题的解决方案就, 在之前的提效 | 如何写好设计文档一文中已经介绍过的用户故事(User Story).

带着这两个问题, 今天就和大家再一起看下用户故事(User Story).

用户故事(User Story)

用户故事(User Story)是指做某事为某用户带来什么价值.

它强调给用户带来的价值, 同时又能评估出为这件事需要做出的任务;

1.1

用户故事的描述方式

常见的用户故事(User Story)描述方式有以下三种:

(1) 我是<角色>, 我希望<功能>, 这样<好处>.

(2) 作为<角色>, 我想要<商业价值>, 以便<原因>.

(3) 作为<角色>, 我想<目标>, 以便<某种原因>.

常见的英文描述方式有两种:

(1) As a <Role>, I want to <Activity>, so that <Business Value>.

(2) As <WHO> , I want to <WHAT>, so that <WHY>.

1.2

用户故事的INVEST原则

用户故事在具体应用时也有写注意事项, 我们称之为INVEST原则.

1.2.1

Independent -- 独立性

用户故事之间是相互独立, 更不能一个故事依赖于其他的用户故事. 如果存在依赖问题, 最好通过组合或者分割来减少相互依赖性.

1.2.2

Negotiable -- 可协商

用户故事是应由用户和开发小组共同协商制定的, 应代表了一个用户群体的需求, 如果需求比较小或者零散, 可以和相关人员沟通, 协商丰富用户故事.

1.2.3

Valuable -- 有价值

用户故事对于最终的用户是有价值的, 因此应该站在用户的角度去描述每个功能和特性而不阶段性的任务.

1.2.4

Estimable -- 可评估

一个用户故事是需要足够的领域知识才能评估其开发周期, 同时也能减少估算的不确定性.

1.2.5

Small -- 短小

故事应该适当短小. 短小的故事可以减少拆解估算的误差, 一般能够在一个迭代周期之内完成是比较合适的大小. 如果太大最好拆分成多个较小粒度的用户故事.

1.2.6

Testable -- 可测试

如果无法进行测试, 那就无法判断该用户故事是否真的完成. 所以, 用户故事必须定义验收测试标准, 并且通过验收后才能认为用户故事开发完毕.

现在回头文章开始的问题, 向老板申请资源时, 你就可以说, “作为产品, 我需要这个分析用户的上线时间功能, 以便我更好的分析用户行为”.