什么是用户故事

用户故事是描述了对用户、系统或软件购买者有价值的功能。

用户故事的组成——3C原则

• Card 故事写在物理卡片上，起到交流提示的作用
• Conversation 故事包含的诸多细节，需要和用户协商确定
• Confirmation 故事包含验收标准和环节，来确保被正确实现

为什么需要用户故事

• 用户故事不仅可以表达出用户需要什么，也可以聚焦功能价值。
• 用户故事便于高效沟通，因为单向的文字、语言或图像都会带来沟通歧义。如“下雨天留客天留我不留”，断句不一样，语义就不一样。人们更擅长记住和理解被组织成故事的零散信息。
• 用户故事适用于迭代开发
  • 故事可大可小，可分可合
  • 故事可量化可跟踪，是迭代中天然的开发/验收单元，在迭代中负责传递一切：信息、承诺、价值、风险
• 适合做计划
  • 每个用户故事代表一个独立的功能，可以在不同发布中挪动故事顺序（优先级），随时调整计划
  • 使得需求实现的范围可调整

什么是好的用户故事

好的用户故事需要遵循 INVEST 原则

Independent 独立的

• 避免引入依赖 依赖会影响客户对优先级的区分，避免让一个故事的实现依赖另一个为基础，避免让故事的工作量和难度与实现的次序相关
• 化解依赖 将相互依赖的故事合并，从新的维度重新划分故事

Negotiable - 可磋商的

• 3C原则中的“Conversation”
• 故事不是合同、方案或需求规格说明书
• 可协商层次递进：How->What->Why

Valuable

• 价值是故事的生命
• 必须挖掘并凸显出核心价值
• 不同的用户，价值关注点不同
• 客户和用户，价值关注点也不同
• 以切蛋糕的方式写故事

Estimatable 可估计的

故事是要被用于计划的，但是又难以估算，原因有：

• 拆分史诗故事困难
• 缺乏领域知识——与客户讨论
• 缺乏技术能力——穿刺
• 缺乏封闭性——拆分故事 冰山模型

每个故事小到能在1个sprint（迭代）内完成--->将来会细化到逐个sprint完成--->史诗将来会被细化到逐个Release

Testable 可测试的

• 3C原则中的“Confirmation”,要可被验收
• 验收条件体现故事范围
• 识别并在验收中增加约束（必须遵守单无需直接实现的故事）
• 能够从界面或接口进行测试

为什么要拆分用户故事

• 价值交付
• 快速、有效地得到用户的反馈
• 以客户未中心“纵向”分解帮助在多个团队间拆分和并行有价值的工作
• 拆分可以支持演进式的分析和开发

拆分的原则

一般推荐一个迭代拆分出4-6个故事

常见故事拆分方法

• 功能/非功能 适用于

1. 功能本身实现并不困难，其主要工作量是如何使它更快速、可靠、更精确或更具伸缩性等等
2. 团队从基本实现中掌握很多情况，而且功能实现应该对用户有一定的价值 原则
3. 将系统需求区分为功能和非功能两类
4. 针对功能类拆分史诗、特性类故事
5. 针对非功能类拆分维护性、扩展性、性能等质量故事 优先实现功能类故事，延迟实现非功能类

故事示例：

1. 作为10086话务员，我可以通过客户端查询任意用户的当前开通套餐信息以便反馈给10086用户
2. 作为运营商，我希望最多支持100个客户端同时查询用户套餐信息以便满足我的10086话务需求

• 业务规则

  • 业务类型 范围：需求固定的流程中，不同的业务规则，不同的处理流程

  原则：按照业务规则拆分故事

  • 操作 适用于根据需求中设计相同数据的不同操作类型（Create、Retrieve、Update、Delete）
  • 原则 按照操作类型进行拆分 比如：1.作为运维人员，我能在后台新建IPV4的TCP链路... 2.作为运维人员，我能在后台查询IPV4的TCP链路...3.作为运维人员，我能在后台删除IPV4的TCP链路...

• 场景

  • 角色目的 比如：投票、投诉、订单、活动等等
  • 数据类型 适用于 需求包含的多个子需求十分类似，完成其中一个子需求之后，其它子需求变得很容易

  原则 选其中一个子需求作为故事，其它作为另外一个故事

  示例：

  1. 作为客户，我能用微信来为我购物车中的物品付费
  2. 作为客户，我能用其它方式来为我购物车中的物品付费
  • 数据实例化 适用于 当某一类处理很复杂，需要选择一个实例化的对象操作

  原则：针对需求操作的数据对象的不同进行拆分 示例： 作为客户，我能用银行卡来为我购物车中的物品付费 ===> 作为客户，我能用银行卡（招商银行信用卡）来为我购物车中的物品付费

  • 由简入繁1 适用于 根据用户或用户目的已经有明确的需求优先级定义

  原则：先按照最简单的核心价值拆第一个故事，然后增加附加价值拆后续故事

  示例：微信核心功能 即时消息 --> 语音对讲 --> 摇一摇 --> 朋友圈 --> 视频聊天 --> 游戏中心

  • 由简入繁2 适用于 可从开始到结束对整个工作流进行“切片”

  原则：根据情景优先级分解 或 根据情景的难易分解

  • 由简入繁3 适用于 需求的异常分支、场景特别多和特别复杂的情况

原则：先根据简单正常、异常场景分解；再根据异常简单、复杂场景分解

• 替换渠道
  • 用户界面/接口 适用于 需求中业务流程和逻辑规则相同，仅涉及用户的UI界面和接口（获取数据的渠道和方式）的差异进行拆分
  操作原则：将业务流程和逻辑规则与UI界面和接口分离，拆分成不同的故事。 先实现最简单的接口，拆除一个故事
  • “虚假”实现即“打桩”
    • 适用于 依赖的外部元素是硬件、远程设备、需要网络的远程组件、进程间通讯时。对于嵌入式软件系统，打桩是摆脱硬件依赖关系的非常有价值的工具。优劣：可能会延迟与真正依赖的集成。但能加速反馈，两者都要兼顾。
    • 适用于 需求本身具备明显的工作流，如协议流程、用户多步骤交互类的需求。 操作原则：将开始+结束的2个步骤作为基本故事，然后逐次添加中间步骤形成新的故事。 注意：
  1. 注意此步骤并非内部模块间交互的步骤，而是对外呈现的情景步骤或消息交互步骤
  2. 分解后的步骤本身并不是端到端的解决方法，会延迟价值交付
  3. 可以减少风险或增加反馈，同时也增量地构建特性
• 测试集合 适用于 当前已经有了现成的用例集，完整表述用户对系统或系统对系统的复杂交互（继承类需求）。 方法：根据用例来直接生成故事（或进行一定的组合）
• 风险 1.做穿刺
  适应于 实现过程中出现技术、业务阻碍。 原则：列出形成阻碍的1-3个问题，实现一个最小化解决这些问题的穿刺版本。从其中已经掌握的一小部分开始实现它，然后在此基础上从头开始拆剩下的部分。
  2.集成
  适用于 对于系统打算采用一个开源的解决方法，然后做一些修改以提高扩展性或性能的情况。 原则：以移植功能和功能改造类型进行拆分。通过集成开源解决方法提供；带有平均响应时间小于0-3秒的...

常见故事拆分方法

同一个故事可以使用很多拆分方法
如何衡量哪种拆分方法最好呢？

• 选择拆分完后可以可以便于降低某个故事的优先级或干脆扔掉一个故事的方法
• 选择拆分后故事规模比较平均的方法。把一个8点的故事拆分成4个2点的故事比拆分成一个5一个3的故事更有用。PO能更自由的排优先级