[需求管理-5]：需求分析 - 如何进行有潜在商业价值需求的帅选？用户故事的定义方法？

Posted 2022-09-21 文火冰糖的硅基工坊

目录

第1章 需求分析全过程

第2章 帅选过程

2.1 本阶段目的

2.2 本阶段的输入

2.3 本阶段的活动

2.4 本阶段的输出

第3章 用户故事的三要素：角色、活动、价值

3.1 什么是用户故事

3.2 用户故事获取的3C原则

3.3 用户故事定义的INVEST原则

---

第1章 需求分析全过程

参考：

https://blog.csdn.net/HiWangWenBing/article/details/126881623

第2章 帅选过程

2.1 本阶段目的

该阶段的目的是：识别、请求、建议需要列表，并在投入更多精力之前，筛选掉业务潜力低的功能。

2.2 本阶段的输入

（1）特征请求基本信息

• 请求标题
• 请求者
• 技术领域：如FDD/TDD
• 方案领域：OAM or 无线资源管理、平台等等扥

这些基本信息是对需求进行分类的依据，在大型组织内，不同的项目经理负责不同的技术领域。

（2）功能需要背后的客户

这也是划分功能需要的一种方法，大型组织内，不同的产品经理或客户经理，负责不同的客户。

（3）功能需求的详细说明

（4）要求的交货时间表

（5）竞争分析，包括

• 给公司带来的价值以及竞争对手对该需要的满足情形

（6）该需求的内在价值：这是决定该需求是否值得做的重要依据

• 客户遇到的挑战、遇到的问题或内在诉求
• 该需要对于客户价值，给客户带来的价值以及客户竞争对手的分析
• 如果未交付，对客户的影响
• 该商业机会的时间机会窗口，错过了该机会窗口，再提供给需要，价值就不大了。

（7）该需要对于组织的意义（组织为什么要做这件事）

• 机会类型
• 预计的单位价值
• 预估的出货量
• 预计带来的总收益
• 上述估算的基本依据
• 不可量化的理由

2.3 本阶段的活动

（1）分配该阶段分析的主要负责人，当然，并不他一个人完成该阶段的所有活动，而是他负责组织会议讨论、评审该需要，并确保该阶段的相关分析活动得以实施。

（2）澄清该需要的范围和定义功能

（3）按优先级顺序，描述该需要对应的用户故事（User Story）

（4）验证并映射功能背后的客户需要

（5）初步估计需求和业务潜力

（6）定义目标软件发布版本，即期望在哪个软件发布版本中实现该需要。

（7）确定主导产品

（8）识别该需要的外部依赖关系

（9）与设备芯片组和设备功能和可用性保持一致

（10）确定运营支出类别

（11）确定是否需要进一步的技术可行性分析

（11）将需要按照价值大小进行分类：不可销售、可销售或可销售高价值。

2.4 本阶段的输出

（1）该功能需求的负责人

（2）明确特征需要的范围和定义

• 描述需求需要做什么

（3）按优先级顺序排列的用户故事（这是下一步技术分析基础）

（4）期望的软件发布版本号，即期望在哪个软件发布版本中实现该需要

（5）产品类型，如5G, 4G，3G等。

（6） 运营支出类别：哪个部门为该需要支出研发费用，在大型组织中，研发与业务部门往往是分开的，研发部门负责开发，业务部门负责赚钱，根据研发部门的工作量给研发部门支付费用。

（7）主导的功能的分类，如平台、无线资源管理、OAM网管。

（8）商业潜力的初步估计（这是最重要的输出信息）

• 机会类型
• 预计的单位价值
• 预估的出货量
• 预计带来的总收益 （投资回报）
• 上述估算的基本依据

（10）FS0决策建议

• 是否值得投资、研发
• 硬件平台
• 是否需要进行进一步的技术可行性分析，如果需要，主要指派相关的技术专家进行技术可行性分析，如果不需要，跳过技术可行性分析。
• 是否需要做异常设计和分析
• 期望的软件版本
• 采用的价格模型
• 风险等级
• 主要的商业价值点

第3章 用户故事的三要素：角色、活动、价值

3.1 什么是用户故事

（1）用户故事的作用

用户故事在软件开发过程中被作为描述需求的一种表达形式；

为了规范用户故事的表达，便于沟通；用户故事必须包含角色、活动、价值三个基本要素。

（2）什么是用户故事

