将敏捷文化扩展至大型团队

大和敏捷二字通常不会在同一句子中出现。 大型组织因移动缓慢而赢得声誉。 但是，这正在发生改变。 很多大型软件组织正在成功地向敏捷转型。 他们正在学习如何使用或不使用常用的框架（如 SAFe、LeSS 或 Nexus）来调整敏捷原则。

Microsoft 是一家使用敏捷来构建 Azure DevOps 品牌下所提供产品和服务的组织。 此组有 35 个功能团队，每三周发布一次到生产环境。

Azure DevOps 中的每个团队自始至终都对某些功能负责。 他们负责维护客户关系。 他们会管理自己的产品积压工作。 他们会将代码写入生产分支并签入生产分支。 每三周部署一次生产分支，然后公开发布。 接着，团队会监视系统运行状况并修复实时现场问题。

根据 Agile 原则，自治团队的工作效率更高。 敏捷组织希望他们的团队能控制自己的日常执行。 但是，自治而没有统一的标准会导致混沌。 数十个独立工作的团队无法生成统一、高质量的产品。 通过保持一致，可为各团队提供其目的，并确保他们达到组织目标。 如果缺少一致性，即使是表现最好的团队也会失败。

若要调整敏捷，你必须为团队启用自治，同时确保与组织保持一致。

若要管理一致性与自治之间的微妙平衡，DevOps 领导层则需定义分类、制定规划流程并使用功能聊天。

定义分类

敏捷团队及其所属大型敏捷组织需有明确定义的积压工作才能开展成功。 如果组织目标不清晰，团队将难以取得成功。

为了制定明确的目标和说明每个团队如何围绕目标做出贡献，组织需定义分类。 明确定义的分类可为组织创建命名法。

常见的分类为长篇故事、功能、故事和任务。

长篇故事

长篇故事描述了对组织成功非常重要的举措。 长篇故事可能需要几个团队和几个冲刺才能完成，但它们并非没有结束的时候。 长篇故事有一个明确的目标。 一旦达到，长篇故事就会关闭。 正在进行的长篇故事数量应能管理，以使组织保持专注。 长篇故事可分解为功能。

功能

功能定义了实现长篇故事目标所需的新功能。 功能是发布单位，它们表示向客户发布的内容。 可以根据最近完成的功能列表生成已发布的发行说明。 功能可能需要多个冲刺才能完成，但应调整其规模以确保向客户提供一致的价值流。 功能可划分为故事。

情景

故事定义了团队为创建功能而必须提供的增量价值。 团队可将功能分解为若干增量部分。 单个已完成的故事可能无法为客户提供有意义的价值。 但是，完成的故事却表示生产质量的软件。 故事是团队工作的单位。 团队定义了完成功能所需的故事。 故事可选择性地分解为任务。

任务

任务定义了完成故事所需的工作。

计划

此分类方法不是一个一刀切的系统。 很多组织引入了一个高于长篇故事的级别：计划。

每个级别的名称都可以按组织进行定制。 然而，上文定义的名称（长篇故事、功能、故事）却被广泛用于业内。

自治线

设置分类后，组织需要绘制自治线。 自治线是级别所有权从管理层传递到团队的点。 管理层不会干扰团队负责的级别。

以下示例显示了根据功能绘制的自治线。 管理层负责长篇故事和功能，而它们可提供一致性。 团队负责故事和任务，并对其执行方式具有自主性。

在此示例中，管理层不会告知团队如何分解故事、规划冲刺或执行工作。

但是，团队必须确保其执行符合管理层的目标。 虽然团队负责其积压的故事，但他们必须将其积压工作与分配给他们的功能保持一致。

规划

若要调整敏捷规划，团队需为每个级别的分类制定计划。 但是，迭代和更新计划非常重要。 此流程被称为滚动波规划。

该计划可为某一固定时间段提供方向，并定期进行所需的校准。 例如，可以每隔六个月校准一个为期 18 个月的计划。

每个级别分类的规划方法示例如下：长篇故事、功能、故事、任务。

影像

愿景可通过长篇故事来表达，它设定了组织的长期方向。 长篇故事定义了组织在未来 18 个月内想完成的内容。 管理层负责该计划，且每六个月校准一次。

