Liga译文 | 一文讲清「敏捷路线图」

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

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

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

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

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

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

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

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

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

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

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

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

02 SAFe：敏捷适配器

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

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

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

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

03 敏捷性需要空间来操作

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

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

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

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

1. 计划实现的路径必须是可塑的。 定义一个愿景或最终目标，但允许具体的功能和内容在执行时可以有所变化。 我们无法准确预测一个功能会如何运转，所以需要测试它。敏捷团队要允许每个功能能被反复加工、打磨或扩展几次，直到真正实现它。

2. 计划需要为调整和优化留出弹性空间。 如果时间已经全部按计划分配完，就需要删掉一些东西。正确的策略是在一开始就不要填满所有时间，让它保持开放状态；可以为新想法整理一个新队列，直到时间允许，再进入迭代分配。后文的 「Now-Next-Later」也会详细讲解这一方法。

3. 领导的支持。 这通常是三点中最难实现的。

04 领导力是敏捷性的关键

最具影响力的成功因素是组织展示和激励的领导范式。 —— Agile 2

很多领导层都认为敏捷是团队内部的事情。这种假设肯定是错误的，而领导们也需要以敏捷的方式行事。在项目过程中，如果要为团队提供调整的空间，领导者就要接受临时的计划。「可塑性强的路径」和「允许调整的弹性空间」印证了这点。

管理者要有足够的勇气和决心，才能对团队说：“我们不打算在这个迭代将你们的工作填满；你们需要跟着数据走，看看自己的工作成果。”

如果领导者要真正拥抱敏捷，他们就需要做出根本性的改变。这遵循精益创业的精神：建立一个项目、测试它、从数据中学习、并将这些经验直接反馈到后续的项目中。

同时，领导者也要有勇气，接受这些事实：团队不会在外部干扰下提前确定工作，也不会一轮接一轮无缝地进行功能开发。团队需要更多实验性、创造性和跨职能的工作。

这同样意味着，领导者需要快速响应、批准通过更多碎片化的需求变更。他们要探索出更灵活地工作方法，以便为团队提供及时审批。这无疑会打破官僚主义的枷锁，而由领导者们组成的小团队则能更快、更独立地监督和批准自己团队的工作。

05 Now-Next-Later 模型

更常用的敏捷路线图工具是 「Now-Next-Later」模型。甘特图中层层叠叠的功能集可以归纳总结为三个模块。

• Now：我们正在积极工作的事情。
• Next：「Now」完成后，即将开始的工作。
• Later：其他所有未分配和未承诺的功能。

将新的需求、功能和工作按模块规划好，比挤进拥挤的甘特图要容易得多。我们可以很轻松地在每个模块中留出弹性容量空间，以便后续根据最新信息做出调整。

可以看到，「Now」中的项目定义得比「Next」更加详细，「Later」是定义和描述最少的。每个模块的时间跨度可以自由决定，但最好跨度大一些，尽量覆盖多个迭代和优化周期；建议的时间周期是每个模块 6 周或者一个季度。

正确地使用「Now-Next-Later」，既能让我们适应短期变化，为后续工作和 Bug 修复留出空间，也能适应长期变化，改变我们对哪些功能要从模块中取出的想法。

但它不会消除干系人要求尽快交付功能的压力。这也是为什么领导者需要自己拥抱敏捷，才能让团队成功。领导者需要通过自己的努力，倡导敏捷的工作方式，并以同样的标准要求自己。

06 结论

许多自称敏捷的组织，他们提前计划了大量功能列表——通常提前一整年——并告诉团队要以小批量的方式交付。这不是敏捷，这是增量瀑布。

敏捷开发的核心特征是小批量地交付可工作的产品，从早期迭代中获得洞察力，并在后续迭代中进一步完善和优化相同的功能。 其中的关键在于我们无法预知和确定什么是可行的，什么是行不通的；这需要洞察和跟踪数据。打造一款优秀的产品，我们要一边走，一边制定计划。这与一年长的甘特图完全不同。

「Now-Next-Later」只有与团队自主权相结合时才有意义。这样才能使团队发现计划的调整空间，及时做出应对。

想要灵活地工作，在做计划时要注意建立高度灵活的路线图、留出充足的弹性空间用于响应调整，以及获得领导层的积极支持。利用好这三点，就可以持续地引导项目，而不是在前期就将它固定下来。这就是敏捷真正的意义所在。

---

原文作者：Raj Nagappan
文章出处：Medium

了解更多敏捷开发、项目管理、行业动态等消息，关注我们 LigaAI@oschina 或点击LigaAI - 新一代智能研发协作平台，在线申请体验我们的产品。