管理涉及多个渠道的史诗故事

如果产品是依赖于不同渠道的多个团队，如何管理和跟踪史诗故事【译注 1】？Sntio LLC 的联合创始人 Keren Deer 在她最近的文章里讨论了如何管理涉及多个渠道的史诗故事。

Keren 提到一个项目例子，其产品负责人管理多个工作流、工程团队和零售执行团队，各自有不同的工作流程、期限和周期，需要考虑各自的利益相关者的想法、反馈和认可。

开发涉及多个渠道的产品是一件很有挑战性的事情。然而，在一个通过云计算而日益网络化的世界里，为你的客户提供他们所期望的产品——无论是在手机上、平板电脑、可穿戴设备或其它设备，这是非常关键的。

Keren 提到了一些用于管理这些情况的策略，如

• 在史诗故事级别获取尽可能多的细节，获得其全貌。收集更多的信息，有助于避免不同渠道的重复。
• 为依赖做计划。如果有多个团队在协同工作，你要确保把各团队的待办事项列表安排好，以配合各个团队之间的依赖关系。
• 以消除或减少故事队列为优先考量。多个团队协同工作的时候，常常难以把所有功能都完成。也许一个团队可能会进度正常，但其它团队则被别的事情拖住。这个时刻你必须做出艰难的决定。数据和市场调研可以帮助你做权衡取舍。

Jira Agile 6.3 提供了管理涉及多个项目的史诗故事的功能。 Atlassian 的资深敏捷传道士 Dan Radigan 在其一篇名为《用 JIRA Agile 做项目组合管理》的文章里阐述了这个场景。

你的史诗故事是否在牵涉到多个 JIRA 项目的时候遇到问题？如果是的话，项目经理应该有一块“影子”Scrum 板【译注 2】，采用与项目的看板一致的 JQL 语句【译注 3】。这块 Scrum 板包含来自于各个项目的问题，用于做史诗故事状态报告。如果你不使用影子 Scrum 板，而是团队的 Scrum 板，那么信息将被限制在一个项目之内，你无法从史诗报告中获得其它项目的问题信息。

还有一些其它工具同样可提供在多个 Scrum 板之间管理史诗故事的功能。一个 Scrum 板可以专用于一个工作流。 YouTrack 是一个这样的工具，团队可以用它创建一个与所有项目相关联的史诗故事，看板将与这个史诗关联在一起。团队也可以为所有的史诗故事创建一个看板，并按照其问题类别设定信息泳道。JetBrains 的技术作家 Ekaterina Ivanova 在她的名为《多级敏捷看板或我们如何支持史诗》的文章里阐述了通过在YouTrack 里为史诗故事设定泳道的方式，使其在管理者的看板中得到最高级别的关注度。

GE Software 的敏捷领袖 Tom Looy 谈到了在多团队项目中规模化敏捷开发的“长城”。

长城是一面现实世界中的墙，团队将解决方案的用户体验地图贴在墙上。最开始的时候地图是以顾客的视角来组织的，按照从左向右的顺序以用户故事的形式讲述顾客的故事。随后用户故事将按照其优先级在地图上分层，每层都可以是一个 MVP（最小化可行产品）。这些层对应于产品的各个发布计划。

布置一个长城，一个物理可见的用户故事地图，把它当做项目状态工具来使用，并把它放在一个显眼的地方，让所有团队都可以访问到，这是一个很棒的用于优化交付的实践，同时也可以将其用做 Tom 所提到的组织状态和管理工具。

【译注】

1. 史诗故事（Epic）是非常大的用户故事，需要被分解为一系列足够小的用户故事才能进入开发团队的 Backlog 中。通常史诗故事与功能 / 特性（Feature）在规模上是等价的。
2. Scrum 板是 Scrum 与看板的结合。Dan 的文章主要讨论在 JIRA 里如何应用 SAFe 等规模化敏捷开发框架，而这些框架都是以 Scrum 为团队工作的基础，用看板做可视化管理。
3. JQL（JIRA Query Language) 是与 SQL 很相似的、用于 JIRA 数据查询的一套语法。使用 JIRA 时，项目经理往往通过 JQL 定制化看板上的数据内容。

查看英文原文： Managing Epics Across Multiple Channels

感谢曹知渊对本文的审校。

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