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