敏捷与甘特图：如何将两者结合使用

是的，它们能共存。这是诚实的答案

向一位 scrum 纯粹主义者和一位交付负责人提出同样的问题，你会得到相反的答案。纯粹主义者说甘特图是披着外衣的瀑布模型。负责人说待办列表无法告诉客户功能何时发布。两人各对了一半。甘特图与敏捷并非对手，它们在不同的高度上运作。敏捷负责每个冲刺内部的日常工作。甘特图在冲刺之上描绘发布的全貌：各个阶段、硬性日期，以及任何单一待办列表都无法展现的团队间交接。

真正的错误是强迫一个工具去做两份活。在甘特图上规划一个为期两周的冲刺，你会在故事移动时每天早上重画一遍。仅凭待办列表就承诺一个发布日期，那是在对速率瞎猜。把每个工具放到合适的位置，那种由来已久的紧张感就悄然消失了。

两个工具，两个高度

看板和待办列表是为流动而生的。它们回答团队接下来该拉取什么、今天什么被阻塞、当前冲刺还剩多少。它们刻意对日历上的日期视而不见，因为日期并不是驾驭冲刺的方式。甘特图是为时间而生的。它回答某个阶段何时开始、哪些团队必须先完成另一个团队才能开工，以及发布是否仍能如期落地。

问题	看板与待办列表	发布甘特图
我们接下来构建什么？	是，待办列表顶部	否
我们今天被阻塞了吗？	是	部分
我们能赶上发布日期吗？	否	是
哪个团队制约着我们？	很少可见	是，以依赖的形式
这一阶段之后是哪个阶段？	否	是

注意这些列几乎不重叠。这正是重点。你不是在两者之间做选择，而是在覆盖两组不同的问题。

敏捷计划的三个层次

健康的敏捷交付建立在三个层次上，其中只有一个是冲刺。把它们分开，正是让甘特图和看板能并肩共存而不彼此干扰的原因。

• 路线图层。季度与主题。这半年什么重要，以及大致的先后顺序。这是一个战略视图，不是时间表。
• 发布层。甘特图就住在这里。一次发布是跨越数个冲刺的一组阶段，带有真实日期、里程碑和跨团队依赖。你正是在这里向客户作出承诺。
• 冲刺层。看板和待办列表。故事、点数、每日流动。估算在这里不断变化，这没关系，因为上面那一层会吸收波动。

当有人说甘特图扼杀了敏捷，他们通常是指有人试图在甘特图上经营冲刺层。把甘特图提升到发布层，这个异议便烟消云散。

甘特图能带来而待办列表做不到的东西

待办列表是一份扁平的、按优先级排序的清单。它在排序工作上出类拔萃，却在发布所依赖的三件事上糟糕透顶。第一，跨团队依赖。当 API 团队必须先交付一个网关，应用团队才能构建结账时，这种关系在任何一方的待办列表里都看不见，但在甘特图上作为一条依赖却一目了然。第二，硬性截止日期。一场展会、一项合同条款或一个监管日期都是待办列表根本无法表达的固定点。第三，发布视图：一张图就能向干系人展示从设计到发布的整段跨度。

待办列表告诉一个团队接下来做什么。甘特图告诉整个组织所有这些工作的总和是否能按时抵达。这不是同一个问题，而一份发布计划需要两者都有答案。

用甘特图把握发布，用冲刺处理细节

行得通的模式是滚动式波次规划。你在阶段和史诗的层面绘制发布甘特图，大致每个史诗或每个冲刺一根条，而不是每个故事一根条。近期是细化的，因为你了解它。远期是一个粗略的区块，因为老实说你还不了解它，而假装了解正是甘特图落下坏名声的原因。

每个冲刺里，团队照常在看板上规划自己的故事。这一点毫无改变。改变的是，在冲刺结束时你要更新甘特图上对应的那根条：这个史诗是完成了、延期了，还是缩小了？甘特图不是管理任务的第二个地方。它是一面透镜，把八周的冲刺结果化作一个关于发布日期的单一答案。用团队真实的速率来估算那些粗略的条，而不是一厢情愿的算法，并在承诺日期之前读一读我们关于估算工期的指南。

实战示例：横跨四个冲刺的 2.0 版本

一个支付团队承诺在八周内交付自助结账，即四个为期两周的冲刺。看板经营故事。甘特图经营发布。下面是各史诗如何映射到冲刺上，以及风险所在。

