软件开发平台 DevCloud软件开发平台 DevCloud

计算
弹性云服务器 ECS
裸金属服务器 BMS
云手机 CPH
专属主机 DeH
弹性伸缩 AS
镜像服务 IMS
函数工作流 FunctionGraph
云耀云服务器 HECS
VR云渲游平台 CVR
特惠算力专区
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
弹性文件服务 SFS
存储容灾服务 SDRS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属企业存储服务
云存储网关 CSG
专属分布式存储服务 DSS
CDN与智能边缘
内容分发网络 CDN
智能边缘云 IEC
智能边缘小站 IES
智能边缘平台 IEF
人工智能
AI开发平台ModelArts
华为HiLens
图引擎服务 GES
图像识别 Image
文字识别 OCR
自然语言处理 NLP
内容审核 Moderation
图像搜索 ImageSearch
医疗智能体 EIHealth
园区智能体 CampusGo
企业级AI应用开发专业套件 ModelArts Pro
人脸识别服务 FRS
对话机器人服务 CBS
视频分析服务 VAS
语音交互服务 SIS
知识图谱 KG
人证核身服务 IVS
IoT物联网
设备接入 IoTDA
设备管理 IoTDM(联通用户专用)
全球SIM联接 GSL
IoT开发者服务
IoT数据分析
车联网服务 IoV
路网数字化服务 DRIS
IoT边缘 IoTEdge
设备发放 IoTDP
开发与运维
软件开发平台 DevCloud
项目管理 ProjectMan
代码托管 CodeHub
流水线 CloudPipeline
代码检查 CodeCheck
编译构建 CloudBuild
部署 CloudDeploy
云测 CloudTest
发布 CloudRelease
移动应用测试 MobileAPPTest
CloudIDE
Classroom
开源镜像站 Mirrors
应用魔方 AppCube
云性能测试服务 CPTS
应用管理与运维平台 ServiceStage
云应用引擎 CAE
视频
实时音视频 SparkRTC
视频直播 Live
视频点播 VOD
媒体处理 MPC
视频接入服务 VIS
管理与监管
统一身份认证服务 IAM
消息通知服务 SMN
云监控服务 CES
应用运维管理 AOM
应用性能管理 APM
云日志服务 LTS
云审计服务 CTS
标签管理服务 TMS
资源管理服务 RMS
应用身份管理服务 OneAccess
区块链
区块链服务 BCS
可信跨链服务 TCS
智能协作
IdeaHub
开发者工具
SDK开发指南
API签名指南
DevStar
HCloud CLI
Terraform
Ansible
API问题定位指导
云生态
云市场
合作伙伴中心
华为云培训中心
其他
管理控制台
消息中心
产品价格详情
系统权限
我的凭证
客户关联华为云合作伙伴须知
公共问题
宽限期保留期
奖励推广计划
活动
容器
云容器引擎 CCE
云容器实例 CCI
容器镜像服务 SWR
应用编排服务 AOS
多云容器平台 MCP
基因容器 GCS
容器洞察引擎 CIE
云原生服务中心 OSC
容器批量计算 BCE
容器交付流水线 ContainerOps
应用服务网格 ASM
网络
虚拟私有云 VPC
弹性公网IP EIP
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
虚拟专用网络 VPN
云连接 CC
VPC终端节点 VPCEP
数据库
云数据库 RDS
数据复制服务 DRS
文档数据库服务 DDS
分布式数据库中间件 DDM
云数据库 GaussDB (for openGauss)
云数据库 GaussDB(for MySQL)
云数据库 GaussDB NoSQL
数据管理服务 DAS
数据库和应用迁移 UGO
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
可信智能计算服务 TICS
推荐系统 RES
云搜索服务 CSS
数据可视化 DLV
数据湖治理中心 DGC
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
应用中间件
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
API网关 APIG
分布式缓存服务 DCS
分布式消息服务RocketMQ版
企业应用
域名注册服务 Domains
云解析服务 DNS
云速建站 CloudSite
网站备案
华为云WeLink
会议
隐私保护通话 PrivateNumber
语音通话 VoiceCall
消息&短信 MSGSMS
云管理网络
SD-WAN 云服务
边缘数据中心管理 EDCM
云桌面 Workspace
应用与数据集成平台 ROMA Connect
ROMA资产中心 ROMAExchange
API全生命周期管理 ROMA API
安全与合规
安全技术与应用
DDoS防护 ADS
Web应用防火墙 WAF
云防火墙 CFW
应用信任中心 ATC
企业主机安全 HSS
容器安全服务 CGS
云堡垒机 CBH
数据库安全服务 DBSS
数据加密服务 DEW
数据安全中心 DSC
云证书管理服务 CCM
SSL证书管理 SCM
漏洞扫描服务 VSS
态势感知 SA
威胁检测服务 MTD
管理检测与响应 MDR
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
专属云
专属计算集群 DCC
解决方案
高性能计算 HPC
SAP
游戏云
混合云灾备
华为工业云平台 IMC
价格
成本优化最佳实践
专属云商业逻辑
用户服务
帐号中心
费用中心
成本中心
资源中心
企业管理
工单管理
客户运营能力
国际站常见问题
支持计划
专业服务
合作伙伴支持计划
更新时间:2021-09-24 GMT+08:00
分享

