敏捷扩展：Scrum Master 的 SAFe 最佳实践

本文是 Toptal 的敏捷扩展系列的第二部分，旨在指导项目经理进行团队扩展工作。 阅读第一期，“5 个敏捷扩展框架比较：你应该使用哪个？” 深入了解最受欢迎的选项。

随着产品的增长和变得越来越复杂，生产它们的团队也在增长。 当需要扩展时，许多公司从 Scrum 过渡到扩展敏捷框架 (SAFe)，这是一个在企业级实施的系统，允许企业管理需要团队开发的多个复杂产品。

进入 SAFe 框架的 Scrum master 将进入一个既熟悉又新的环境。 工件、角色和仪式基于 Scrum。 但是，在更高的规模上运营会带来一些额外的责任，尤其是对于选择担任发布火车工程师 (RTE) 角色的 Scrum master，这是一个常见的轨迹。 RTE 充当整个发布系列的 Scrum 主管。 RTE 不再领导一个 9 到 11 人的 Scrum 团队，而是成为跨多个部门的团队的仆人式领导，他们组织更大规模和范围的活动。

基础知识：从 Scrum 到 SAFe

SAFe 允许公司在多个团队中应用敏捷方法、价值观和原则。 由此产生的“团队团队”被称为敏捷发布列车 (ART)。 各个团队继续雇用 Scrum master 照常开展业务，而 ART 上类似 Scrum master 的角色由 RTE 完成。 RTE 应用 Scrum 的一般机制和治理，但在组织而不是团队级别。 其他传统的团队级 Scrum 角色和工件也会相应地发生变化。 例如，ART“产品负责人”成为产品经理； “产品积压”成为程序积压； “冲刺积压”是迭代积压； “产品增量”现在是程序增量（PI）。

SAFe 有四种配置——基本、大型解决方案、组合和完整——您使用的一种取决于您的公司采用该框架的广泛程度。 这些配置允许在多个级别实施，从多个团队合作到完整的产品组合集成和企业范围的业务敏捷性。 但在每个层面，目标仍然是扩展敏捷和 Scrum 实践，而不是取代它们。

SAFe 中的 Scrum Master

在团队级别的 SAFe 框架中工作的 Scrum master 会发现他们的工作没有显着不同。 他们将继续作为敏捷团队的仆人式领导者，负责指导和教育，消除障碍，并营造一个让团队成员感到安全的环境，让他们能够发挥自己的最佳水平并不断改进。

但是，会有一些新的责任。 SAFe Scrum master 在 PI 计划活动和程序执行中支持 RTE，并在 ART 同步会议中代表他们的团队。 当存在超出团队能力范围的障碍时，Scrum master 会将其上报给 RTE。

决定成为 RTE 的 Scrum master 会发现他们的角色带来了更多的考虑。 ART 可能包括您不熟悉或不熟悉敏捷的团队，例如业务分析、硬件或合规性。 而且由于 SAFe 的更高配置包括项目或项目组合操作，管理层将直接并定期以他们不会参与 Scrum 的方式参与，确保一切都与企业和/或项目组合级别的目标保持一致。

RTE 负责消除超出单个团队能力的障碍。 他们与利益相关者沟通并推动 ART 级别的持续改进。 RTE 不仅指导团队，还指导这些团队的领导者，帮助各个级别的 ART 朝着自我组织和自我管理的方向发展。

安全事件

正如 Scrum master 促进团队级别的事件一样，RTE 促进 ART 级别的事件——PI 计划、ART 同步、系统演示以及检查和调整。 作为一名 RTE，与作为 Scrum 主管相比，您将与更广泛的利益相关者进行接触，并处理具有相互竞争利益的多个团队。 每场活动都有更多、更多样化的参与者，您需要调整优先事项并提前获得对计划的支持。

PI 规划

PI 计划活动是 SAFe 的重要仪式，这是一个为期两天的大型会议，通过创建 PI 计划来调整 ART 内所有团队在接下来的 8 到 12 周内的目标。 这就像一个冲刺计划活动，但它跨越多个团队的多个冲刺。

输入

• 商业愿景
• 要实现的前 10 到 15 个功能列表
• 每个团队能力的详细信息

输出

• PI 计划（接下来五到六个冲刺的交付计划）
• 绩效指标目标
• 潜在风险清单

PI 计划活动的一般提示

• 获得利益相关者的支持。 在会议之前，RTE 应确定关键利益相关者是谁，并与小组分享他们的意见。
• 调整优先级。 在会议开始之前，安排与产品管理团队进行为期一天的会议，以就应交付哪些功能以及未来优先事项达成一致。 在活动中会有很多工作要做，比如风险和依赖关系，而且有基本的方向性协议是很好的。
• 排练！ PI 计划是一件大事。 花两天时间排练可能没什么用，但与 ART 的团队领导进行 2 到 4 小时的会议，创造尽可能接近的体验将大有帮助。 创建活动议程的简化版本并在排练前分享，以便练习可以从消息灵通的地方开始。
• 为任务蠕变做好准备。 PI 计划的目标是在相对较短的时间内交付长期计划。 有时人们会想要详细了解所有事情，这不是活动的目的。 在排练和会议中向团队负责人解释这一点； 提醒团队，目标是提供高水平的计划并建立一致性，而不是计划未来三个月的每一分钟。
• 准备团队容量信息。 请您的 Scrum 主管提供接下来 8 到 12 周的容量计算。 期待一些阻力或问题； 例如，Scrum master 可能不知道他们的团队在接下来的两个月内将缺席多少次。 在这种情况下，要求进行估算，并在 PI 期间灵活应对容量限制。
• 分享 PI 计划议程。 至少在活动开始前两周分发时间表，并准备好回答很多问题。 将有很多与会者，如果 SAFe 对您和您的公司来说是新的，那么它对许多其他团队成员来说可能也是新的。 以我的经验，到第二次或第三次 PI 计划活动时，随着团队熟悉活动并知道会发生什么，促进者的压力会变得不那么强烈。
• 安全管理考勤。 管理人员或高级管理人员通常很难参加为期两天的活动，但管理人员出席是确保高层一致的必要条件。 至少在 PI 计划前两周确认他们的出勤率，并安排他们需要的任何支持。 这同样适用于需要签署 PI 目标的企业主。

