4. 高级路线图的数据源配置
高级路线图（Advanced Roadmaps，在 Jira Cloud 中现称 Plans）之所以能跨团队规划，核心不在于它画得好看，而在于它把多个项目、多个看板、多个过滤器里的工作项汇聚成一条统一的数据流。如果数据源配置错了，路线图上就会出现“同一个需求在两个团队各算一次”“某个团队的 Epic 根本没进来”“排期和实际看板对不上”这类问题。本节要解决的就是：数据从哪里来、以什么口径进来、进来之后如何保持同步。
一、先理解数据源的三层结构
Plans 的数据源不是“选一个项目”这么简单，它由三层叠加而成：项目范围决定哪些项目的工作项有资格进入；过滤器在项目范围之上做二次筛选，决定哪些工作项真正被纳入计划；看板则提供状态列映射和迭代（Sprint）信息，让路线图上的进度条、状态和实际执行保持一致。三者是“范围—筛选—映射”的关系，而不是互相替代。
需要特别注意的是：Plans 默认只纳入 Epic、Story、Task、Bug 等标准层级，且对子任务（Sub-task）通常不纳入计划视图。如果你希望某个自定义工作项类型（例如“需求”“特性”）出现在路线图上，必须先在 Jira 的 issue type scheme 中把它配置为可被 Plans 识别，否则无论怎么加过滤器都不会显示。
二、项目范围：决定“谁有资格进来”
在 Plans 的 Data sources 页面，第一步是添加项目。这里有一个容易被忽略的细节：添加项目时可以选择“包含所有工作项”或“仅包含特定工作项类型”。如果你的 Jira 实例中项目很多，建议不要一次性把全部项目加进来，而是按团队或产品线分组添加。例如：
Data sources → Projects
├─ PLAT (平台研发) → 包含 Epic / Story / Task / Bug
├─ MOB (移动端) → 包含 Epic / Story / Task / Bug
└─ DATA (数据中台) → 包含 Epic / Story / Task / Bug
如果某个项目只用于记录运维工单，不希望它出现在路线图上，就不要把它加入项目范围。项目范围是“粗筛”，一旦加入，该项目下所有符合类型的工作项都会进入候选池。
三、过滤器：决定“哪些真正被纳入”
过滤器是 Plans 中最灵活也最容易出错的一层。它本质上是一个 JQL 查询，Plans 会定期执行这个 JQL，把结果集作为计划的工作项来源。常见的配置方式有两种：
- 按标签筛选：例如
labels = roadmap-q3，适合季度规划场景，团队只需给要纳入规划的工作项打上标签即可。 - 按项目 + 状态筛选：例如
project in (PLAT, MOB, DATA) AND status != Done，适合持续跟踪未完成工作项。
这里有一个关键原则：过滤器要尽量“窄而稳定”。如果过滤器写得太宽（比如只写 project in (PLAT, MOB, DATA)），会把大量历史已完成工作项也拉进来，导致路线图臃肿；如果写得太依赖临时字段（比如某个即将被删除的自定义字段），过滤器会突然失效，路线图数据源断裂。建议把过滤器保存为 Jira 中的“已保存过滤器”（Saved Filter），然后在 Plans 中引用该过滤器，这样修改 JQL 时只需改一处。
注意：Plans 对过滤器的执行有数量限制。如果一个过滤器返回超过 5000 个工作项，可能会被截断或导致加载缓慢。跨团队规划时，建议按“季度 + 团队”拆分多个过滤器，而不是用一个巨型过滤器覆盖所有项目。
四、看板映射：决定“状态和进度怎么显示”
看板（Board）在 Plans 中的作用是提供状态列映射和Sprint 数据。Plans 本身不定义状态，它读取看板的列配置，把看板列映射为计划中的“状态类别”（如 To Do、In Progress、Done）。如果某个团队使用 Kanban 看板，没有 Sprint，那么该团队的工作项在路线图上就不会有迭代条，但状态颜色仍然可以正常显示。
配置看板映射时，需要为每个项目指定一个看板。如果同一个项目有多个看板（例如“前端看板”和“后端看板”），Plans 只会读取你指定的那一个。因此，建议为跨团队规划专门维护一个“规划看板”，把各团队的关键状态列统一命名，例如：
| 看板列名称 | 映射到 Plans 状态 | 说明 |
|---|---|---|
| 待规划 | To Do | 尚未排期 |
| 已排期 | To Do | 已进入 Sprint 但未开始 |
| 开发中 | In Progress | 进行中 |
| 验收中 | In Progress | 等待测试或验收 |
| 已完成 | Done | 关闭 |
这样映射之后，无论团队内部叫“开发中”还是“编码中”，在路线图上都会统一显示为 In Progress，跨团队对比时就不会因为命名差异而产生误判。
五、同步机制：数据源不是一次配置就结束
Plans 的数据同步分为两种：自动同步和手动刷新。工作项的状态、Sprint、负责人等字段变更后，Plans 通常会在几分钟内自动更新；但如果你修改了过滤器 JQL 或新增了项目，需要手动点击 Refresh data sources 才会生效。此外，看板列的映射关系变更后，也需要重新加载计划才能看到新的状态颜色。
为了保持数据口径一致，建议建立以下日常检查习惯：
- 每天上班后打开 Plans，查看顶部是否有“数据源需要刷新”的提示。
- 每周检查一次过滤器返回的工作项数量，如果突然大幅增加或减少，说明 JQL 可能被误改或标签被批量修改。
- 每月核对一次看板列映射，特别是当团队调整了工作流状态后，及时更新映射关系。
实用技巧：可以在 Plans 中为每个数据源添加“描述”字段，写明该数据源对应的团队、过滤条件和负责人。这样当多人协作维护路线图时，能快速定位问题来源。
六、统一数据口径的三个关键动作
跨团队规划最怕“各说各话”。要统一数据口径，建议在配置数据源时同步完成三件事：
- 统一工作项类型：确保各项目都使用相同的 Epic/Story 层级，避免有的团队用“需求”有的用“Story”。
- 统一状态映射：通过看板列映射，把不同团队的状态归并到 To Do / In Progress / Done 三类。
- 统一过滤器标签：约定一个全局标签（如
roadmap-2025），所有要纳入路线图的工作项都必须打上该标签，过滤器只认这个标签。
完成以上配置后，你的 Plans 就会形成一个稳定的数据管道：项目范围提供候选池，过滤器做精准筛选，看板映射负责状态翻译，同步机制保证数据新鲜。后续无论是调整排期、查看依赖还是做容量规划，都建立在这套统一的数据口径之上，跨团队协作的沟通成本会显著降低。