用户故事地图

《用户故事地图》这本书的原作者是一位独立顾问,讲师和敏捷教练,他所提出的用户故事地图的方法主要用于解决敏捷需求分析过程中的问题:

  • 只见树木不见林,重要的待办项容易淹没在各种细节中看不到全貌,因而难以排列优先级。
  • 不能明显地聚焦于用户需求。
  • 很难了解不同粒度故事(史诗故事、主题故事以及故事)之间的关系。
  • 不能方便地了解系统提供的功能的完整性。
  • 不能方便地了解系统提供的工作流以及价值流。
  • 不能方便地利用递增和迭代的方式去确定发布计划以及发布目标。

当开始进行一个产品或者项目规划的时候,首先需要梳理出一个backlog,在其中按照优先级列出所要实现的场景和具体功能。这时我们首先遇到的一个问题就是:如何确保backlog覆盖了最重要的用户体验路径,是否我们当前所规划的场景确实可以为用户提供价值?这点对于敏捷开发非常重要。

在精益中有MVP(Minimum Viable Product,最小化可用产品)的概念。MVP的目的是以最小的投入发布对用户有价值的产品,快速试错,并通过不停的迭代最终找到产品的正确方向。

这个思路很好,但如何确认backlog中的内容是“最小的”而且“可用”的产品却是件很困难的事情。

团队一起讨论初始产品需求的时候,常常会因为团队成员的理解不同而花费大量的时间进行梳理。即使每次讨论都将结果用文档记录下来,大家仍然缺乏对产品的总体认识,这就是所说的“只见树木不见林”的状态。因为,缺乏一种将用户故事可视化的方法。

用户故事可视化——起床故事

讨论一个最简单的场景:早上起床出门,作为第一个用户故事地图。

每个人都非常熟悉这个场景,但是当我们开始讨论的时候,有两个问题开始浮现:

  1. 每个人习惯不同,如何统一我们的故事?
  2. 从起床到出门要经历几个不同的阶段,到底应该如何确定阶段?

第一个问题其实是“用户故事”要解决的首要问题:这个场景的角色(Person)是谁?

第二个问题其实就是确认需求粒度的过程。

在敏捷需求分析过程中,对Person的确认非常关键,如何统一思路并让大家可以在讨论某个场景的时候可以聚焦到特定的Person上,是经常遇到的问题。讨论中经常会跑题:原本在谈Person A,结果讨论到另外一个Person B了。

在讨论中,首先将Person的定义通过卡片贴在时间线的左侧,这个很小的动作,却让团队的成员可以非常专注于当前Person的场景讨论,效率很高。

粒度方面,经常有人问Backlog Item的粒度如何确定?过去的回答是,从实现的角度来考虑,比如:控制在2-3天的工作量上。其实这是个非常不靠谱的建议,因为在讨论需求的过程中还无法确认是否要做,更谈不上评估工作量。

这就暴露了Scrum的一个最主要的问题,Backlog解决的是在Story确认以后如何进行开发过程规划的问题,而对Story该如何产生、如何设计的问题,并没有给出很好的解决办法。我们往往把Story当成需求来看,而实际上敏捷使用Story来描述需求的目的是为了协助团队进行讨论,以便最终确认需求(也就是Specification)。

用户故事地图的作用就是将User Story的简单描述:As a .... I want to ... so that ...,用可视化的方式展现在团队面前,让团队可以仔细梳理、讨论、确认这个Story包含的内容,最终产出Specification进行开发。

用户故事地图的结构

每个用户故事地图代表一个完整的用户故事:

  • 地图的核心是一条从左到右的时间线。
  • 时间线的上部放置最大粒度的内容(可以理解为Epic)。
  • 时间线的下部的第一行放置二级粒度内容(可以理解为Backlog Item),并在每个一级粒度下按照从左到右的优先级进行放置。
  • 每个二级粒度内容的下面,自上而下放置三级粒度内容(可以理解为Task)。

最终绘制出来一个完整的端到端的用户故事。

这样的用户故事地图构建体验中,很强烈感受的是:大家专注、目标明确,讨论完成的故事非常完整。

