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 页规范文档 | 幻灯片规格 |
| 私有仓库 | 开源或内部源 |
| 深层组织层次结构 | 平展组织层次结构 |
| 安装数量决定成功与否 | 用户满意度决定成功与否 |
| 功能每年交付一次 | 功能在每个冲刺后交付一次 |
关键结论
- 认真对待敏捷科学，但不要过于程式化。 敏捷可能会变得过于严格。 让敏捷思维模式和文化蓬勃发展。
- 庆祝结果，而不是活动。 部署功能胜过代码行数。
- 在每个冲刺完成后交付，以建立节奏并确定所有需完成的工作。
- 构建可实现所需行为的文化。