将敏捷文化扩展至大型团队
很多人不会在同一句话中使用 大 和 敏捷 的话。 大型软件组织赢得了大而缓慢的变化的声誉。 但是，这正在改变。 许多大型组织成功地将转型为敏捷组织。 他们正学习如何使用或不使用常用框架（如 SAFe、LeSS 或 Nexus）缩放敏捷原则。
Microsoft Azure DevOps组织之一在Azure DevOps品牌下构建产品和服务。 他们有 35 个功能团队，每三周发布一次生产。
Azure DevOps中的每个团队从头到尾拥有一切。 他们拥有客户关系。 他们管理自己的产品积压工作。 它们将代码写入生产分支并签入生产分支。 每隔三周部署一次生产分支，发布将公开。 然后，团队监视系统运行状况并修复实时站点问题。
根据 Agile 原则，自治团队的工作效率更高。 敏捷组织希望他们的团队在日常执行方面具有自治性。 但是，自治而没有统一的标准会导致混沌。 数十支独立工作的团队不会生产统一、高质量的产品。 对齐为团队提供了他们的目的。 对齐可确保团队满足组织目标。 如果没有对齐，即使是表现最好的团队也会失败。
若要缩放敏捷，你必须为团队启用自治，同时确保与组织保持一致。
若要管理对齐与自治之间的微妙平衡，DevOps领导者需要定义分类、定义规划过程和使用功能聊天。
定义分类
明确定义的分类定义组织的名词。
敏捷团队需要明确定义的积压工作才能成功。 它所属的大型敏捷组织也是如此。 如果组织目标尚不清楚，Teams将难以成功。
敏捷组织需要明确定义其目标和状态，每个团队需要如何为这些目标做出贡献。 为此，组织需要定义分类。
常见的分类是 史诗、 特征、 故事和 任务。
长篇故事
史诗声明了对组织成功非常重要的举措。 史诗可能会采取几个团队和几个冲刺完成，但他们不是没有结束。 史诗有一个明确的目标。 一旦达到，史诗被关闭。 应管理正在进行的史诗数量，以便使组织保持专注。 史诗分为特征。
功能
特征定义实现史诗目标所需的新功能。 功能是发布单元;它们表示向客户发布的内容。 可以根据最近完成的功能列表生成已发布的发行说明。 功能可以采用多个冲刺来完成，但应调整大小以确保对客户的价值流保持一致。 功能细分为故事。
情景
故事定义团队必须提供的增量值才能创建功能。 团队将该功能分解为增量部分。 单个已完成的故事可能无法为客户提供有意义的价值。 但是，完成的故事表示生产质量的软件。 故事是团队的工作单位。 团队定义完成功能所需的故事。 故事（可选）细分为任务。
任务
任务定义完成故事所需的工作。
计划
这种分类不是一个一刀切。 许多组织引入了一个高于史诗的级别，称为 计划。
每个级别的名称都可以根据组织定制。 然而，上面定义的名称 (史诗、特征、故事) 相当接近行业标准。
自治路线
设置分类后，定义 自治线。 自治线是团队明确所有者和管理不会干扰的点。
下面的示例绘制了以下特征的自治线。 管理层拥有史诗和功能，提供对齐方式。 Teams自己的故事和任务，并具有执行方式的自主性。
管理不会将所有权扩展到自治线以下。 例如，管理不会告诉团队如何分解故事、计划冲刺或执行其工作。
但是，团队必须确保其执行符合管理层的目标。 虽然团队拥有他们积压的故事，但他们必须将其积压工作与分配给他们的功能保持一致。
规划
为了缩放敏捷规划，团队需要针对分类的每个级别制定计划。 滚动波规划是关键。 该计划为固定时间段提供方向，并定期进行预期校准。 例如，每 6 个月可以校准一个 18 个月的计划。
下面是分类的每个级别的规划方法示例：史诗、特征、故事、任务。
影像
愿景通过史诗表达，并设定了组织的长期方向。 管理层拥有该计划，每 6 个月校准一次。 史诗定义组织在未来 18 个月内想要完成的内容。 这一愿景是在一次全手会议中提出的。 由于愿景旨在雄心勃勃，因此对于一个敏捷组织来说，在此期间可能会发生很大变化，预计能实现大约 60% 的愿景。
赛季
一个 季节 通过功能描述，并设置未来 6 个月的策略。 功能确定组织希望为其客户点亮的内容。 管理层拥有季节性计划，并在全手会议中呈现愿景和季节性计划。 所有团队计划都必须与管理层的季节性计划保持一致。 预计完成约 80% 的季节性计划。
3-Sprint 计划
3 冲刺计划定义团队将在接下来的 3 次冲刺中完成的故事和功能。 团队拥有该计划，并校准每个冲刺。 每个团队都提供了他们通过功能聊天管理的计划， (请参阅以下) 。 该计划指定团队的执行如何与 6 个月的季节性计划保持一致。 预计完成大约 3 冲刺计划的 90%。
冲刺计划
冲刺计划定义团队将在下一个冲刺中完成的故事和功能。 团队拥有冲刺计划，并将其通过电子邮件发送到整个组织，以保持完全透明度。 该计划包括团队在过去冲刺中取得的成就，以及下一个冲刺的焦点。 预计完成大约 95% 的冲刺计划。
自治路线
“自治线”被绘制为展示团队规划自治的位置。 上述规划过程绘制自治线，如下所示：
如上所述，管理不会将所有权扩展到自治线以下。 他们提供使用愿景和赛季计划的指导，并让团队自主创建 3 个冲刺和冲刺计划。
功能聊天：自治性满足对齐方式的位置
功能聊天是一个低仪式会议，其中每个团队都提出了他们 3 冲刺计划进行管理。 此会议可确保团队计划与组织目标保持一致。 它还有助于管理随时了解团队正在执行的操作。 虽然 3 冲刺计划是校准每个冲刺，但功能聊天会根据需要进行，通常每 1-3 个冲刺一次。
功能聊天会议为每个团队分配 15 分钟。 通过十二个功能团队，这些会议可以安排在大约三个小时内。 每个团队都准备一个包含三张幻灯片的幻灯片，并使用以下幻灯片：
功能
团队将在接下来的 3 个冲刺中点亮这些功能。
债务
团队如何管理其技术债务。 债务是不符合管理层质量条的任何内容。 工程总监设置质量条，所有团队 (对齐) 相同。 示例质量条包括 #bug/工程师、%单元测试通过和性能目标。
问题/依赖项
影响团队进度的任何内容。 团队无法解决或依赖于需要升级的其他团队的问题。 每个团队直接向管理演示其幻灯片。 团队介绍了其 3 冲刺计划如何与 6 个月的季节性计划保持一致。 领导们提出澄清的问题，并建议方向的变化。 他们还可以请求后续会议来解决更深层次的问题。
如果团队的计划不符合管理层的期望，管理层可能会请求重新计划。 在此罕见事件中，团队将重新计划并安排第二个功能聊天来查看它。
信任：粘附在一起保持其对齐和自主性
大规模练习敏捷时，信任是双向街道：
管理层必须信任团队才能做正确的事。 如果管理层不信任团队，他们不会赋予团队自主性。
团队通过持续提供高质量的代码来赢得信任。 如果团队不可信，管理不会赋予他们自治权。
管理必须为团队提供明确的计划，以便与团队保持一致并信任其团队执行。 Teams必须使其计划与组织保持一致，并以可信的方式执行。
随着组织希望将敏捷扩展到更大的方案，关键是让团队获得自主性，同时确保他们符合组织目标。 关键构建基块明确定义了所有权和信任文化。 一旦组织有了这个基础，他们就会发现敏捷可以很好地扩展。
后续步骤
对于任何规模的团队来说，有多种方法可以立即开始了解优势。 请查看这些 缩放做法中的一些做法。
了解跨团队进行项目组合管理和可见性的Azure DevOps功能。
Microsoft 是世界上最大的敏捷公司之一。 详细了解 Microsoft 如何缩放DevOps规划。