敏捷开发方法(四) 用户故事

2018-10-29 研发管理研发管理, 笔记评论

描述：总体描述，用来做计划和行为提示，用户故事描述包含三个要素：角色、活动以及商业价值
- 描述方式为：作为XXX（用户角色）能够XXX（动作），以便于XXX（目的）其中：
  - 用户角色：谁要使用这个功能，在本指南中可以采用用户建模中的角色；
  - 活动：需要完成什么样的功能；
  - 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
有关故事的具体化细节: 故事相关活动的细化说明，主要包含的内容.
- 在这个故事中，每个角色需要参与的工作（活动）及实现的结果；
- 在这个故事中，每个角色的工作流程；
- 每个工作流节点的具体工作内容及具体业务控制逻辑要求和逻辑条件。
- 包括在故事在团队讨论中内容形成的注释。
验收标准：用于表达和明确故事细节且可用于确定故事何时完成，用于明确团队完成故事的标准。

提示:用户故事要使用用户可以接受的业务语言来描述故事，不能够使用技术语言来描述。用户故事的质量是后续工作顺利完成的基础，因此尽可能保证用户故事的质量，不要因为用户故事的不清晰使得在开发中过多的投入到故事论述中，导致开发结果没有完成。

优秀用户故事特征-INVEST原则

I – Independent，独立性，可独立交付给客户：要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
N – Negotiable，可协商性，便于与客户交流：一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
V - Valuable ，价值性，对客户有价值：每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
E - Estimable ，估算性，能估计出工作量：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
S - Small ，短小：分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成，一个好的故事在工作量上要尽量短小，最好不要超过一个迭代周期的工作量,要确保的是在一个迭代中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
T - Testable，可测试性:一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

建立用户角色模型

建立用户角色模型即梳理用户角色:把客户和开发人员聚集到一个房间中，通过头脑风暴，列出初始的用户角色集合，然后整理最初的角色集合，通过整合角色和提炼角色，最终确定出使用软件的角色。

具体操作方法可以参考如下：

所有相关人员包括开发人员、需求人员、客户等均聚集在一起，通过头脑风暴首先列出原始的用户角色：

只需要在卡片中写出自己想到的角色，不需要讨论和评估；

将卡片读出来，粘贴到展示板中；

直到大家没有新的角色提出；

要注意列出的角色是产品实际使用用户。
初步分类：将第一步形成的用户角色进行初步分类，形成角色集合：

将卡片进行初步分组，标明角色间的关系；

相同的进行重叠；

包含关系通过卡片的覆盖进行体现；

系统角色尽量是一个具体的人。
整合角色：

去掉完全重合的卡片角色，讨论中可能会新增新的卡片；

丢弃对系统不重要的角色。
提炼角色，建立角色卡片：

经过前期的讨论，已经对角色之间的关系有了基本的了解；

通过提炼的角色，描述角色特征，角色特征可以从如下几个方面进行考虑：

用户使用软件的频率；

用户在相关领域的知识水平；

用户使用软件和计算机的熟悉程度；

用户使用该软件的目标和特点，如用户特别关注便捷性、关注用户体验；

本软件对该用户有帮助的特征；

将特征形成用户角色特征卡片。

为了让角色更加完整，在用户故事后续重更加生动准确。可以进行如下两个角色的补充，根据产品实际情况进行，非必需。

虚拟角色：虚构出一个实际用户，阐述他的特点和可能使用的场景，该角色需要真正代表产品的目标客户，作为软件虚拟使用人员，可以配以名字、照片、相关信息描述，在项目中可以理解为是真实存在的。
极端角色：可以找到一些遗漏的故事，根据产品需要决定是否有必要；

用户故事场景

概念

定义：从用户的角度出发，描述了一组典型用户在典型工作环境下的典型需要、想法、工作习惯等，是指一个应用(通常就是你的那个产品)被使用的时候，用户“最可能的”所处场景。

用户故事场景的设计，主要从以下几个方面考虑：

对每一个场景，设计一个场景入口，就是描述场景如何开始

用户故事主要是描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）

需要给场景划分优先级，并按优先级排序

用户场景有大有小，适度、平衡即可

用户和系统有成百上千种可能的交互情况，在写场景的时候要有针对性
用户故事场景的特征：

场景的背景：

典型用户

用户的需求、迫切需要解决的问题

假设

行业背景等

场景：
关于这个场景的文字描述：要列出这故事中出彩的地方, 例如：软件的哪些功能让用户特别满意? 逻辑和界面设计要注意哪些因素? 第一次使用的用户和多次使用的用户在体验上有何区别对待?

其他参考资料（工作规程、组织机构图、工作职责清单等）
场景通常在限定的条件内而存在，场景包括时间、空间、设备支持、社交及用户情绪等多个方面，进行应用场景的判断和描述的时候，尽量把这些都考虑完整。

场景的类型

基于故事目标或者任务的场景：主要描述用户想做什么，不包含用户如何完成任务的任何信息。
精细化的场景:提供了更多的用户使用细节。这些细节能帮助团队更深入的理解用户特点。
全面的场景描述:场景和人物角色还可以结合起来，分类呈现不同类型的用户使用产品的原因，有什么样的需求，揭示出“什么样的人”在“什么样的场景”下会有“什么样的行为”。
测试场景:说明预期的用户是如何完成这个任务的所有路径和步骤，包括用户可能使用的主要的入口或者其他的入口，供观察人员和记录人员在测试中使用。而在测试后，可对比下你的预期过程和用户完成任务的真实过程。

