需求分析 - 用户故事（User Story）

用户故事(一)

用户故事在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通；包含角色、活动、价值三个要素。

用户故事的概念

概念这种东西我喜欢说文解字的方式去理解和阐述；用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户和用户需求的简短描述。

用户故事的三要素

用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

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

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

3C原则

用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。

• 卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。
  
  卡片的正面书写故事的描述，格式为：作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。

• 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通；确保各方对故事的理解正确。
  

• 确认（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）包含依赖

包含依赖是指在组织用户故事时使用有层级的管理，比如常见的特性－故事两级管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。

解决方式：

• 用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划，特性一级可以用来做发布计划；
• 特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去；
• 遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。

用户故事（二）

1. 敏捷开发的需求敏捷化的手段

就职在互联网企业，在一个不大的项目组里，还是个要发挥产品经理主观能动性的产品，你要去探索商业模式，做产品规划，求生存。就先给你一只打火机让你在黑暗中找金矿，你打着打火机只能照亮周围1米，步子不能跨太大，不知道1米外是不是个坑，先跨一步看看，再能跨下一步。

更悲剧的是你的打火机不能一直按着，一直按着烫手啊，还要担心燃气够不够用。只能走走停停，摸摸索索，还要各方求资源补充燃气。

这种环境下，整个团队都在讲小迭代，讲敏捷，同样你必须写用户故事啊。

用户故事的出现使敏捷开发方法覆盖了软件研发中的“需求”环节，是敏捷开发模式中的需求敏捷化的重要手段。敏捷方法诞生十余年到现在我们知道，一个研发团队要想实现完全的敏捷转型光是实现迭代开发过程的敏捷化是不够的，SCRUM和Kanban都无法解决产品需求敏捷化的问题。

而用户故事的诞生，就是为了实现需求的敏捷化。虽然用户故事实践本身还存在一些不足，但是至少到现在我们知道，用户故事是需求敏捷化的基石之一。

Ps：如果你说你们在敏捷开发，但是你从不写用户故事，那怕是你们对敏捷开发有误解，你们做的应该就是单纯的迭代开发，不是敏捷开发。敏捷中重要的一点就是团队达成一致意见，成员都认同要做的事的价值，这是建立在对需求的3W（who、what、why）重复理解和讨论的基础上达成的。传统的需求表述方式只体现了what，无法支撑这种理解和讨论。

2.贯穿整个产品实现过程

需求评审会之后，进入开发、测试环节，常常能听到的声音是“这个需求当初为什么要这么定？”“我也不知道，产品就这么定的。”

随着时间的推移，可能产品经理自己也会忘记为什么要做这个需求，以及为什么要这么做。这就会造成团队的后劲不足，无法明确自己正在做的事的价值。当一个人对于正在做的事，不知道有何意义时，是痛苦的。

而用户故事能有效的将软件研发过程中的需求环节、开发环节和测试环节有效的连接起来。通过经典的“三段论“描述和渐进的细节探索，用户故事实现了需求描述的敏捷化；通过优先级排序和故事点的有效应用，用户故事实现了需求到开发的连接；通过验收标准的渐进明确，用户故事实现了需求与测试的连接。

可以说，正是有了用户故事这根线，才把软件研发团队的主要的工作环节：需求、开发、测试都有机的串联起来。整个团队成员都明确自己做的事能给团队和客户带来什么价值，形成内驱动。

3. 提高沟通效果

举个需求评审的场景：敏捷开发中，开发、设计、测试等在需求评审时，就会秉着敏捷参与的文化理念，来挑战你的权威，一起怼产品啊，怎能错过如此良机：这个需求谁提的，为什么这么做，做了有什么价值？

一顿舌战群儒后，身心俱疲，开发还是用怀疑的眼光看着你说：“这都是你YY的吧？”

最后，不得已来一句，老板就让这么做的，下周3上线。

但是，你用用户故事的”三段论”作为一个<用户角色>，我想要<完成活动>，以便于<实现价值>，在会前把故事发出去，注意力就是在故事的主人翁上，会中就是大家一起在探索用户场景、路径、给你提供思路，而不是在怼产品。

讲故事不用太在意听故事的人是谁？

用户故事的一个核心在于对话（Conversation），客户和开发人员可以就某个故事深入的交流，对每个重要的细节达成共识。这避免了通过文字记录而可能导致的不精确性或语义多重性的问题。并且向用户或客户显示价值，不涉及专业的技术术语，从而使得用户和开发者理解起来都很容易。

