Scrum_tp11

SAFe中没有魔法,也许除了PI Planning。

未来的产品开发任务是无法被预先确定的。将计划和控制权分配给那些能理解并对最终结果做出反应的人。
                                                                                            —— 迈克尔·肯尼迪,精益企业产品开发

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”一文中,对如何成功管理此类会议场景提供了进一步的参考指南和注意事项。

微信图片_20220506170157

图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”。

微信图片_20220506172229
图2 为期两天的PI Planning标准议程

第一天 议程安排
  • 业务背景 —— 由业务负责人或高层管理者阐述业务现状,分享投资组合愿景,并就现有解决方案在满足客户需求方面的有效性发表观点。
  • 产品/解决方案愿景 —— 由产品管理者阐述当前愿景(通常体现在接下来的十大重要产品功能上),并强调从上一次PI Planning之后发生的变化,以及即将到来的里程碑。
  • 架构愿景和开发实践 —— 由系统架构师/工程师阐述架构愿景。同时,可能由高级开发经理介绍在敏捷支持性的开发实践上的变化,例如测试自动化,DevOps,持续集成,持续部署等,这些在即将到来的PI中得到推进。
  • 规划背景及午餐 —— 由RTE对规划会议的流程及预期结果进行阐述。
  • 团队分组讨论 #1 —— 在分组讨论中,团队对每个迭代的容量进行预估,识别实现功能所需的待办事项。每个团队迭代式的进行计划,且对所有成员可见。

在这个过程中,团队识别出风险及依赖,起草初始版本的PI目标。PI目标中通常包含了“未承诺的目标”,这些目标被纳入计划中(如,针对这些目标已定义并包含的故事),但由于较多的风险及未知因素,团队无法承诺该目标的达成。未承诺的目标并不是当有时间的时候才做的额外的工作。相反的,他们增加了计划的可靠性,并给予管理层关于ART可能无法实现的目标的早期警告。团队还需要将功能及相关依赖都添加到Program Board上,如图3所示。

微信图片_20220506172416图3 展示功能及相关依赖的Program Board

  • 计划草案审查 —— 在时间紧迫的计划草案审查中,团队陈述关键计划产出,包括团队容量和负荷,初步PI目标,潜在风险和依赖。业务负责人,产品管理者,其他团队及干系人审查计划并提供意见。
  • 管理层审查及问题解决 —— 计划草案中可能会出现一些挑战,如范围,人员,资源限制以及依赖。在问题解决会议中,管理层可能会就范围变化进行协商,并通过对各种计划的调整来解决其他问题。RTE主持会议,并保证主要干系人在一起的时间足以做出达成目标所必要的决策。

在多个敏捷发布火车组成的解决方案火车中,类似的活动可能在第一天的规划会议结束后举行,以解决跨发布火车的问题。或者,相关火车的RTE们可以互相沟通,提出问题,并在后续各个ART的特定管理层审查及问题解决会议中处理。解决方案火车工程师(STE)协助促进并解决跨ART的问题。

第二天 议程安排
  • 计划调整 —— 第二天的会议开始时,首先由管理层阐述关于计划的范围,人员,资源的变化。
  • 团队分组讨论 #2 —— 团队继续根据前一天的议程开展计划活动,并做出适当的调整。他们最终确定PI的目标,由业务负责人为这些目标分配商业价值。

微信图片_20220506172624

图4 分配了商业价值的团队PI目标卡

  • 最终计划审查及午餐 —— 在这个环节中,所有团队面向大家介绍各自的计划。各团队介绍的最后,会提出存在的风险和障碍,并将风险提供给RTE以便在后续的ROAMing练习中使用。接着团队会询问业务负责人,是否接受该计划。如果计划被接受,团队就将他们的PI目标卡带到房间的前面,这样所有人都可以看到整体目标的实时进展。如果业务负责人有所顾虑,则团队有机会调整计划以解决发现的问题,再对修改后的计划进行阐述。
  • Program的风险 —— 在计划期间,团队识别出了对达成目标的能力有所影响的风险和障碍,这些被放到了更大的管理背景下,在整个火车的成员面前得到解决。一个接一个的风险,得以被真诚、透明地讨论和解决,接着归入以下类别之一:
    • 已解决 —— 团队一致同意该风险已经不再是问题
    • 已认领 —— 由于无法在PI Planning过程中解决,火车中的一员成为该风险的负责人
    • 已接受 —— 有些风险是客观事实或潜在的必须理解和接受的问题
    • 已缓和 —— 团队制定了一个计划来减轻风险带来的影响
  • 信心投票 —— 当所有风险都被处理时,各团队就其对PI目标达成的信心进行投票

各团队用“五指拳”投票法,如果平均数是三个手指或以上,则管理层应该接受承诺。如果少于三,团队就要重新修订计划。任何一位投了两个手指或更少的成员,都应该有机会说出他们的担忧。这可能会被加入风险清单,需要调整计划,也可能只需要同步一些信息。当每个小组的投票完成,大家就用同样的方式对整个ART进行信心投票,每个成员都要表达他们对整体计划的信心,如图5所示。

微信图片_20220506172844

图5 ART信心投票

  • 计划修订 —— 必要的话,团队对计划进行修改,直到能得到一个更高的信心水平。在这个场合下,对齐与承诺比遵循时间盒更有价值。
  • Planning的回顾及推进 —— 最后,RTE主持一个针对PI Planning活动的简短回顾,来记录哪些做得好,哪些做得不好,以及哪些可以在下次做改进,如图6。

微信图片_20220506172942

图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会议上所做的迭代计划没有考虑到故事级的验收标准,因此很可能需要对第一个及后续的迭代计划进行调整。

微信图片_20220506173046图7 Program级PI目标

解决方案火车Planning

本文重点讨论的是单个敏捷发布火车的规划活动。然而,大型价值流可能包含多个ART及供应商。在这种场景下,解决方案火车采用一个Pre-PI Planning来为单个ART的PI Planning提供背景和输入信息。在ART的PI Planning结束后,会有一个Post-PI Planning活动,用来整合对解决方案有贡献的ART规划结果。

微信图片_20220506173158图8 Pre 和Post-PI Planning

在“创新和规划迭代”一文中,提供了涉及Pre-和Post-PI Planning的示例日历。

 

原文地址:https://www.scaledagileframework.com/pi-planning/

关于译者:

Scrum中文网翻译组:Scrum中文网是全球第一个Scrum中文网站,中国最早的Scrum和敏捷教育及推广机构,也是国际Scrum联盟(ScrumAlliance)官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。Scrum中文网是中国敏捷教练的摇篮,启蒙和培养了数万名敏捷专业人士,帮助数百家知名企业成功转型敏捷。