场景描述方法

场景描述中需要明确：

环境-人员-事情-产生的价值；
用户故事可以采用卡片、故事访谈链接、用户场景截图、故事板等方式表达故事的场景

验收标准

验收标准：定义故事是否完成的标准，让团队和产品负责人对此达成一致

面向用户的价值设定验收标准，业务验收标准主要包含：

PO或需求从业务的角度描述此功能的验收标准，在故事进入迭代计划之前该验收标准明确清晰；

按照用户的需要，产品Backlog条目完成；

PO或需求在Sprint结束时接受或拒绝接受开发团队的工作成果，对每个演示的故事和主要缺陷，PO表示接受（符合预期和验收标准）或拒绝（不符合预期或不满足验收标准），并给予团队反馈或意见；

PO或需求根据用户的价值确定功能优先级，并确认功能已经开发完成；

PO确认已经达成产品的投资回报率(ROI);

用户故事分级拆分

拆分原则

缩短完成用户故事的时间；
减少用户故事大小的差异性；
采用逐级分解细化方式，最终拆解为用户故事。

用户故事的大小

用户故事的大小与完成时间不是成正比的，故事增加两倍，投入时间可能增加5倍；当前我们通过时间盒的方法控制用户故事的大小。目前我们的要求是：用户故事大小不能超过迭代周期。

史诗：通常为大一点的用户故事，通常分为两种

复合故事（compound story）：由多个小的故事组成；
复杂故事（complex story）：本身就很大且不容易分解的故事。

通常通过分层的方式体现，有些需要采用探针实验进行验证

用户故事的分级

用户故事可以两个维度进行划分：一个是产品展现形式，一个是产品颗粒度。

产品展现形式分为以下三部分：

客户可见: 产品史诗、产品功能、产品增强，描述产品的卖点(展现给客户)
产品经理可见: 产品优化、产品约束、产品条件、产品性能等
开发团队可见三部分进行区分：产品缺陷，产品重构

产品颗粒度采用树形结构的形式进行细分，上级故事也可称为史诗级别的故事。

用户故事拆分

主要是要从客户角度对用户故事进行划分，具体可以：

按照不同操作— 即根据动作对故事进行分解，添加、删除、修改、浏览等
按照数据—即根据数据边界进行分解，可以浏览产品名和介绍、可以浏览产品价格
按照特性—易用性、性能、兼容性、并发性等等
按照角色—从不同用户角度按照投入的人力 - 比如要完成信用卡支付(Visa, Master, AmericanExperess)，可以分成三个故事来实现
按照实现复杂程度、步骤—解为探针实验调研以及实现两部分进行分解；
按照流程: 即根据业务流程进行分段，明确输入输出
产品缺陷：分为两类，一类是客户发现的，需要展现给用户，一类是我们自己发现。

用户故事优先级

用户故事优先级排序介绍

PO负责排序Story，产品总监负责排序Eipc和拍板有争议的story，排列优先级时需要考虑下面几点：

大部分用户和客户对特定特性的渴望程度
小部分重要用户和客户对特定特性的渴望程度
故事之间的互补或依赖关系

用户故事优先级排序放法

Kano模型

我们根据用户需求重要性将需求分为三种类型：基本型需求>期望性需求>兴奋型需求，这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。

需求类型	定义	不满足时	满足时
兴奋型需求	要求提供给顾客一些完全出乎意料的产品属性或服务行为，使顾客产生惊喜	当其特性不充足时，并且是无关紧要的特性，则顾客无所谓	当产品提供了这类需求中的服务时，顾客就会对，产品非常满意，从而提高顾客的忠诚度
基本型需求	顾客认为产品“必须有”的属性或功能	当其特性不充足（不满足顾客需求）时，顾客很不满意	当其特性充足（满足顾客需求）时，无所谓满意不满意，顾客充其量是满意
期望型需求	要求提供的产品或服务比较优秀，但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚，但是是他们希望得到的	当没有满意这些需求时，顾客就不满意	在市场调查中，顾客谈论的通常是期望型需求，期望型需求在产品中实现的越多，顾客就越满意

通过两个问题确定功能的分类：

关于产品中具有这项功能，用户会觉得怎样——功能存在形式

关于产品中没有这项功能，用户又会觉得怎样——功能缺失形式

对每个问题采用五点度量方式进行问答

我希望这样

我预期就是这样

我没有意见

我可以忍受这样

我不希望这样

答案分类，得到每条需求的分类维护在维度内进行数字优先级排序多人问卷调查，提高准确性实施：通过excel进行。

相对权重法

考虑一项功能所带来的正面益处，和缺乏他所产生的负面影响。评估如果实现它所带来的收益、如果不实现它所会招致的惩罚。
同故事点估算一样，对收益和惩罚也是采用1-9的尺度进行相对度量。

提示：

优先级= 价值百分比/成本百分比
价值百分比= 功能价值/价值总和

IT老魁

互联网从业者