Azure Boards 将计划关系存储为前驱和后继链接，但它没有内置的关键路径甘特图视图。使用依赖跟踪器或连接的调度程序，并验证连接器实际导入的链接。
Azure DevOps 依赖关系如何显示在甘特图中？
Azure Boards 通过定向前驱和后继工作项链接记录交付依赖性，但 Azure Boards 不提供内置关键路径甘特图。 Microsoft 的依赖性跟踪器扩展提供列表、风险视图和 beta 时间表。连接的调度程序可以提供任务栏和CPM，但前提是它导入或重新创建依赖关系链接。
GanttFather 目前将 Azure DevOps 工作项、日期、分配、状态和父/子层次结构导入到甘特图项目中。它不将 Azure 前驱/后继链接导入为甘特图依赖项。拉取后，添加GanttFather中的调度关系；这些本地链接驱动依赖箭头和关键路径分析，并且不会被以后的拉取覆盖。
行为已验证： 2026 年 8 月 30 日根据 Microsoft 文档和 GanttFather 的当前 Azure DevOps 功能合同进行验证。
哪个 Azure DevOps 链接类型代表依赖关系？
使用前任/后继作为交货订单。前任是必须排在第一位的生产者；继任者是依赖它的消费者。 Azure DevOps 可防止此依赖关系拓扑的循环关系并支持一对多链接。
| Azure DevOps 关系 | 含义 | 这是日程依赖性吗？ | 甘特图解读 |
|---|---|---|---|
| 前任 | 链接项目应在当前项目之前完成 | 是的 | 通常是 FS 链接的前导端 |
| 继任者 | 链接的项目应该出现在当前项目之后 | 是的 | 通常是 FS 链接的后继侧 |
| 家长/孩子 | 项目组合或待办事项层次结构 | 否 | 摘要行/子行 |
| 相关 | 一般协会 | 否 | 仅供参考 |
| 生产用于/消费自 | 跨组织方向依赖 | 是的，对于远程工作项目 | 需要显式映射的外部依赖 |
管道 dependsOn | YAML 中的阶段或作业执行顺序 | 仅管道 | 不是工作项链接 |
父母/孩子和前任/继承人回答不同的问题。家长/孩子说“功能 12 包含用户故事 34。”前任/继任者表示“API 合同必须在移动集成开始之前完成。”不要从待办事项嵌套推断调度顺序。
如何在 Azure Boards 中创建工作项依赖关系？
- 打开必须等待的工作项。
- 打开 链接 部分并选择 添加链接。
- 选择前任。
- 找到必须首先发生的工作项并保存。
- 打开另一个工作项目并确认相互的后继链接。
- 如果关系将显示在时间线上，请添加有意义的迭代日期或计划字段。
对于必须按顺序完成的任务，Microsoft 建议使用前驱/后继。这些链接可以跨项目，尽管当 Excel 往返很重要时，Microsoft Excel 导入/导出指南建议使用相同项目的前一个链接。
Azure 工作项依赖项链接本身不会存储所有经典的 CPM 详细信息。前驱/后继链接传达顺序，但外部调度程序可能仍然需要持续时间、日历、滞后以及到 FS、SS、FF 或 SF 的显式映射。
如果没有其他调度程序，Azure DevOps 可以可视化什么？
Azure DevOps 提供了几个类似时间线的界面，但每个界面都回答不同的问题。
| 天青色表面 | 最佳使用 | 显示依赖关系 | 完整甘特图调度/关键路径 |
|---|---|---|---|
| 董事会和积压订单 | 流程、优先级、层次结构 | 每个项目上可见的链接 | 否 |
| 交付计划 | 跨团队迭代和路线图时间安排 | 不是依赖网络调度程序 | 否 |
| 依赖跟踪器扩展 | 消费者/生产者依赖风险 | 是的；列表、图表和时间线视图 | 没有CPM；时间线被记录为测试版 |
| 直接链接 WIQL 查询 | 审核链接的工作项目 | 是的，作为查询结果 | 没有时间表 |
| 外部甘特图调度程序 | 日期、条形图、箭头、日程分析 | 取决于连接器合同 | 是的，当存在链接和持续时间时 |
Microsoft 声明 Azure Boards 没有内置方法来显示关键路径。依赖跟踪器可以根据前置和后继时间标记正确或不正确的流程，但其时间线取决于分配给已配置开始和结束日期的迭代路径的工作项。
如何将 Azure DevOps 的工作转移到 GanttFather 中？
当前 GanttFather 工作流程是受控拉动，而不是连续镜像：
- 连接： 输入组织 URL 和 Personal Access Token，然后完成“测试连接”。
- 项目： 选择该令牌可访问的 Azure DevOps 项目。
- 来源： 选择已保存的查询或团队看板；对于看板，选择一层或完整树。
- 类型： 检查要导入的计划工作项类型。
- 日期和工作量： 为每个包含的类型映射开始、结束和可选工作量字段。
- 状态： 将检测到的 Azure 状态映射到准确的 GanttFather 项目状态，并检查 Push 使用的状态。
- 目标： 选择目标父任务，检查摘要并保存。保存会启动第一次 Pull。
添加来源会复用已保存的连接和项目，从来源开始执行最后五个步骤。配置字段使用同一模型，但在日期和工作量（第 3/5 步）打开；通过返回可检查类型和来源。第一次 Pull 后，检查日期和层级并添加 Gantt 依赖关系。
有关屏幕截图和字段映射详细信息，请使用 Azure DevOps 集成文档 以及更广泛的 Azure DevOps 甘特图设置指南。
GanttFather 从 Azure DevOps 导入哪些字段？
| Azure DevOps 数据 | GanttFather 结果 | 重要行为 |
|---|---|---|
System.Title | 任务名称 | 丢失时回退到工作项 ID |
System.Description | 任务描述 | HTML 标签已删除 |
System.State | 项目状况 | 使用默认或配置的状态映射 |
| 优先级 | 任务优先级 | Azure 值 1–4 映射到高/中/低 |
| 配置的开始字段 | 任务开始 | 缺席时回退到创建日期 |
| 配置的目标/结束字段 | 任务结束 | 缺席时回退至开始后一天 |
| 故事点/配置的估计 | 预估 | 可选 |
| 分配给 | 成员或虚拟资源分配 | 从已知身份解析 |
System.Parent | 父任务 | 仅当父级位于同一同步源时才解决 |
| 前任/继任关系 | 未进口 | 在本地添加和维护甘特图依赖项 |
重复拉取会更新现有的映射任务，而不是复制它。如果 Azure 工作项的修订版未更改，GanttFather 会跳过它。当映射的工作项离开查询或面板时，GanttFather 将关闭本地任务而不是删除它，除非同一连接中的另一个源仍在跟踪它。
导入后应该如何对依赖关系进行建模？
翻译传递约束，而不仅仅是 Azure 链接标签。大多数 Azure 前任/后继关系是 finish-to-start，但实际工作可能需要其他类型。
| 情况 | 甘特图依赖性 | 示例 |
|---|---|---|
| 后继者在前任完成后开始 | FS | 安全审核后部署 |
| 两个任务可以一起开始 | SS | 后端和前端实现 |
| 两项任务必须一起完成 | FF | 文档和功能发布 |
| 一项任务只有在另一项任务开始后才能完成 | SF | 新支持开始后停止旧支持 |
| 活动结束后的等待期 | FS 具有正滞后 | 推出两天后开始测量 |
| 故意重叠 | 具有负滞后的适当类型 | 在实施完成前两天开始质量检查 |
GanttFather 强制执行同级任务之间的依赖性规则，拒绝周期和跨项目链接，并支持从 -365 到 365 个日历日的滞后。阅读 四种甘特图依赖性类型 在转换复杂的 Azure 关系之前。
仅在检查导入日期后才创建依赖项。由于缺少 Azure 目标日期而导致的默认一日栏可能会使技术上有效的依赖网络产生毫无意义的关键路径。
当 Azure DevOps 或 GanttFather 稍后更改时会发生什么？
审阅 Pull 在更改时间线前比较映射字段。仅 Azure 的更改会被选中；冲突的本地日期或状态通过默认 保留我的更改 留在本地。正常打开 Pull 时，摘要保持简洁且高级设置处于折叠状态；保留我的更改 和 从 Azure 恢复 位于高级设置中。项目标题栏中的 Azure 快捷方式和 数据与同步 只显示两个日常操作：从 Azure Pull 和 Push 到 Azure。初始导入在设置过程中完成，而独立的完整 同步来源 操作仍是设置中的维护操作。两个流程都不会覆盖本地依赖关系或任务顺序。
从快捷入口、设置或 数据与同步 打开 Pull 或 Push 时，如果上一次比较已经完成，系统会向服务器请求新的比较，以便审阅包含最新的 Azure 更改。只有在同一来源的检查仍在进行时再次打开，才会共享该进行中的请求。
Push 是独立的审阅发布流程。符合条件的本地日期和状态（包括冲突）默认选中；确认会覆盖更新的 Azure 映射值，先 Pull 是可选的。审阅 Pull 会立即展开高级设置，在同一对话框中显示 保留我的更改 和 从 Azure 恢复。成功的 Pull 或 Push 会关闭对话框；保留我的更改 · 关闭 会在不启动操作的情况下关闭。估算和本地依赖关系永远不会被发送。发布需要具有工作项：读取和写入权限的 PAT。
如果所选开始或结束日期与 Azure 中当前的另一日期组成无效范围，发送会在发布前被禁用，并且不会向 Azure 写入任何内容。审阅 Pull 会展开高级设置，以便恢复一致的日期范围；也可以关闭对话框并调整本地日期。
没有用于集成的调度程序或 Webhook。如果 Azure 计划每天都会更改，请指派所有者或管理员按照商定的节奏进行操作，并在安排审核之前记录上次成功的同步。
市场扩展与外部甘特图工具相比如何？
当 Azure DevOps 应该仍然是唯一的工作管理界面并且团队主要需要跨团队消费者/生产者风险时，请使用依赖跟踪器。它保留本机链接并减少重复。
当团队需要可拖动的日期栏、依赖关系类型、滞后、关键路径、利益相关者共享或包含非 Azure 工作的计划时，请使用外部甘特图工具。在选择任何连接器之前，请验证以下具体问题：
- 它导入前驱/后继链接还是仅导入父/子层次结构？
- 哪些日期和持续时间字段是权威的？
- 同步是自动、计划还是手动？
- 哪个方向可以写，有复习步骤吗？
- 当某个项目离开源查询时会发生什么？
- 能否往返依赖类型和滞后而没有损失？
GanttFather 在第一点上很坦率：其当前的 Azure 连接器导入层次结构，但不导入 Azure 依赖项链接。当您想要在本地构建规划网络时，这使得 GanttFather 适合；它不是 Azure 链接图的零维护副本。
是 YAML dependencies 与工作项依赖性相同吗？
Azure Pipelines 号使用 dependsOn, dependencies, 和 stageDependencies 控制阶段/作业执行并读取先前的输出。这些表达式是管道运行时概念。它们不会在 Azure Boards 工作项之间创建前置/后继链接，并且不会自动显示在甘特图中。
例如， $[ dependencies.Build.outputs['setVersion.value'] ] 读取前一个作业的输出变量。它没有提及功能或用户故事的预定日期。使用微软的 管道表达式参考 用于 YAML 错误和计划关系的工作项链接参考。
GanttFather 何时与 Azure DevOps 一起有用？
当 Azure DevOps 应该保留在积压和交付记录系统中，而较小的团队拥有跨团队计划时，请使用 GanttFather。连接器可以将映射的工作项字段和父/子层次结构拉入一个甘特图项目；每次手动拉取后，规划人员可以添加 FS、SS、FF 和 SF 具有滞后的依赖项，计算关键路径，并与观众或来宾共享实时结果。
这不是依赖项镜像：Azure 前驱/后继链接不会导入或通过 Push 发送，所有者或管理员必须触发并审查应用程序中的集成活动。免费套餐涵盖一个自有项目，拥有两个编辑席位以及无限的观众和客人。如果受控分割适合您的流程， 创建一个免费的 GanttFather 项目 并在构建完整的本地网络之前验证一个 Azure 查询。
关于 Azure DevOps 依赖关系，人们还会问什么？
Azure DevOps 有原生甘特图吗？
Azure Boards 有路线图和基于扩展的时间线表面，但 Microsoft 不提供具有关键路径分析的内置经典甘特图。 Dependency Tracker 包括依赖流的 Beta 时间表；交付计划侧重于基于迭代的跨团队规划。
GanttFather 是否导入 Azure 前驱/后继链接？
否。当前连接器导入工作项字段和同源父/子层次结构。 Azure 前驱/后继链接不会转换为甘特图依赖项。导入后在GanttFather中添加这些日程关系；重复拉取保留本地依赖集。
GanttFather 能否将依赖关系推送回 Azure DevOps？
否。已审核的 Push 涵盖明确选择的映射工作项字段，而不是 Azure 关系链接。它不会创建、更新或删除前任/后继关系。当其他 Azure 工具需要这些本机链接时，请保持 Azure 链接图的权威性。
Azure DevOps 可以显示关键路径吗？
Microsoft 声明 Azure Boards 没有内置关键路径视图。外部调度程序可以在具有有效的任务日期、持续时间和完整的依赖网络后计算。仅基于父/子层次结构的图表无法生成可靠的关键路径。
AI 代理可以通过 GanttFather MCP 触发 Azure DevOps 同步吗？
否。GanttFather 的 MCP 服务器没有 Azure 集成工具。所有者或管理员必须在应用程序中配置连接、触发 Pull、检查比较并确认 Push。任务出现后，授权代理可以处理 GanttFather 任务和本地依赖项。
产品行为检查： 2026 年 8 月 30 日。
来源
