本文是Toptal扩展敏捷系列的第一部分, 设计用于指导项目经理进行团队扩展工作. 下一期，”敏捷扩展:Scrum大师的安全最佳实践，为促进外管局的活动提供实用建议.

想象一下:在一个项目的开始, 你组装一个, 有效的, 致力于实现产品目标的跨职能团队. 为了提高绩效，你要确保团队精通 敏捷. 对产品的需求增长了，需求增加了，待办事项也增加了. 您和其他涉众意识到团队需要扩大规模. 听起来很熟悉?

一个可伸缩的敏捷框架允许多个团队一起工作来维护他们的 敏捷性. 如果有更多的工作要做，你的团队在合理的时间内无法处理, 是时候扩大规模了. 但是，为了这样做，您需要选择 正确的框架，其中有几个可供选择. 选择不当，实施可能会失败, 破坏生产力并导致严重的财务影响.

最适合您的团队大规模使用敏捷的框架会有所不同, 取决于可用资金等因素, 组织方法, 以及产品的复杂性.

何时应该进行扩展?

在考虑扩展之前，有一些关键的标准需要满足:

你能否只用一个团队来管理开发?

实现了 敏捷框架 可能很复杂且耗时，所以如果不需要就不要进行扩展. 当您的团队的工作负载超过其能力时，那么扩展是必要的.

你的团队敏捷吗??

也许最重要的标准是您的团队对敏捷方法的熟练程度. 如果你的团队没有敏捷经验，那么扩展会产生更多的问题.

你的团队的开发实践需要改进吗?

如果你的团队的工程实践没有效率，扩展可能不会产生期望的结果. 实践，如适当的实施 DevOps 和一个 CI / CD管道 是否对团队的一致性至关重要. 此外，如果没有标准化的质量保证，可能很难 测试新功能.

您的团队交付集成增量了吗?

扩展涉及到整合多个团队在同一产品上的协作, 每个团队在哪里产生协同工作的特性. 下表详细介绍了团队和产品的四种可能配置. 注意，只有一个需要缩放.

选择缩放框架

这个扩展的敏捷框架比较将集中在五个最广泛使用的解决方案上: 规模化敏捷框架(安全)、联系、大规模Scrum (少)、Scrum@Scale和自律敏捷(DA). 我发现这些是最有效的框架, 它们可以应用于各种场景和组织. 以下部分将为您提供所需的信息，以便为您独特的扩展上下文做出最佳选择.

1. 规模化敏捷框架(安全)

安全 最流行的敏捷扩展框架是什么. A 2021年的调查 发现37%的敏捷实践者使用它, 主要是由于它的多种配置, 所有这些都集中在价值流上，并具有良好定义的指南和过程.

因为安全用于交付复杂的解决方案，需要超过50人, 它将团队组织成 敏捷发布训练(ARTs). 同步ART中的团队, 安全使用程序增量迭代——类似于Scrum sprint——每次迭代通常持续8到12周. 这种方法允许产品经理专注于总体目标，并有效地监督复杂的产品路线图，而不会引入过多的更改.

安全是基于 Scrum框架 but with a couple key differences: 安全 adoption happens at the enterprise level rather than the team level; and while Scrum gives the product owner sole authority over prioritization, 外管局鼓励采取更民主的方式.

外管局的实施分为四个层次:

必要的安全

基本安全是安全的基础，必须掌握之前移动到任何后续配置. 它利用了既定的Scrum角色，比如 Scrum master、产品经理和产品负责人，还引入了一个新角色: 放行列车工程师. 这个人充当仆人式领导和ART教练，指导团队调整目标. ART可以有5到12个团队, 每个抗逆转录病毒疗法都能提供完整的解决方案.

大型解决方案

该配置位于必要的安全之上，并引入了一个称为“解决方案列车”的概念.“当构建大型复杂的解决方案时，需要多个艺术家(可能是数百甚至数千人)在同一价值流上进行协调时，就会使用它. 例如, 如果你在微软工作，并且有三个独立的团队在编程Excel, 词, 和演示文稿, 它们都在为同一个价值流做出贡献:微软办公软件.

投资组合

投资组合由处理不同价值流的多个art组成. 继续微软的例子:独立的团队开发公司的Office, Skype, 或Xbox产品.

完整的安全

这个配置组合了所有的基本层, 大型解决方案, 和项目组合-协调企业范围内的团队管理.

