什么是用户故事
摘要:
一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。本文描述了敏捷开发的技巧：如何以用户故事管理项目.
什么是用户故事(user story)
假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。
因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”
上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。也就是说，上面我们的客户所说的话，就是在描述一个用户故事（user story）。
(我解释一下为什么用故事这个词，没兴趣也可以忽略。在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事，这件事情不是一个例子，所以不叫事例，这也不是故事，也不能算一段历程，而是一个例行的事。)
如果我们想要记下这段用户故事，我们可能会用这样的格式：
名称：卖饮料
事件：
1. 用户投入一些钱。
2. 售货机显示用户已经投了多少钱。
3. 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。
4. 用户按了某个亮了的按钮。
5. 售货机卖出一罐饮料给他。
6. 售货机找零钱给他。
注意到，一个用户故事里面的事件可以这样描述：
1. 用户做XX。
2. 系统做YY。
3. 用户做ZZ。
4. 系统做TT。
5. ...
用户故事只是描述系统的外在行为
一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面有下划线的那些文字，就属于不应该出现在用户故事中的系统内部动作：
1. 用户投入一些钱。
2. 售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。
3. 售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料，对于钱足够买的那些饮料，对应的按钮的灯就会亮起来。
4. 用户按下一个亮起来的按钮。
5. 售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减1。
6. 售货机找零钱给用户。
不管是口头描述的，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别的，千万不要提及任何有关数据库，记录，字段之类的对客户一点意义都没有的东西。
评估发布时间
用户故事是用来干嘛的？假定客户希望在50天内递交这个系统。我们做得了吗？为了解答这个问题，我们就要在项目开始的阶段，试着找出所有的用户故事，然后评估一下，每一项历程需要多长的开发时间。可是，怎么评估呢？
比如，我们现在收集了下面这些用户故事：
卖饮料：如上面所说的。
取消购买：在投入了一些钱后，用户可以取消购买。
输入管理密码：授权的人可以输入管理密码，然后增加存货，设定价格，拿走里面的钱等等。
补充饮料：授权的人可以在输入管理密码后增加存货。
取出钱箱里的钱：授权的人在输入管理密码后，可以取出钱箱里的钱箱里面的钱。
安全警报：有些事情经常发生的话，系统会自动打开安全警报。
打印月销售报表：授权的人可以打印出月销售报表。
然后找出里面最简单的用户故事（这里的“简单”，意思是说实现周期最短）。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如，我们觉得“输入管理密码”是最简单的用户故事。然后我们判断说，这个用户故事算1个“故事点（story point）”。
用户故事 故事点
卖饮料
取消购买
输入管理密码 1
补充饮料
取出钱箱里的钱
安全警报
打印月销售报表
不过一般我们不会列出清单，而是做出一堆卡片贴在墙上，每张卡片记录一个用户故事，然后将故事点写在卡片上面：
这样的一张卡片就叫“故事卡（story card）”。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
Ron Jeffries的3个C
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
Ron Jeffries的3个C
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
用户故事的六个特性- INVEST
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。