敏捷的重要工具——用户故事

一、用户故事概述

1 什么是用户故事

敏捷最重要的思想是关注交付价值，如何确定价值？需要沟通，需要新软件的人必需和开发新软件的人充分沟通，一个合适的工具“用户故事”、应运而生。

（客户在项目整个过程中全程参与）

• 【故事卡片】首先，由客户使用“商业语言”来编写用户故事，这样，便于按价值排列优先级。（用户故事没有超出客户认知的技术术语）
• 【交流】然后，当某故事开始纳入任务周期时、并且如果因缺乏细节无法继续开发，开始沟通（开发团队与客户沟通）：① 很大的史诗级故事分解成小故事；② 缺乏细节的补充细节。（注意，不是从一开始，就把所有用户故事的细节一次性确认下来。由于客户可能一开始也不一定了解自己真正的需求，所以用户故事可以推迟考虑细节。）
• 【确认-验收测试描述】通过客户提出的可能的测试情景，来了解客户的期望。（注意，建议在开发之前就编写测试描述，这样开发人员对于客户的预期就更加心中有数。）

2 用户故事的大小适用于迭代开发、适合做计划

FIRST 将用户故事按照优先级进行排序

优先级的考虑因素：

• 大部分客户对用户故事的看重程度；
• 小部分重要客户对用户故事的看重程度；
• 故事之间是否有关联：比如如果故事A和B有互补关系，故事B是高优先级的，而A优先级可能不高，但是因为与B有互补关系，所以，也可以被排到前面；
• 根据性能需求排优先级；（有些时候，重构可能非常困难）
• 可以使用莫斯科规则为故事定位：必须有、应该有、可以有、这次不会有；

SECOND 估算故事的大小和复杂度

示例：

THIRD 根据开发团队每轮迭代速率、分配故事

尽可能选择固定的迭代长度，假如团队每轮迭代开发速率为13个故事点；

为什么把优先级较低的故事10排在了优先级较高的故事9前面了呢，因为故事9需要5个工作点，如果塞在迭代3中，该轮迭代故事点太大，按团队速率难以完成。

有没有更好的将价值前置的方法呢？

还可以将大故事进行拆分、然后分配，比如故事9可以拆分为故事9.1（2个故事点）和故事9.2（3个故事点），故事9.1比故事9.2更重要：

那么，就可以像下面这样分配：

二、编写用户故事

1 用户角色建模

为什么需要梳理用户角色？显然，我们不能从单一的角度来编写用户故事，同一个系统会有多种用户角色，他们的需求是不同的。

当然，不同角色的需求也可能有重叠，但是可能他们的使用的方式不同，接下来看如何进行角色建模。

• 进行头脑风暴，列出初始的用户角色们
• 整理、整合/浓缩角色

整理发现：有些角色之间有明显的重叠、有些角色有小部分重叠；

从完全重叠的角色入手、讨论、精炼角色名称；

从现实世界用户维度入手、取代没有现实意义的一些角色；

定义角色特征（任何可以区分这个角色的特点）；

• 其他：虚构人物、极端人物

虚构人物：定义一个虚构的人物，详细写出他的个人工作、家庭、日常习惯、诉求等。

极端人物：有助于编写遗漏的用户故事。

2 什么样的是好的用户故事

如何编写好故事

• 考虑每一个用户角色，思考他们使用软件的大体步骤、目的，得到高层次的故事，然后再衍生新的低层次的故事。
• 在故事里包括用户角色

我作为（角色），想要（功能），以此（商业价值）；

• 一个故事为一个角色编写
• 用“切蛋糕”的方法分解大故事，而不是用制作整个蛋糕的步骤（调面糊、打蛋、混合、烘焙……）

例如一个完整的大蛋糕：求职者可以发布简历；

开发人员可能会按照制作蛋糕的步骤来分：a.求职者可以填写简历；b.简历上的信息可以写入数据库。这样的分法，导致任何一部分都不能单独产生价值。

按照“切蛋糕"的方法，可以这样分：

a.求职者可以提交简历，简历上只包括姓名、地址、教育背景这样的基本信息；

b.求职者可以提交简历，简历上包括雇主想看的所有其他类型的信息。

• 要编写让用户觉得他完成了某个任务的故事；

比如：“招聘者可以管理他发的招聘广告”，就不是一个好故事。

可以换成：“招聘者可以更改招聘广告的过期日期”、“招聘者可以审核根据他所发广告引流的简历”、“招聘者可以删除不合适的申请”……

• 不是所有需求都适合写成用户故事

比如：用户界面、重要系统间的接口等；

INVEST

• 独立的（Independent）
• 可以讨论的（Negotiable）
• 对客户有价值的（Valuale）
• 可估计的（Estimatable）
• 小的（Small）
• 可以被测试的（Testable）

独立的-->

假设3个故事存在依赖，去除依赖的方法

方法一：把它们合并成一个大的独立的故事；

方法二：用不依赖的方式分割故事：故事1：用一种……；故事2：用另外两种……；

方法三：假设故事A和B相互依赖，则在故事卡上加2个估计，一个是A早于B实现，给一个较多的估计；一个是A晚于B实现，给一个工作量较少的估计。

可以讨论的-->

包含一两句短句、以提醒开发团队与客户沟通，不需要太多细节；

可以包含一点注释、标明在对话中亟待解决的问题。

对客户有价值的-->

比如：

隐含测试用例的细节要和故事本身分开；

不能是只对开发人员有价值的故事；

可估计的-->

故事太大导致不好估计-->分解为小故事；

可能开发团队缺少领域知识、导致不好估计-->与客户讨论；

可能开发团队缺少该方面技术知识、导致不好估计-->探针试验（spike），可以将探针试验放在迭代里；

小的-->

分解复合故事和复杂故事；

合并太小的故事（比如用户界面变更一点点）-->可以将若干小故事合并到需要半天完成的故事里。

可以被测试的-->

比如，这种故事是不能被测试的：

用户觉得软件好用；

用户不能花很长时间等待窗口出现。

三、用户故事开发迭代

团队迭代速率：每个迭代完成的故事点；

初始速率：猜测、或者使用一轮初始迭代-得到速率。

在后续的迭代中监控速率。

示例：

可以从表中得出各种趋势：

• 实际速率；
• 计划故事点和实际故事点；
• 故事点迭代燃尽图；

此外，在每个迭代中，还可以有每日燃尽图，展示团队的剩余工作量。