使用 Mind Map Studio 直观规划下一次 Jira 发布

即使 Jira 发布中的事项列表井然有序，团队仍然可能有许多疑问。

这次发布会为客户带来哪些变化？哪些工作属于同一组？上线前应该测试什么？开发完成后，还需要做什么才能将所有内容部署到生产环境？

事项列表是这些讨论的起点。思维导图提供了另一种梳理方式：将相关工作归为一组，把规划问题放在相关区域旁边，并与团队一起审视发布范围。

本指南将以一个准备发布客户门户的虚构团队为例。我们会使用 Mind Map Studio 将此次发布的 Jira 事项添加到导图，梳理范围，并建立共享发布操作清单。

你也可以将相同方法用于下一次发布，从几个事项和一份简短清单开始。

从 Jira 中即将发布的版本开始

示例团队正在准备一次客户门户更新，涉及三个工作领域：

• 登录：让密码重置说明更清晰，并改进链接过期提示。
• 通知：新增电子邮件偏好设置，并修复重复通知问题。
• 账单：纠正发票上显示的账单地址。

团队已在 Jira 中创建了一个尚未发布的版本，并通过“Fix versions”字段分配了相关事项。

这项准备很重要。Mind Map Studio 的“Jira releases”面板列出当前 Jira 项目的版本及其已发布或未发布状态，并允许查看已分配的事项。先在 Jira 中创建版本并管理事项分配，再使用此面板围绕这些工作进行规划。

要完成本指南中的操作，你需要拥有查看项目及其事项的权限，以及一张可以编辑的思维导图。

打开导图，在顶部选择“Jira releases”，然后找到要讨论的未发布版本。其中的“Attached issues”区域会显示 Jira 中已分配给该版本的工作。

如果发布版本没有关联事项，请检查你预期会出现的事项中的“Fix versions”字段。空版本也可以拥有操作清单，但暂时没有已分配的事项可添加到导图。

为发布建立便于团队讨论的结构

先创建一个能够清楚说明发布内容的中心主题：

客户门户——十月发布

在其下方添加三个分支：

• 登录和账户访问
• 通知偏好设置
• 账单准确性

这些分支以便于团队与支持、产品和工程同事讨论的方式描述变化。

选择适合此次发布的分组方式。面向客户的变化可以按用户体验的不同部分划分。基础设施发布可能更适合按服务或系统评审。较小的发布可能只需要两个分支。

一个实用的问题是：这样的结构能帮助别人解释我们要交付什么吗？

在客户门户示例中，将密码重置事项放在一起，可以清楚呈现它们的共同目标。将通知相关变更放在一起，则便于团队结合重复邮件修复来讨论新的偏好设置控件。

放大

将已分配的 Jira 事项添加到导图

选择应该放置该事项的分支。在“Jira releases”面板的“Attached issues”下找到事项，将鼠标悬停其上，再选择加号按钮。

Mind Map Studio 会添加一张包含 Jira 事项键和摘要的子卡片。你也可以将事项从发布面板拖到画布上，放在目标父主题附近。

对其他事项重复此操作，直到发布形成有用的可视化结构。

将事项添加到导图只会改变导图。它不会修改事项的“Fix versions”、编辑事项或创建 Jira 事项链接。因此，这些可视化分组能够服务于发布讨论，而不会改变 Jira 中的工作分配。

使用导图评审发布范围

安排好事项后，与团队一起浏览导图。

先问一个简单的问题：

这里是否展示了我们预期要交付的全部内容？

一次评审一个分支。在我们的示例中，登录分支包含两项变更，但讨论又揭示了另一个需要考虑的问题：支持团队的密码重置说明可能需要更新。

在相关工作旁添加一个规划主题：

检查支持指南是否需要更新。

在团队调查期间，它可以继续保留为一个问题。如果团队决定需要将其作为交付工作进行跟踪，请通过适当的 Jira 工作流程创建并分配这项工作。

将问题放在相关分支附近，有助于保留上下文。查看登录变更的人可以明白，为什么会提到支持指南。

寻找需要跨事项进行的检查

接着问：

哪些变化应该一起验证？

通知分支包含新的偏好设置页面和重复邮件修复。每个事项可能都有各自的验收标准，但发布讨论还应考虑这些变化共同作用后的体验。

例如：

• 关闭某项通知后，是否不会再发送对应的邮件？
• 重新开启后，是否恢复预期行为？
• 启用该通知时，客户是否只收到一封邮件？

