限时领|《AI 百问百答》专栏课+实体书(包邮)! 了解详情
写点什么

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

  • 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:092854
用户头像

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

关注

评论

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

虚拟人,如何用好这个“外挂”?一定要看看这本书!

博文视点Broadview

探索高质量大模型训练平台建设路径——大模型训练标准第三次研讨会顺利召开

中国信通院AI Infra工作组

华为全联接大会2024︱鲲鹏计算产业峰会成功举办

极客天地

云南大理等级保护测评机构在哪里?电话多少?

行云管家

等保 云南

云栖大会Day1:云应用开发平台 CAP 来了

阿里巴巴云原生

阿里云 云原生 云栖大会

中国人工智能产业发展联盟正式发布《科研智能(AI4R&D)——人工智能驱动的研发新范式》

中国信通院AI Infra工作组

一文说清楚ETL与Kafka如何实现集成

RestCloud

kafka 数据处理 分析 ETL 数据集成

活动预告:“大模型时代下AI中台”主题沙龙

中国信通院AI Infra工作组

“前沿思享会:探索AI+材料新边界”闭门研讨会顺利召开

中国信通院AI Infra工作组

《科研智能(AI4R&D)——人工智能驱动的研发新范式》正式发布

中国信通院AI Infra工作组

海尔连续3年蝉联生态品牌认证“领航者”,飞书获评“突破者” ,共建生态绿洲

ToB行业头条

可信AI评估|中国信通院可信AI“大模型一体机”第二批评估正式启动

中国信通院AI Infra工作组

京东商品属性的详细api数据解析:颜色、尺寸与材质

技术冰糖葫芦

API Gateway API 接口 API 测试 pinduoduo API

Amazon Bedrock 模型微调实践(二):数据准备篇

亚马逊云科技 (Amazon Web Services)

人工智能

中国信通院可信人工智能基础平台(AI Infra)评估工作正式启动

中国信通院AI Infra工作组

中国信通院边缘人工智能平台标准首轮评估正式启动

中国信通院AI Infra工作组

阿里巴巴拍立淘API返回值:商家优化商品信息的深度指南

代码忍者

API 测试 pinduoduo API

AI助力低代码平台:从智能化到高效交付的全新变革

天津汇柏科技有限公司

低代码 AI 人工智能

LED厂家告诉您LED玻璃幕墙如何设计

Dylan

设计 艺术 LED LED display LED显示屏

Apache Doris 2.1.6 版本正式发布

SelectDB

数据仓库 数据分析 LakeHouse 物化视图

【Tomcat源码分析】从零开始理解 HTTP 请求处理 (第一篇)

派大星

tomcat源码解读

VMware Live Site Recovery 9.0.2 发布下载,新增功能概览

sysin

vmware esxi

万界星空科技电线电缆行业MES系统核心功能

万界星空科技

mes 万界星空科技 电线电缆行业 电线电缆mes

助力企业降低成本,ByteHouse打造新一代“弹性”云数仓

字节跳动数据平台

数据库 大数据 云原生 Clickhouse 数仓

大模型训练平台标准第三次研讨会即将召开

中国信通院AI Infra工作组

中国信通院启动科研智能(AI4R&D)重点标准化方向及参编专家征集工作

中国信通院AI Infra工作组

探索高质量大模型推理平台建设路径——大模型推理标准第二次研讨会即将召开

中国信通院AI Infra工作组

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