关于用户故事的点点点

这是2021年第44篇随笔，全文1274字。

4月的第8篇。

4月计划9篇，随笔8/9篇。
老大要针对我们SM用户故事进行考试。这也是帮助我们温故知新。
考点已经给出：
用户故事写法，拆分法，在迭代中怎么安排，好坏，大小，优先级，user case

下面是准备的内容
我参见的书籍为Mike Cohn的《用户故事与敏捷方法》

1. 用户故事的写法
   用户故事的编写的INVEST特点。
   1. Independent独立的：故事之间应该是独立的。我们尽量实现这一目标。故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现。
      关于这一点，我发现我们目前的敏捷用户故事都是实施顺序有关的，很多卡都有相互依赖的顺序。这一点一直忽略了。
   2. Negotiable可讨论的：故事细节由用户和开发人员讨论得出。在我们公司，用户的代表产品经理跟开发讨论出故事细节。
   3. Valuable对用户或客户有价值的：应该很清楚的体现对用户或客户的价值。最好的做法是让客户编写故事。目前客户代表产品经来在写。目前问题比较大的也是用户故事的标题没有明确的体现出对于客户或者用户的价值。
   4. Estimatable可估计的：对开发人员来说，能估算/猜一下故事的大小，或者把故事变为代码的时间量很重要。
      3个原因导致故事不可估计：
      开发人员缺少领域知识--跟写故事的客户了解大概
      开发人员缺少技术知识-Spike
      故事太大了-拆分
   5. Small小的：故事大小很关键。故事的大小最终取决于团队，它的容量和使用的技术
      1. 分割故事：如果故事太大，复合故事或者复杂故事可以分成几个小故事
      2. 合并故事：如果故事太小，几个小故事可以合并成为大故事。
   6. Testable可测试的：故事应该是可以测试的。给故事加注释的最好方法是给他编写测试用例

然后来到什么是用户故事

• 用户故事3要素(用户故事标题-主动语态)：作为一个<用户角色Who>，我想要<What完成活动>，以便于<Value实现价值>
• Ron Jeffries 3C原则：Card，Converation，Confirmation
• 好的故事INVEST原则
• 3个准则：1个用户；完整价值；不依赖

2. 用户故事的拆分法
   来自敏捷大师Mike Cohn的高效拆分用户故事的5中方法-SPIDR
   简单高效拆分用户故事的5种方法

上图：

SPIDR

S：Spike
P：Path 按照用户故事可能的路径来拆分
I：Interface 当用户故事涉及到横跨多种用户交互接口或数据交互接口可以用此法拆分
D：Data 按照数据类型进行拆分
R：Rule 按照业务规则和技术标准进行拆分

3. 在迭代中怎么安排用户故事
   《用户故事与敏捷方法》第15章：
   在Scrum中使用用户故事：
   在Sprint计划会议中，PO和团队一起讨论产品Backlog中那些高优先级的条目。
   团队确定下一个Sprint中需要完成的条目。
   然后向PO作出承诺
   把这些故事划分成小任务，方便Sprint中团队成员认领。

4. 用户故事的好坏
   好的用户故事就是INVEST

   
   INVEST用户故事

5. 用户故事的大小

6. 用户故事的优先级
   总结一下，迭代开始前，PO排列优先级。 from：用户故事优先级的建立

采用MoSCoW方法加上财务，成本，知识准备和风险排除,最后加上风险和价值的关系几个要素来排列优先级。
MoSCoW

MoSCoW是以下短语的缩写
必须有（Must have）
应该有（Should have）
可以有（Could have）
这次不会有（Won't have this time）

MoSCoW
How
Risk vs. Value

7. user case
   用例user case-需求分析的工具

Use Case(用例) ：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。是UML一个重要的概念。更适合需求分析阶段
User Story(用户故事)：描述对软件（或系统）用户或客户有价值的功能,只是需求描述，而不是详细的需求规范。更适合需求探索阶段
from:用例和用户故事的区别