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