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

组织一份产品待办事项列表（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）关注我们，并与我们的编辑和其他读者朋友交流。