未来的产品开发任务是无法被预先确定的。将计划和控制权分配给那些能理解并对最终结果做出反应的人。
—— 迈克尔·肯尼迪，精益企业产品开发
SAFe中没有魔法，也许除了PI Planning。
—— 匿名
PI Planning
Program Increment (PI) Planning 是一个有节奏的，面对面的活动，它是敏捷发布火车（ART）的心跳，将ART上的所有团队对齐到共同的使命和愿景之下。
PI Planning对于SAFe来说至关重要：如果你没有在做PI Planning，那么你就没有在做SAFe。
详解
敏捷宣言指出，“不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。”SAFe通过PI Planning将这句话提升到了新的层次。
在世界各地的许多企业中，都在开展大规模的PI Planning活动，这可能涉及到物理位置的重新调配。他们真实展现了财务上的投资回报率，更不用说由多敏捷团队组建的社会结构所带来的无形资产，对于个人和集体来说都有着积极的回报。
让整列敏捷发布火车的团队同时在场也许并不总那么现实，而当下的新冠疫情也使得这成为了一种奢望。尽管面对面的计划会议有许多好处，但SAFe中不成文的“规则”是，“由做事的人来做计划”。当无法在线下召开时，实时、同步、虚拟、面对面的计划会议也同样被证实是有效的。事实上许多ART都成功的采用了一种线上线下混合方案，即有一部分团队远程加入，如下图1中所示。
在“SAFe中的分布式PI Planning”一文中，对如何成功管理此类会议场景提供了进一步的参考指南和注意事项。
图1 面对面的PI Planning，远程团队利用视频会议同时参与计划
PI Planning有标准的议程，包含关于商业背景和愿景的介绍，接着是团队规划的分组讨论——各团队针对即将到来的PI进行迭代规划和目标设定。PI Planning在创新与规划（IP）迭代中进行，由敏捷发布火车的RTE来主导，所有的ART成员都需要参与到会议中。在IP迭代期间举行，可以避免影响当前PI的团队计划或容量。PI Planning通常持续两天时间，但由于跨时区团队协作的需要，会议时间常常被延长。
PI Planning的商业效益
PI Planning带来了许多商业利益，包括：
- 在所有团队及干系人间建立了面对面的交流
- 建立了ART所依赖的社交网络
- 通过业务背景、愿意、团队及Program PI目标，将开发与业务目标对齐
- 识别依赖，并促进跨团队、跨ART的协作
- 为指导“恰到好处”的架构及精益用户体验（UX）提供机会
- 使需求与能力想匹配，消除多余的在制品（WIP）
- 快速决策
PI Planning的输入与输出
PI Planning的输入包含：
- 商业背景（参见下文的“内容准备”）
- 路线图和愿景
- Program Backlog中的前十个功能
一个成功的PI Planning活动包含两个主要产出：
- 承诺的PI目标 —— 一系列符合SMART原则的目标，它们由各团队根据业务负责人分配的商业价值来创建
- Program Board —— 突出新功能的交付日期，各团队间的功能依赖，以及相关的里程碑
准备工作
PI Planning是一个重要活动，需要准备，协调，及沟通。它由RTE主导，参与者包括业务负责人，产品管理者，敏捷团队，系统及方案架构师/工程师，系统团队，及其他干系人。所有参与者都需要被提前通知，以便对会议做好充分准备。业务负责人的积极参与，为预算支出提供了重要的保障。
为了PI Planning的成功举办，必须做好以下三个方面的准备：
- 组织准备 —— 战略对齐，以及团队和火车的设置
- 内容准备 —— 管理和开发准备
- 后勤准备 —— 成功举办活动所需的考虑事项
下面是ART准备活动的检查表要点。（完整的检查清单在“SAFe PI Planning工具包”中面向SPC提供。）
组织准备
在PI Planning之前，参会者、干系人与业务负责人之间需要进行战略对齐，关键角色被指派。为了提前进行准备，会议组织者们需要考虑以下几点：
- 规划范围及背景 —— 规划过程的范围（产品，系统，技术领域）是否明确？是否知道哪些团队需要在一起做规划？
- 业务对齐 —— 业务负责人间是否就优先级达成了合理的一致意见？
- 敏捷团队 —— 我们有敏捷团队吗？每个团队是否都有全职的成员和指定的Scrum Master及产品负责人？
内容准备
与之同样重要的是，要确保有一个清晰的愿意和背景，且保证正确的干系人参与其中。因此，PI Planning必须包括：
- 执行简报 —— 介绍和定义当前的业务背景
- 产品愿景简报 —— 由产品管理者们准备的介绍，包含Program待办清单中的前十项功能
- 架构愿景简报 —— 由CTO、企业架构师或系统架构师陈述，对新技术，新功能和非功能需求进行介绍
后勤准备
准备一个支持大规模参会者的活动并不是一件小事。对于在同一地理位置开展的会议，可能包含对物理空间的确认和准备。对于远程参会，或完全分布在不同地域的情况来说，还包含了对必要的技术基础设施的投资和准备。注意事项主要有以下这些：
- 位置 —— 每个会议地点都必须事先做好准备
- 技术和工具 —— 实时信息共享工具，支持分布式计划活动或远程参会者的工具
- 通信渠道 —— 保障可用的主次音频、视频、演示渠道
标准议程
PI Planning的标准议程如图2所示。以下是对每个活动项的介绍。关于如何运用这份议程指南以支持跨时区的规划，请参考拓展话题：“SAFe中的分布式PI Planning”。
图2 为期两天的PI Planning标准议程
第一天 议程安排
- 业务背景 —— 由业务负责人或高层管理者阐述业务现状，分享投资组合愿景，并就现有解决方案在满足客户需求方面的有效性发表观点。
- 产品/解决方案愿景 —— 由产品管理者阐述当前愿景（通常体现在接下来的十大重要产品功能上），并强调从上一次PI Planning之后发生的变化，以及即将到来的里程碑。
- 架构愿景和开发实践 —— 由系统架构师/工程师阐述架构愿景。同时，可能由高级开发经理介绍在敏捷支持性的开发实践上的变化，例如测试自动化，DevOps，持续集成，持续部署等，这些在即将到来的PI中得到推进。
- 规划背景及午餐 —— 由RTE对规划会议的流程及预期结果进行阐述。
- 团队分组讨论 #1 —— 在分组讨论中，团队对每个迭代的容量进行预估，识别实现功能所需的待办事项。每个团队迭代式的进行计划，且对所有成员可见。
在这个过程中，团队识别出风险及依赖，起草初始版本的PI目标。PI目标中通常包含了“未承诺的目标”，这些目标被纳入计划中（如，针对这些目标已定义并包含的故事），但由于较多的风险及未知因素，团队无法承诺该目标的达成。未承诺的目标并不是当有时间的时候才做的额外的工作。相反的，他们增加了计划的可靠性，并给予管理层关于ART可能无法实现的目标的早期警告。团队还需要将功能及相关依赖都添加到Program Board上，如图3所示。
图3 展示功能及相关依赖的Program Board
- 计划草案审查 —— 在时间紧迫的计划草案审查中，团队陈述关键计划产出，包括团队容量和负荷，初步PI目标，潜在风险和依赖。业务负责人，产品管理者，其他团队及干系人审查计划并提供意见。
- 管理层审查及问题解决 —— 计划草案中可能会出现一些挑战，如范围，人员，资源限制以及依赖。在问题解决会议中，管理层可能会就范围变化进行协商，并通过对各种计划的调整来解决其他问题。RTE主持会议，并保证主要干系人在一起的时间足以做出达成目标所必要的决策。
在多个敏捷发布火车组成的解决方案火车中，类似的活动可能在第一天的规划会议结束后举行，以解决跨发布火车的问题。或者，相关火车的RTE们可以互相沟通，提出问题，并在后续各个ART的特定管理层审查及问题解决会议中处理。解决方案火车工程师（STE）协助促进并解决跨ART的问题。
第二天 议程安排
- 计划调整 —— 第二天的会议开始时，首先由管理层阐述关于计划的范围，人员，资源的变化。
- 团队分组讨论 #2 —— 团队继续根据前一天的议程开展计划活动，并做出适当的调整。他们最终确定PI的目标，由业务负责人为这些目标分配商业价值。
图4 分配了商业价值的团队PI目标卡
- 最终计划审查及午餐 —— 在这个环节中，所有团队面向大家介绍各自的计划。各团队介绍的最后，会提出存在的风险和障碍，并将风险提供给RTE以便在后续的ROAMing练习中使用。接着团队会询问业务负责人，是否接受该计划。如果计划被接受，团队就将他们的PI目标卡带到房间的前面，这样所有人都可以看到整体目标的实时进展。如果业务负责人有所顾虑，则团队有机会调整计划以解决发现的问题，再对修改后的计划进行阐述。
- Program的风险 —— 在计划期间，团队识别出了对达成目标的能力有所影响的风险和障碍，这些被放到了更大的管理背景下，在整个火车的成员面前得到解决。一个接一个的风险，得以被真诚、透明地讨论和解决，接着归入以下类别之一：
- 已解决 —— 团队一致同意该风险已经不再是问题
- 已认领 —— 由于无法在PI Planning过程中解决，火车中的一员成为该风险的负责人
- 已接受 —— 有些风险是客观事实或潜在的必须理解和接受的问题
- 已缓和 —— 团队制定了一个计划来减轻风险带来的影响
- 信心投票 —— 当所有风险都被处理时，各团队就其对PI目标达成的信心进行投票
各团队用“五指拳”投票法，如果平均数是三个手指或以上，则管理层应该接受承诺。如果少于三，团队就要重新修订计划。任何一位投了两个手指或更少的成员，都应该有机会说出他们的担忧。这可能会被加入风险清单，需要调整计划，也可能只需要同步一些信息。当每个小组的投票完成，大家就用同样的方式对整个ART进行信心投票，每个成员都要表达他们对整体计划的信心，如图5所示。
图5 ART信心投票
- 计划修订 —— 必要的话，团队对计划进行修改，直到能得到一个更高的信心水平。在这个场合下，对齐与承诺比遵循时间盒更有价值。
- Planning的回顾及推进 —— 最后，RTE主持一个针对PI Planning活动的简短回顾，来记录哪些做得好，哪些做得不好，以及哪些可以在下次做改进，如图6。
图6 PI Planning回顾会
- 通常会有一个针对下一步行动，以及对各团队的最终指导的讨论，可能包括：
- 清理用于Planning的会议室
- 在敏捷项目管理工具中记录团队PI目标及故事
- 审阅团队和ART的活动日历
- 确定迭代计划和每日站会的时间地点
当Planning活动结束后，RTE和其他的ART干系人将各团队的PI目标，整合成整个Program的PI目标（图7），以此作为对外沟通和目标进展跟踪的基础。
产品管理者根据Program的PI目标来更新产品路线图，并调整对未来两个PI的预测。
在Scrum of Scrums的过程中，Program看板常常用来跟踪依赖关系。在PI Planning结束后，它可能会被（手动）维护，也可能不会，取决于所使用的敏捷项目管理工具及ART的需要。
在PI Planning活动结束时，团队会带着预先填充好的下个迭代的待办列表。他们将自己团队的PI目标，迭代计划和风险带回日常工作区域。Program的风险依旧由RTE负责，他将确保风险负责人已经掌握信息并在积极的管理风险。
最重要的是，ART继续执行PI，跟踪进展，并根据涌现的新信息带来的变化进行必要的调整。以PI计划为起点，PI的执行始于所有团队开展的第一个迭代计划会议。由于在PI Planning会议上所做的迭代计划没有考虑到故事级的验收标准，因此很可能需要对第一个及后续的迭代计划进行调整。
图7 Program级PI目标
解决方案火车Planning
本文重点讨论的是单个敏捷发布火车的规划活动。然而，大型价值流可能包含多个ART及供应商。在这种场景下，解决方案火车采用一个Pre-PI Planning来为单个ART的PI Planning提供背景和输入信息。在ART的PI Planning结束后，会有一个Post-PI Planning活动，用来整合对解决方案有贡献的ART规划结果。
图8 Pre 和Post-PI Planning
在“创新和规划迭代”一文中，提供了涉及Pre-和Post-PI Planning的示例日历。
原文地址：https://www.scaledagileframework.com/pi-planning/
关于译者：
Scrum中文网翻译组：Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。Scrum中文网是中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
