故事的好处

软件开发是渐进明细的过程，充满挑战。软件需求是被识别为最常见的痛苦根源。如何定义需求，冗长的文档已经不被阅读者接受，简单、精准、一目了然的格式一致的用户故事越来越被接受。当掌握刚刚足够的信息就继续前行，按需及时开展，通过交谈获取所需要的细节。从用户角度出发描述功能，让我们站在最终用户立场考虑问题，避免开发者自行其是。

方便沟通和传递，只有一句话或者简短描述就能知道用户诉求，比任何长篇大论漂亮的需求文档好太多。更多的细节在交谈中获取，强调频繁的沟通和反馈。

用户故事的组成

用户故事描述了对用户，系统或者软件购买方有价值的功能。一般由以下三个方面组成：

1，一份书面的故事描述，用来做计划和提示

2，有关故事的对话，用于具体话的故事细节

3，测试场景或者举例，用于表达故事细节且可用于确定故事何时完成。

一般故事写在卡片上，正面描述，反面是验收测试场景，另外可以在空白处加上优先级，以及谈话中讨论的细节提醒。

如果一个故事太大（史诗故事Epic)，那么需要再细分为更小的故事，直到每一个故事能覆盖到每一个细节，每一个细节之间都不能有重复，避免冲突和减少依赖。

使用故事的过程

过去是瀑布，强调文档编写完再设计，所有细节设计完成后进入开发，开发完成后进入测试。如果使用故事则玩不通，因为故事强调沟通，最需要的是客户和用户在项目中全程参与，需要在项目中随时可以找到可沟通的人，得到正确和真实的反馈。

让用户编写故事

软件客户和用户应该在编写用户故事时承担活跃的角色，客户参与写用户故事有两个好处，首先那个故事必须使用业务语言写，而不是使用技术语言，这样团队可以排列故事优先级；其次作为产品的构想者和使用者，用户和客户应该最清楚和适合描述产品的行为！

优秀的用户故事准则

目标故事：了解使用软件的目的，通过目标衍生故事。例如找工作是一个目标，那么可以拆分为搜索工作，编写简历，投递简历，申请工作等……

切蛋糕方法：面临一个大的故事，采用纵向切蛋糕的方法拆分更小的故事，每个故事都提供某种完整的end to end（闭环） 的功能。例如“求职者可以发布简历”这个故事拆分“求职者可以提交简历，简历包括名字，地址和教育背景这样的基本信息；求职者可以提交简历，简历包括雇主想看到的所有信息。

在编写故事时，更倾向编写一整块完整蛋糕那样功能完整的故事。

编写封闭的故事

一个封闭的故事是指随着一个有意义的目标的实现而结束的故事，让用户觉得使用后能完成某个任务。而不是开放性，比如管理简历就是个开放性的故事；而保存简历，删除简历，更改简历的信息，就是封闭式的故事。好处在于每个故事都是一个闭环，用户会有一定程度成就感。

卡片约束

任何必须遵守而不需要直接实现的故事，设定为约束。如“系统必须要支持最大50个并发用户的峰值”。约束卡片不需要估算，也不会被安排到迭代中，可以作为其他可能关联故事实现时候的提醒。

不要过早的涉及用户界面

项目早期应该对系统设计还没有一个深入设计，很多需求都只是一个构想，如果过早的设计用户界面，那么会将用户界面细节陷入故事。软件设计是个渐进明细的过程，请不要违背这个过程。例如，如果项目刚开始就设计一个“用户可以在搜索界面上从日期部件上选择日期”，那么其实对于开发人员来说是比较困难去开发的，因为在早期软件可能还没有设计搜索和日期相关的功能，尽量不要因为过早设计页面左右了真实需求。软件只有在越来越完整的时候，并且从全新的功能转向修改或扩展现有功能的时候。

在故事中包括用户角色

如果项目已经识别了角色，那么请在故事中使用已经识别的角色。这样可以让用户在开发人员脑子里保持着最重要的位置。例如不要写“用户可以发布简历”，应该描述为“求职者可以发布简历”。这样开发者会联想到实际的，真切的用户，开发出满足用户需求的软件。

只为一个用户编写

当故事只为单一用户编写时，故事的可读性通常是最强的。如“求职者可以删除简历”，应该描述成“求职者可以删除他自己的简历”。从单个用户角度思考问题，会让故事更清晰。

故事发布计划

Must have 必须有(基本功能)

Should have 应该有(很重要但是短期内有可替代解决方法的功能)如果项目时间没有约束，应该有的功能应该是强制性的

Could have 可以有(如果没时间，可以在发布中不考虑的功能)

Won’t have this time 这次不会有(客户期望有，但是承认需要在后续发布中实现的功能)

排列优先级

用户对故事进行优先级排序，一般会从广泛性和重要性开来判断。

如果用户的优先级和开发人员实现的顺序不一样时，应该客户说了算。在确定优先级时，应该先对故事进行估算，这样用户可能重新调整优先级，根据估算大小，评估发布顺序让价值最大化。

迭代计划

讲解故事，澄清问题，优先级排序，任务拆分，任务认领，评估任务是否能完成。

拆分任务

1 实现故事的开发人员一般不是一个人

2 故事拆分为开发人员的待办事项(to do list)时团队透明，团队集体智慧有助于不容易遗忘

3 拆分任务的同时也是一个即时设计短脉冲的过程，这个过程类似瀑布过程的前期设计阶段

4 团队成员自愿认领和执行任务

5 团队围绕共同目标执行迭代，在迭代后期如果有人任务无法完成，团队其他人应用于承担，避免有人任务完成，还有人的任务列表还有待处理的情况。。

用户故事的优势

强调口头沟通，人人都可以理解用户故事，用户故事大小适合做计划和迭代开发。

用户故事鼓励延迟细节，并根据沟通适应随机应变。鼓励参与性设计和传播阴性知识。此部分难以理解，目前我们仍然使用prd记录和描述用户需求，尽可能记录清楚用户诉求自己可能场景和用例。此处和书上描述避免使用过详细的记录相悖论。我们因为部门墙的存在，用户可能没办法和研发团队频繁交流，且反馈环拉的很长。我们产品经理就处于与用户沟通和设计产品的角色，所以大家还是希望产品能将沟通记录和结果记录清晰。

用户故事促使我们重视口头交流，提供迅速的反馈周期，促使对需求的理解。用户故事范围比用户用例(IEEE830 定义的软件需求包括用户用例和场景)场景