敏捷----用户故事

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

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

    上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(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）”。

状态墙（任务看板）： 

一个迭代的故事卡就组成了该迭代的任务看板：

关于用户故事，Ron Jeffries用3个C来描述它：

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

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

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