ART 同步

ART 同步活动是每周一次的会议，RTE 可以在其中深入了解团队的进度并确定项目风险和障碍。 尽管 RTE 绝不是评估障碍并确定是否需要升级的唯一场合，但这是一个重要的事件，它为提出这些问题提供了一个常规场所。

输入

• 团队的进步
• 障碍日志
• PI 计划（识别计划与实际进度之间的任何重大偏差）

输出

• 升级（如果需要）
• 关于 PI 计划的任何更改的决定

ART Sync 活动的一般提示

• 鼓励定期沟通。 因为 ART Sync 是每周一次，而不是像 Scrum 站立会议那样每天一次，RTE 应该明确表示团队可以立即提出紧急问题，而不应该等待下一次 ART 同步。
• 准备好数据。 要求 Scrum 主管和产品负责人提供可量化的进度指标，例如燃尽或累积流，以便就进度进行知情对话。
• 超越每周状态审查。 ART 同步是一个优先级一致并解决问题的事件，而不是简单的签到。

系统演示

系统演示旨在展示之前迭代期间创建的全部工作范围。 在这次活动中，产品经理和他们的团队向企业主和其他利益相关者展示了 ART 当前形式的综合进展。

输入

• 基于所有敏捷团队成员在上一次迭代过程中的输出的当前工作状态

输出

• 对系统是否适合目的的反馈
• 对积压的更改（如果需要）

系统演示活动的一般提示

• 排练！ 每隔一周花 30 到 45 分钟与演示者一起确定他们的细分。
• 扔掉幻灯片。 呈现实际的集成工作。 如果您正在开发软件产品，请让演示者向利益相关者展示工作产品增量，而不是幻灯片。 如果可能，请在暂存环境中展示您的产品。 您希望演示准确地模拟最终用户体验。 如果您无法每两周展示一次集成系统，请查看您的交付管道并与团队讨论如何采用 CI/CD 和 DevOps 文化。
• 专注于商业价值。 您的演示文稿面向企业主和利益相关者； 分享对他们来说最重要的东西。
• 保持反馈的重点。 您收到的利益相关者反馈很重要，但这次活动不是对产品愿景或路线图进行重大更改的时候。 准备好将对话引导回高层反馈，团队可以在以后将其转化为行动项目。
• 保持简短。 利益相关者是忙碌的人； 45 到 60 分钟的会议将导致更频繁和更积极的出席。
• 留出时间进行问答。 在你的答案中保持透明。 请记住，有时“我不知道，但我们可以找到”是最好的答案。

检查和调整

检查和调整是在 PI 结束时举行的大型回顾会议。 会议分为三个部分，

• PI 系统演示：展示整个 PI 的集成输出。 它与主系统演示类似，但不是一次迭代，而是展示了整个 PI 的集成工作。
• 定量和定性测量： RTE 有机会展示在 PI 过程中收集的指标。 这些指标包括（但不限于）团队速度、接受的用户故事、单元测试覆盖率或开放缺陷。
• 回顾和解决问题研讨会：参与者有机会回顾 PI，反思哪些工作有效，哪些无效，识别系统性问题，并提出解决方法。

输入

• 团队的进步
• ART 集成工作的当前状态，包括所有程序增量的输出

输出

• 潜在改进列表

检查和调整事件的一般提示

• 提前通知企业主。 在活动开始前至少提前两周通知。 在会议之前与任何与会的产品经理和企业主会面，以就定性结果演示保持一致。
• 确保高级利益相关者的出席。 当您展示团队的工作和不断发展的产品时，他们的存在在 PI System 演示中最为重要。 常规系统演示的许多要点在这里适用：事先排练，避免演示幻灯片，并展示实际可交付成果。
• 避免责备。 在整个会议期间，确保没有人会受到所提供的数据或回顾中发现的问题的威胁。 如果另一支球队的人数更高，一些球队可能会感到嫉妒或防御，或者如果问题源于他们的球队，他们会感到被孤立。 拥抱整个团队的文化，以抢占此类问题。
• 关注系统性问题。 尽量不要过多关注零星的问题，为您的团队提供他们需要头脑风暴的空间，并为提出的解决方案自由发挥想象力。
• 创建可操作的提案。 在活动结束时，您应该有待办事项供团队实施。 如果您不采取措施解决问题，那么识别问题将无济于事。

下表将 SAFe 事件与其 Scrum 等效事件进行了比较，并描述了企业级仪式的频率和执行情况：

加强和扩大规模

从 Scrum 到 SAFe 的过渡可能会令人生畏。 即使是最熟悉的实践，以更高的规模运营也总是会带来新的挑战和新的思考方式。 如果你选择成为一名 RTE，你会发现这份工作很大程度上取决于你已经拥有的技能。 RTE 是变革推动者和仆人式领导者，就像 Scrum 大师一样，这份工作让你有机会在企业层面上扮演这个角色，提升你的技能以及你的产品。