用户故事 = 用户+故事 = 人+故+事，那就是什么人因什么原因要做什么事，提炼出来三要素就是who、why、what。

从需求角度描述就是一个用来确认用户和用户需求的简短描述。

（3）用户故事的三要素与用户故事的书写格式

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

用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

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

角色（who）：谁要使用这个活动（what）

活动（what）：要完成什么活动

价值（value）：为什么要这么做，这么做能带来什么价值。

3.2 用户故事获取的3C原则

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

（1）卡片（Card）：

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

卡片的正面：用户故事的描述方法

书写故事的描述，格式为：作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求；

卡片的背面：用户故事的验证方法

书写完成用户故事的规则和完成标准，格式为：Given…When…Then。

Given…: 在.....前置条件下，

When：当发生什么事件或输入时

Then：输出什么的结果，或系统做出什么的行为反应。

（2）交谈（Conversation）：

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

（3）验收确认（Confirmation）：

客户通过验收测试，来确认用户故事被正确完成或实现。

3.3 用户故事定义的INVEST原则：小而整

好的用户故事除了格式规范、要素完整外，还应该遵循INVEST原则：

​

• 自身角度：独立；
• 客户角度：可协商、有价值
• 管理角度：可评估
• 开发角度：足够小
• 测试角度：可测试

（1）Idependent（独立的）-- 用户故事自身的角度

要尽可能的让一个用户故事独立于其他的用户故事。

用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。

（2）Negotiable（可协商的）-- 客户的角度

一个用户故事的内容要是可以协商的，用户故事不是合同。

一个用户故事只是对用户故事的一个简短的描述，不包括太多的细节；

具体的细节在沟通阶段产出。

一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。

（3）Valuable（有价值的） -- 客户的角度

每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。

用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。

这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作对客户的价值。

（4）Estimatable（可评估）-- 项目管理的角度

计划会议里面一个很重要的环节，那就是故事点（工作量）的估计。

实际上就是对要开发的User Story进行一个粗量级的工作量的估算，以便于团队能够知道这个user story的复杂度（工作量）。

重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计用户故事。

开发者难以估计故事的原因：对于业务领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

（5）Small（小的） -- 开发的角度

一个好的故事在工作量上要尽量短小。

最好不要超过10个理想人/天的工作量,  至少要确保的是在一个迭代中能够完成。

用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

备注：这里给出的10个人天，并不适合所有的场合，主要适合互联网的用户功能，在无线通信领域，只要一个10人的以内的小团队在一个迭代周期内能够完成，就可以认为已经足够小了。

（6）Testable（可测试的）-- 测试的角度

一个用户故事要是可以测试的，以便于用户确认它是可以完成的。

如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。

一个不可测试的用户故事例子：软件应该是易于使用的。

3.4 三个准则：一个用户、完整价值、不依赖。

（1）一个用户

只包含一个用户，因为多个用户常常有细微的差别。

一般是典型的用户，常常有共同的某类需求。

（2）完整价值

完整地交付一个客户价值。

一个完整的用户故事意味着这个故事完成后，用户可以达成一个明确的、有意义的目标。

（3）不依赖

依赖性的三种常见类型是：重叠、顺序和包含。

重叠关系在故事之间功能点之间需要避免的；

顺序关系是现实存在，在多数情况下可以通过一些手段解决；

包含关系对复杂系统是有帮助的，利于把复杂功能分解成简单功能，但对排定发布和迭代计划的影响需要注意。

• 重叠依赖

重叠依赖是带来最多困扰的依赖形式，特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合，该集合应该包含且仅包含一次需要的功能。

重叠导致两个故事重复实现某种功能，容易导致边界混乱和不清晰。

解决方式：

将重叠部分单独剥离出来做为独立的用户故事；

合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中；

使用Scrum开发模式。

• 顺序依赖

顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。

顺序依赖通常是无害的，在现实软件开发是也是常见的现象。从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的。

但从另外的角度，不必要的顺序依赖使得排列和调整优先级变的比较困难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以把握。（顺序依赖主要影响项目管理）

解决方式：

一个迭代内的用户故事尽量做到没有内在依赖；

保持迭代之间只有单向依赖，在时间上只有后面迭代的故事对前面迭代故事的单向依赖（前向依赖）；

剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。

尽可能把可以独立的故事独立出来。

• 包含依赖（自顶向下、自底向上）

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

解决方式：

用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划，特性一级可以用来做发布计划；

特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去；

遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。