实施敏捷开发并不代表你不知道目标在哪，而是意味着你将使用灵活的方式达成目标。Product Owner 需要使用路线图来概述在未来产品将有哪些功能，以及这些新功能将在何时发布。本文将分享敏捷开发情境下路线图构建、使用、以及实现信息共享的方法。
实施敏捷开发就意味着“抛弃长期规划”这种观点并不正确。路线图对于敏捷团队和瀑布团队同样重要，因为它为团队的日常工作提供了背景信息，并让团队能够及时响应竞争格局的变化。与传言中“难以理解的敏捷路线图”不同，正确的敏捷路线图很容易构建和理解。
一、什么是产品路线图
产品路线图是产品或解决方案如何随时间演变的工作计划。Product Owner （产品负责人）使用路线图来概述在未来产品将有哪些功能，以及这些新功能将在何时发布。当路线图用于敏捷开发时，它能为团队的日常工作提供了重要的背景信息，并且能够指引团队响应竞争格局的变化。在有些情况下，多个敏捷团队可以基于一个产品路线图进行工作。
二、如何构建产品路线图
在构建产品路线图时，Product Owner 需要考虑市场发展趋势、产品价值和资源限制等因素，一旦这些因素在分析评估之后，它们就会变成一个个计划和史诗（或特性\用户故事）在路线图中呈现。下面是 PingCode 团队常用路线图示例：史诗为宏观的目标，史诗下由特性和用户故事等分解为颗粒度更小、可执行的目标，然后通过红色的里程碑标记目标每个阶段的完成节点。
三、如何通过产品路线图实现信息共享
一旦构建了路线图，就需要与整个产品团队共享，以便每个人都了解目标和规划。在很多团队，Product Owner 会用 PPT 和 Excel 表格创建路线图，然后通过电子邮件发送给团队成员。这种方式的出发点非常好，但是存在缺陷，因为这样做会让每个团队成员都有自己使用的路线图版本，并且无论是让每个人都自己更新路线图，还是自己更新之后再发送最新版本，这样都会带来一些不便。
那么 Product Owner 如何让团队及时了解路线图的变更和进度呢？非常简单。
大多数的研发项目协作工具都会自动通知项目的所有参与者，让他们知道路线图已更改。（如过你还没体验过该类工具，可通过 PingCode 了解）
当 Product Owner 将计划添加到路线图时，需要考虑以下问题：
- 每个史诗目标的优先级是什么？
- 每项计划的开展时间是什么？
- 是否需要团队在特定时间完成？
- 任务具有哪些前后依赖关系，是否涉及内部团队或外部团队？
- 每个团队都分别在处理哪些计划？
- 当前负责团队是否有足够的工作时间和工作容量？
- 新计划加入我们能保持目前的敏捷团队稳定吗？
- 如果不能，团队可以怎么调整重组？
- 是否在项目时间计划中考虑了新组建的团队？
- 如果不能，团队可以怎么调整重组？
四、如何使用产品路线图
将团队的工作内容和路线图关联起来很重要，因为只有这样你才能获得我们前文中提到的整个任务“上下游”信息。一种行之有效的方法是将计划分解为产品待办事项列表中的史诗，然后进一步将它们分解为特性和用户故事。这样就能将它们关联在一起，使 Product Owner 和开发团队更容易安全合理的做出短期规划。让我们看一个例子，看看这是如何发挥作用的。
比如我们项目管理产品上推出了“搜索消息内容”的功能，但发现用户对于该功能的使用度很低，这个功能之后是否要继续上线和迭代？在做出决定前我们需要分析原因，可以通过一些A/B 测试来帮助决策，以及参照路线图的产品规划，了解哪个方案的用户使用数据更接近产品目标和发展方向。
在做出关键决策之前先退后一步进行更深入的研究，这是敏捷路线图的一个重要特点，它使团队能够在更多地了解产品和市场之后再决定是否开发该功能。但有一些需要避免的错误做法：
- 完全忽略长期规划
- 其他团队对于自己团队在做什么一无所知
- 频繁更新或从不更新路线图
- 路线图的过多的呈现细节
产品路线图扩展
在瀑布项目，由于在开始前需要大量的前期投资，因此更改需求会让团队成员前功尽弃，所以团队成员宁愿遵循原本的路线图而不做出正确的选择，这是可能存在的一种状况。
而在敏捷开发项目中，则可能会遭遇三种不同的风险：
- 如果路线图更新得太频繁，团队可能会对领导层的战略决策能力失去信心
- 如果路线图更新不够频繁，该产品可能会因上市太晚而丧失风口机会
- 过渡聚焦在短期策略上，而忽略了与长期规划对齐，并以过多的细节进行弥补
因此，为了打破陈旧的框架，促进产品的长远发展，路线图应该均匀体现产品的短期目标和长期战略。这里推荐一个适用于所有团队项目的方法：每季度审查一次产品路线图，根据市场需要进行调整并及时同步给团队；同时注意一个路线图目标可能多个团队共享，因此及时调整和沟通同步。
