第五章 需求与用户故事

我是伊昂杨啊，我把自己的Scrum学习之路搬来了咱们煎饼果子铺????。

每天积累一点小知识，每天在这里一点碎碎念，顺便和你交个朋友，一起学习，一起考证，一起进步????。

一、概述

Scrum和顺序产品开发对待需求的区别：

1、顺序产品开发：

① 需求不可协商、早早地就已细化并且是独立的。

② 需求事先拟定并以高度详尽的文档形式移交给开发组。接下来是开发组的工作，照着这些详细需求来生产产品。有变更的时候，必须通过正式的变更控制流程来管理。

2、Scrum：

① 需求细节是在开发期间持续不断的对话中商讨出来的，在团队开始构建功能的时候，及时、刚好地细化这些需求为团队提供支持。

② 不会在前期就投入大量的时间和成本详细描述需求。等过段时间进一步了解特性之后，细节是会变的，所以要避免在今后可能丢弃的需求上投入太多精力和时间。与以前事先拟定详尽的需求文档不同，我们为需求创建“占位符”，即“PBI”。每个 PBI 代表客户期待的一个业务价值。

图片来自网络（侵删）

???? 伊昂杨啊帮助理解：

最开始的时候，PBI的个头很大（代表大块业务价值），相关细节很少。随着时间推移，经由干系人、产品负责人及开发团队围绕这些 PBI 所进行的一系列对话，它们被修订成了更小、更详细的 PBI。最终，一个 PBI 应该足够小且足够详细，可以放入一个冲刺，完成设计、构建与测试。就算是进入了冲刺，也还会有更多细节在产品负责人与开发团队之间的对话中冒出来。

二、利用对话

1、需求定义

需求是一种沟通工具，可用于引导大家对特性达成共识。通过需求，了解应该创建哪些特性的人便可以和负责创建特性的人讲清楚自己想要什么（期望）。

2、顺序产品开发与Scrum对需求的理解：

① 顺序产品开发：顺序产品开发严重依赖于书面需求，很容易被误解。

② Scrum：将对话用作确保需求可让妥善讨论与沟通的关键工具。口头沟通具有高带宽和可提供快速反馈的优势，能够更简便地取得共识。另外，对话使双向沟通成为可能，可以激发与问题和机会相关的想法，阅读文档可没有这种效果。

三、逐步细化

1、顺序产品开发与Scrum对需求的细化：

① 顺序产品开发：所有需求必须同时达到相同的详细程度。已批准的需求文档必须详细描述每一个需求，不能把任何细节留到日后再加。

② Scrum：并非所有需求都必须在相同时间做到同样详细。采取逐步细化的策略。

四、用户故事

⚠️用户故事要遵循3C原则：卡片Card、会话Conversation和确认 Confirmation。

1、用户故事定义：用户故事是可用于陈述业务价值的一种简便格式，适合各种 PBI，特别是特性。

2、用户故事的作用：用户故事的制作方式旨在帮助业务人员与技术人员双方都能理解需求。

3、用户故事不是描述PBI 的唯一方法。用户故事是一种轻量级方法，与敏捷核心原则及对高效占位符较符合。

4、用户故事的3种表现形式

（1）卡片这个想法非常简单。最初，人们直接在3×5 英寸的索引卡或便利贴上写用户故事。

（2）通用模板格式：①明确用户种类（即用户角色）、②这类用户想要达成什么（目标）、③用户为什么想达成此目标（收益）。

图片来自网络（侵删）

（3）使用空间有限的小卡片，目的就是让用户故事尽可能简洁。点明需求的精髓或目的，提醒利益干系人、产品负责人及开发团队进行更深入的讨论。

（1）开发团队、产品负责人和利益干系人会在对话中发现并探讨需求的细节。用户故事仅仅是进行此会话的承诺。

（2）对话开启了一个更丰富的信息交换与协作形式，从而确保正确描述需求并使每个人都能理解需求。会话可能得出可以记下来的一张用户界面草图或业务规则的一份详细阐述。