史诗	团队	冲刺	依赖于
支付网关集成	API	1 至 2	无
结账界面	应用	3 至 4	网关（完成到开始）
反欺诈规则	风险	2 至 3	网关（开始到开始）
发布与合规签署	全体	4	以上全部

决定你日期的那条链

在上面的示例中，网关然后结账然后发布这一序列，是依赖性工作的最长路径。其余一切，比如并行推进的反欺诈规则，都有移动的余地。那条最长的链就是你的关键路径，而它是唯一真正决定发布日期的东西。反欺诈规则可以延后几天，发布照样能出。网关不行。

这正是甘特图在敏捷团队里物有所值之处。速率图告诉你单个团队推进得有多快。它们无法告诉你四条并行工作流中，究竟是哪一条挟持了整个发布。关键路径能，它让你把注意力花在延误真正会让你丢掉日期的地方，而不是把忧虑平均分摊到每个团队身上。

常见异议，诚实的回答

这种反对声是可以预料的，而当甘特图被误用时，其中大多数都是公允的。下面是 scrum 团队会提出的异议，以及对每一条的诚实回答。

异议	诚实的回答
甘特图就是瀑布	只有当你在上面规划故事时才是。在发布层，它只是一个依赖和日期的视图。
估算每个冲刺都在变	没错，所以把条保持在史诗层面，并在每个冲刺后更新它们。别画故事。
它会过时	如果没人负责，它会的。指定一位负责人，在每次冲刺评审时更新它，不要更早。
看板已经显示了阻塞	在一个团队内，是的。跨团队的关卡和固定日期，它不显示。
干系人应该去读待办列表	他们不会读的。发布甘特图才是高管和客户真正能看懂的产物。

这些异议没有一条能经受住与一张放在正确高度的甘特图的碰面。它们几乎全都其实是在抱怨那些放在错误高度的甘特图。

如何在一个下午搭出一张发布甘特图

你不需要重量级工具，也不需要什么认证。你需要的是各个史诗、你已经承诺过的日期，以及和团队负责人一起的一个小时。流程如下。

1. 列出本次发布的史诗，而不是故事。目标是五到十二根条。
2. 先标出固定日期：发布、演示、合同截止。这些是里程碑，画成菱形，它们不会移动。
3. 用你真实的速率把每个史诗按冲刺估算规模，然后把它放到时间线上。
4. 画出史诗之间的依赖，尤其是那些跨团队的。这是价值最高的一步。
5. 找出依赖性史诗的最长链。那就是你要捍卫的路径。
6. 指定一位负责人，在每次冲刺评审时更新图表，别在其他时候更新。

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

保持轻量，否则它会消亡

甘特图在敏捷团队里失败的最大原因是分量。有人搭出一张漂亮的百行图表，它在一个冲刺内就过了时，于是团队得出结论说甘特图行不通。失败的不是图表，是粒度。一张发布甘特图应当小到让一个人在冲刺评审时用十分钟、拖动几根条、移动一个日期就能更新完。

像跟踪任何计划与现实的差距那样跟踪发布，把你说过每个史诗应当在哪里，与它实际落在哪里作比较。每次评审时做一次快速的基线核对，能在日期漂移演变成危机之前很久就告诉你它是否在漂移。一张搭好后就再也没人碰的甘特图不是计划，是愿望。要么更新它，要么删掉它，但别让它在共享盘里腐烂，还假装自己是真相。

何时干脆跳过甘特图

诚实是双向的。并非每项敏捷工作都需要甘特图，在它带不来任何价值的地方硬加一张，只是额外的负担。如果你的工作是一连串小而独立的事项的持续流动，既没有外部截止日期，也没有跨团队交接，那么一块看板就够了。一个纯维护团队、一条支持队列，或是一个每天都往生产环境交付的单一小队，从发布层里得到的很少，因为根本没有要塑造的发布。

当三个信号一同出现时，再去动用甘特图：一个你已经承诺过的固定外部日期、不止一个其工作依赖另一个团队的团队，以及一位需要一次看清整段跨度的干系人。当三者齐备时，待办列表会留下真正的问题悬而未决，而甘特图能回答它们。当一个都没有时，心安理得地跳过它，让看板去做它的本职工作。

常见问题

延伸阅读

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

本文也提供英文版本。