关于SAFe流程中PI Planning的认知迭代

目前，在软件开发工程领域，敏捷开发流程已经逐步取代瀑布开发流程成为主流。敏捷开发流程的最大特点是以两个星期为一个开发周期（即Sprint）逐步进行迭代，从而更好的响应来自客户需求，UI设计或者技术方案的变化。Sprint Planning可以说是整个流程中最重要的一步了，在这一步会理清需求，消除尽可能多的不确定因素，从而确定下来整个Sprint任务的范围进而分配任务到个人，让团队能够稳定的交付。

我目前所在的企业，开发流程采用了企业级的Scrum框架SAFe(scaled agile framework)，它相对于经典Scrum流程，增加了许多环节，其中一个就是PI Planning。PI Pllanning是针对一个PI，通常是6个Sprint中的5个正常的开发Sprint的范围作计划，剩下的1个IP Sprint用于PI Planning、Innovation和修bug等等。

刚接触SAFe流程时，我最大的困惑就是关于PI Planning了。按照Sprint Planning的思路来推演，计划是为了消除变化，从而稳定的交付，那么计划的周期越长，不确定因素就越多，也就越难消除变化。

一个PI的目标确定下来后，它工作内容的范围基本上是固定的，通常是不会更改的。相对固定的工作内容，一方面让响应变化的周期将从一个Sprint扩大的一个PI；另一方面，在PI Planning时，是会把要做的工作细化到把每个Sprint中去的，当PI Planning结束时，每个Sprint要做的事情也会有个大概，并且相对固定，那么Sprint Planning的作用会削弱，更偏向于任务的细化和分配。

这样的流程中一个隐藏的困境就是一旦某个Sprint的工作因为各种原因滞后或者错误估计了，其实是没有多少调整空间的，要不就会影响后续的Sprint。

关于这个潜在风险，SAFe的指导原则是，除了第一个Sprint需要排满工作量，后面的Sprint的工作量可以逐渐递减来应对一些预期之外的变化。这是一个好的建议，但是因为整个PI的目标是固定的，如果再加上如果整体开发工作的时间节点是固定的，这个原则就真的只起“指导”作用。于是，再高大上的管理流程，在干活的人眼里也只是“理想”，现实才是真实的。

借用薛兆丰老师在得到专栏《北大经济学课》的一句话来说，“凡政策必遭遇对策”，开发团队的“对策”就是：

1. 重视PI Backlog Grooming，在PI Planning之前尽可能的发现不明确的地方，并尽可能的想办法消除。方法不外乎两种，要么自己研究，要么问明白人。

2. 合理的估计团队的工作能力，即Velocity。

3. 合理的协调PO(Product Owner)的期望。

前两条SAFe的指导原则中有提到。后面两条团队处理的好坏在一定程序体现了这是否是一个成熟的团队，没什么太好的方法，需要一定的时间，来慢慢磨合。

如果这三条都没做好，那只能是自己挖的坑，自己填，硬着头皮上吧，需要加班就加班吧，千万别问不是说好的，跑了Scrum就会不加班了吗？嘿嘿

简单来说，那时我就是把PI Planning当大号的Sprint Planning来对待的。加上在公司的前几个项目，都比较独立，和其它的团队交集不是很多。于是，在相当长的时间里，我都觉得PI Planning有些鸡肋。

这个印象直到去年开始做公司的下一代平台中的项目时才有此许改变。公司在下一代平台的项目上投入了很大的资源，方方面面有10多个团队工作在不同的子项目上，这样的项目背景是SAFe最适用的场景。

PI Plannning提供了一个合适的窗口来协调各个团队之间的依赖，并分析潜在的风险。我试着用更高的格局来看待PI Planning，把PI Planning中计划的Feature类比为Sprint Planning中的User Story，参与PI Planning中的各个团队类比为参与Sprint Planning中的一个个成员，那么PI Planning其实是身处幕后的管理团队的Sprint Planning，只是他们需要通过各个团队的反馈来实现，而不是自己实现。

再则，因为计划的粒度变大了(Feature通常有多个User Story组成，User Story又由多个Task组成)，所以计划的周期由两个星期扩大到三个月是合理的。

顺着这个思路想，高管团队应该是通过管理团队的Release Planning来做他们的Sprint Planning，周期就更长了。

回到团队的角度，作为要落地实施的团队成员，相对于Sprint Planning，PI Planning需要的考虑的因素多了，计划的粒度大了（即计划的是User Story，而不是Task），所以本质上还是存在当计划的粒度变大周期拉长，不确定因素概率变大的问题。我接受了这是一个限制，因为能够解决的问题是问题，不能够解决的问题就是限制，只能接受。

按我的理解，一个开发团队走向成熟的过程就是和这个限制逐渐和解的过程。

参考：

https://zhuanlan.zhihu.com/p/28002721