本节课程我们主要解决三个问题:为什么要有用户故事?用户故事是什么,它们具有哪些属性、内涵和特征?在产品开发的全流程中怎么使用用户故事?
理解用户故事
理解用户故事,从两个问题开始。
用户想要达到的目标是什么?
- 达到这个目标的成本是多少?
- 为了回答这两个问题,我们需要把大目标分解为小目标,排优先级和估算。
用户故事是这个过程中使用的基本单元载体。比用户故事大或者模糊的可以叫做史诗,主题或者只是一个产品点子。
关于上面两个根本问题,“@左耳朵”有很好的描述:
亚马逊里挑战产品和运营的方法论是 T-shirt Size Estimation。就是用 T 恤的尺寸来做评估。你要做这个东西可以,但是产品和运营必须得拿出证据说明你要做的这个东西是什么样尺寸的。
比如说 XXL 可以带来一百万人民币或一百万用户受益,XL 就是 50 万,L 是 25 万,这样砍下去,然后这些需求给到技术团队,这边技术团队也会做个评估。XXL 是要六个月做完,XL 是三个月,L 是一个月,M 是两周,S 是一周。这样两边一对。如果说业务影响力比较高,而且技术实施比较轻,这就是小而美,那就是最高优先级;如果是反过来,技术这边要花好大的力气,业务影响力又不是特别高,那就坚定不移地把它砍掉;如果两个都是中等,那就是自由行事;如果两个都是 XXL 的话,那能不能需求这边降低一个维度。比如将 XXL 降到 XL,我这边可以降好几个档次,两三个星期就可以实现出来,这样可能会是一个比较好的方式。
产品愿景是用户故事的统摄
产品愿景要回答三个问题:
- Who:它的用户是谁?
- What:它是什么?一是要有清晰的画面感,二是与已有产品不同。
- Why:它意味着什么?有什么价值和目的?
两个产品愿景的例子:
- 我们要在10年的时间里,把一个人送到月亮上,还要让他回来。
- 把1000首歌装在口袋里。
产品愿景可以从最初的一个点子开始,慢慢打磨成熟。而在产品愿景打磨的过程中,把大而模糊的点子敲碎成清晰而可执行的小块,就是用户故事。产品愿景与用户故事同生同长,用户故事全部做完了,产品愿景就实现了。
用户建模,是用户故事的起点
用户建模可以考虑用户的两点:
- Pain 痛点:用户在产品目标领域目前有什么痛点?
- Gain 收益点:我们的产品能给用户带来什么收益?
用户角色建模,要以用户为中心。建模的 BSCR 步骤:
- Brainstorm:产品探索团队头脑风暴出用户角色。
- Sort:对头脑风暴出的用户角色快速分组和识别层级。
- Consolidate:对每一角色逐一讨论,整合角色。
- Refine:提炼角色。识别用户角色的:
用户角色分组可以考虑用户的:
- 使用频次
- 领域知识
- IT 知识
- 使用目标
用户建模的其他技术:
- 典型用户画像。针对一种角色,虚构出一个人物,描述他的行为特征,使用场景,核心诉求。还可以给出画像。打印出来放在团队可见的地方,让团队在开发产品时对用户的需求能感同身受。
- 极端用户。想象一个极端用户会有什么诉求,以产生新的灵感。这方面不用太用力。
用户故事
用户故事是从用户的角度描述功能。
用户故事的 WWW 及格式
- Who:谁要使用这个功能?
- What:需要完成什么样的功能?
- Why:这个功能带来的价值是什么?
用户故事的格式
- 英文:As < a user > ,I want < to do something >, so that < I can achieve some purpose >.
- 中文:作为 < 一个用户 >,我想要 < 做什么 >,以便 < 达成什么目的 >。
例子:
作为一个求职者,我想要发布简历,以便用人单位找到我。
现存世界上第一张用户故事卡,from @张克强。
用户故事的 AC(Acceptance Criteria)验收标准
- 验收标准也是迭代结束时 Demo 的标准
- 更多代表外部质量
- 简洁与完备之间平衡
- 包含成功路径和失败路径
对前述故事的验收标准例子:
- 我想要发布 Word 简历
- 我想要发布 PDF 简历
- 发前能预览
- 发后能检查
- 可以设置公开或私密状态
- 失败有原因提示
搜集故事的方式
- 用户访谈:不设定立场,问开放式问题和背景无关问题。
- 问卷调查:问卷可简单直接,比如了解用户使用软件功能的频率。
- 直接观察用户如何使用产品。
- 产品探索团队使用故事编写工作坊,头脑风暴,输出简单原型和用户故事。
用户故事的一些重要特征
- 一目了然格式一致的表达。
- 用户故事有两个部分:描述部分和验收标准。描述部分的常用格式是:As <用户>,I want <功能>,so that <目的>。验收标准可以有多条,常用的格式是:Given <前提条件>,When <动作>,Then <结果>。
- 鼓励推迟细节,只需有足够的信息以使项目前行。
我们不需要一次性把项目的所有需求搞清楚,我们只需要在迭代之前把一个迭代要做的事搞清楚即可,而以用户故事作为基本单元,可以支持这种开发模式。 - 用户故事以合适的颗粒度,方便理解,方便排优先级,保证重要的事先做。随着时间的推移,不重要的事也许就不需要了。
- 用户故事鼓励通过交谈了解细节。强调对话而不是书面沟通。
- 用户故事的验收标准保证成果可以被审核验证。
- 以用户故事为载体,促进结构化沟通,使谈话有落地点。
- 从业务角度描述,可以同时被业务人员和开发人员理解。
- 用户故事的大小适合估算和做计划。颗粒度适合迭代开发。
- 支持随机应变的开发,检视和适应。
- 鼓励各方参与交流,传播隐性知识。
用户故事的 3C,鼓励通过交谈了解细节
Card 卡片:用户故事通常写在卡片上,描述用户想要达到的目标,突出对用户有价值。
Conversation 对话:书面文档是一种低带宽沟通,表达信息的能力受限,接受信息的体验受限,信息传递能力受限。面对面交流是高宽带沟通,利用检验,适应和反馈促进沟通的有效性。用户故事模式鼓励对话。无形的对话为有形的卡片补充细节。
Confirmation 验收标准:无形的对话再次落实到有形的验收标准,并成为故事的一部分。
排优先级要考虑的要素
- 大部分用户对该功能的渴望程度。
- 少部分重要用户对该功能的渴望程度。
- 故事之间的关系,是否有开发的先后顺序。
- 技术实现的难度。
- 成本高低。
关于优先级的两个模型
MoSCoW 莫斯科定律:Must have 必须有;Should have 要有;Could have 可以有;Woudn’t have 不会有。
Kano 模型:没有不行的功能,线性功能,尖叫功能。
用户故事的 INVEST 准则
Independent:用户故事之间是独立的。如果不独立,可能是划分的方法有问题,可重新划分。
Negotiable:用户故事是可讨论的。使用卡片是为了提醒对话。讨论的细节会变成测试。
Valuable:用户故事对用户有价值。有条件的话,让用户写或确认用户故事。
Estimatable:用户故事是可估算的。不可估算的原因可能是:缺乏领域知识(多与客户讨论,学习对方的语言,了解对方的想法,事实往往比想象的简单),缺乏技术知识(可以把故事分为两部分:探针实验 spike,和实际开发),故事太大(分拆)。
Size appropriately:大小适中。故事的合适大小取决于团队,容量和使用的技术。
需要分割的故事,可能是复合故事(按 CRUD 分拆),或复杂故事(可以分探针实验 spike 和实际开发两个故事,与其他故事一起排排优先级,然后在不同的迭代完成探针实验 spike 和实际开发)。需要合并的故事,包括若干小 bug,或小改动。
- Testable:用户故事是可测试的。故事的描述需使用具体的量化的描述,而不是绝对的含糊的描述。
其中有价值和可估算是第一级标准,对应着本文开始时提到的产品开发所要回答的两个根本问题。另外四个标准更多是为了方便迭代开发。
用户故事的一些其他原则
- 从目标开始,大目标分解成小目标。
- 切蛋糕式划分故事,竖切而不是横切。
- 故事的描述要封闭,有完成感。故事针对一个场景,一个画面,一次完整的动作。
- 约束也可以作为一个故事。
- 故事的冰山法则:近期要开发的要划分的细而清晰,远期开发的可粗而模糊。
- 文档也可以作为故事。
- 故事中要包含用户角色,一个故事只包含一种用户。
- 为了表述简单,故事使用主动语态。
- 有可能的话,让用户编写故事。
- 故事不用编号。可提炼出作为标识的关键词以方便讨论时引用。
- 一定不要忘记故事的意图。
- 避免镀金,开发不需要的功能。团队公开透明的工作方式可以帮助这一点。
- 非功能需求可以作为故事。
- 缺陷可以作为故事。
故事分级
- Epic 史诗:一个很大的故事。
- Theme 主题:安放一组类似故事的篮子。
- Story 故事:业务角度。
- Task 任务:技术角度,一个故事可分解为多个任务。
用户故事分解
大故事拆成小故事,9种不同切分方法。
按工作流程步骤切分
是否可以先完成工作流程的头尾部分,再添加中间步骤去完善该故事呢?按操作切分
是否可以把不同操作切分成独立的故事呢?(比如是有关“管理”或“配置”某物)按不同业务规则切分
是否可以先完成业务规则的一个子集,后续再添加其他规则呢?(比如故事中有没有范围型词语像是“灵活的日期”来暗示着多种变化呢?)按不同类型数据切分
是否可以先处理一种类型的数据,后续再处理其他类型的数据呢?按实现先后依赖切分
该故事的实现背后是否依赖另一个流程的数据输入?按照体验质量切分
是否可以先完成一个低体验质量的故事,然后再提高体验水平?按不同界面切分
是否能先简化复杂界面,先完成一个简单版本?如果多个界面获取相同类型数据,是否可以先从一个界面处理数据,后续再增添其他界面呢?按简单/复杂切分
如果简单的核心就能提供大部分价值,是否可以先完成简单核心,再通过后续的故事来扩充它呢?延迟性能优化
是否可以先使其工作,后续再满足非功能性需求呢?(当复杂主要来自非功能性需求时)
绝对估算与相对估算
绝对估算:按天或小时。
相对估算:
- 按倍增数列:1,2,4,8,16,32,64
- 按斐波那契数列:1,2,3,5,8,13,20,40,100
- 按T恤衫尺寸:XS,S,M,L,XL
估算纸牌
- 产品负责人讲一个故事
- 团队提问澄清
- 团队成员独立出牌估算,互不干扰,喊统一翻牌时才翻牌
- 出到最小点数和最大点数的人讲讲话
- 其他人可参与对话
- 第二轮出牌
- 对同一个故事不超过三轮出牌
客户参与、产品探索和产品交付的全流程
第一,产品负责人收集需求。利用前文讲到的客户团队和需求收集方法。需求来自客户和干系人,也来自产品负责人的思考。需求以业务角度为主,也考虑技术角度。需产品负责人与技术领域的架构师等密切协作完成需求的梳理。
第二,产品探索团队利用故事写作研讨会对用户建模,编写用户故事,放入待办列表,排序,估算,制定发布计划。
好的故事估算方法
- 允许团队随着对产品了解的加深随时改变想法。
- 要能适用于史诗和小故事。 估算精度随故事变大而变小。
- 估算快速。
- 能帮助提供进度和剩余工作的有用信息。
- 要能做到不精确也没事。
- 可以用来制定发布计划。
- 团队集体估算。
- 故事估算的单位可采用故事点或者理想天。
具体的估算方法
- 产品负责人拿起一个故事,进行讲解,团队成员提问澄清。
- 团队成员用斐波那契序列的纸牌出牌估算,出到点数最大和最小的人说明,其他人可参与讨论。独立出牌估算,翻牌前不要把估算讲出来,也不要受他人估算的影响。
- 大多数故事的估算会在一到两轮出牌后收敛。最多也不要超过三轮出牌。
- 还可用冒泡分桶法进行快速估算。把故事按从小到大从左到友排成一排,从冒泡法排到大家都认可为止。然后分组分到不同的桶里。桶的大小排列也是斐波那契序列。
- 每个迭代能完成的故事点数是速率。速率是一个靠谱的指标的依据是:故事的估算值与实际大小的偏差呈正态分布。每个迭代选取的故事的正负偏移可以彼此抵消。因此故事估算的精度不会影响速率指标的可靠性。速率指标可靠的前提是:在项目过程中始终采用一致化的估算方法,迭代之间的故事没有交叉重叠,项目过程中没有发生影响速率的大的异常。
速率和估算的几个注意事项
- 不要拿速率来比团队。
- 分解后小故事估算的总合不一定等于大故事的估算。
- 任务工时的总和不需要跟故事点成正比。
- 结对编程不影响对故事的估算方法。
- 做到一半的故事不能计入速率。没有完全完成的事情是不靠谱的。鼓励一件流。迭代完成后不要修订速率。
- 发布计划的制定
- 选定迭代长度。
- 预测速率。
- 产品的总故事点除以速率,即得出需要多少个迭代完成。
速率预测可采用
- 历史值
- 执行一轮看看速率是多少
- 猜测
可视化发布计划的方法
- 墙
- 电子表格
- 甘特图
第三,与客户确认发布计划。
第四,与交付团队梳理故事,达到准备好的状态(DoR - Definition of Ready)。故事要有清晰的验收标准,优先级和估算。团队成员有充分的理解。
第五,迭代计划,分解任务,生成迭代待办列表。
- 在迭代计划会上
- 选取本迭代要完成的故事。
- 把业务故事分解为技术任务。分解也是做设计。不能技能的人员可以在同一个故事中合作。
- 团队做出承诺。
第六,每日工作,按故事和任务的优先级执行。
- 测量和监控速率的方法
- 迭代故事点燃尽图。
- 迭代工时燃机图。
- 每迭代计划速率和实际速率趋势图。
- 每迭代计划和实际速率累计图。
这些图表只是团队监测趋势的工具。团队要在每天的工作中检视和适应以保证能达到完成迭代目标的趋势。
第七,迭代验收和演示。最好能有客户参与,以获得反馈。
在 Scrum 中,用户故事运转在两条轨道上。一条是产品级别的产品列表精化,既帮助产品的长远规划,也为迭代的开始做好准备。另一条是迭代级别,故事经过精化准备好之后,经由迭代计划会进入迭代,经由每一天的检查与适应,在迭代评审会议上展现为产品增量和可工作的软件,在经过迭代回顾会议探讨下一个迭代如何做得更好。