Dual-Track Agile

Dual-Track Agile 由 Marty Cagan 和 Jeff Patton 推广普及，建立在 Desiree Sy 在 Alias 早期工作的基础之上，它把「弄清楚该构建什么」这项活动，和「把它构建出来」这项活动区分开——但没有把人分开。探索轨道运行实验、访谈、原型和分析，以降低候选想法的风险。交付轨道把经过验证的想法，转化为可交付、具备生产质量的软件。两条轨道都持续并行运行，一周接着一周。

连接的机制是一个单一的、按优先级排序的待办事项列表。探索的工作，是用已经通过了关键风险检验的条目——价值（客户会想要吗）、可用性、可行性，以及商业可行性——来填充这个列表。交付则从这个列表的顶部拉取条目。团队是同一群人，在不同时刻戴着不同的帽子，而不是两个分别配备人力的单位。

最大的失误模式，是把这两条轨道当成两个团队来对待：一个由 PM、设计师和研究员组成的「探索团队」，把经过验证的规格文档扔过一堵墙，交给一个由工程师组成的「交付团队」。这恰恰重建了 dual-track 本该消解的瀑布式交接。工程师失去了对「为什么要构建这个」的理解，设计师失去了关于「到底什么才可行」的反馈，待办事项列表里堆满了交付端没有任何人参与打磨过的详细方案。

这两条轨道是并行的工作流，不是组织单位。工程师参与探索——在可行性 spike 上进行结对，评审原型，提前标记技术风险。设计师和 PM 在交付过程中持续保持参与。让它们并行运行的意义在于，同一批人把上下文带向两个方向，因此一个探索发现可以在它出现的当周就重新引导交付。

探索饥饿是常见的症状：在交付压力下，探索轨道会悄悄地清空，团队又退回到构建声音最大的利益相关者所要求的东西。修复方法，是把探索保护为一种持续的产能，而不是一个阶段——是每个周期里固定的一份，而不是一个会「完成」的项目。

相反的失败，是探索远远跑到了交付前面，产生了一大批经过验证、却在交付之前就过时了的想法库存。健康的节奏让两条轨道大致保持同步：探索保持领先一到两个交付周期，而不是十个。留意第二种反模式——「验证剧场」，即探索产出的是幻灯片和主观意见，而不是证据。探索条目进入待办事项列表时，应该明确写明它们消除了什么具体风险（例如「8 个目标用户中有 7 个无需帮助就完成了任务」），否则它们就不算是真正被探索过。

只有当探索发现和交付工作共享同一个事实来源时，dual-track 才能奏效——也就是验证了某个想法的客户访谈、提出这个想法的收入群体，以及构建它的 sprint 卡片，是连接在一起的，而不是分散在一个研究仓库、一个反馈收件箱和一个独立的追踪工具里。当它们分开存在时，上下文就会在轨道之间的交接中丢失，团队就会退回去构建未经验证的工作。

建立在共享主线之上的产品操作系统，会把这些连接在一起：在探索中捕获的一条洞察，会一直和机会、背后的客户，以及它最终变成的交付任务保持关联。AIOProductOS 的反馈与探索模块、PM 看板，以及 Customer 360，都从同一条记录中读取数据，因此一张交付卡片可以展示证明它成立的证据，一个探索发现也可以被追溯到它触发的工作——让一个待办事项列表真正由同一套事实支撑。