这些是针对虚构产品的示例问题。你的检查应围绕此次发布实际改变的行为展开。

导图通过将相关工作放在一起来支持讨论。团队仍然需要决定测试内容，并按照日常测试流程记录结果。

具体表述尚未解决的问题

“账单方面的顾虑”这样的主题，很难让团队知道该做什么。

更有用的问题是：

地址更正会影响之前生成的发票吗？

这种表述明确了不确定之处，也更容易找到合适的人来回答。

结束评审前，逐一查看待解问题，并商定由谁跟进。当讨论带来明确的后续行动时，可视化计划才真正发挥作用。

放大

建立共享发布操作清单

理解发布范围是发布规划的一部分，协调上线当天的工作则是另一部分。

在“Jira releases”面板中打开该版本的“Deploy Notes & Checklist”。在这里，你可以创建按顺序排列的部署步骤清单。

操作清单属于该 Jira 项目和发布版本，因此参与同一发布的人员可以遵循同一份已保存的执行顺序。

输入一个步骤，然后按 Enter 或选择添加按钮。继续添加，直到清单覆盖团队需要协调的各项活动。

对于客户门户发布，初稿可以如下所示：

请将其作为起点。合理的顺序取决于你的系统、部署流程和发布风险。

有些团队需要为备份、审批或维护通知设置明确步骤。另一些团队的部署已自动化，操作清单主要用于协调验证和沟通。

编写让执行者能够明确完成的步骤

“检查所有内容”很难得到一致的执行。

“验证客户能否请求密码重置邮件并成功使用其中的链接”，则为执行检查的人提供了具体行动。

在整份操作清单中应用这一原则：

• 写明要执行的动作。
• 指出相关功能或系统。
• 在有帮助时，明确预期结果。

保持清单易于阅读。详细操作流程可以保留在团队现有文档中；操作清单应让发布顺序易于遵循。

Mind Map Studio 支持上移或下移步骤、删除步骤，以及将步骤标记为完成。已完成步骤数量和进度条会显示操作清单的完成程度。

该进度仅针对操作清单。完成一个步骤不会改变 Jira 事项状态，也不会将 Jira 版本标记为已发布。

让计划与 Jira 保持一致

首次规划会议之后，发布范围可能发生变化。

某个事项可能被移到后续版本。测试后可能新增一项修复。团队也可能调整实现方式，从而需要增加一项生产环境检查。

当 Jira 中的版本或事项分配发生变化时，选择“Refresh Jira releases”，以获取当前版本及其关联事项。

然后根据更新后的范围检查导图和操作清单。确认可视化计划是否仍然反映本次发布，以及部署步骤是否仍然合理。

刷新发布列表后，还应进行一次计划评审；不要假设刷新已经协调好了现有导图的每个部分。

明确区分以下职责：

当你发现似乎缺少某些内容时，这种分工也有帮助。如果某个事项未出现在“Attached issues”中，请检查其在 Jira 中的发布分配，然后刷新面板。

避免三种常见规划错误

导图过于详细，难以评审

如果每个分支都包含长篇注释和细微的实现细节，理解整个发布就会变得更困难。

从发布的主要领域和相关 Jira 事项开始。只有在辅助主题有助于回答规划问题时才添加它们。详细需求仍由 Jira 事项承载。

验证步骤含糊不清

“测试登录”对不同的人可能意味着不同的内容。

写明此次发布改变的行为。在我们的示例中，密码重置请求和过期链接需要具体检查，因为更新的正是这些体验。

将清单完成视为发布成功的证明

完成的操作清单只能记录其中的步骤已被勾选。团队仍然需要适当的测试结果、生产环境观察，以及对发布结果的判断。

商定完成验证步骤前需要哪些证据，并按照常规流程在 Jira 中更新发布。

在下一次 Jira 发布中试一试

选择一个即将发布、事项数量便于管理的版本。

在 Mind Map Studio 中打开导图，在“Jira releases”中找到该版本，并将其关联事项安排到几个有意义的分支中。利用这个概览讨论范围并识别尚未回答的问题。然后打开“Deploy Notes & Checklist”，写下团队在上线当天将遵循的执行顺序。

对于客户门户团队，这会形成同一次发布的两个实用视图：一张解释变化内容的导图，以及一份协调上线和验证的清单。

先从这个小成果开始。下一次发布会议将让你有机会了解，哪些分组、问题和检查对团队最有帮助。

在下一次 Jira 发布中试用 Mind Map Studio，建立一份团队可以共同梳理的可视化计划。