本文是Toptal敏捷扩展系列的第二部分, 设计用于指导项目经理进行团队扩展工作. 请阅读第一部分。”5个敏捷扩展框架的比较:你应该使用哪一个?，以深入了解最受欢迎的选择. 在本系列的最后一篇文章中，安全案例研究:来自现场的转型笔记Toptal专家和安全发明人Dean Leffingwell讨论了规模化过渡.

随着产品的增长和变得越来越复杂，生产它们的团队也在不断发展. 当需要扩展时，许多公司从Scrum过渡到 规模化敏捷框架 (安全), 在企业级实现的系统，允许企业管理多个, 需要多个团队共同开发的复杂产品.

A Scrum master 进入 安全框架 会步入一个既熟悉又陌生的环境吗. 工件、角色和仪式是基于Scrum的. 但更大规模的运营伴随着一些额外的责任, 特别是对于那些选择进入发布训练工程师(RTE)角色的Scrum管理员。, 共同轨迹. RTE充当整个发布系列的Scrum主管. 而不是领导一个9到11人的Scrum团队, rte成为跨多个部门的团队团队的仆人式领导者, 他们组织规模更大、范围更广的活动.

基础知识:Scrum to 安全

安全允许公司应用敏捷方法， 值, 原则 跨多个团队. 由此产生的“团队中的团队”被称为 敏捷发布训练(ART). 个别团队继续使用 Scrum master 像往常一样做业务，而ART上类似Scrum管理员的角色是由RTE完成的. RTE应用Scrum的一般机制和治理，但在组织中, 而不是团队, 水平. 其他传统的团队级Scrum角色和工件也会随之改变. 例如，ART“产品所有者”变成了 产品经理; a “产品待办事项列表” becomes the program backlog; a “sprint backlog” is an iteration backlog; and the “product increment” is now the program increment (PI).

有四种构型 安全发生, 大型解决方案, 投资组合, 和full——您使用哪个取决于您的公司采用该框架的广泛程度. 这些配置允许在多个级别上实现, 从几个团队一起工作到完整的投资组合集成和企业范围的业务敏捷性. 但在每一个层面，目标仍然是扩大规模 敏捷和Scrum实践，而不是取代它们.

Scrum master in 安全

在团队级别的安全框架下工作的Scrum管理员会发现他们的工作并没有明显的不同. 他们仍然是敏捷团队的仆人式领导者, 负责指导和教育, 消除障碍, 培养一个让团队成员感到安全的环境，让他们表现得最好，并不断改进.

然而，会有一些新的责任. 安全 Scrum管理员在PI计划事件和程序执行中支持RTE, 并代表他们的团队参加ART同步会议. 当存在超出团队能力的障碍时, Scrum管理员将它们升级为RTE.

决定成为RTE的Scrum管理员会发现，他们的角色显然需要更多的考虑. 的 抗逆转录病毒治疗包括 对您或对敏捷不熟悉的团队，如业务分析、硬件或法规遵从. 而且因为外管局的高级配置包括项目或投资组合操作, 管理层将以Scrum中没有的方式直接和定期地参与进来, 确保一切都与企业和/或投资组合级目标保持一致.

RTE负责消除超出单个团队能力的障碍. 他们与利益相关者沟通并推动ART水平的持续改进. RTE不仅指导团队，还指导团队的领导者, 帮助各级抗逆转录病毒疗法走向自我组织和自我管理.

安全事件

就像Scrum管理员促进团队级别的事件一样, RTE促进艺术级别的活动- PI计划, ART同步, 系统演示, 并且检查和适应. 作为RTE, 你将会接触到比Scrum管理员更广泛的干系人，并处理多个利益冲突的团队. 每次活动的参加者越来越多, 你需要调整优先级，并提前很好地获得倡议的支持.

π规划

项目策划活动是外管局重要的仪式, 这是一个为期两天的大型会议，通过制定PI计划来协调ART中所有团队在未来8到12周内的目标. 这就像一个sprint计划事件，但它跨越了多个团队的多个sprint.

输入

• 业务愿景
• 列出最需要实现的10到15个功能
• 每个团队容量的详细信息

输出

• PI计划(未来五到六个sprint的交付计划)
• π的目标
• 潜在风险清单

PI计划活动的一般提示

• 获得利益相关者的支持. 会议前, rte应该确定谁是关键利益相关者，并与团队分享他们的投入.
• 排列优先级. 会议前, 与产品管理团队安排一个为期一天的会议，就应该交付哪些特性的高层视图达成一致, 以及未来的优先事项. 在这次活动中会有很多事情需要解决, 比如风险和依赖性, 有基本的方向一致是很好的.
• 排练! PI计划是一件大事. 花两天的时间排练可能没有用, 但与ART的团队领导进行两到四个小时的会议，创造尽可能近距离的体验，将大有帮助. 创建一个简化版本的活动议程，并在排练之前分享它，这样练习就可以从一个知情的地方开始.
• 做好任务蔓延的准备. PI计划的目标是在相对较短的时间内提供长期计划. 有时人们会想要对每件事都进行详尽的讨论, 这不是这个活动的目的吗. Explain this to the team leaders at the rehearsal and in the session; remind the teams that the aim is to deliver high-水平 plans and create alignment, 不要计划未来三个月的每一分钟.
• 准备团队能力信息. 让你的Scrum主管提供未来8到12周的容量计算. Expect some pushback or questions; for instance, Scrum管理员可能不知道他们的团队在接下来的两个月里会缺席多少次. 在这种情况下, 要求估算, 并且在PI本身响应容量限制时要灵活.
• 分享PI计划议程. 至少在活动前两周分发日程表, 准备好回答很多问题. 会有很多与会者, 如果外管局对你和你的公司来说是新的, 对于许多其他团队成员来说，这可能也是新的. 根据我的经验, 第二次或第三次PI计划事件, 随着团队熟悉活动并知道会发生什么，主持人的压力就会小得多.
• 安全管理考勤. 对于经理或高级经理来说，参加为期两天的活动通常是很困难的, 但管理层出勤是确保高层一致的必要条件. 至少在PI计划前两周确认他们的出席, 安排他们需要的任何支持. 这同样适用于需要签署PI目标的企业所有者.

