SAFe之PI运作指南

PI（Program Increment）是SAFe中的一个基本概念，目前还没有一个贴切的中文翻译，我们就直接称其PI好了。

1. ART中存在着两级增量开发节奏

图1 ART中的两级增量开发节奏

对于需要多个敏捷团队协同开发和交付的解决方案，存在着两级增量开发节奏（如图1所示）：

• 团队级增量开发节奏：每个敏捷团队需要以固定的迭代节奏进行增量开发。为了实现多团队的同步，所有团队都必须做到节奏一致。
• ART级增量开发节奏：解决方案同样需要以固定的迭代节奏进行增量构建。一个解决方案增量，往往需要多个开发迭代才能完成。

2. PI以及其用途

PI，就是固定的ART级增量开发节奏。通过设置固定的PI节奏，我们能够实现以下目的：

• 有节奏地进行ART工作规划，提供工作的预测性。
• 有节奏地获得解决方案的外部反馈，以学习和完善解决方案。
• 限制每个解决方案增量版本的内容，加快价值流动，以期更加频密地交付价值。
• 在ART级进行持续地回顾和改进。

3. PI的时长和构成

经验表明，PI持续时间在8周到12周之间效果最好。

图2 PI构成示意图

PI由一系列的迭代构成。

在Scrum实施中，Scrum团队往往会把迭代的开发工作排得过满，从而出现在团队改进和下迭代准备上投入不足的情况。SAFe在设计PI结构时对此做了优化，将其设计为n+1模式——n个开发迭代 + 1个创新和规划（IP，Innovation and Planning）迭代，以更好地实现ART级PDCA学习循环。（最典型为4+1模式——4个开发迭代+1个创新和规划迭代。）

4. 按节奏开发和按需发布

PI提供了解决方案的增量开发节奏，但并不意味着解决方案系统必须按此节奏来进行发布。

企业可以根据需要，选择在任何合适时机执行解决方案系统的发布。简单来说，就是既可以在1个PI内完成多次解决方案系统的发布，也可以经过多个PI才做一次解决方案系统的发布。

图3 PI事件

如图3所示，PI采用了类似于敏捷迭代的五个事件来进行管理。这五个事件形成了一个闭环的体系，可以保证敏捷发布火车的持续、顺利运行。

我们可以把PI事件与敏捷迭代事件做一个对比，具体见表1。

表1 PI事件与敏捷迭代事件的对比

1. PI Planning（PI计划会议）

PI始于PI Planning会议。

由于PI以固定的节奏进行，所以PI Planning的日期几乎是固定的，这就使得ART团队能提前在日程表上安排PI Planning事件，以确保ART团队成员都能参与。

在PI Planning期间，团队对要交付的内容和交付时间进行估算，识别风险以及各项工作的跨团队依赖关系，并整合形成最终要开发、集成和演示的工作清单，以及将在哪个迭代完成这些事项的计划，具体如图4所示。

图4 PI Planning的输出

2. ART Sync

1）Scrum of Scrums（SoS）

在PI期间，RTE（Release Train Engineer，发布火车工程师）会组织召开SoS（Scrum of Scrums）会议，以持续协调和处理ART中各敏捷团队间的开发依赖。

SoS的频次通常为每周1次，但也可以根据需要增加会议频次。

SoS的与会人员包括RTE和各敏捷团队的代表（通常是各敏捷团队的Scrum Master），必要时也可以邀请其他相关人员参与。

SoS中，将针对PI目标和跨团队依赖，回顾各团队的工作进展、规划下次会议前的工作目标，并暴露障碍。

SoS的会议时间盒为30-60分钟。在SoS会后，相关人员可以召开“meet after”会议，以专题讨论和解决障碍。

下面是一个推荐的SoS会议议程和操作指南，如图5所示。

图5 推荐的SoS议程和操作指南

2） PO Sync（PO同步会议）

在PI期间，解决方案PM（产品经理）会组织召开PO Sync会议，以实现各敏捷团队PO间的同步和协作。

PO Sync的频次通常为每周1次，但也可以根据需要增加会议频次。

PO Sync也有会议时间盒（30-60分钟）。在PO Sync会后，也可以组织召开“meet after”会议，以专题讨论和解决问题。

PO Sync的主要与会人员为解决方案PM、各敏捷团队PO。此会议可以由RTE或者解决方案的产品经理来组织推进。

PO Sync会议的目的主要有：

• 基于PI目标，以可视化的方式呈现ART的进展。
• 讨论特性开发中识别的产品问题或改进机会。
• 对PI范围调整需求，进行评估。

此外，PO Sync还可以用于准备下一个PI，例如优化规划的待办项或者调整优先级。

3）ART Sync（敏捷发布火车同步会议）

可以将SoS和PO Sync同步合并为一个会议，称为“ART Sync”。

3. 发布管理会议

发布管理会议管控即将进行的发布，同时也是一个与管理层进行沟通的机会。

4. System Demo（系统演示会）

需要注意的是，System Demo并不是仅在PI结束时才进行的事件，而是会每两周进行一次。

System Demo主要有以下作用：

• 能够获取干系人对解决方案的有效性和可用性的反馈。
• 确保同一个ART的敏捷开发团队，每个迭代至少进行一次解决方案的集成，以尽早地暴露集成问题。
• 例行对解决方案的意义和发展前景进行评估。

5. Prepare for the Next PI Planning Event（准备下次PI 计划）

准备下次PI计划，并不是一次会议，而是一个持续进行的过程，需要聚焦于三个方面：

• 对待办项及其优先级，在管理层、解决方案PM、敏捷团队PO及其他关键干系人间达成一致，组织上为下次PI准备就绪。
• 对待办项的内容，准备就绪。
• 对PI计划必需的后勤保障，准备就绪。

6. Inspect & Adapt（检视和调整）

当时间盒到期时，PI也随之结束。

RTE组织召开Inspect & Adapt工作坊，主要包括以下内容：

• 进行PI System Demo。这是PI的最终System Demo，将会演示PI中已完成的所有功能。
• 反思和解决问题，确定要采取那些必要的措施，以加快下一PI的速度、提升质量和可靠性。

工作坊通常会输出一系列“改进故事”，这些“改进故事”会添加到待办项列表中，以实现持续改进。

本文作者

李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练

参考文档：

SAFe的PI链接：

https://www.scaledagileframework.com/program-increment/