创建用户故事地图(User Story Mapping)的8个步骤

  1. 召集到3-5名对产品非常熟悉的人员参与。3-5人听上去像是个魔法数字,实际上是的。因为更少的人意味着你无法获得足够的建议,而更多人则会因为讨论和协调降低会议效率。
  2. 使用静默头脑风暴模式,让每个人在便签纸上写下自己认为重要的“所要做的事情”,也就是用户任务(User Tasks)。每个人都用同样颜色的便签来书写自己的用户任务描述,这个阶段不要互相讨论。一旦大家都基本完成了准备,让每个人轮流大声读出自己的内容,并把便签纸全部放置在桌面上。这时如果出现重复的内容就可以省略掉:
    1. 根据产品规模,这个过程可能需要3-10分钟的时间,你可以观察大家的行为来判断是否需要停止。
    2. 基本上每张便签都会以一个动词开头,如:发送邮件、创建联系人、添加用户等。
    3. 这些便签组成了一级用户故事,也称为用户任务(User Tasks),它们组成了用户故事地图上的 "行走的骨骼" (The walking skeleton)部分。
    4. 这时可以提示参与者:我们只用了很少的时间就完成了需求的收集过程,而且有些内容你可能没有想到,而其他人帮你想到了。
  3. 然后,让大家将桌面上所有的便签进行分组,将类似的任务分为一组,其它的类似:
    1. 这个过程最好也采用静默模式进行,因为这样做会更快。如果发现重复的内容,就略过。
    2. 基本上分组会很容易完成。
    3. 这时同样观察每个人的行为,判断大家是否已经做完,基本上这个过程需要2-5分钟。
  4. 选择另外一个颜色的便签,对每个组进行命名,并贴在每组便签的上部。
  5. 对这些分好组的便签进行排序,一般按照用户完成操作的顺序,从左到右摆放:
    1. 如果大家无法决定顺序,那么顺序可能没有那么重要(明显)。
    2. 这一组便签,Jeff Patton称为用户活动 (User Activities)
    3. 这时你的地图应该类似于:

      A1

      A2

      A3

      用户活动

      T1,T2,T3

      T4,T5,T6

      T7,T8,T9

      用户任务

  6. 现在,按照 "行走的骨骼" 用户行为这行开始讲述用户故事,确保你没有遗漏任何用户行为和用户任务。这时一般由组织者进行讲述,其他人提出意见,甚至可以让最终用户来参与讨论。
  7. 这时,我们已经完成了用户故事地图的基本框架,可以在每个用户任务下面添加更加细节的用户故事(User Stories)了。此时仍然建议使用静默头脑风暴的模式来进行第一轮用户故事的产生,同时借助如Persona和Scenario等方式协助完成这个过程。一旦你完成了用户故事的创建,就可以开始划定发布计划(Releases)了:
    1. 一般在第一个发布中只选择每个用户任务的2-3个用户故事,这对于帮助大家排定优先级和范围将很有帮助。
    2. 基本上不必使用用户故事的标准句法(As a ...)来书写这些故事,因为每张便签都处于地图的特定位置,很容易识别其所处的场景和角色。
  8. 最后,针对第一个发布的所有用户故事进行分解,确保我们的第一个发布越小越好,基本上需要保证在1-2个迭代后就可以发布产品的第一个版本。

用户故事地图规范

  • 第2个步骤中的便签表示用户任务(User Tasks),也就是下图中的绿色便签。
  • 第3-4个步骤中的便签表示用户行为(User Activies),也就是下图中的黄色便签。

Jeff称这两行的内容为 “行走的骨骼(walking skeleton)”和“主干(backbone)”。

  • 用户故事(User Stories),也就是黄色便签在每个用户任务下自上而下排列,便于我们确定优先级

一般来说用户会按照从左到右的顺序来使用你的系统(用户故事地图)。

用户故事地图样例

下图是一个蛋糕制作及心得分享系统的用户故事地图:

第三行所包含的内容就是“大家在电子邮件系统所要做的事情”,包括:注册、配置信息、发布、下单、支付等。

第二行对这些事情进行了分组。

与一般用户故事地图不同的是,这张图当中增加了第一行的角色划分,以使整个流程更加清晰明了。

黄色的便签的第一行包含了最小化的用户故事,如:“蛋糕小白”的注册只包括手机注册和验证码登录,其他如微信绑定则不在此行,放入更靠下的便签中。

在黄色便签上,可以贴上更小的蓝色和橘黄色便签,以表示不同的状态,比如:蓝色代表完成,橘黄色代表进行中(WIP),这样你就可以看到项目的进展。

现在如果我们专注于从左到右完成第一行的黄色便签,就可以确保很快发布一款包含了最基本功能的蛋糕制作及心得分享系统,这样就可以验证我们的系统整体架构可行。同时也可以帮助我们对系统的功能进行端到端的测试,确保我们可以从用户处获取到反馈,知道我们是否解决了它们的问题(提供了商业价值)。注意:在第一行没有包含“心得分享”这一功能,因为并不一定要完成所有用户任务的开发。

分享:

    相关文档

    相关产品

关闭导读