4. 用户故事适合于迭代开发

在开始编码之前，我们并不需要写出所有的用户故事，我们可以写出一部分故事，就开始编码与测试，然后按需求的节奏重复这个过程。在写故事时，也可以按照我们认为合适的粒度去写，正是因为我们很容易对故事本身也进行迭代，所以用户故事很适合迭代开发。

5. 用户故事鼓励延迟细节

我们可以先写出一个起始的目标层面及占位意义的故事，在这个故事再后来对于开发进程变得重要时，才用更多对的细节来代替这个简单的描述。

这很适用于有时间限制的项目。团队可以非常迅速的写出数十个用户故事，让大家对要开发的系统有一个整体的概念，然后先讨论当前时间优先级较高的故事的细节并开始编码，相对于事先完成系统的整体需求文档，大大加快了研发进度。

6. 用户故事传播隐性知识

缘于对面对面沟通的重视，故事能够促进团队内隐性知识的积累。开发人员与客户之间以及他们内部的沟通越密切，越多的隐性只是能得到传播与加强。

撰写有效的用户故事

用户故事（User Story）描述了将要实现的特性（Feature）或需求（Requirement），用户故事与特定的工具无关（Jira、Rally、Trello等等）。用户故事在各种敏捷框架使用，包括Scrum，看板（Kanban）和极限编程（Extreme Programming）等等。

用户故事应该根据业务需求编写成较小的（small）、独立的（independently）、可测试的（testable），增量的（increments），并有产品负责人确定其优先级。当产品负责人编写用户故事时，Scrum团队可以提供非功能性/技术性用户故事。但是，添加到待办事项列表中，所有的功能性/非功能性需求要求被产品所有者审核并确定其优先级。总而言之，用户故事应成为团队（产品负责人、Scrum团队、其他业务人员）之间沟通的桥梁。

编写用户故事

在Sprint Grooming期间，产品负责人将特性（Feature）、需求（Requirement）或史诗（Epic）分解为用户故事。然后，Sprint计划会（Spring planing）用来评估当前Sprint需完成的用户故事。

用户故事是从最终用户的角度对功能的简短描述：

作为[用户类型]，我想要[一些目标，功能]，以便[一些原因]。

一个例子：

作为一名房产中介，我希望能够租户身份证照片，以便可以将其附加到租赁合同中。

在编写用户故事时，它需要以下关键内容：

• 描述（Description）：对满足业务需求的功能描述
• 验收条件（Acceptance criteria）：所有可以标记用户故事为完成的条件
• 最重要的是，它应该是：
  
  用户故事应充分分解并保证其独立性， 这样就可以方便对工作进行适当的任务分配，估算，规模确定和测试。 产品负责人与Scrum团队根据用户需求协商功能的优先级，而用户故事的价值决定了其优先级。

此外，在** 验收条件（Acceptance criteria) **中记录了用户故事的测试用例。 它应该表示为：“谁”（用户），“什么”（功能）和“为什么”（结果）

用户故事该怎么写

一个完整的用户故事需要写的内容包含：

展现形式如下：

一、故事标题

用户故事的描述在列表中进行管理时，不利于快速理解，也不能一行展示。为每个故事取个标题（名字）就很有必要，而且像禅道、TAPD软件的需求表述格式中标题也是必填项。

就行邮件的主题，用户故事的标题是为了让读者能快速了解这个用户故事的要点和大致范围；怎么写好标题也是有章可循的。
常见的做法有：

1. 用户角度的动宾短语

如：创建商品、输入名称、修改头像等等这是动作+对象形式，擅长描述从用户看到的活动或功能。

2. 系统角度的动宾短语

此处的系统是指待开发的对象。

如，toast提示网络异常，记录用户访问次数，显示搜索结果，显示倒计时。擅长描述系统要执行的反馈和操作。

3. 主谓宾短语

有时动宾短语不能推断主语时使用主谓宾短句，或者可能有可能混淆时需要明确主语，此时就需要增加动作主语，如，超级管理员重置普通管理员的口令；A系统推送批量客户和合同信息。

随着时间推移，新增的用户故事有不少是基于原有的功能来再提升修改，这时往往要在标题里加上状语来区分，比如根据客户所在城市来查询客户列表，在客户没有登记电话号码时强制客户登记号码。 状语要清晰得说明用户故事所处的情况，能够区分类似的用户故事。

