敏捷路线图的重要性以及构建、使用方法

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