微软如何使用 DevOps 进行计划

Microsoft是世界上使用敏捷方法的最大公司之一。 经过多年的经验，Microsoft开发了一个 DevOps 规划过程，该过程可以从最小的项目扩展到大规模的工作，例如 Windows。 本文介绍在规划整个公司的软件项目时Microsoft实施的许多教训和做法。

关键性更改

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

• 促进文化一致性和自治。
• 将焦点从个人更改为团队。
• 创建新的规划和学习策略。
• 实现多船员模型。
• 改进代码健康状况做法。
• 促进透明度和问责。

促进文化一致性和自主性

彼得·德鲁克说，“文化能决定策略的成败。” 自主性、精通和目标是关键的人类动机。 Microsoft尝试为 PMS、开发人员和设计人员提供这些激励因素，以便他们感到能够生成成功的产品。

此方法的两个重要贡献者是 对齐 和 自治。

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

对齐和自治之间有微妙的平衡。 太多的对齐方式可以创造一种消极的文化，人们只有在被告知时才能表演。 太多的自治可能导致缺乏结构或方向、低效的决策和糟糕的规划。

将焦点从个人更改为团队

Microsoft将人员和团队组织成三个组：PM、设计和工程。

• 产品经理定义了 Microsoft 构建的内容及其理由。
• 设计负责设计Microsoft生成的内容。
• 工程部门构建产品并确保其质量。

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

• 跨学科
• 10-12 人
• 自我管理
• 明确的 12-18 个月的计划和目标
• 物理团队会议室
• 自己的功能部署
• 在生产环境中拥有自己的功能

努力实现跨职能团队

以前，Microsoft 的团队是水平式组织，涵盖所有 UI、所有数据或所有 API。 现在，微软致力于 垂直团队。 团队负责整个产品的各自领域。 某些层中的严格准则可确保整个产品团队之间的统一性。

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

允许自选团队

大约每18个月，微软会进行一次“黄色便签活动”，开发人员可以在其中选择自己希望在接下来几个规划周期中从事的产品领域。 此练习提供自主性，因为团队可以选择要处理的内容和组织一致性，因为它在团队之间促进平衡。 在本次活动中，大约80% 的人仍然留在他们目前的团队中，但他们感到被赋予权力，因为他们拥有选择的权利。

创建新的规划和学习策略

德怀特·艾森豪威尔说，“计划毫无价值，但规划是一切。Microsoft规划分解为以下结构：

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

工程师和团队主要负责冲刺和计划。 领导主要负责周期和策略。

下图说明了Microsoft规划策略：

此规划结构还有助于在进行规划时最大化 学习 。 Teams 能够获取反馈、了解客户想要的内容，以及快速高效地实施客户请求。

实施多成员模型

以前的方法培养了 bug 和现场事件的“中断文化”。 Microsoft团队想出了自己的方法来提供专注，避免分心。 团队为每个迭代自组织成两个不同的团队：特性（F团队）和客户（C团队）。

F-crew 在承诺的功能上工作，C 组处理现场问题和中断。 该团队建立了一个轮换节奏，使成员能够更轻松地计划活动。 有关多成员团队模式的详细信息，请参阅 “生成高效、以客户为中心的团队”。

改进代码健康实践

在切换到敏捷方法之前，团队习惯让代码 bug 积累，直到在开发阶段结束时代码完成。 然后，团队发现了错误，并致力于修复它们。 这种做法带来了层出不穷的 bug，这影响了团队的士气和生产力，因为团队不得不修复这些 bug，而不是实现新功能。

Teams 现在实现由公式计算的 # 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通常使用以下指标：

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

团队避免使用不会为实现目标贡献价值的指标。 虽然它们可能具有某些用途，但以下指标对跟踪目标进度没有帮助：

• 原始估计的准确性
• 已完成的小时数
• 代码行
• 团队容量
• 团队烧毁
• 团队速度
• 发现的缺陷数量
• 代码覆盖率

敏捷之前和敏捷之后

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

关键结论

• 认真对待敏捷科学，但不要过于规范。 敏捷可能变得过于严格。 让敏捷思维模式和文化发展。
• 庆祝结果，而不是活动。 部署功能比代码行数更为重要。
• 在每个冲刺中交付，以建立节奏和步调，并识别出所有需要完成的工作。
• 建立你期望的文化，以促成你想要的行为。