Microsoft 如何使用 DevOps 进行计划

Microsoft 是全球使用敏捷方法的最大规模公司之一。 凭借多年的经验，Microsoft 制定了一个 DevOps 规划流程，该流程通过 Windows 等大规模工作从最小的项目进行扩展。 本文介绍 Microsoft 在整个公司规划软件项目时所汲取的众多教训和做法。

行之有效的变化

以下关键变化有助于开发和交付周期更为健康、高效：

• 促进文化一致性和自治。
• 将焦点从个人改为团队。
• 创建新的规划和学习策略。
• 实现多群体模式。
• 改进代码运行状况实践。
• 促进透明和问责。

促进文化一致性和自治

Peter Drucker 说过：“文化以策略作为早餐”。自治、掌握和目的是关键的人类动机。 Microsoft 试图向 PMS、开发人员和设计人员提供这些激励因素，以便他们自信能构建出成功的产品。

此方法的两大重要推手是一致性和自治。

• 自上而下进行协调，从而确保个人和团队了解其职责如何与更广泛的业务目标保持一致。
• 自治则是自下而上来执行，从而确保个人和团队能对日常活动和决策产生影响。

一致性和自治之间存在微妙的平衡。 过分强调一致可能会形成一种消极文化，此时人员会被动开展工作。 过度自治则可能导致缺乏结构或方向、低效的决策和糟糕的规划。

将焦点从个人改为团队

Microsoft 将人员和团队划分为三个组：PM、设计和工程。

• PM 定义了 Microsoft 构建的内容以及原因。
• 设计则负责设计 Microsoft 构建的内容。
• 工程负责构建产品并确保其质量。

Microsoft 团队具有以下关键特征：

• 跨领域
• 10-12 人
• 自我管理
• 12-18 个月的清晰宪章和目标
• 物理团队会议室
• 自己的功能部署
• 生产环节的自有功能

努力打造垂直团队

Microsoft 团队曾经采用水平团队，且涵盖所有 UI、数据或 API。 现在，Microsoft 致力于打造垂直团队。 团队会负责特定的产品端到端领域。 某些层级中的严格准则可确保整个产品中各团队之间的统一性。

下图展示了水平团队和垂直团队之间的概念差异：

允许自选团队

大约每 18 个月，Microsoft 都会举行一次“黄色便签练习”。在此期间，开发人员可在其中选择要在未来几个规划期内从事的产品领域。 此练习可提供自主性，因为团队可以选择要从事的内容。同时，它还可实现组织一致性，因为它可在各团队之间促进平衡。 在本练习中，约 80% 的人员仍会留在目前的团队中，但他们会感到自己有权力进行选择。

创建新的规划和学习策略

Dwight Eisenhower 说过，“计划毫无价值，但规划却是一切。”Microsoft 规划可细分为以下结构：

• 冲刺（3 周）
• 计划（3 个冲刺）
• 季度（6 个月）
• 策略（12 个月）

工程师和团队主要负责冲刺和计划。 领导层主要负责季度和策略。

下图展示了 Microsoft 规划策略：

此规划结构还有助于在进行规划时实现最高水平的学习。 团队可获取反馈、了解客户所需的内容，以及快速高效地实施客户请求。

实现多群体模式

以前的方法培养出 bug 和实时现场事件的“中断文化”。 Microsoft 团队想出了自己的方法来提供焦点，并避免干扰。 团队针对每个冲刺自行组织为两个群体：功能（F 群体）和客户（C 群体）。

F 群体致力于实现承诺的功能，而 C 群体则负责处理现场问题和中断。 该团队制定了一个轮换节奏，以便成员更轻松地规划活动。 有关多群体模式的详细信息，请参阅构建高效、以客户为中心的团队。

改进代码运行状况实践

在切换到敏捷方法之前，团队过去常常让代码 bug 不断累积，直到代码在开发阶段结束时完成。 然后，团队会发现 bug，并致力于修复它们。 此做法会造成 bug 的过山车效应，从而在团队不得不处理 bug 修复而不是实现新功能时影响团队的士气和生产力。

