结合自己的理解，整理出的User Story笔记。
定义：
软件开发中常用的一个基本工具，用户故事，又称User Story。
wikipedia上是这样定义的：
In software development and product management, a user story is an informal, natural language description of one or more features of a software system.
软件开发中，用来描述一个软件系统单个或多个特性的非正式自然语言。
我的理解是，定下角色，然后从角色的角度出发，理清会做什么事，最后实现了什么样的价值。
Why User Story：
开发中常常遇到如下情况：
- 不知道如何整理项目需求
- 不知道如何拆分需要成实际的任务
- 大概知道要去拆分，但是不知道要描述到多详细
- 如何才能让大家都能很快读懂，参与协作。
User Story是解决上述情况的一大利器。
格式：
User Story的格式如下：
As a role of user, I want some feature, so that some business value.
身为「某角色」， 会做「某事」， 以完成「某商业价值」
例如：
- 管理者可以新增职缺
- 用户可以申请职缺
- 用户可以浏览详细的工作内容
- ……
这里，角色正是系统复杂度的关键。
撰写的秘诀：
既然工具有用，那么要如何写好User Story？
注意粒度大小，粒度大小很重要
- 针对不同的受众，颗粒度是不一样的，例如：
对于投资人／生意人来说，颗粒度就要很大，而针对用户或者客户，则是相对小的size，而针对开发人员，则需要更为小的颗粒。
- 拆分User Story，就好比切蛋糕，直着切，不是横着切。
- 不要用技术去切分，而是具体而微，让用户可以体验到一个相对完整，有价值的功能。好比不能单作controller，单作model，或者view，而是结合成一个MVC
- 要具体切多小呢？有什么标准？
- 不需要写太多，比如写20条User Stories，就过多了
- 一条story不是描述中间一个步骤，而是完成一件事情
- 一个user story大约是半天～数天的实作长度
比如下图：
可彻底完成的小故事
是要完成一个小目标，让用户可以彻底完成一个任务，而不是发散，模糊，持续进行的故事。
例如：管理员可以管理商品，就不是一个好的user story，比较发散，模糊。
而拆分成：
- 管理员可以上架商品，字段包括商品名称，价格，说明等
- 管理员可以编辑上架时间，过期商品自动下架
- 管理员可以上传多张产品图片
这才是好的stories
描述功能需求，而不是解决方案
不要描述技术细节，包括UI规格，技术规格
只描述对用户有价值的功能
辨识用户角色
- 包含用户角色，并讲清楚用户可以做的事情
- 身为「某角色」， 会做「某事」， 以完成「某商业价值」
- 撰写User Story用主动语态
- 角色越多，项目整体复杂度会快速上升
收集和排序：
以购物网站示范,将想到的User Story都写在便利贴上，贴在白板上
Top-down方式：有明确目标导向
先列出3～5个主要活动，然后将主要活动拆分成至少3个以上的可执行story
Bottom-up方式：创意导向，适合头脑风暴
将所有user story贴出来，然后按照时间顺序分类，将类似功能的user story放在一组，如下：
将分组后的活动进行小结，整理成3～5个主要活动。
排序：
根据优先级，分出Must have ，Should have , Could have, Nice have，先做must，然后should，could，最后再考虑Nice