愿景是在全员会议中提出的。 由于愿景旨在实现雄心勃勃的目标，且在此期间可能会发生很大变化，因此预计会实现约 60% 的愿景。

季节

一个季度可通过功能来描述，它设定了未来六个月的策略。 功能确定了组织希望为其客户重点提供的内容。 管理层负责季度计划，并在全员会议上展示愿景和季度计划。 所有团队计划均须与管理层的季度计划保持一致。 预计可完成约 80% 的季度计划。

3 冲刺计划

3 冲刺计划定义了团队将在接下来的三个冲击中完成的故事和功能。 团队负责该计划，并在每个冲刺期间进行校准。 每个团队均需通过功能聊天展示其管理计划（请参阅下文）。 该计划指明了团队的执行如何与 6 个月的季度计划保持一致。 预计可完成 3 冲刺计划的约 90%。

冲刺计划

冲刺计划定义了团队将在下一冲刺中完成的故事和功能。 团队负责冲刺计划，并将其通过电子邮件发送到整个组织，以保持完全透明度。 该计划包括团队在过去冲刺中完成的工作，以及下一冲刺的重点。 预计可完成冲刺计划的约 95%。

自治线

在此示例中，绘制了自治线以显示团队规划自治的执行位置。

如上所述，管理层不会将所有权扩展到自治线以下。 管理层使用愿景和季度计划来提供指导，然后让团队自主创建 3 冲刺计划和冲刺计划。

功能聊天：将自治与一致性相结合

功能聊天是一种低仪式会议，其中每个团队都会向管理层提供其 3 冲刺计划。 此会议可确保团队计划与组织目标相一致。 它还有助于管理层随时了解团队的工作内容。 虽然 3 冲刺计划会在每个冲刺期间进行校准，但功能聊天为按需举行，通常每隔一到三个冲刺进行一次。

功能聊天会议为每个团队分配了 15 分钟时间。 假设有 12 个功能团队，这些会议则可安排在约三个小时内完成。 每个团队都会准备一个包含 3 张幻灯片的幻灯片，同时会使用以下幻灯片：

功能

第一张幻灯片概述了团队在接下来的三个冲刺中将重点提供的功能。

债务

下一张幻灯片介绍了团队如何管理技术债务。 债务是指不符合管理层质量条件的所有问题。 工程总监会设置质量条件，而这些条件对所有团队均相同（一致）。 示例质量条件包括了每个工程师的 bug 数、通过的单元测试百分比和性能目标。

问题和依赖关系

最后一张幻灯片列出的问题和依赖关系包括影响团队进度的所有内容，例如团队无法解决的问题或需要升级的、针对其他团队的依赖关系。

每个团队会直接向管理层展示其幻灯片。 团队会展示其 3 冲刺计划如何与 6 个月的季度计划保持一致。 领导层会提出澄清问题，并就方向改变提出建议。 他们还可请求召开后续会议来解决更深层次的问题。

如果团队的计划不符合管理层的期望，管理层可能会要求重新计划。 在此罕见事件中，团队需重新计划并安排第二次功能聊天来接受审查。

信任：将一致性与自主结合在一起的粘合剂

大规模实践敏捷时，信任是一条“双向街道”：

• 管理层必须信任团队才能完成正确的事务。 如果管理层不信任团队，则不会给予团队自主性。

• 团队通过持续交付高质量代码来赢得信任。 如果团队不可信，管理层则不会赋予他们自主性。

管理层必须为团队提供明确的计划，以便与团队保持一致，然后信任其团队能按计划执行。 团队必须将其计划与组织保持一致，并以可信的方式切实执行。

随着组织希望将敏捷扩展到更大的场景，其中的关键是让团队获得自主性，同时确保他们与组织目标相一致。 其中关键的构建块是：明确定义的所有权和信任文化。 一旦组织有了这个基础，他们就会发现敏捷可异常顺利地进行扩展。

后续步骤

对于任意规模的团队来说，现在已有多种方式初现成效。 请查看其中某些调整做法。

了解实现跨团队项目组合管理和可见性的 Azure DevOps 功能。

Microsoft 是全球最大的敏捷公司之一。 详细了解 Microsoft 如何调整 DevOps 规划。