4. 差劲标题举例

（1）外访业务处理

点评：处理是万金油词语，没有突出重点。

（2）设计资产逾期流入流出报表

点评：主语既不是用户，也不是待开发的系统，而是开发人员，这更像是一个任务的标题。

（3）角色分配资源

点评：要做什么呢？不能快速理解故事核心。

二、故事描述

固定格式“作为……（用户角色），我想要……（完成活动），以便于……（实现价值）”的格式。故事描述一这种三段式表述，相比较于传统需求表述，体现了需求方和需求价值的重要性，也为保证了需求描述的可协商性。

三、规则描述

为了完成故事，有时需要制定故事的实现规则，涉及的名词定义等。规则描述由产品经理初步制定，在故事讨论后，进行修订确认。写作方式就是一条条穷举列出。注意这里不涉及原型页面和交互规则。

四、验收标准

可作为验收测试用例的具体例子。这也是我们常说的实例化需求，也是为了避免误读，让抽象的需求变得具体和可测试。
这一步很难，但非常重要。没有明确的验收条件，我们便不知道如何测试，业务也不知道如何验收。

通常，一个用户故事包含若干个验收条件，包括快乐路径（Happy Path）与意外场景（Exceptional Scenario）。

建议将验收条件全部写成“Given…When…Then”的 Gherkin 语言格式，这种写法和测试用例类型，是一条条具体的路径/场景，信息传递误差小。延伸开来，这一原则适用于任何事情。做一件事情，以终为始，在一开始明确要做成什么样子，行成闭环，才能指导行动并确保结果正确。

五、具体设计方案

故事完成需要具体的执行方案，方案一般都有故事实现的原型界面，交互规则；如果是数据类故事需求，还有数据指标的定义等。具体设计方案的产出可以在故事确认前也可以在故事确认后，具体看产品的时间和团队的要求。

方案文件一般为附件或原型链接。

六、上线检查清单

有些用户故事的上线可能需要一些额外的步骤，在做用户故事开发时就应该时刻想着上线时要留意的问题，及时记录作为备忘，以确保上线成功。
这里，确认理解、问为什么以及验收条件是重点，作为“就绪定义”（Definition of Ready, DoR），帮助我们厘清用户故事的具体需求。

用户故事例子

在编写有效的用户故事时，重要的是要有描述和详细的验收标准，以帮助团队决定何时将用户故事标记为“完成”。请参照以下例子：

史诗（Epic）	用户故事（User Story）	验收准则（ACCEPTANCE CRITERIA）
作为一个拍卖系统的用户，我希望能够安全登陆拍卖平台，以至于我可以投标购买商品	作为拍卖系统的用户，我希望能从拍卖平台选择商品，以至于我可以投标购买	保证拍卖系统的用户可以：1.成功登陆拍卖平台2.打开拍卖页面3.可以选择商品并投标
	作为拍卖系统的用户，我希望查看拍卖历史记录，以至于我可以移除过期的拍卖	保证拍卖系统的用户可以：1.成功登陆拍卖平台2.成功打开拍卖历史记录页面3.选择一个多个过期的历史记录4.移除选择的记录
作为市场部门主管，我希望有一个内容管理系统（content management system），以至于我可以管理并提供高质量的内容给顾客	作为内容提供者，我希望可以创建产品内容，以至于我可以给用户提供产品的内容给顾客	保证内容提供者可以：1.登录内容管理系统2.创建内容3.更新内容4.保存变更把内容提交给编辑审核
	作为编辑，我希望可以在内容发布前审核，以至于我可以保证内容被优化，没有语法错误	保证编辑可以：1.登录内容管理系统2.查看存在的内容3.编辑、保存内容4.对内容做标注5.将内容打回要求重新修6.改定期发布内容
作为人力资源主管，我希望有一个虚拟的职位看板，以至于我可以查看企业人力资源需求和职位状态	作为人力资源主管，我希望查看应聘者状态，以至于我可以在招聘环节中管理应聘者的状态	保证人力资源主管可以：1.登录虚拟职位看板2.编辑、添加及查看应聘者的信息3.每个阶段的更新（例如，电话筛选已完成，安排了面试，正在进行的背景调查等）4.向员工发送有关候选人的电子邮件通讯