写点什么

具有流程图和故事图的产品待办事项列表

  • 2013-05-30
  • 本文字数:2015 字

    阅读完需:约 7 分钟

组织一份产品待办事项列表(backlog)有助于保持对用户故事的概观并放眼大局。Shrikant Vashishtha 撰写的一篇题为《故事映射与流程图》的博文,描绘了如何将用户故事映射到流程图。他对比了用于组织用户故事的流程映射方法,以及来自 Jeff Patton 的故事映射。

在 Scrum 中,产品待办事项列表用于管理产品需求。对大型产品而言,待办事项列表中也许会有许多用户故事,以至于很难保持概观并放眼大局。同样,如果有太多用户故事,团队的 Sprint 待办事项列表也会面临相似的问题:

(……)很多时候,人们看向卡片墙(Scrum 板)时会发现并不是很有头绪。或许,卡片墙看上去就像是一张由不同状态的用户故事织就的网,这些状态包括:待办、进行中或已完成。然而仅仅通过查看用户故事无法明确地回答某些更大的问题。

Shrikant 建议进行流程映射以组织产品待办事项列表,并将用户故事视觉化:

将完整的业务流以流程图的形式进行形象化展示,以识别其中的用户故事(需要完成的工作),这个办法怎么样?

流程图涉及了用于实现部分流程的用户故事的 ID。查看流程图可以看到业务流需要哪些用户故事,而使用彩色可以展现出业务流的进展。

组织大型产品待办事项列表的另一个方法是故事映射,Jeff Patton 在 2008 年发表的文章《新的用户故事待办事项列表采用图的形式》中对此进行了描绘:

按将要构建的顺序安排用户故事无法帮助我向其他人解释系统的用途。当利益相关者或用户提出“你正在构建的系统有什么用途”的问题时,可以试着向他们提供用户故事待办事项列表。在我看来,尝试理解系统——整个系统——是软件开发的困难所在。我从敏捷团队听到的最常见抱怨之一,是他们失去了全局视野——如果他们最初曾经拥有过的话。

Jeff 解释了故事映射如何辅助沟全局视野:

我发现,挂起来用作信息辐射体的故事图成为对正在构建的产品进行的讨论中的不动点。随着项目运行,它成了我们的 Sprint 或迭代的计划板。我们直接在图上识别或划分出下个迭代周期中将要构建的故事。在迭代过程中,我们将正在处理的故事单独放到一面任务墙上以管理它们的开发——但故事图还留在计划墙上以提醒我们全局视野中都有什么,以及我们已经完成了多少。

此前 InfoQ 在《故事图为用户故事提供上下文》中撰写了故事映射如何帮助组织产品待办事项列表

故事图是二维的,它既能显示故事的优先级,又能表示故事之间的关系,还有用户的更为长远的目标。它帮助团队理解这些故事如何组合在一起形成发布的产品。

在《故事映射与流程图及其对比》中描述了流程映射如何工作之后,Shrikant Vashishtha 继续在博客文章中对比了流程映射与故事映射。他讲述了使用故事映射的产品待办事项列表看上去是什么样子的:

故事映射的理念是以这样的方式准备产品待办事项列表:“大故事”(称为“用户活动”、叙事诗或特征等等)位于图的顶部。这些“大故事”被进一步分割为用户任务(由某些人为了实现目标而做的某些事)。

Shrikant 也列出了使用故事图的一些缺点:

故事图是很好的信息辐射体。然而它们也许需要很大空间以捕获整个发行产品的故事。此外,故事映射并不一定要提供这样的信息:有关故事之间的连接,或是如何将叙事诗 / 用户故事编配到一起以实现业务目标。

在难以使用故事图保持概观之处,Shrikant 建议使用流程图以获得帮助,因为流程图并不展现全部细节:

我们可以使用内嵌了用户故事标识的流程图的大幅海报,而不是将所有的故事都放到板上。流程图本身也是个故事,而且它能够帮助人们达成一致意见。

他认为可以同时使用流程图和故事图以组织大型产品待办事项列表,并以此作为总结:

(……)看起来流程图和故事图是用于解决相同问题的完全不同的概念,但实际上并非如此。这两种工具都能够让板上的内容更清晰。它们可以基于上下文互相补足。

