一个用户故事包括哪三要素（用户故事一）
一个用户故事包括哪三要素（用户故事一）（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通；确保各方对故事的理解正确。用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。（1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。卡片的正面书写故事的描述，格式为：作为一个<角色> 我想要<完成活动> 以便于<实现价值>描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。
用户故事在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通；包含角色、活动、价值三个要素。
一、用户故事的概念
概念这种东西我喜欢说文解字的方式去理解和阐述；用户故事=用户 故事=人 故 事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户和用户需求的简短描述。
二、用户故事的三要素
用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色> 我想要<完成活动> 以便于<实现价值>。
一个完整的用户故事包含三个要素：
- 角色（who）：谁要使用这个
- 活动（what）：要完成什么活动
- 价值（value）：为什么要这么做，这么做能带来什么价值
三、3C原则
用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
（1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。
卡片的正面书写故事的描述，格式为：作为一个<角色> 我想要<完成活动> 以便于<实现价值>描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。
（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通；确保各方对故事的理解正确。
（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。
四、INVEST原则
好的用户故事除了格式规范，要素完整外，还应该遵循INVEST原则：Idependent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimatable（可评估）；Small（小的）；Testable（可测试的）。
1. Idependent（独立的）
要尽可能的让一个用户故事独立于其他的用户故事。用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。
2. Negotiable（可协商的）
一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事只是对用户故事的一个简短的描述，不包括太多的细节；具体的细节在沟通阶段产出。一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。
3. Valuable（有价值的）
每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。
这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。
4. Estimatable（可评估）
计划会议里面一个很重要的环节，那就是故事点的估计。实际上就是对要开发的User Story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量）。
重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计用户故事。
让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
5. Small（小的）
一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量 至少要确保的是在一个迭代中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
6. Testable（可测试的）
一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
五、三个准则
用户故事在遵循了INVEST原则后，基本就是一个好的用户故事了。再重点分析三个准则，帮助在产出用户故事时更好地符合原则。
三个准则是：一个用户、完整价值、不依赖。
1. 一个用户
只包含一个用户，因为多个用户常常有细微的差别。一般是典型的用户，常常有共同的某类需求。
2. 完整价值
完整地交付一个客户价值。一个完整的用户故事意味着这个故事完成后，用户可以达成一个明确的、有意义的目标。
3. 不依赖
依赖性的三种常见类型是：重叠、顺序和包含。
总体上来说，故事之间功能点相互重叠是需要避免的；顺序关系是现实存在，在多数情况下可以通过一些手段解决；包含关系对复杂系统是有帮助的，对排定发布和迭代计划的影响需要注意。
（1）重叠依赖
重叠依赖是带来最多困扰的依赖形式，特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合，该集合应该包含且仅包含一次需要的功能。
解决方式：
- 将重叠部分单独剥离出来做为独立的用户故事；
- 合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中；
- 使用Scrum开发模式。
（2）顺序依赖
顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。顺序依赖通常是无害的，而且有一些方式可以减轻这种依赖。
从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的。
但从另外的角度，不必要的顺序依赖使得排列和调整优先级变的比较困难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以把握。
解决方式：
- 一个迭代内的用户故事尽量做到没有内在依赖；
- 保持迭代之间只有单向依赖，在时间上只有后面迭代的故事对前面迭代故事的单向依赖（前向依赖）；
- 剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。
（3）包含依赖
包含依赖是指在组织用户故事时使用有层级的管理，比如常见的特性－故事两级管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。
解决方式：
- 用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划，特性一级可以用来做发布计划；
- 特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去；
- 遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。
参考文章
本文由 @chun 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
