什么是用户故事？

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

• 一份书面的故事描述，用来做计划和作为提示。
• 有关故事的对话，用于具体化故事细节
• 测试，用于表达和编档故事细节且可用于确定故事何时完成。
  用户故事的描述信息通常以手写的方式写在纸质卡片上。卡片代表客户需求而不是记录需求，这是对用户故事的最佳诠释：卡片包含故事的文字描述，然而需求细节要在“对话”中获得，并在“确认”部分得以记录。
  多个小故事远远胜于一个庞大的故事。史诗故事可以分成两个或更多的小故事。例如，“用户可以搜索工作”可以分成下面几个小故事。
• 用户可以通过地区、薪水、职位、公司名和发布日期之类的属性来搜索工作。
• 用户可以查看搜索结果中每个工作的信息。
• 用户可以查看发布工作的公司的详细信息。
  然而，我们并不需要不断地分解故事，直到有一个故事能够覆盖每一个细节。

由客户团队而不是开发人员来编写用户故事主要基于两个原因。
首先，每个故事必须用商业语言来写，而不是技术术语，这样一来，客户团队可以排列故事的优先级，放入迭代和发布。其次，作为主要的产品构想者，客户团队所处的位置最适合描述产品行为。

在故事编写会上，大家集思广益，充分想象用户故事。有了可以开始工作的故事集合后，开发人员便可以估计每个故事的大小。
客户团队和开发人员一起选择迭代长度，一周至四周的时间。在每轮迭代结束时，开发人员将负责发布完全可用的应用程序子集。
为了做发布计划，沃恩把故事排列成许多堆，每一堆代表一轮迭代。每一堆包含一定数量的故事，最高优先级的故事放在第一堆，当那一堆放满后，次优先级的故事放入第二堆（代表第二轮迭代）。直到已经有许多堆故事完成。
优先级排列标准：

• 大部分用户和客户对特定性的渴望程度。
• 小部分重要用户和客户对特定性的渴望程度。
• 故事之间的关系。

用户故事计划

第二章 编写故事

一个优秀的故事应该具备以下特点：

• 独立的
• 可讨论的
• 对用户或客户有价值的
• 可估计的
• 小的
• 可测试的

独立的

尽量避免故事间的相互依赖。有两个方法绕过这种依赖。

• 将相互依赖的故事合并成一个大的、独立的故事。
• 用一个不同的方式去分割故事。

可讨论的

故事是可以讨论的，它们不是签署好的合同或者软件必须实现的需求。
故事卡包含以下信息就变得有意义了

• 一两句短语，用来提醒开发人员和客户进行对话。
• 一些注释，用以表明在对话中亟待解决的问题。

对用户或客户有价值的

用户不关心配置信息在哪里存储，但是购买者可能会关心。

可测试的

故事必须是可测试的，通过测试可以证明开发人员正确地实现了故事。如果故事不能被测试，开发人员怎么知道他们什么时候才算是完成了代码？

通常，不可测的故事发生在一些非功能性的需求上，这些需求和软件有关，但不直接与功能有关：用户必须觉得软件很好用。

第三章 用户角色建模

角色建模的步骤

通过以下步骤来识别、选择有用的用户角色集合。

• 通过头脑风暴，列出初始的用户角色集合。
• 整理最初的角色集合
• 整合角色
• 提炼角色
  .```
  用户使用软件的频率
  用户在相关领域水平的知识水平
  用户使用计算机和软件的总体水平
  用户对当前正在开发的熟悉程度
  用户使用软件的总体目标，便捷性、用户体验等

##两个额外的技术
虚构人物、极端人物

#第七章 优秀用户故事准则
##从目标故事开始