在题为《用户故事映射——目标驱动待办事项列表开发》的博客文章中,Scott Sehlhorst 给出了故事映射的概览。首先他介绍了故事映射的目的:

用户故事映射是一种用于确保每个发布或迭代都使产品明显变得更好的工具。(……)用户故事映射推动我们明确地理解用户在解决问题时遵循或将要遵循的流程,以及这些用户达成目标所依赖的价值链或工作流。

Scott 解释了如何完成故事映射,以及它能够带来哪些好处:

借助用户故事映射,我们可以将用户故事或用户执行的任务以分组形式组织,以识别哪些故事对传递价值而言是共同需要的。这是一个用于评估需求 _ 完整性 _ 的强大技术。同时它也是保证每个发布或迭代都有价值增量的工具,价值增量来自让用户解决或更有效地解决问题——避免某次交付只解决了一半问题。

你如何使用故事图或流程图组织自己的产品待办事项列表?它们是否帮助你保持概观并放眼大局?

查看英文原文: Product Backlogs with Process Maps or Story Maps


感谢李彬对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2013-05-30 09:092554
用户头像

发布了 256 篇内容, 共 74.9 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

支持多套对象存储,冷热数据分层又添新功能

焱融科技

分布式 云原生 高性能 文件存储 技术博客

绍兴柯桥淘宝拼多多电商培训到哪里?兴德

Geek_196d9f

Bzz算力挖矿系统开发节点部署

薇電13242772558

数字货币 算力

绍兴柯桥PS培训到哪里?怎么修图?兴德

Geek_196d9f

绍兴柯桥平面设计培训到哪里?兴德

Geek_196d9f

签了!百度智能云携手浙江广播电视集团共推媒体数智化转型

百度大脑

媒体 百度智能云

智能量化网格策略交易机器人,马丁倍投机器人

绍兴柯桥数码印花金昌描稿调色分色培训到哪里?兴德

Geek_196d9f

绍兴柯桥插花花艺培训到哪里?兴德

Geek_196d9f

绍兴柯桥JAVA,web前端编程培训到哪里?兴德

Geek_196d9f

IDC数据中心介绍

大数据技术指南

数据中心 5月日更

聊聊业务数据分析那些事儿

小飞象@木木自由

数据分析 业务场景分析 业务数据分析 业务分析

绍兴柯桥服装设计培训到哪里?兴德

Geek_196d9f

绍兴柯桥电脑办公培训到哪里?兴德

Geek_196d9f

绍兴柯桥视频剪辑影视后期PR,AE培训到哪里?兴德

Geek_196d9f

Leveldb解析之五:理解leveldb的持久化和MVCC实现机制

Jowin

leveldb

低代码核心优势是:降本增效+多系统集成,这真的对吗?

优秀

低代码

KubeSphere+QKE 轻松实现容器多集群管理

青云技术社区

容器 k8s 开发工具

五种网络IO模型详解

Linux服务器开发

后端 epoll Linux服务器开发 网络io 网络模型

绍兴柯桥CAD制图培训到哪里?兴德!

Geek_196d9f

人生算法:内控控制点

石云升

读书笔记 思维模型 5月日更

绍兴柯桥学历提升培训到哪里?兴德

Geek_196d9f

千万级学生管理系统考试试卷存储方案

chenmin

Kubernetes 稳定性保障手册:洞察+预案

阿里巴巴云原生

数据库 容器 云原生 k8s 监控

并发王者课 - 青铜4:synchronized用法初体验

MetaThoughts

Java 多线程 并发 并发王者课

绍兴柯桥淘宝美工培训到哪里?兴德

Geek_196d9f

绍兴柯桥室内设计培训到哪里?兴德

Geek_196d9f

绍兴柯桥摄影摄像培训到哪里?兴德!

Geek_196d9f

最详细的 Python 结合 RFM 模型实现用户分层实操案例!

JackTian

Python 编程 程序员 数据分析 RFM模型

绍兴柯桥会计实操培训到哪里?兴德

Geek_196d9f

绍兴柯桥3Dmax效果图培训到哪里?兴德

Geek_196d9f

具有流程图和故事图的产品待办事项列表_文化 & 方法_Ben Linders_InfoQ精选文章