作为<用户角色>，我想要/希望<产品特性>，所以可以<价值或收益>。
什么是用户故事？对于终端用户而言，用户故事是用几句简单的话来描述用户的原始需求以及他最终想要达成的结果。用户故事描述的不是用户想要在产品上看到的功能，而是即便在产品尚未成形的时候，用户有哪些需求需要被满足。
作为一个消费者，我希望可以在网上买到化妆品，这样我没空出门的时候也可以即时补给化妆品了。
用户故事是讨论的起点，诸如上述的这个用户故事，可以知道我们现在面临的是一个终端用户，他想要上网买化妆品，而他这个需求的出发点则是因为他没有空亲自去现场买化妆品。所以对于这个用户而言，他真正要解决的问题是他没有空亲自去购物，而在网上订购产品只是其中一个能够解决问题的方案而已。一个好的开发团队能按照用户故事去讨论如何实现解决方案，而一个出色的开发团队甚至能开发出用户故事中不曾提及的解决方案 (一个神奇的产品可以自动侦测什么东西什么时候需要自动补货？)
一般而言，用户故事是由Product Owner根据与用户或是需求方面对面接触与了解之后撰写的。对于Product Owner而言，用户故事还有更深一层次的含意。用户故事代表了可以在一次迭代内实现的，一定量的商业价值。一个好的用户故事完整的传达了用户的真实需求，而Product Owner将会带著这个用户故事，在用户故事或是用户故事中与团队讨论这个故事的由来，以及什么样的实现方向最能向用户交付价值。一个好的用户故事需要符合INVEST原则，他们分别是：
- Independent: 具备独立性，表示这个故事可以单独交付，不依赖任何其他用户故事，这样我们才能在任何时间，自由排序这个任务的优先级
- Negotiable: 可以被商讨的，所以团队可以按照用户的原始需求来讨论如何实现，而且可以选择在有限的时间内要实现多少
- Valuable: 有价值的，对于终端用户而言这个故事是能对他们产生价值的
- Estimatable: 可以被估算的，团队可以根据实现方案来评估为了实现这个价值团队必须付出多少努力
- Small: 小的，一个过大的用户故事很难被预估或是计划，如果一个故事太大了，就把他拆分开成若干个小故事
- Testable: 可以被测试的，好的用户故事会有验收条件，或是完成条件，所以测试案例可以根据这些条件被设计，并且被执行
为什么要使用用户故事？
- 确保我们是为了交付价值而工作，而不是为了工作而工作
- 避免在早期就定义出太多的细节，反而限制了开发团队只能在一种解决方案下思考实现方式
- 确保开发团队真的知道他们为什么要去做一件事情，而不仅仅是被要求而已
- 避免解决方案是由一个人来设计的，一个好的解决方案应该是集思广益的方式被团队探索与讨论
- 将技术实现交给架构师，开发者，测试人员去烦恼，最初期的解决方案才能围绕在价值实现层上
用户故事应该要多大？
用户故事应该能在一次迭代内被开发，以及被测试，所以理想状态下应该控制在3~5天。很多用户故事会组成一个Epic，Epic就是一个用户故事的集合，所以如果一个Epic里面包含了10个用户故事，我们可以推估完成这个Epic至少需要一个月。在一开始写用户故事的时候，我们会把东西写的很大，其实我们在写的就是Epic，只要在交接到开发团队之前慢慢的把Epic逐步的分解成故事就行了。
用户故事应该要多细？
让我们来看看几个案例：
太粗：
- 一个团队成员可以看到迭代状态
太细：
- 一个团队成员可以看到用表格方式排列的用户故事，包含他们的优先级，名称，大小，关连性，拥有者以及状态
- 一个团队成员可以点击一个红色的按钮来展开一个表格，该表格包含所有任务，优先级，名称，大小，关联系，拥有者以及状态
刚刚好：
- 一个团队成员可以看到一次迭代中所有的用户故事，以及他们的主要状态
- 一个团队成员可以在状态页面当中看到项目的燃尽图，并且可以点击项目燃尽图来看到更多细节
- 一个团队成员可以隐藏或是展开故事底下的子任务
- 一个团队成员可以在迭代状态页面上直接编辑一个任务
那什么时候应该开始加细节？
用户故事中的合格条件(Acceptance Criteria)定义了一个故事如何才能被认定为"完成"。 随著需求慢慢的被疏理，Product Owner会不断的增加合格条件，所以细节是需要被加入到验收条件中的东西，而不是加到用户故事中的东西(欢迎参考本文最下方的图解)。合格条件应该越清楚越好，一是帮助团队具体的了解为了交付一个价值有哪些功能是必须实现的，二是帮助团队针对合格条件去设计测试任务。
用户故事的职责：
创建职责：终端用户，用户代理，Product Owner，或是任何利益关系人都可以贡献用户故事拥有以及维护职责：Product Owner拥有这些用户故事，所以也是Product Owner的职责去撰写，收集，维护，以及区分用户故事的优先权。使用职责：开发工程师，测试工程师，以及其余的开发团队成员使用用户故事来确定任务目标与内容，他们根据用户故事来决定开发内容，以及确认何时才算开发完成。Product Owner全程跟进开发过程，确保项目进度符合公司预期。
一般常见错误：
太正式或是太多技术细节的用户故事：热情高昂的Product Owners有时候会写了太制式的用户故事，如果开发团队在冲刺计划会议的过程中看到了长得跟电气电子工程师学会(IEEE)开出的需求标准文档一样的用户故事，他们会假设所有细节都已经被制定好而直接跳过讨论环节。技术任务混淆成用户故事：敏捷其中一个重要的理念就是在每次迭代后都有可用的软件，如果用户故事很多都是具体的技术任务的话，在迭代后取得一个能让用户测试的产品并取得反馈的产品的可能性是很低的，同时间我们也丧失了在计划会议中安排任务优先级的灵活性。跳过讨论环节：用户故事(User Stories)不是需求(Requirements)，需求是一种要求，而故事是可以被讨论的。在与团队沟通的过程当中，永远都要先让团队知道任务的原始需求，再开始讨论有哪些东西是需要被实现后才能认定这个用户故事是完成的。如果跳过合格条件的讨论环节，我们冒著让团队往错误的方向走的风险。
范例一用户故事：作为一个网站上的消费者，我希望我可以用信用卡支付，所以我可以马上知道支付结果。
Sample User Story
欢迎参考以上在网上搜到的一个用户故事范例，该用户故事经过多次冲刺计划会议与团队讨论并完善之后，已经很接近要被计划进下一次冲刺当中了。合格条件包含了：
- 接受Discovery，Visa，MasterCard等卡片类型
- 在用户输入的过程中检验信用卡号的合格性
- 检查信用卡到期日以及安全码的合格性
- 验证用户填写的帐单地址是合格的
- 处理结果会显示成功或是失败的信息反馈给用户
完成条件包含了：(这边通常是所有用户故事共用的，不会发生不同的用户故事有不同的完成定义)
- 通过所有回归测试
- 通过所有UAT测试(上述合格条件)
- 由UI团队审核通过
- 可以交付用户作Demo
网友评论