很多团队认为，敏捷的价值观是“拥抱变化胜于执行计划”。那么，既然咱们做敏捷了，那就不用做什么计划了。

这是对敏捷价值观的误解。如果完全没有计划，团队一定会得过且过，没有危机感，致使项目一片混乱。这样的话，前几节介绍的商业模式、产品愿景都将无法落地实现。我在前面介绍的Sprint计划和看板填充节奏都是敏捷里的计划活动，但敏捷计划不只是这些。

很多敏捷团队非常专注于眼前的工作，只关注当前迭代的交付，或者是那些已经进入看板就绪队列的需求的交付，但是对产品下一步要做什么、未来要做什么都不清楚。

实际上，产品规划是在多个层面上持续进行的活动，我称之为“洋葱圈规划”，如图8-12所示。

图8-12洋葱圈规划示意图

表8-3介绍了各层级计划活动的时间节奏、活动参与人和计划的重点内容。

表8-3各层级计划内容一览表

第1层：投资组合计划

一个企业或业务部门一般会并行管理多个产品，这时需要在整个组织层面规划好要投资做哪些产品、要对哪些产品撤出投资，以及正在做的产品准备何时上市。

投资组合计划除了规划整个组织的产品研发上线时间，还需要规划产品的预算、人力等成本。

第2层：产品路线图计划

对于一个创新产品而言，在团队创建了商业模式和产品愿景，并用第一版MMR探索了市场反馈之后，团队对需要做哪些优化心里更加有谱。这时，团队可以规划相对长期的产品路线图。

团队通常产品路线图以季度或月度为单位，来规划即将发布的产品的重大特性。产品路线图包括以下内容：

• 重要版本的发布时间；
• 重要版本的名称；
• 重要版本要实现的目标；
• 重要版本的特性（这些特性不需要做详细拆分）。
  

产品路线图计划是渐进明晰的，即发布时间越近，产品特性越明确，交付时间越准确；发布时间越远，产品特性越不明晰，启动时间越不明确。当时间节点到的时候，一般团队会召集人员对产品路线图的实施情况进行评审，并对产品路线图进行更新。

第3层：版本计划

在产品路线图的每个时间段内都会有一个或多个版本发布。产品路线图规划了某个时间节点上要交付的产品特性；而版本计划则更加详细，团队不仅需要将特性拆分成最小价值单元的用户故事，还要依据团队的速率数据，计划一个版本的完成需要多少个迭代。版本计划也是渐进明晰的，即相对于当前版本计划，越往后的版本计划越粗略，特性拆分的粒度也越粗。

团队支付一个版本后，一般会召开版本评审会议和回顾会议，其流程与Sprint评审会议、Sprint回顾会议相似。所以，团队在版本最后一个迭代的时候，可以将Sprint评审会议和回顾会议的范围拓展到对整个版本的评审和回顾。

第4层：迭代计划

一个版本可能会经过多个迭代才能完成。每个迭代都要有明确的计划，当迭代结束时，团队要召开评审和回顾会议。

需要说明的是，很多互联网团队的交付能力比较成熟，每个迭代甚至在每天都会发布多个版本。这说明，版本周期小于迭代周期。在这种情况下，团队一般不需要召开评审和回顾会议。

第5层：每日站会

每日站会是团队成员每天对项目情况进行审视，并计划当天的工作的活动。因此，每日站会是最小单元的计划活动。

很多团队认为，敏捷的价值观是“拥抱变化胜于执行计划”。那么，既然咱们做敏捷了，那就不用做什么计划了。

这是对敏捷价值观的误解。如果完全没有计划，团队一定会得过且过，没有危机感，致使项目一片混乱。这样的话，前几节介绍的商业模式、产品愿景都将无法落地实现。我在前面介绍的Sprint计划和看板填充节奏都是敏捷里的计划活动，但敏捷计划不只是这些。

很多敏捷团队非常专注于眼前的工作，只关注当前迭代的交付，或者是那些已经进入看板就绪队列的需求的交付，但是对产品下一步要做什么、未来要做什么都不清楚。

实际上，产品规划是在多个层面上持续进行的活动，我称之为“洋葱圈规划”，如图8-12所示。

图8-12洋葱圈规划示意图

表8-3介绍了各层级计划活动的时间节奏、活动参与人和计划的重点内容。

表8-3各层级计划内容一览表

第1层：投资组合计划

一个企业或业务部门一般会并行管理多个产品，这时需要在整个组织层面规划好要投资做哪些产品、要对哪些产品撤出投资，以及正在做的产品准备何时上市。

投资组合计划除了规划整个组织的产品研发上线时间，还需要规划产品的预算、人力等成本。

第2层：产品路线图计划

对于一个创新产品而言，在团队创建了商业模式和产品愿景，并用第一版MMR探索了市场反馈之后，团队对需要做哪些优化心里更加有谱。这时，团队可以规划相对长期的产品路线图。

团队通常产品路线图以季度或月度为单位，来规划即将发布的产品的重大特性。产品路线图包括以下内容：

• 重要版本的发布时间；
• 重要版本的名称；
• 重要版本要实现的目标；
• 重要版本的特性（这些特性不需要做详细拆分）。
  

产品路线图计划是渐进明晰的，即发布时间越近，产品特性越明确，交付时间越准确；发布时间越远，产品特性越不明晰，启动时间越不明确。当时间节点到的时候，一般团队会召集人员对产品路线图的实施情况进行评审，并对产品路线图进行更新。

第3层：版本计划

在产品路线图的每个时间段内都会有一个或多个版本发布。产品路线图规划了某个时间节点上要交付的产品特性；而版本计划则更加详细，团队不仅需要将特性拆分成最小价值单元的用户故事，还要依据团队的速率数据，计划一个版本的完成需要多少个迭代。版本计划也是渐进明晰的，即相对于当前版本计划，越往后的版本计划越粗略，特性拆分的粒度也越粗。

团队支付一个版本后，一般会召开版本评审会议和回顾会议，其流程与Sprint评审会议、Sprint回顾会议相似。所以，团队在版本最后一个迭代的时候，可以将Sprint评审会议和回顾会议的范围拓展到对整个版本的评审和回顾。

第4层：迭代计划

一个版本可能会经过多个迭代才能完成。每个迭代都要有明确的计划，当迭代结束时，团队要召开评审和回顾会议。

需要说明的是，很多互联网团队的交付能力比较成熟，每个迭代甚至在每天都会发布多个版本。这说明，版本周期小于迭代周期。在这种情况下，团队一般不需要召开评审和回顾会议。

第5层：每日站会

每日站会是团队成员每天对项目情况进行审视，并计划当天的工作的活动。因此，每日站会是最小单元的计划活动。