敏捷路线图：构建、共享、使用与发展

摘要：产品路线图是指产品或解决方案随时间演变的行动计划。产品负责人利用路线图概述未来的产品功能和新功能的发布时间。在敏捷开发中使用路线图时，路线图可为团队的日常工作提供重要背景，并就竞争格局的变化做出响应。

有了敏捷开发，就不用再长期规划的想法堪称继尼斯湖水怪以来最大的神话。路线图对敏捷团队和瀑布式团队同样重要，因其可提供团队日常工作的背景信息，并就竞争格局的变化做出响应。不过，与传说中的苏格兰水兽不同的是，良好的敏捷路线图不仅很容易找到，也很容易理解。

产品路线图是指产品或解决方案随时间演变的行动计划。产品负责人利用路线图概述未来的产品功能和新功能的发布时间。在敏捷开发中使用路线图时，路线图可为团队的日常工作提供重要背景，并就竞争格局的变化做出响应。多个敏捷团队可以共用一个产品路线图。

制定路线图时，产品负责人需要考虑市场轨迹、价值主张和工程限制。理性理解这些因素后，要以计划和时间表的形式将其反映到路线图中。下面是产品团队可以使用的一些非常简单的路线图。其中，计划以蓝色字体表示，时间表以红色节点表示。

制定好路线图后，需要分享给整个产品团队，让所有人都能了解团队的愿景和方向。在很多组织当中，产品负责人会使用 PowerPoint 和电子表格来制定路线图，然后通过电子邮件将幻灯片和电子表格发给团队。尽管出发点是好的，但这种策略从一开始就存在缺陷。每个团队成员都有自己的路线图副本，而当路线图发生变化时，让所有人及时了解就变得非常麻烦（至少可以这么说）。

那么，产品负责人怎样才能确保团队成员及时了解最新消息呢？简单。

大部分针对这一情况构建的协作工具都会在路线图发生变化时向所有项目参与者发送通知，让他们及时了解相关情况。（如果您的工具不具有这一功能，可能您就需要买一个这样的工具了。）

在路线图中添加计划时，需考虑以下几个问题：

在我们讨论动态预测解决方案之前，让我们先来以建房子为比喻，聊聊制定长期敏捷计划的步骤：

• 各项计划的相对优先级如何？
• 我们打算什么时候启动各项计划？
  • 有没有对团队提出特定的日期要求？
  • 该计划在内部或其他团队具有哪些依赖关系？
• 各项计划分别由哪些团队参与？
  • 当前团队的日程安排是否有足够的空闲时间，能力上能否匹配？
  • 当前敏捷团队能否保持稳定？
    • 如果不能...
      • 如何对团队进行重组？
        • 我们是否考虑在项目时间表中增加新组建的团队？

务必要将您的团队工作与路线图建立关联，以把握我前面提到的整体“背景信息”。在这方面，有一个屡试不爽的做法是将计划分解为产品待办事项中的战略举措，然后进一步整理成要求和用户故事。将所有这些捆绑到一起可以让产品负责人和开发团队在不影响未来工作的前提下，更轻松地做出短期决策。我们来透过一个例子看看这种做法是如何发挥作用的。

假设我们在网站上推出了广泛的用户个人资料功能。然而，我们发现客户都不怎么用这个功能，那我们还要继续投资打磨这个功能吗？这个时候，可能要继续，也可能不要继续。在做出最终决定之前，我们需要了解其使用率低的原因。所以，与其硬着头皮向前推进，不如进行一些 A/B 测试，以获取一些关于使用率低的见解。相比直接硬着头皮向前，添加更多的花哨配饰，这些见解也许更能为我们指明方向。

在敏捷开发过程中，在做出重要决策之前，具备后退一步，深入研究的能力非常关键。有了这种能力，团队在对产品，对市场有了更多了解之后，便可以不断优化其功能。

瀑布式项目前期投资巨大。结果，团队成员在情感上对路线图产生了依赖，并以牺牲正确的决策为代价，因为否定既往付出太痛苦了，这是人性的弱点，如果有的话。

就其本身而言，敏捷开发会遇到三种不同风险：

• 如果路线图更新地过于频繁，团队可能会对领导层做出战略决策的能力失去信心。
• 如果路线图更新地不够频繁，则产品上市时可能为时已晚，错过了被压抑的需求。
• 对于较短的迭代来说，长期努力可能看起来“太庞大，也太困难了”。团队如果将工作划分地太精细，就可能出现过度补偿，最终过于关注短期结果。

为防止“遭遇重创”、迂腐和短视，需要确保在路线图上均匀地关注短期战术和战略以及长期目标。为此，一个比较好的办法是每季度审查一次路线图，并根据需要调整，然后分享。这一办法适用于任何规模的组织，但请记住：一个路线图可以涵盖多个敏捷团队，所以要进行相应的检查、调整和沟通。

继续阅读《敏捷教练》，了解具有跨团队路线图的敏捷产品组合的大型管理团队需要特别注意的事项。也可以详细了解 Jira Software 的路线图产品。