图片来自网络（侵删）

（1）用户故事还要包含确认信息，它体现为满意条件的形式，是接收标准。开发团队可以更好地理解要构建和测试什么，产品负责人可以确认用户故事的实现是否符合预期。

（2）卡片正面是对故事的几行描述，背面就可以写上满意条件。

图片来自网络（侵删）

五、详细程度

编写不同抽象层级的用户故事来捕获客户及用户需求。

图片来自网络（侵删）

① 第一层为月度级别，即史诗级别。

② 第二层为星期级别，大于一个冲刺，也称为特性。

③ 第三层为天级别，冲刺就绪。

底层为小时级别，是具体的任务（任务并不是故事，比如强调的是如何构建不少构建什么）。

六、好故事的INVEST原则

⚠️INVEST 标准：

独立（Independent）、可协商 （Negotiable)、有价值 （Valuable）、可估算（Estimatable）、小（Small（大小合适））、可测试（Testable）。

用户故事应该是独立的，至少也应该是相互间松散耦合的，这样才实用。相互依赖程度高的故事会使估算、排优先顺序和规划复杂化。采用独立标准的目的不是消除所有依赖，而是在写故事时，尽量避免依赖关系。

故事细节应该是可协商的。能够清晰地捕提哪些业务功能是用户想要的，他们为什么想要。它们要为产品负责人、利益干系人与团队留出谈判空间。可协商性有助于当事人避免在使用详尽的前期需求文档时常见的那种彼此推诿、相互指责的心态。写可协商的故事就能避免事先写详尽需求所带来的种种问题。

故事都要有价值，客户才会支付产品。对于技术性故事属于完成因为价值所涉及的任务。

故事的工作量和成本。如果团队无法衡量故事大小，原因不外乎两个：故事太大或太模糊；团队积累的知识不够。

故事应该是大小合适。咱们在前面刚才提到的用户故事四个层级抽象，一定要够小，同时一定要考虑故事的时间点。

故事要有相应的优质接收标准（与满意条件有关）。测试标准就是3C中的确认。

七、非功能性需求

1、非功能性需求代表了系统级约束。

图片来自网络（侵删）

2、作为系统级约束，非功能性需求很重要，可以写到用户故事中，也可以不写，任何一个测试不能正常工作，都是没有完成。

八、知识获取型故事

简单理解为探针。

???? 伊昂杨啊帮助理解：

比方说咱们现在要做一个支付的开发需求，有不同的方式，可以通过二维码扫码支付，或者链接点击支付等。不同的方式技术的呈现方式不一样，那么现在不知道哪一种更好，就做一个实验（也叫探针），一个探针就是一个用户故事，做完实验之后发现这个扫码支付方式更好更可行，那么就用这个扫码支付的实验来进行开发工作。

九、收集故事

① 集体进行头脑风暴，讨论预期的业务价值，并为应该做的产品或服务创建用户故事占位符。

② 参加研讨会的通常是产品负责人、ScrumMaster 和开发团队，还有内外部利益干系人。大部分研讨会持续几个小时到几天就结束了。

① 以用户为中心的视角产出一整套用户故事。基本思想是将概要性用户活动分解为工作流，工作流还可以继续分解成一套明确的任务。

图片来自网络（侵删）

???? 伊昂杨啊帮助理解：

上图横向看，业务流可分为【管理账户】【浏览】【购买】【支付】【配送】【退货】6个流程。

开发一个购书流程，首先要在网站上注册登录，浏览进行购买支付，然后配送包括退货等这些内容。

在【发布1】的板块里面，我都做完了这些工作就是一个简单的购书流程，此时满足了基本的流程实现，商业价值也是最高的。在接下来的【发布2】【发布3】种进行完善优化。

其实也就是把产品的backlog中的一个个小需求在【业务流程/商业价值】二维度中进行重新排列，但是，还是按照backlog中的优先级任务进行干活。