2. Jira路线图功能体系解析
在Jira中，“路线图”并不是一个单一功能，而是由多个层级、多种视图和不同数据来源共同构成的功能体系。很多团队在使用时容易混淆：为什么有的路线图只能看到当前项目的问题？为什么有的路线图能跨项目聚合？为什么某些字段在路线图里无法作为泳道或筛选条件？要回答这些问题，必须从计划层级、权限模型与数据来源三个维度理解Jira路线图的功能体系。
一、三层路线图的核心差异
Jira路线图大致可分为三类：团队级路线图、项目级路线图和高级路线图（Advanced Roadmaps）。它们并非简单的“功能多少”差异，而是面向不同计划范围、不同数据聚合粒度和不同权限模型的三套机制。
团队级路线图通常出现在团队管理的看板或Scrum板中，数据来源是当前板所关联的一个或多个项目。它的时间轴较短，一般以Sprint或周为单位，关注的是团队近期要交付的Epic和Story。团队级路线图适合做迭代排期和短期依赖对齐，但无法跨多个团队做长期容量规划。
项目级路线图以单个项目为边界，数据来源是该项目的Epic、版本（Version）和问题。它通常用于向项目干系人展示项目里程碑、版本发布节奏和Epic完成情况。项目级路线图的权限继承项目权限方案，能看什么取决于用户在该项目中的角色。
高级路线图是Jira Premium及以上版本提供的能力，它不再局限于单个项目或单个板，而是通过计划（Plan）来定义数据范围。一个Plan可以包含多个项目、多个团队、多个Board，并支持跨团队的容量规划、依赖管理和场景模拟。高级路线图的数据来源是JQL筛选出的问题集合，再叠加团队、发布、目标等计划层字段。
二、计划层级：从Epic到Plan的父子关系
理解路线图的关键在于理解Jira的问题层级（Issue Hierarchy）。标准Jira中，层级通常是：Epic → Story → Sub-task。高级路线图允许扩展层级，例如在Epic之上增加Initiative，形成Initiative → Epic → Story → Sub-task的四级结构。这个层级直接决定了路线图能展示什么。
在团队级和项目级路线图中，通常只能展示到Epic层级，因为标准层级中Epic就是最高层。而在高级路线图中，你可以把Initiative作为泳道或分组依据，把Epic作为时间条，把Story作为子项展开。这意味着：如果你希望路线图能按“战略主题”分组，就必须先在Jira中配置好对应的层级和问题类型，否则路线图没有数据可聚合。
实际配置时，管理员需要在“Jira设置 → 问题 → 问题类型层级”中定义层级方案，并确保项目使用该方案。例如，一个常见的配置是：Initiative（层级1）→ Epic（层级0）→ Story（层级-1）→ Sub-task（层级-2）。配置完成后，高级路线图的Plan中才能选择Initiative作为“父级”字段进行分组。
三、权限模型：谁能看到什么
三层路线图的权限控制逻辑不同，这是实际使用中最容易出问题的地方。
- 团队级路线图：权限完全继承Board和项目权限。如果用户没有某个项目的浏览权限，该项目的问题不会出现在路线图中。Board的过滤器（Filter）共享范围也会影响可见性。
- 项目级路线图：权限继承项目权限方案。用户需要拥有项目浏览权限，且路线图展示的Epic和Version受项目角色控制。如果项目使用了问题安全级别（Issue Security Level），路线图同样会过滤掉无权查看的问题。
- 高级路线图：权限是双重的。首先，用户需要拥有Plan的访问权限（Plan可以共享给特定用户、组或项目角色）；其次，Plan中JQL筛选出的问题仍然受项目权限约束。也就是说，Plan权限决定“能不能打开这个计划”，项目权限决定“打开后能看到哪些问题”。如果用户有Plan权限但没有某个项目的浏览权限，该项目的问题在Plan中会显示为不可见或直接缺失。
四、数据来源：路线图的数据从哪里来
路线图的数据来源可以归纳为三类：问题数据、计划层字段和团队/容量数据。
问题数据是路线图的基础。团队级和项目级路线图直接读取Board或项目中的问题；高级路线图则通过Plan中的JQL来定义数据范围。例如，一个Plan的JQL可以写成：project in (PAY, ORDER, USER) AND issuetype in (Initiative, Epic) AND status != Done。这条JQL决定了Plan中会出现哪些问题。
计划层字段是高级路线图特有的。这些字段不存在于标准问题界面中，而是由Plan维护，包括：团队分配（Team）、发布（Release）、目标（Goal）、依赖（Dependency）、开始/结束日期等。这些字段只影响Plan内的视图，不会写回问题本身（除非显式同步）。
团队/容量数据用于高级路线图的容量规划。管理员需要在“团队”设置中定义团队名称、成员、Sprint长度、每日工时等参数。Plan会根据这些参数计算每个团队在每个时间段的容量，并与分配的问题估算值对比，从而显示“超载”或“空闲”。
五、如何选择正确的路线图层级
选择哪一层路线图，取决于你要回答的计划问题。以下判断依据可供参考：
| 计划问题 | 推荐层级 | 关键数据来源 |
|---|---|---|
| 本团队下两个Sprint要交付哪些Epic？ | 团队级路线图 | Board关联项目的问题 |
| 本季度版本发布包含哪些Epic？ | 项目级路线图 | 项目Epic + Version |
| 三个团队未来半年的容量是否够用？ | 高级路线图 | Plan JQL + 团队容量参数 |
| 跨项目依赖是否会导致交付延期？ | 高级路线图 | Plan依赖字段 + 时间轴 |
需要强调的是，高级路线图并不是“更高级所以更好”。如果团队只需要管理单个项目的版本发布，项目级路线图已经足够，强行使用高级路线图反而会增加配置成本和维护负担。正确的做法是：先明确计划问题的范围和时间跨度，再选择匹配的路线图层级。
总结来说，Jira路线图功能体系的核心在于“层级匹配”：团队级对应短周期单团队，项目级对应中周期单项目，高级路线图对应长周期跨团队。权限模型从项目权限逐步叠加到Plan权限，数据来源从Board/项目问题扩展到JQL+计划层字段+团队容量。理解这三条主线，就能在实际配置中快速判断该用哪一层、该配什么、该查什么。