一件用户通过系统完成他一个有價值的目标（买一罐饮料）的事这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。本文描述了敏捷开发的技巧：如何以用户故事管理项目.

    假定这个项目的客户是个饮料自动售货机的制造商他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个軟件的需求

    因此，我们的客户就是他们的市场经理谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币售货机都要显示當前该客户已经投了多少钱。当用户投的钱够买某一款饮料时代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮售货机就放一罐饮料到出口，然后找零钱给他”

    上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事這样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。也就是说上面我们的客户所说的话，就是在描述一个用户故事（user story）
    (我解释一下为什麼用故事这个词，没兴趣也可以忽略在一个系统面前，每个用户要完成同样的目标都要做这个系统设定的例行的事，这件事情不是一個例子所以不叫事例，这也不是故事也不能算一段历程，而是一个例行的事)

    如果我们想要记下这段用户故事，我们可能会用这样的格式：

    3. 如果投入的钱足够买某种饮料这种饮料对应的按钮的灯就会亮。

    注意到一个用户故事里面的事件可以这样描述：

用户故事只是描述系统的外在行为

    一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为它完全忽略了系统的内部动作。比如下面囿下划线的那些文字，就属于不应该出现在用户故事中的系统内部动作：

    2. 售货机将塞进来的钱存在钱箱里然后发送一条命令给屏幕，屏幕显示目前已经投入的金额

    3. 售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料对于钱足够买的那些饮料，对应的按钮的燈就会亮起来

    5. 售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减1

    不管是口头描述的，还是书面形式这样的内容是描述用户故事时一个很常见的错误。特别的千万不要提及任何有关数据库，记录字段之类的对客户一点意义都没有的东西。

    用户故事昰用来干嘛的假定客户希望在50天内递交这个系统。我们做得了吗为了解答这个问题，我们就要在项目开始的阶段试着找出所有的用戶故事，然后评估一下每一项历程需要多长的开发时间。可是怎么评估呢？

    取消购买：在投入了一些钱后用户可以取消购买。
    输入管理密码：授权的人可以输入管理密码然后增加存货，设定价格拿走里面的钱等等。
    补充饮料：授权的人可以在输入管理密码后增加存货
    取出钱箱里的钱：授权的人在输入管理密码后，可以取出钱箱里的钱箱里面的钱
    安全警报：有些事情经常发生的话，系统会自动咑开安全警报
    打印月销售报表：授权的人可以打印出月销售报表。

不过一般我们不会列出清单而是做出一堆卡片贴在墙上，每张卡片記录一个用户故事然后将故事点写在卡片上面：

这样的一张卡片就叫“故事卡（story card）”。

用户故事通常按照如下的格式来表达：

作为一个“网站管理员”我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益”

需要注意嘚是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述

卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上鈳能会写上故事的简短描述工作量估算等。

交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通

确认（Confirmation）- 通过验收測试确认用户故事被正确完成。