一文讲清「敏捷路线图」，从此不再掉入瀑布陷阱

尽管许多组织和团队声称自己非常敏捷，但他们仍在使用瀑布的方式规划产品。为什么会这样？我们该如何改变这种「错误敏捷」？

原则上，践行敏捷开发很简单：构建一个增量；测试这个增量；了解需要改变的信息；将信息反馈到第一步中，并重复步骤。

整个过程可以从两个方面，将敏捷开发与瀑布开发彻底区分开：第一，尽早且频繁地交付小批量的可工作的产品；第二，根据（一）得到的新变化和信息，对产品进行恰当的调整。

如下图所示的敏捷路线图很常见。时长一年的甘特图上堆满了功能，并提前完成了任务分配。研发团队只能在一个个不间断的迭代中，实现所有的功能；他们还没有机会总结已交付的工作并作出调整，就必须立刻进入下一个功能开发。

图1. 这样的甘特图怎么可能敏捷？

如果前两个产品功能交付后被证明是错误的（这非常有可能发生），难道我们还要按原计划迭代下去吗？继续遵循上面的甘特图，可能会一错到底。因为计划好的路线图无法帮助我们评估交付效果，识别问题并及时调整。

敏捷开发刻意只关注下一次迭代的即时计划，但许多团队构建了一年甚至更长时间的甘特图，并且罗列了无数个待开发功能和完成截止日期。这样怎么会敏捷呢？

01 前瞻性计划：敏捷刻意忽略的部分

除了当前迭代正在构建的产品外，敏捷方法论不太关注前瞻性的计划。因为只有这样才能做到 「实时计划」 ——我们应该看到什么是可行/不可行的，并根据反馈的数据决定下一步该怎么做。

敏捷意味着「能够快速轻松地行动」，而敏捷开发需要被持续引导，逐步提供价值，再根据市场反馈的情况快速调整策略和方向。 这是一个建立在洞察与反应几乎同步的快速反馈周期，而不是基于前期的大计划。

但是，组织（尤其是大型或传统组织）通常不喜欢没有计划地工作。没有计划的组织会陷入「计划缺失焦虑症」；更准确地说，组织的领导者会很焦虑。因此，他们会制定一个功能列表，提前做好分配，以确保每个人都能按预定的方式有序地工作。

敏捷的组织应当正面解决计划缺失的焦虑，但许多团队没有这样做。反而是领导者们认为，过去路线图和甘特图很有用，那就应该继续使用它们。慢慢地，敏捷就变形成「Water-Scrum-Fall」，就像下图这样。

图2. 迭代中的「敏捷式开发」仅是瀑布开发中很小的部分

不幸的是，敏捷的核心——灵活自由地根据新信息进行调整——被完全忽略了。许多团队实践的敏捷并不是真的敏捷，而过去的瀑布式任务列表也演变成了「用户故事」列表。

敏捷框架没有提供任何当前迭代以外的具体规划建议，而扩展框架正填补了这一空白。SAFe 有一个优点：作为从前期瀑布式大计划到团队敏捷执行的适配器，它可以很容易地被理解。

使用 SAFe（或其他扩展框架），产品管理团队提出功能，设计团队绘制 UI 模型，再发送给管理层审批。当工程师开始编写代码时，管理层会很放心。因为他们已经做好了充分的计划，而成百上千名程序员都会尽职尽责地工作。

通过敏捷扩展框架，管理人员可以看到所有计划中的功能，而开发人员可以在迭代中专注地写代码。这也是敏捷扩展框架受欢迎的原因：它们将领导者熟悉的大型计划，转换为研发团队可执行的敏捷迭代。在一些高级管理者看来，这就是最重要的。

事实上，工程团队已沦为「功能工厂」，他们几乎失去了所有学习、快速调整和改变的能力。管理者却真诚地相信，团队已经完成「敏捷转型」。

回到前面提到的两个决定性敏捷特征：尽早且频繁地交付小批量的可工作的产品；根据（一）得到的新变化和信息，对产品进行恰当的调整。

第一点比较好理解，几乎所有资料也都集中在这上面；能够正确掌握第二点的人要少很多。如果团队没有从早期部署的迭代中学习，也没有将洞察力融入后续的迭代优化，那么就没有正确地践行敏捷——这其实只是 「增量瀑布」。

正确的敏捷要求组织多次发布和重新发布相同的功能，并且每次都要从早期的经验中吸取教训，使该功能更易于使用、更强大、性能更好或在某些方面更好。这需要时间，而且这些时间无法在前期被充分估计和预先承诺。

因此，要想成功地洞悉变化，完成迭代优化，团队需要在计划中做到以下三点。

计划实现的路径必须是可塑的。 定义一个愿景或最终目标，但允许具体的功能和内容在执行时可以有所变化。 我们无法准确预测一个功能会如何运转，所以需要测试它。敏捷团队要允许每个功能能被反复加工、打磨或扩展几次，直到真正实现它。
计划需要为调整和优化留出弹性空间。 如果时间已经全部按计划分配完，就需要删掉一些东西。正确的策略是在一开始就不要填满所有时间，让它保持开放状态；可以为新想法整理一个新队列，直到时间允许，再进入迭代分配。后文的「Now-Next-Later」也会详细讲解这一方法。
领导的支持。 这通常是三点中最难实现的。