现在，团队可实现由公式 # of engineers x 5 = bug cap 计算得出的 bug 上限。 如果团队的 bug 计数超过冲刺结束时的 bug 上限，则必须停止处理新功能并修复 bug，直到它们降至上限之下。 此时，团队需实时偿还 bug 债务。

促进透明和问责

在每个冲刺结束时，每个团队都会发送一封邮件，报告他们在上一冲刺中取得的成就，以及他们计划在下一冲刺中执行的操作。

目标和关键结果 (OKR)

当团队明确组织试图实现的目标时，此时最有成效。 Microsoft 通过目标和关键结果 (OKR) 为团队提供明确性。

• 目标定义了要实现的目标。 目标具有重大性、具体性、行动导向性，且理想情况下是针对意向的鼓舞人心的陈述。 目标代表较大的想法，而不是实际数字。
• 关键结果定义了实现目标的步骤。 关键结果是可量化的结果，可用于评估进度并表明在特定时间段内针对目标取得的成功进展。

OKR 反映了最佳结果，而不仅仅是最可能的结果。 领导层会试着表现出雄心勃勃，而非谨慎。 推动团队追求具有挑战性的关键结果，推动加速目标，并优先考虑朝更大目标迈进的工作。

采用 OKR 框架有助于团队出于以下原因更好地执行：

• 每个团队都针对计划保持一致。
• 团队专注于实现结果，而不是完成活动。
• 每个团队都定期对工作负责。

OKR 可能存在于产品的不同级别。 例如，可以有顶级产品 OKR、组件级 OKR 和团队级 OKR。 保持 OKR 一致相对容易，尤其是在自上而下设置目标的情况下。 出现的所有冲突都是组织不一致的宝贵早期迹象。

OKR 示例

目标：培养一个强大且快乐的客户群。

关键结果：

• 将外部净推荐值 (NPS) 从 21 提高到 35。
• 将文档满意度从 55 提高到 65。
• 新管道流的 Apdex 分数为 0.9。
• 作业的队列等待时间为 5 秒或更短。

有关 OKR 的详细信息，请参阅使用目标和关键结果度量业务成果。

选择正确的指标

关键结果仅与它们所基于的指标同等有用。 Microsoft 使用关注变革的领先指标。 随着时间的推移，这些指标会构建出产品加速或减速的工作图片。 Microsoft 通常使用以下指标：

• 采用每月增长率的变化
• 性能变化
• 学习时间的变化
• 事件频率的变化

团队会避免指标不针对目标来累算价值。 虽然它们可能具有某些用途，但以下指标对跟踪目标进度没有帮助：

• 原始预估的准确性
• 已完成的小时数
• 代码的行数
• 团队容量
• 团队燃尽
• 团队速度
• 找到的 bug 数
• 代码覆盖率

敏捷之前和之后

下表总结了 Microsoft 开发团队采用敏捷做法时所做的更改。

之前	之后
4-6 个月里程碑	3 周冲刺
水平团队	垂直团队
个人办公室	团队会议室和远程工作
长期规划周期	持续规划和学习
PM、开发和测试	PM、设计和工程
年度客户参与度	持续客户参与度
功能分支	每个人都在主分支中工作
20 多人团队	8-12 人团队
机密路线图	公开共享的路线图
Bug 债务	零债务
100 页规范文档	幻灯片规格
私有仓库	开源或内部源
深层组织层次结构	平展组织层次结构
安装数量决定成功与否	用户满意度决定成功与否
功能每年交付一次	功能在每个冲刺后交付一次

关键结论

• 认真对待敏捷科学，但不要过于程式化。 敏捷可能会变得过于严格。 让敏捷思维模式和文化蓬勃发展。
• 庆祝结果，而不是活动。 部署功能胜过代码行数。
• 在每个冲刺完成后交付，以建立节奏并确定所有需完成的工作。
• 构建可实现所需行为的文化。