了解自适应甘特计划如何补充 Scrum 或看板的里程碑、依赖关系和跨团队预测，而无需将敏捷工作转变为固定的瀑布计划。
当团队需要协调里程碑、跨团队依赖性、外部日期和长期预测时，甘特图在敏捷环境中仍然很重要。当每个积压项目提前几个月被冻结并且图表被视为承诺而不是随证据而变化的模型时，它们就会变得有害。
审核日期：2026 年 8 月 7 日。 本指南依赖于敏捷原则和调度实践，而不是有争议的通用项目成功百分比。
甘特图与敏捷价值观不兼容吗？
不。敏捷宣言重视响应变化而不是遵循计划；它没有说“从不计划”。有用的甘特图使当前的假设可见并且易于修改。反敏捷图表隐藏了不确定性，惩罚诚实的更新，或者迫使团队保留过时的序列。
问题不在于是否存在时间表。这就是时间线的使用方式。
敏捷甘特图应该包含什么？
保持协调级别：
- 发布或计划里程碑
- 跨团队、供应商或系统的依赖关系
- 批准、采购、迁移和启动窗口
- 高水平的工作包而不是每一项日常任务
- 预测范围或可能的明确不确定性
- 当前的关键和近关键路径
产品待办事项列表仍然是 Scrum 中未来产品工作的有序来源。 Sprint Backlog 是由开发人员制定并为开发人员制定的计划。跨团队的甘特计划不应默默地取代任何一个工件。
Scrum 和甘特计划如何结合在一起？
使用不同的视野做出不同的决策：
| 地平线 | 主要问题 | 有用的视图 |
|---|---|---|
| 今天到当前的 Sprint | 我们现在在做什么和学什么？ | Sprint 积压工作或看板 |
| 下一个版本 | 哪些里程碑和依赖性风险需要协调？ | 高级别甘特图时间表 |
| 产品方向 | 哪些结果和主题很重要？ | 产品目标和路线图 |
在冲刺评审中，用所学到的知识更新长期预测。在冲刺计划中，使用外部约束作为上下文，而不从团队外部分配固定的个人任务计划。
如何保持甘特图的适应性？
使用滚动式规划。详细说明近期工作；将以后的工作保持在更高的水平，直到有证据证明分解是合理的。标记假设和决策日期。当范围、持续时间、依赖性或容量发生变化时，重新计算计划。
实用规则：
- 将承诺日期与预测分开。
- 仅链接真实的调度约束。
- 避免超出可靠规划范围的错误精度。
- 更新剩余持续时间，而不仅仅是完成百分比。
- 检查近关键路径和外部依赖关系。
- 保留发起人级别承诺的变更记录。
甘特图可以揭示哪些敏捷问题？
时间表可以显示三个团队在同一周内需要同一位专家，供应商批准阻止多个版本，或者集成里程碑没有前置逻辑。看板可以显示一个团队内部的流程，同时隐藏那些较长的链条。
图表无法自动解决冲突。它为团队和利益相关者提供了一个用于协商顺序、范围、容量和日期的共享对象。
常见的反模式有哪些？
- 提前一年安排每个用户故事
- 将目标日期视为固定的，没有决策记录
- 通过酒吧是否符合旧计划来衡量生产力
- 私下更改图表并将其呈现为团队同意
- 将不完整的依赖逻辑隐藏在有吸引力的颜色后面
- 在每日 Scrum 期间使用图表分配日常工作
- 忽略实际进度、剩余持续时间或资源冲突
过时的图表比没有图表更糟糕，因为它会产生虚假的信心。
敏捷团队什么时候应该跳过甘特图？
当工作几乎没有有意义的日期依赖性、团队正在优化连续流程并且服务水平期望或看板回答了规划问题时，请跳过它。不要仅仅因为模板说每个项目都需要一个而维护第二个工件。
使用支持决策的最小视图。
GanttFather 如何支持敏捷规划模型？
GanttFather 将基于依赖关系的交互式时间线与同步看板视图相结合。团队可以使用看板进行日常流程，而交付负责人则跟踪里程碑、外部交接以及相同任务数据的关键路径。
GanttFather 不会做出特定的预测、自动调整资源或提供专用的基线覆盖。团队仍必须更新假设并保留其治理流程中的正式承诺。
在 GanttFather 内构建自适应计划 并以与它所代表的工作相同的节奏对其进行审查。
常见问题
敏捷是否意味着没有最后期限？
不会。敏捷方法鼓励实证规划和适应。组织仍然可以有市场、监管、合同或运营日期。
每个用户故事都应该出现在甘特图上吗？
通常不会。包括解释里程碑和依赖性所需的工作水平；将日常细节保留在团队的工作系统中。
甘特图可以代替产品待办事项列表吗？
不会。在 Scrum 中，产品待办事项列表是改进产品所需的有序、紧急的工作列表。
敏捷时间表应该多久更新一次？
当有意义的证据发生变化时进行更新，并以可预测的节奏进行审查，通常围绕 Sprint 评审或发布计划检查点进行。
路线图与甘特图相同吗？
不会。路线图传达战略成果和方向；甘特图对计划的活动和依赖关系进行建模。
最好的详细程度是多少？
足够的细节可以暴露协调风险，但又不会太严重，以至于维护图表成为与团队工作脱节的第二个全职计划。
