用户故事笔记
用户故事的三要素
用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：
作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>
一个完整的用户故事包含三个要素：
- 角色（who）：谁要使用这个
- 活动（what）：要完成什么活动
- 价值（value）：为什么要这么做，这么做能带来什么价值
用户故事包含的模块：标题，描述，规则，验收标准，优先级等
3C原则
-
卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。
-
交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通，
确保各方对故事的理解正确。
-
确认（Confirmation）：通过验收测试确认用户故事被正确完成。
INVEST原则
-
独立 – 不依赖其他故事
-
可协商 – 并非一成不变，可以进行讨论
-
有价值 – 对某些利益相关者（通常是最终用户）
-
可估计的 – 足够清晰，交付团队可以很好地知道它有多大
-
足够小 – 小到足以在一个sprint /迭代中传递多个故事
-
可测试 – 如果无法测试，则显然对任何用户都无济于事
用户故事拆分
用户故事不宜过大，识别出的史诗级故事需要进行拆分，拆分成团队可以接受的用户故事，拆分的9中方法
-
简单/复杂：
假如团队正在讨论的某个故事变得越来越大，我们可以停下来并提问：“可以工作的最简单版本是什么?”捕捉这一简单版本作为一个单独故事，然后把所有变体和复杂性拆解到它们各自的故事中。
-
推迟性能实现：
不要太早考虑性能要求，我们常常忘了“让它工作，然后让它更快”这个原则，比如：
作为一个订单专员，我希望能1秒内获取订单信息的查询结果，以便于我能快速的查看订单内容
故事一：作为订单专员，我希望能查询出订单信息，以便于查看订单信息的具体内容
故事二：作为订单专员，我希望1秒内能获取订单查询结果，以便于快速的查看订单信息
-
基于工作流步骤进行拆分：
识别出用户为完成具体工作流采取的特定步骤，然后通过一些增量阶段实现工作流。如果已经能画出具体场景的流程，则可以先从工作流程拆分。该方法也叫作最简路径法，即先拆出最简路径，再基于最简路径添加步骤，直到覆盖完整路径。
-
接口可变性
对于需求中业务流程和逻辑规则相同，仅涉及接口不同，也就是获取数据的渠道和方式不同，我们可以基于接口的差异进行故事拆分。
例如，作为微信用户，我可以添加好友以便扩大朋友圈。
故事1，……我可以通过摇一摇方式添加好友……
故事2，……我可以通过扫二维码方式添加好友……
故事3，……我可以通过手写输入方式添加好友……
-
主要投入
根据主要投入或工作量来拆分故事。有时一个故事可以分为几部分,大部分的工作将用于实现第一个故事，其他的故事由于实现第一个故事，有一定的基础，添加更多的功能相对简单
-
业务规则可变性
针对需求中固定的流程加载不同业务规则的情形，我们按照业务规则拆分故事。
例如，作为网站用户，我希望A网站能提供热门推荐以便我可以更快找到感兴趣的内容。
故事1，……能根据帖子数量给出热门频道推荐……
故事2，……能根据发帖数给出热门作者推荐……
故事3，……能根据回帖数量给出最多评论推荐……
-
数据多样性
我们可以根据数据类别进行拆分。
比如我的用户故事是：作为用户，我希望能够查看系统的警告通知。我们系统警告通知有很多类型，各种警告的内容差别很大，那么我们可以把这个大故事拆分成以下几个小故事：
故事1，作为用户，我希望能够查看系统的异常流量警告通知;
故事2，作为用户，我希望能够查看系统的恶意代码警告通知;
故事3，作为用户，我希望能够查看系统的僵尸网络警告通知。
-
故事穿刺
故事穿刺其实就是摸着石头过河。一个故事比较大不一定因为它复杂，而是由于我们对实施知之甚少。在这种情况下,再多的讨论也不能让我们知道如何拆分它。我们可以在一定时间内针对怎么实施，先做个探针试验。试验过后，知道了深浅，揭开了面纱，我们往往就可以知道如何拆分它了
例如，作为用户，我可以用信用卡支付：
故事1，调查信用卡数据处理机制;
故事2，实施信用卡处理。
-
业务操作，CURD大法
有些用户故事使用了“管理”、“控制”等词汇，它掩盖了对故事执行的多种操作，大的用户故事可以基于不同类型的操作进行故事拆分，例如，管理里面包含了 增删改查，根据CURD来拆分故事