2. 联系

的 联系 框架也基于Scrum，但比安全更轻量级, 只需要小的调整来促进3到9个团队之间的协作. 实现 联系 不需要任何额外的角色. 而, 来自每个团队的一名代表加入一个中央集成团队，该团队将工作对准单一目标. 类似于Scrum, 所有团队聚集在一起进行冲刺计划会议, 其结果形成了共享的产品待办事项列表. 检查进度, 每个团队每天举行一次类似于单口相声的会议, 并且集成团队也会开会报告他们团队的进展.

在冲刺期间，团队参与细化会议，确定待办事项的优先级并对其进行评估. 因为待办事项管理的复杂性随着团队数量的增加而增加, 联系要求细化会议. 团队在每个sprint之后召开评审和回顾会议.

3. 大规模Scrum (少)

少 几乎和联系一模一样, 但它有一些小的不同, 如命名约定和附加, 团队特定的冲刺计划会议. 它的第二种结构的扩展能力也不同， 更少的巨大它支持超过8个团队的协作.

更少的巨大采用以客户为中心的方法来组织开发. 有效管理工作, 它要求产品所有者将高层次的产品待办事项划分为更细粒度项目的更小的“区域待办事项”，然后将它们进一步分类到需求区域中.

这些需求区域由区域产品负责人(apo)管理。. apo专注于与每个领域相关的领域，并与多个团队合作，为他们的领域提供解决方案. 存储在待办事项列表中的每个需求只属于一个需求区域, 每个区域由一个APO管理. 在一起, 产品负责人和apo组成一个团队，负责在产品范围内确定优先级.

4. Scrum@Scale

Scrum@Scale 是Scrum的延伸，可能是最容易学习和理解的框架. 它可以从一个团队扩展到多个团队.

该框架的核心组件是Scrum of Scrum (so)。. 每个团队选择一个人代表他们参加SoS会议, 这些通常在每天的单口相声之后进行. 每天的SoS会议的目的是帮助团队之间的协调和沟通, 并简化任何依赖或重叠的管理.

这个框架中的独特角色包括SoS主, 本质上是一个扩展版的Scrum管理员, 以及首席产品负责人, 谁与团队产品负责人一起为SoS形成联合待办事项.

Scrum@Scale没有其他框架那么规范, 允许组织按照自己的节奏进行扩展. 如果团队数量继续增长，SoS会议变得太大, 组织可以将该框架升级为Scrum of Scrum (soso)。.

5. 自律敏捷(DA)

DA 与其他框架的不同之处在于，它更像是一个工具箱，您可以从中选择最合适的扩展策略, 而不是一个你必须遵守的严格框架. 这是一个情境驱动的过程 各种框架的混合,包括 Scrum和看板，可以根据每个项目的需求进行定制，并以“选择是好的.“DA的理念是，每个团队和组织的规模都是独一无二的, 分布, 和域, 每个团队成员都是独一无二的, 有自己的技能和经验.

它可以应用于软件开发团队级别或企业范围. 对于后者, 数据处理工具包确定了各种业务功能(例如财务), 它操作, 供应商管理应该解决这个问题, 并提出了一系列的选择.

DA区分了三个项目阶段——先启阶段, 建设, 和产品化——每一个都包含面向交付的过程目标. 因为这个框架关注的是整个交付生命周期, 而不仅仅是构建, 它比其他框架引入了更多的角色. 每个数据分析团队的主要角色是利益相关者，团队成员， 团队领导产品负责人和架构负责人. 还有五个配角, 通常在临时的基础上用于协助缩放;专家, 领域专家, 技术专家, 独立的测试人员, 和积分器.

数据处理可以在其他框架之上使用，以进一步扩展.

仔细选择，慢慢扩展

扩展 敏捷团队 无缝地集成他们的工作是困难的，但可以通过选择最好的框架来简化. 使用下面的流程图作为指导你的决策过程的第一步.

我相信您会找到适合您组织经验的可伸缩敏捷框架, 方法, 预算, 以及这里展示的产品. 无论您选择哪种框架, 重要的是不要仓促地增加规模，以尽量减少干扰并提前计划更改.

您在任何扩展活动中使用过这些框架吗? 请在评论区告诉我们你的经历.

阅读Toptal敏捷扩展系列的下一篇文章:敏捷扩展:Scrum大师的安全最佳实践.”