一、用户故事概述
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),可以将探针试验放在迭代里;
小的-->
分解复合故事和复杂故事;
合并太小的故事(比如用户界面变更一点点)-->可以将若干小故事合并到需要半天完成的故事里。
可以被测试的-->
比如,这种故事是不能被测试的:
用户觉得软件好用;
用户不能花很长时间等待窗口出现。
三、用户故事开发迭代
团队迭代速率:每个迭代完成的故事点;
初始速率:猜测、或者使用一轮初始迭代-得到速率。
在后续的迭代中监控速率。
示例:
可以从表中得出各种趋势:
- 实际速率;
- 计划故事点和实际故事点;
- 故事点迭代燃尽图;
此外,在每个迭代中,还可以有每日燃尽图,展示团队的剩余工作量。