用于软件开发的甘特图

甘特图属于软件，只要放在正确的高度

这种反对很常见。把一张甘特图摆在一个 scrum 团队面前，总会有人说它是穿了西装的瀑布。他们有一点说对了，其余都说错了。他们说对的是，在甘特图上排期单个用户故事是个错误，因为那些故事每天都在变，图表到午饭时就已经过时。他们说错的是，认为甘特图在软件里根本没有一席之地。

诀窍在于高度。待办列表运作在故事层面，那里的工作细碎、不断重排，由流动而非日期来驱动。甘特图运作在高一层，即发布层面，在那里你对上线日期作出承诺、跨团队协调，并向不看 Jira 的利益相关者交代。把甘特图保持在那个高度，它与敏捷之间的张力就干脆消失了。把它降到故事层面，团队冲你发出的每一句抱怨你都活该承受。

软件进度的五个阶段

大多数功能工作都会经过五个可辨认的阶段，而甘特图正是为展示这种序列而生的。探索澄清问题与范围。设计敲定界面、数据模型和 API 契约。构建是工程的主体。测试涵盖集成、质量保证和加固。发布涵盖部署、迁移和上线本身。每个阶段都倚赖前一个阶段，而这正是条形图能让人看见的关系。

阶段不是冲刺。像构建这样的单一阶段可能横跨三到四个冲刺，而探索也许一个冲刺就能装下。这没问题。甘特图里每个阶段一条，而不是每个冲刺一条，更不是每张工单一条。正是这种粗粒度的视图，让一位负责人瞥一眼图表，就能在一秒内看出团队还在构建，还是已在为发布做加固。待办列表永远给不了你这种形态，因为它刻意隐藏了日期。

甘特图胜过待办列表之处

待办列表是一份扁平的、按优先级排序的清单。它在安排接下来几天的工作上出类拔萃，却对发布所依赖的三件事视而不见。第一，发布视图。一位利益相关者问结账功能何时上线，想要的是从探索到上线整段跨度的一幅图，而不是在 200 张工单里翻滚。甘特图在一个画面里就把这幅图给了他。

第二，截止期。一条合同条款、一次会议演示或一个合规日期，都是时间上的固定点。待办列表没有日历日期的概念，所以它无法告诉你承诺的日期是否仍然现实。甘特图把这些日期锚定为里程碑，并显示出它们之前的余量，或是余量的缺失。第三，依赖。当一个团队卡住另一个团队时，那种关系在两个团队的看板上都不会出现，但它恰恰是软件日期延误最常见的原因。甘特图是唯一能让它一目了然的产物。

待办列表胜过甘特图之处

诚实是双向的，确实有一类真实的工作甘特图永远不该去碰。繁杂多变的日常属于看板。接下来拉取哪张工单、今早什么被阻塞、冲刺里还剩多少点数、刚失败的那个不稳定测试由谁来接：这些都不属于甘特图，硬把它们塞进去，正是甘特图在工程界落下坏名声的原因。

看板上的工作时时刻刻都在变。估算在挪动，故事在拆分，缺陷在插队，每次站会之后优先级又重新洗牌。一张要这么频繁重画的甘特图比没用还糟，因为它看上去很权威，实际却是错的。看板天生就是来吸收这种波动的。它把变化当作正常的流动，而不是对某个计划的偏差。所以，把嘈杂、快速变动的细节留在看板上，让它翻腾。甘特图只关心每个冲刺产出的结果，而不关心团队为到达那里所走的每一分每一秒的路径。

甘特图与待办列表并排对照

这两个工具几乎不重叠，而这正是你两者都用的原因。把各自回答的问题排在一起，分工就显而易见了。

问题	待办列表与看板	发布甘特图
我们接下来构建什么？	能，待办列表顶部	不能
现在什么被阻塞了？	能	部分能
我们能赶上上线日期吗？	不能	能
哪个团队卡住了我们？	很少可见	能，作为依赖
这个阶段之后是哪个阶段？	不能	能
它能有多善变？	每小时都在变	每个冲刺变一次

注意这两列共享的东西有多少。你不是在两个工具里二选一。你是用两种不同的工具覆盖两组不同的问题。

跨团队依赖才是真正的理由

如果说软件甘特图单凭一件事就配得上它的位置，那就是跨团队依赖。软件工作充满了没有任何单一看板能展示的交接。API 必须先暴露一个端点，界面才能调用它。基础设施必须先配置好集群，任何人才能向它部署。数据团队必须先交付迁移，功能才能读取新的模式。这其中每一项都是一个跨越团队边界的完成到开始的依赖，而每一项在相关团队的看板上都是隐形的。

在甘特图上，这些交接就是一根根箭头，它们改变了你管理发布的方式。一旦你能看到界面那条在 API 那条完成之前无法开始，你就知道该保护哪项工作、哪项可以有弹性。你不再把每个团队的延误都当作同等紧急，而开始去守护那些真正决定日期的具体交接。这是待办列表永远无法为你提供依据的决定，因为待办列表根本不知道另一个团队的存在。

