未来的产品开发任务是无法被预先确定的。将计划和控制权分配给那些能理解并对最终结果做出反应的人。 —— 迈克尔·肯尼迪，精益企业产品开发
SAFe中没有魔法，也许除了PI Planning。 —— 匿名
对于正在进行SAFe规模化敏捷的朋友，上面这句话应该是耳熟能详的，毕竟这是官方的解释
https://www.scaledagileframework.com/pi-planning/
纸上得来终觉浅，但真正做的时候还是明显的能够感受到很多细节的地方。
- 为什么要做PI Planning 在Scrum团队中可以通过Planning Meeting完成从PB到SB的梳理，通过Refinement完成进一步的功能澄清，通过Review会议完成Increment的演示。 这些都是建立在小团队、目标清晰的情况下，一旦上升到多个团队，那么团队和团队之间使用类似SOS的方式进行扩张虽然可行，但是忽略了业务方的参与度，加上参与角色的限制，导致团队和团队之间的协作越发困难，进一步构建了新的部门墙。 PI就是一个让所有人参与的活动，去了解我们是谁，我们要做什么，我们要去哪里。而让所有参与方深刻意识到这不是一个所谓大杂烩的会议，并且清晰的理解每一步该做什么，本身需要大量的培训，引导。 通过基于ART的Retro构建一个节拍对上一个PI的思考，构建一个节拍基于ART的Planing对于下一个PI的展望，让模糊的事情清晰一点，让所有团队之间的认知更加统一。
- PI Planning前需要准备什么
PI需要Business Own的深度参与，为整个ART团队介绍商业背景；由PM介绍系统整体的路线图、Program Board中主要功能的和里程碑；由架构师提供技术架构上构建规划；
这里就在业务和技术两方面同时为业务目标提供了对应的参考，而不仅仅是让BO理解功能怎么实现，也要关注技术所带来的的额外成本。
为了保证PI能够顺利的进行，相关的同步工具，协作工具也不可少，例如线下的看板，线上的Miro板等。由于PI的时间有限，提前对某些已知的Feature进行梳理也是有必要的。
3.PI planning各个阶段在做啥
看起来内容很多，但是简单总结下可以归为以下几类：
- 我们要做啥，现在我们能做啥，有什么要考虑的技术架构；
- 团队根据Program Board进行所有Feature的拆解，并且同步团队和团队之间的依赖，构建迭代交付的规划；
- 评估迭代交付的能力和实际交付的负载，评估交付风险；
- 同步评估风险及交付目标Business Value的打分投票；
往往团队内部自己梳理的过程都比较顺利，有成熟的Planning Meeting经验，但一旦涉及到依赖关系，往往就出现时间捉襟见肘的情况。而这正是PI所希望达到的目标，将团队之间依赖的风险暴露。
那么在进行Team Breakouts中为了减少这类依赖导致的时间紧张问题，就需要围绕高风险高价值的内容尽早评估尽早安排对应的Sprint，而对于剩余的Feature团队给出对应的规模评估后，根据团队的Capacity能力进行排列，确保每个Sprint的Load不会超标。
通过PO对交付目标的介绍，团队之间进行协调，可以在第二天对目标进行调整，重新对齐整个PI的交付计划，并与团队内部进行进一步调整。而这个调整过程也就是适应过程，依赖于Feature下的各个任务相互依赖及优先级的清晰性。
针对中间可能存在的风险（技术风险、节假日风险等）进行分类归纳。
最后的介绍中BO会对每个团队的PI Objectives交付目标进行BV打分，从而对齐业务方与技术团队之间的目标，并为后续ART Demo确认节奏。
4.PI planning形式没啥特别的，为什么做了也没啥用
如果非要说PI做了啥，本质上就是让所有相关方在一起都参与了未来整个ART的交付规划。BO参与开始要做什么及最后做的内容是不是自己想要的；PM及架构师给出了整个团队Feature之间的关系梳理及技术架构支持；交付团队给出了Feature梳理之间的联系，工作量的评估及可能存在的风险。
形式是很容易模仿的，但是做好是依赖于一些历史的经验教训的。好比做多个家庭之间的共同旅游计划，每个家庭自己的能力、认知、情况都有不同，要最后按照一个大家都能不产生阻碍的节奏进行整个假期是很困难的。什么时候大家要在一起，什么时候自由活动，如果遇到某些意外怎么办。相信如果做过旅游攻略的，两个年轻人出去玩可以完全的“敏捷”，两队年轻人可能就要有一些不同的景点要协调，而多队拖家带口的时候，做好万全的规划就相当于的困难。
所以做纯敏捷不难，做纯瀑布也不难，难在怎么根据团队当前的组织、目标、能力做一个目标瀑布，交付敏捷的适度规则。
