摆脱甘特图后遗症的发布规划：常见的敏捷陷阱
敏捷交付中最顽固的迷思之一，是认为规划一次发布在某种程度上不够敏捷——好像对当前冲刺之外的任何事做出承诺，就背叛了敏捷的精神。并非如此。《Scrum 指南》说得很清楚：产品负责人对产品待办列表进行排序以最大化价值，产品目标则给团队一个更长期的努力方向。发布规划不过是把这个目标与一个团队之外的人可以依赖的日期连接起来。问题在于，大多数团队要么像瀑布式排期那样过度规划，要么干脆拒绝规划。
这两个极端都有害。在2022年这样的年份里，预算在收紧，干系人既想要可预测性又不愿牺牲应对变化的能力，把发布规划做对，决定了一支团队是被信任还是被事无巨细地监管。以下是这些陷阱。
把发布规划变成做戏的错误
按范围规划，而不是按价值规划。 为一个固定日期锁定一份固定的功能清单，等于假设过程中不会学到任何东西。但以冲刺方式工作的全部意义恰恰在于你会有所学——因此发布计划应当承诺一个结果（产品目标），并把功能清单当作预测，而非合同。
把速率当成承诺。 在一支稳定的团队内，速率是有用的规划输入，但它是平均值，而非保证。把上个冲刺的点数乘以距截止日期的冲刺数，会得出一个整齐的数字，却悄悄忽略了波动、假期，以及尚未估算的工作。
尚未就绪、无法用于规划的待办列表。 如果靠前的条目含糊、过大或充满未知，任何基于它们的发布预测都是虚构。待办列表梳理不是可有可无的整理——它正是让前瞻性规划成为可能的前提。
把发布计划当成一成不变。 一份在一月做出、之后从不复审的预测，比没有计划更糟，因为大家仍然相信它。预测应随着每个冲刺真实数据的到来而更新——这才使它可信，而非一厢情愿。
为了显得有把握而隐藏不确定性。 用虚假的精确报出单一日期，是在为所有人铺设失望的伏笔。一个区间，并把背后的假设明白地说出来，更可信，也对依赖它的人更有用。
如何诚实地规划一次发布
从产品目标出发，而不是从功能清单出发。先问这次发布必须达成什么结果，再让排好序的产品待办列表向你展示通往该结果的最小工作集合。有几项实践能让计划脚踏实地：
用区间而非单一日期来做预测，并说明区间所依赖的假设，以便它们可以被质疑。
持续梳理待办列表的前部，使接下来几个冲刺的工作被充分理解、规模适当。
每个冲刺都用实际完成的工作重新预测，并在情况变化时及时告知干系人，而不是等到最后。
守住产品目标，但让范围有弹性——如果交付吃紧，先舍弃或推迟价值最低的条目。
这并不比传统计划更不严谨；这是把严谨对准了正确的目标。你不再去捍卫一个在所知最少时做出的猜测，而是用手头最好的信息持续打磨一份预测。干系人得到的是他们真正想要的可预测性——对何事可能发生、何时发生的可靠判断——而无需逼团队假装未来是固定的。
这样进行的发布规划，把关于取舍的那场不可避免的对话，从截止日的危机变成了寻常而频繁的交流。计划于是成为一份关于价值与时机、共享而鲜活的约定，而这正是计划本应有的样子。
如果你的团队卡在僵硬的路线图与完全没有计划之间，XNM 的项目集与项目交付咨询服务可以帮你建立一套诚实、有用、并被干系人信任的发布规划。