艺术同步

ART同步活动是每周一次的会议，RTE可以在会上了解团队的进展情况，并确定项目风险和障碍. 但这绝不是RTE评估障碍并决定是否需要升级的唯一场合, 这是一个重要的活动，为这些问题的提出提供了一个定期的场所.

输入

• 团队的进步
• 障碍的日志
• PI计划(识别计划与实际进度之间的任何主要偏差)

输出

• 升级(如果需要)
• 关于PI计划变更的决策

ART同步事件的一般提示

• 鼓励定期交流. 因为ART同步每周一次, 而不是每天都像Scrum一样站起来, RTE应该明确团队可以立即提出紧急问题，而不应该等待下一次ART同步.
• 准备好数据. 要求Scrum管理员和产品负责人带来可量化的进度指标，比如 燃尽 or 累积流量，以便就进展进行知情的对话.
• 不要只做每周一次的状态回顾. 抗逆转录病毒治疗同步意味着一个优先事项一致和问题得到解决的事件, 不是简单的登记.

系统演示

系统演示旨在展示在之前的迭代中创建的全部工作范围. 在这次活动中, 产品经理及其团队以当前形式向企业所有者和其他利益相关者展示ART的综合进展.

Input

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

输出

• 对系统的反馈 适合用途
• 待办事项的变更(如果需要)

系统演示事件的一般提示

• 排练! 每隔一周花30到45分钟和主持人一起确定他们的部分.
• 抛弃幻灯片. 呈现实际的综合工作. 如果你正在开发一个软件产品, 演示者是否向涉众展示了工作产品增量，而不是幻灯片. 如果可能的话，用一个 登台环境. 您希望演示准确地与最终用户体验相似. 如果你不能每两周提交一个完整的系统, 查看您的交付管道，并与团队就如何采用进行头脑风暴 CI/CD和DevOps文化.
• 关注商业价值. Your presentation is for business owners and stakeholders; share what’s most important to them.
• 保持反馈的重点. 你收到的涉众反馈很重要, 但这次活动并不是对产品愿景或路线图进行重大调整的时候. 准备好引导对话回到高层反馈，团队可以在稍后的时间将其转化为行动项目.
• 保持简短. Stakeholders are busy people; a 45- to 60-minute meeting will result in more frequent and engaged attendance.
• 为Q留出时间&A. 在你的回答中要透明. 记住，有时候“我不知道，但我们能找到答案”是最好的回答.

检查和适应

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

• PI系统演示: 展示整个PI的综合输出. 它类似于主系统演示, 但不是一次迭代, 这个事件展示了整个PI的集成工作.
• 定量和定性测量: RTE有机会展示在PI过程中收集的指标. 这些指标包括(但不限于)团队速度, 接受的用户故事, 单元测试覆盖率, 或者开放缺陷.
• 回顾及解决问题工作坊: 让参与者有机会回顾PI, 反思什么起作用了，什么不起作用了, 识别系统问题, 并提出解决问题的方法.

输入

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

Output

• 潜在改进列表

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

• 提前通知企业主. 至少在活动前两周通知. 在会议之前，与任何出席会议的产品经理和业务所有者会面，以协调定性结果演示.
• 确保高级利益相关者的出席. 在PI系统演示中，当您展示团队的工作和不断发展的产品时，他们的存在是最重要的. 常规系统演示的许多要点在这里都适用:提前演练, 避免演示幻灯片, 展示实际交付成果.
• 避免责任. 在整个会议期间, 确保没有人会因为回顾中提出的数据或发现的问题而感到威胁. 如果另一支球队的数据更高，一些球队可能会感到嫉妒或防御，或者如果问题是由自己的球队引起的，他们会感到被孤立. 拥抱一种团队文化，以预防此类问题.
• 关注系统问题. 尽量不要过多关注零星的问题, 为你的团队提供他们需要进行头脑风暴的空间, 让想象力自由发挥，为提出的解决方案发挥作用.
• 创建可操作的建议. 在活动结束时，您应该有供团队实现的待办事项项. 如果你不采取措施解决问题，发现问题是没有用的.

下表比较了安全事件与它们的 Scrum等价物，并描述了企业层面仪式的频率和执行情况:

加快步伐，扩大规模

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

阅读Toptal敏捷扩展系列的下一篇文章:安全案例研究:来自现场的转型笔记.”