实例演练：一个为期十周的结账功能

一个团队承诺在十周内交付自助结账。探索和设计先行，然后三个团队并行构建，最后一切汇入测试和发布。看板负责工单。甘特图负责发布。下面是各阶段和负责方如何映射到时间轴上。

阶段	团队	周次	依赖于
探索与设计	产品、设计	第 1 至 2 周	无
支付 API	API	第 3 至 5 周	设计
基础设施与部署流水线	平台	第 3 至 4 周	设计
结账界面	应用	第 6 至 8 周	支付 API
测试与加固	QA、全体	第 8 至 9 周	界面、基础设施
发布与上线	全体	第 10 周	以上全部

决定你日期的那条链

在上面的例子里，设计到支付 API 到结账界面到测试到发布这一序列，是最长的一条依赖工作链。基础设施并行推进并提前完成，所以它有挪动的余地。那条最长的链就是你的关键路径，而它是唯一真正决定上线日期的东西。平台工作延误几天，发布照样能出。支付 API 则不行。

这正是甘特图在工程团队里物有所值之处。一张速度图告诉你某一个团队推进得有多快。它没法告诉你三条并行工作流里是哪一条劫持了整个发布。关键路径能，它让你把注意力花在延误真会让你丢掉日期的地方，而不是把忧虑平摊到每一个团队身上。用真实的历史吞吐量而非乐观情绪去估算那条链上的各个条形，并在你对任何会被客户听到的日期作出承诺之前，先读我们关于估算工期的指南。

把发布甘特图与冲刺执行配对起来

可行的模式很简单。甘特图掌管发布。冲刺掌管细节。你在阶段和史诗的层面绘制甘特图，然后让每个团队完全像今天一样在看板上规划自己的故事。冲刺的各项仪式毫无变化。变化的是，在每次冲刺评审时，你更新对应的阶段条：它完成了、延误了，还是缩短了？

把近处的阶段规划得细致，因为你理解它们；把远处的阶段保留为粗略的块，因为你老实说还不理解它们。随着每一块逼近当前冲刺，再去细化它。这种滚动式推进让甘特图保持真实，而不假装在第 2 周就知道第 10 周的情况。甘特图不是管理任务的第二个地方。它是一面透镜，把一个季度的冲刺成果浓缩成关于上线日期的一个答案。看板回答接下来构建什么。甘特图回答所有这些构建的总和是否按时抵达。

一步步搭建进度

搭建一份进度，你既不需要重量级工具，也不需要项目认证。你需要的是各个阶段、你已经承诺的日期，以及和团队负责人一起度过的一个小时。下面是步骤。

1. 列出本次发布的各个阶段和主要史诗，而不是故事。目标是六到十二条。
2. 先标出固定日期：上线、任何演示，以及任何合规或合同截止期。把它们画成不会移动的里程碑菱形。
3. 用你真实的吞吐量给每个阶段定大小，然后把它放到时间轴上。
4. 画出阶段之间的依赖，尤其是每一处跨越团队的交接。这是价值最高的一步。
5. 找出依赖阶段最长的那条链。那就是你要守护的关键路径。
6. 指定一个人在每次冲刺评审时更新图表，别处一概不动。

在甘特图编辑器里打开一份空白计划，每个阶段加一行，连上依赖，不到一个小时你就有了一份发布视图。把工单的细节留在看板上，那才是它该待的地方。

保持粗粒度，否则它会腐烂

甘特图在软件团队里失败最主要的原因是太重。有人搭了一张漂亮的图，每张工单一条，不到一个冲刺它就过时了，于是团队得出结论：甘特图没用。失败的不是图表。是粒度。一张发布甘特图应当小到让一个人在冲刺评审时十分钟就能更新完，拖动几条、挪一个日期即可。

一张只搭一次、再也不碰的甘特图不是计划，而是愿望。要么更新它，要么删掉它，但绝不要让它在共享盘里腐烂，还假装自己是事实。

什么时候干脆跳过甘特图

并非每一项软件工作都需要甘特图，在它毫无产出的地方加一张纯属额外负担。如果你的工作是一连串细小、独立、没有外部截止期、也没有跨团队交接的持续流动，那么一个看板就绰绰有余。一个维护小队、一条支持队列，或一个每天多次向生产环境发布的单一团队，从发布层中得到的很少，因为根本没有可塑造的发布。

当三个信号同时出现时，再去取用甘特图：一个你已经承诺的固定外部日期、不止一个团队的工作依赖于另一个，以及一位需要在一个视图里看到整段跨度的利益相关者。三者俱全时，待办列表会把真实的问题悬而不决，而甘特图能干净利落地回答它们。三者皆无时，大可问心无愧地跳过它。而如果你确实想要一张，也不必为它付费，因为我们盘点的最佳免费甘特图软件所涵盖的工具，正好能应付这类需求。

常见问题

延伸阅读

• 任务依赖详解
• 关键路径法详解
• 里程碑与任务
• 返回指南列表

本文也提供英文版本。