优秀用户故事的准则

一、用户故事的概念：

用户故事描述了对软件（或系统）用户或客户有价值的功能。用户故事包括三方面内容：书面描述（用于计划和备忘），交谈（细化故事细节），以及测试用例（验证故事实现）。

书面描述--包括故事的描述，为谁服务，唯一标识，提示信息，对迭代计划编制有所帮助。

交谈--和用户一起进行面对面的沟通，记录笔记，模型，文档交流。

测试用例--立验收测试的标准，这个标准是让用户来如何来确认这个故事已近完成的。

一个好的用户故事包含三个要素：角色、活动以及商业价值。角色即功能的使用者，活动描述需要完成怎样的功能，商业价值描述功能的必要性以及功能带来的价值。

用户故事的格式为：作为一个<角色>，我想要<活动>，以便于<商业价值>。

注意：用户故事不能够使用技术语言来描述，要使用用户可以接受的业务语言来描述。

二、用户故事与用例的区别：

用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述期操作步骤，以及每个异常路径。

用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度与工作量都相差不多。

用户故事是小粒度的，可测试的，可见的，并且是有价值的。

三、优秀用户故事的特性：

优秀的故事具备六个特点，即：独立性、可协商性、对用户或者客户有价值、可预测性、短小精悍以及测试性。

1、独立性：尽可能避免故事之间存在依赖关系，故事间的依赖关系会产生优先级和规划问题。

2、可协商性：故事是可协商的，不是必须实现的书面合同或者需求。

3、对用户或者客户有价值。确保每个故事对客户或者用户有价值的最好方式是让用户编写故事。

4、可预测性。开发者应该能够预测故事的规模，以及编码实现所需要的时间。

5、短小精悍。故事规模对实现有影响，何种故事规模最合适，取决于开发规模、开发组的能力，以及技术实现等方面。

6、测试性。所编写的故事必须是可测试的。

四、用户故事的划分

用户故事主要是从客户角度划分，可以按照以下原则划分：

1、按照不同操作—添加、删除、修改、浏览等。

2、按照数据—可以浏览产品和介绍、可以浏览产品价格

3、按照特性—易用性、性能、兼容性、并发性等等

4、按照角色—从不同的用户角度

等等

由于调度系统功能点较多，操作也较多，个人认为可按照不同操作来划分用户故事。

五、划分用户故事的原则：

随着用户故事粒度的增大，不定性（由于缺陷、人为因素、外部依赖等因素）会急剧提高。所以用户故事的划分要做到以下几点：

1、缩短完成用户故事的时间。

很多人认为用户故事的大小跟完成时间是成正比的。但是研究表明，随着用户故事规模的增长，完成它所需要的时间会成非线性增长。两倍大小的用户故事需要花五倍的时间来完成。

2、减少用户故事大小的差异性

在开发过程中，很多时候团队成员都在等待，开发人员等待需求，开发人员等待架构和代码审查，测试人员在等开发人员完成开发工作等等。在稀缺资源面前会有一个长长的任务队列。如果能够消除由于资源竞争产生的队列，团队开发的效率就会大大提高。根据排队原理，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定因素主要有：不确定的迭代长度，不确定的用户故事集合，用户故事大小差距很大，团队成员不固定发布时间，不固定新的需求到达时间。解决的方案就是让一切变得确定，稳定。需要把大的任务切成类似大小的小的用户故事。这样就大大减小了不确定性，提高了效率。

将大的用户故事分割成小块的好处：

1、减少等待：下游的成员不必要等待过长的时间，小用户故事在系统内的流传会很快，从宏观来说变成了一个并行模式而不是串行模式。

2、加快反馈：每个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测试的时候才发现的，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好，多次反馈以及不断演进才是一个真正能把功能做好的策略。

3、减少缺陷：沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。

4、更好的衡量进度：可以工作的软件能够更好、更真实的反应项目进度状况。人天生只能关注很小的部分--精力和智力所限。

5、较少的投入获得较早的回报：这样可以尽早的达到成本与收入的平衡点。

6、风险小：小的功能投入的资源较少。

7、更容易分优先级：大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。

8、让每个人接触不同的用户故事：用户故事变小，也会更简单，一次很容易让不同人同时去完成。

六、用户故事的验收测试的技术

进行用户故事的验收测试的技术，以及测试整个主题的方法：

1、列举要点(Bullet points)

在一个用户故事卡片或者wiki上，以列举要点的形式，把对系统行为的期望结果和实际结果记录下来。这种技术适用于较小的或者简单的用户故事。

2、测试场景/数据……

把你测试需要用到的任何场景、数据都记录下来。比如，用正确的/错误的/空的密码来测试密码功能。跟之前的方法一样，这种技术通常非常适用于小的或者简单的用户故事。

3、先测起来

先进行一些测试，再洋洋洒洒把你需要验证的系统功能记录下来。这是一种比较易学的技术。这种方法适用于简单的测试，也是其他方法不适用时的万能钥匙。

4、Given/When/Then

使用三段式：Given，When，Then。在Given部分，罗列出前提条件，测试环境，测试输入以及系统状态。在When部分，则列出一些触发点或者状态转换事件。在Then部分，记录系统行为，期望的输出，或者下一个系统状态。这种技术对于有着很多前提条件或者有特定触发点的测试非常适用。

5、概念形态上的，带有实例的规格说明书(Specification By Example-Conceptual Form)

编制一张表格，包含测试输入和期望输出。所谓概念形态，就是不以特定的值来描述数据。如果能比较容易地做出这张表格，那么使用这种方法就很可能非常有效。

6、互相搭配

选择多种不同的方法应对不同的测试角度。

典型用户故事的例子：

假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。
  因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”
上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。客户所说的话，就是在描述一个用户故事（user story）。
如果我们想要记下这段用户故事，我们可能会用这样的格式：
名称：卖饮料
事件：
1. 用户投入一些钱。
2. 售货机显示用户已经投了多少钱。
3. 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。
4. 用户按了某个亮了的按钮。
5. 售货机卖出一罐饮料给他。
6. 售货机找零钱给他。
注意到，一个用户故事里面的事件可以这样描述：
1. 用户做XX。
2. 系统做YY。
3. 用户做ZZ。
4. 系统做TT。
5. ...

用户故事只是描述系统的外在行为
一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面标为红色那些文字，就属于不应该出现在用户故事中的系统内部动作：
1. 用户投入一些钱。
2. 售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。
3. 售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料，对于钱足够买的那些饮料，对应的按钮的灯就会亮起来。
4. 用户按下一个亮起来的按钮。
5. 售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减1。
6. 售货机找零钱给用户。
不管是口头描述的，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别的，千万不要提及任何有关数据库，记录，字段之类的对客户一点意义都没有的东西。