用户故事笔记

用户故事的三要素

用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：

作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>

一个完整的用户故事包含三个要素：

1. 角色（who）：谁要使用这个
2. 活动（what）：要完成什么活动
3. 价值（value）：为什么要这么做，这么做能带来什么价值

用户故事包含的模块：标题，描述，规则，验收标准，优先级等

3C原则

1. 卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。

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

   确保各方对故事的理解正确。

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

INVEST原则

1. 独立 – 不依赖其他故事

2. 可协商 – 并非一成不变，可以进行讨论

3. 有价值 – 对某些利益相关者（通常是最终用户）

4. 可估计的 – 足够清晰，交付团队可以很好地知道它有多大

5. 足够小 – 小到足以在一个sprint /迭代中传递多个故事

6. 可测试 – 如果无法测试，则显然对任何用户都无济于事

用户故事拆分

用户故事不宜过大，识别出的史诗级故事需要进行拆分，拆分成团队可以接受的用户故事，拆分的9中方法

1. 简单/复杂：

   假如团队正在讨论的某个故事变得越来越大，我们可以停下来并提问：“可以工作的最简单版本是什么?”捕捉这一简单版本作为一个单独故事，然后把所有变体和复杂性拆解到它们各自的故事中。

2. 推迟性能实现：

   不要太早考虑性能要求，我们常常忘了“让它工作，然后让它更快”这个原则，比如：

   作为一个订单专员，我希望能1秒内获取订单信息的查询结果，以便于我能快速的查看订单内容

   故事一：作为订单专员，我希望能查询出订单信息，以便于查看订单信息的具体内容

   故事二：作为订单专员，我希望1秒内能获取订单查询结果，以便于快速的查看订单信息

3. 基于工作流步骤进行拆分：

   识别出用户为完成具体工作流采取的特定步骤，然后通过一些增量阶段实现工作流。如果已经能画出具体场景的流程，则可以先从工作流程拆分。该方法也叫作最简路径法，即先拆出最简路径，再基于最简路径添加步骤，直到覆盖完整路径。

4. 接口可变性

   对于需求中业务流程和逻辑规则相同，仅涉及接口不同，也就是获取数据的渠道和方式不同，我们可以基于接口的差异进行故事拆分。

   例如，作为微信用户，我可以添加好友以便扩大朋友圈。

   故事1，……我可以通过摇一摇方式添加好友……

   故事2，……我可以通过扫二维码方式添加好友……

   故事3，……我可以通过手写输入方式添加好友……

5. 主要投入

   根据主要投入或工作量来拆分故事。有时一个故事可以分为几部分,大部分的工作将用于实现第一个故事，其他的故事由于实现第一个故事，有一定的基础，添加更多的功能相对简单

6. 业务规则可变性

   针对需求中固定的流程加载不同业务规则的情形，我们按照业务规则拆分故事。　

   例如，作为网站用户，我希望A网站能提供热门推荐以便我可以更快找到感兴趣的内容。

   故事1，……能根据帖子数量给出热门频道推荐……

   故事2，……能根据发帖数给出热门作者推荐……

   故事3，……能根据回帖数量给出最多评论推荐……

7. 数据多样性

   我们可以根据数据类别进行拆分。

   比如我的用户故事是：作为用户，我希望能够查看系统的警告通知。我们系统警告通知有很多类型，各种警告的内容差别很大，那么我们可以把这个大故事拆分成以下几个小故事：

   故事1，作为用户，我希望能够查看系统的异常流量警告通知;

   故事2，作为用户，我希望能够查看系统的恶意代码警告通知;

   故事3，作为用户，我希望能够查看系统的僵尸网络警告通知。

8. 故事穿刺

   故事穿刺其实就是摸着石头过河。一个故事比较大不一定因为它复杂，而是由于我们对实施知之甚少。在这种情况下,再多的讨论也不能让我们知道如何拆分它。我们可以在一定时间内针对怎么实施，先做个探针试验。试验过后，知道了深浅，揭开了面纱，我们往往就可以知道如何拆分它了　

   例如，作为用户，我可以用信用卡支付：

   故事1，调查信用卡数据处理机制;

   故事2，实施信用卡处理。

9. 业务操作，CURD大法

   有些用户故事使用了“管理”、“控制”等词汇，它掩盖了对故事执行的多种操作，大的用户故事可以基于不同类型的操作进行故事拆分，例如，管理里面包含了 增删改查，根据CURD来拆分故事