Microsoft AZ-400: 敏捷规划与工作管理 — 学习指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

属于 Microsoft DevOps Engineer Expert AZ-400 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure DevOps 中的敏捷规划和工作管理以清晰的数据模型、规范的流程和迭代实践以及跨团队的可见性为核心。Azure Boards 提供了强大的工作项类型层次结构和灵活的团队配置，而 GitHub Projects 则提供与 Issues 和 Pull Requests 紧密集成的、由自动化驱动的现代化规划。有效的采纳取决于严格的定义（完成的定义、验收标准）、一致的估算（故事点和相对估算）以及可行的洞察（查询、交付计划以及包括 DORA 在内的指标）。以下各节将详细介绍如何大规模地设计、实施和操作这些实践。

Azure Boards 数据模型、流程模板和团队配置

工作项类型和层次结构构成了规划的支柱。在默认的 Agile 流程中，项目组合的层次结构是 Epic > Feature > User Story，其中 Task 和 Bug 是执行级别的工作项。子链接捕获分解关系（User Story → Task），而 Bug 可以与用户故事在同一待办事项级别上管理，也可以根据团队策略独立进行分类处理。链接类型至关重要：

• 父/子：捕获分解层次结构，并驱动进度和工作的汇总。
• 前置/后继：表示工作项之间的排程和依赖关系；这些关系在交付计划中以依赖线的方式呈现。
• 相关/重复/被阻止：为非层次化关系和障碍建模。
• 工件链接：将工作项连接到代码（提交、分支、PR）、构建和发布，从而实现端到端的可追溯性。

Azure DevOps 流程模板定义了状态、字段和 WIT（工作项类型）的命名：

• Agile：需求级别的工作项是用户故事（User Story）；快节奏的团队通常会选择此模板。
• Scrum：需求级别的工作项是产品待办事项（Product Backlog Item, PBI）；冲刺（sprint）和 Scrum 工件是一等公民，并且 Bug 可以配置为像 PBI 一样工作。
• CMMI：需求级别的工作项是需求（Requirement），它还包括用于变更请求、风险和评审的 WIT——当您必须跟踪风险和正式评审时，请选择此模板。
• 自定义（继承）流程：在 Azure DevOps Services 中，通过继承来扩展系统流程，以添加自定义 WIT、状态、规则和字段，同时保持服务兼容性。使用类别将自定义 WIT 放置在正确的待办事项级别。避免过度自定义导致报告分裂；应标准化诸如故事点（Story Points）和剩余工作（Remaining Work）等字段。

团队是通过以下方式配置的轻量级分区：

• 区域路径：界定所有权范围和待办事项筛选；团队选择一个或多个区域路径（并可选择性地包括子区域）来定义“他们”的工作。
• 迭代路径：代表发布节奏和冲刺；团队为规划选择默认和当前迭代。
• 团队待办事项和看板：每个团队都可以选择要显示的项目组合级别（Epic、Feature）、卡片样式和列映射，而不会影响其他团队。
• 团队仪表板：使用速率（Velocity）、燃尽图/燃起图（Burndown/Burnup）、累积流图（CFD）、前置/周期时间图表（Lead/Cycle Time charts）和自定义 Analytics 视图等小组件来组织共享的可见性。

基于流的交付与看板和治理

Azure Boards 中的看板（Kanban）为从承诺到完成的持续流动进行建模。配置列以映射到工作流状态，并可选择性地将关键状态拆分为“进行中/已完成”的子列，以改进吞吐量核算并减少隐藏的队列。为每列和每个泳道设置明确的在制品（WIP）限制；在操作上强制执行这些限制——超出限制会触发改进讨论，而不是让待办事项悄无声息地增长。使用专用泳道（例如，“加速”泳道）来直观地分离高优先级项目，并为该泳道设置更严格的 WIP。

完成的定义（Definition of Done, DoD）是质量和可预测性的基石；将其编码为看板策略、特定状态转换时的必填字段或检查清单，以及验收测试链接。例如，在移动到“完成”状态之前，要求提供一个指向已通过的测试用例的“Tested By”链接，并在移动到“已发布”状态时捕获部署验证步骤。

使用分析功能来管理流程的健康状况：

• 累积流图：验证 WIP 平衡状态，并在条带扩张时检测瓶颈。
• 前置时间：衡量从创建到完成所经过的时间；周期时间则专注于从进入“活动”状态到完成的时间。周期时间图表小组件报告工作项转换到“活动”状态后经过的时间，这与瓶颈分析相一致。
• 吞吐量图表：跟踪每个时间段内完成的项目数；监控其稳定性和趋势。

迭代规划、待办事项列表优化和基于速率的预测

Sprint 规划将优先级转化为有时间限制的承诺。Sprint 待办事项列表列出了被拉入当前迭代的产品待办事项 (PBI) 或用户故事，并将其分解为带有“剩余工时”（以小时为单位）的任务。使用 Sprint 容量来为人员可用性建模：

• 按活动（开发、测试、用户体验）划分的个人容量（小时/天）。
• 个人和团队的休假日，以反映节假日和休假情况。
• 通过将任务与活动关联并审查容量与计划工作的对比，实现活动级别的负载均衡。

速率 (Velocity) 总结了每个 Sprint 交付的故事点数。使用速率图建立一个稳定区间；避免“点数膨胀”。在产品待办事项列表上，启用预测功能，以根据团队的历史平均速率（基于最近几个 Sprint）和迭代长度，来预测燃尽待办事项列表需要多少个未来的迭代。通过排除部分完成的工作并维持严格的 DoD（完成的定义），来保持预测的真实性。

待办事项列表优化旨在确保清晰度和相对规模：

• 验收标准：在工作项的“验收标准”字段中记录清晰、可测试的陈述；优先使用 Given-When-Then 格式以减少模糊性并加速测试设计。
• 故事点：在需求级别估算相对复杂度和不确定性；不要将点数转换为小时——任务承载的是“剩余工时”。
• 相对估算（规划扑克）：使用共享的基线和一个序列（斐波那契或修改后的斐波那契）来快速达成共识。团队可以使用 Marketplace 扩展在 Azure Boards 中运行规划扑克，并将估算值写入 Story Points/Effort 字段，以实现一致的报告。

缺陷 (Bug) 应进行分类，然后可以像需求一样处理（用点数估算并在待办事项列表上规划），也可以作为 Sprint 内的任务来处理；每个团队应选择一种统一的策略，以保持速率的一致性。

跨团队规划、查询、报告、GitHub Projects 和 DevOps 指标

大型项目需要在多个团队和代码仓库之间实现可见性：

• Delivery Plans：创建按区域/迭代路径筛选的多团队时间线。通过依赖关系线（来自 Predecessor/Successor 链接）和里程碑标记（发布日期、外部承诺）按迭代可视化工作。展示 Features 和 Epics 的汇总进度，并暴露自定义字段（例如，Risk）以供治理评审。
• 查询和报告：构建“平铺列表查询”以回答“哪些项匹配这些筛选器”，构建“工作项树”以通过汇总导航层次结构，以及构建“直接链接查询”以分析单跳链接（例如，Feature → Stories 或 Bug → commits）。保存和共享查询，添加图表（饼图、条形图、趋势图），并将其固定到仪表板。对于分析级报告，可使用 Azure DevOps Analytics 服务和 OData 结合 Power BI 来生成项目组合燃尽图、依赖风险热力图和 DORA 可视化。内置报告包括 Velocity、Burndown/Burnup、CFD、Lead Time、Cycle Time 和 Sprint Capacity 使用情况。

GitHub Projects 将规划与 Issues 和 PRs 集成在一起：

• 项目板：在组织或代码仓库范围创建看板或表格视图，定义自定义字段（Status、Iteration、Priority），并按团队筛选。
• 自动化规则：配置内置工作流，以便在 Issue 或 PR 被打开、合并或关闭时设置 Status；自动归档已完成的项；根据字段变更分配或添加标签；以及在视图之间移动项。与 GitHub Actions 结合可实现高级自动化。
• Issues 和 PR 集成：Issues 和 PRs 是 Projects 中的一等公民。在 PR 描述中使用关键字（Fixes #123）来链接并自动关闭 Issues。状态和审查者在项目板上可见，从而实现从代码到计划的可追溯性。

DevOps 指标必须将代码、部署和成果联系起来：

• DORA 指标：
  • Deployment frequency：计算每天/每周的生产部署次数；数据源于流水线发布事件。
  • Lead time for changes：衡量从代码提交（或 PR 合并）到生产部署的时间；确保流水线发出部署时间戳，并将其与提交相关联。
  • Change failure rate：导致影响客户的事件或回滚的生产部署所占的比例；与事件管理标签和流水线结果集成。
  • Mean time to restore (MTTR)：从事件开始到服务恢复所用的时间；数据源于监控警报和事件关闭时间。 将 DORA 与看板分析（Lead/Cycle time）关联起来，以检测规划或交付环节是否是瓶颈。使用仪表板向同一受众呈现这两组指标，以实现持续改进。

实践问题场景

微软的广告部门正在协调八个跨职能团队，他们共同交付一个共享的广告活动管理平台。代码库位于 GitHub；该组织需要可靠的季度承诺、清晰的依赖关系可见性，以及可行的流程和 DORA 指标，同时不增加工具的过度扩展。

1. 选择 Azure DevOps Agile 流程并配置团队

• 原因：Agile 流程提供了 Epic > Feature > User Story 的层次结构，它在简单性与项目组合汇总之间取得了平衡。创建八个团队，每个团队都有自己的区域路径以及当前和未来的迭代路径，从而在看板和仪表板上实现自主性，同时保留组织范围的报告能力。

2. 定义看板治理和面板配置

• 原因：冲刺间的持续流动减少了等待时间。配置映射到状态的列，并为“进行中”和“代码审查”设置“Doing/Done”拆分列。为每列设置 WIP 限制，并添加一个具有更低 WIP 的“加速”泳道。添加看板策略，说明“完成的定义”（单元测试通过、PR 获批、部署验证清单完成），以控制进入“完成”状态的关卡。

3. 实施待办事项列表优化和估算纪律

• 原因：可预测的承诺需要一致的规模估算和清晰度。在 User Stories 上使用 Given-When-Then 格式捕获验收标准。使用 Azure Boards 扩展，通过 Planning Poker (Fibonacci 1–13) 来标准化 Story Points，并将任务估算保留在“剩余工时”中，以支持 Sprint Capacity。

4. 使用容量和基于速率的预测来规划冲刺

• 原因：容量规划可减少过度承诺。按活动和休假日输入个人容量。使用过去六个冲刺的 Velocity 图表来设定一个切合实际的冲刺目标。启用待办事项列表 Forecasting 功能，以预测需要多少个冲刺才能达到季度 Epic 目标，从而统一利益相关者的期望。

5. 建立 Delivery Plans 以实现跨团队可见性

• 原因：依赖关系和里程碑必须在单一时间线上可见。创建一个包含所有八个团队和项目组合级别的 Delivery Plan。为季度发布日期和市场活动添加里程碑标记。使用 Predecessor/Successor 链接来显示依赖关系线，并暴露跨迭代项的风险。

6. 集成 GitHub Projects 以获得以代码仓库为中心的执行视图

• 原因：开发者在 GitHub 中工作；Projects 使执行上下文贴近代码。创建一个组织级别的 GitHub Project，包含看板和表格视图。添加自动化规则，以便在 PR 打开时将 Status 设置为“进行中”，在 PR 合并时设置为“完成”，并自动归档已关闭的 Issues。在 PR 中使用 “Fixes #<id>” 来关闭链接的 Issues，并将状态反映回项目板。

7. 链接代码和工作以实现可追溯性

• 原因：端到端可追溯性支持准确的报告和审计。强制要求在提交消息和 PR 描述中引用 Azure Boards 工作项 ID；在工作项上使用工件链接，以便 Delivery Plans 和分析功能可以从代码活动中汇总进度。

8. 在仪表板上实施流程和 DORA 指标

• 原因：共享的自动化指标驱动改进。在团队仪表板上，固定 CFD、Lead Time 和 Cycle Time 图表以管理流程。在项目群仪表板上，呈现 Velocity、Delivery Plan 摘要和 DORA 指标：使用来自生产阶段的流水线部署事件计算部署频率和前置时间；通过标记事件并将其与部署相关联来推导变更失败率和 MTTR。这种统一视图突显了瓶颈是在规划（看板的前置/周期时间）还是在交付（DORA）环节。

这种方法在团队自主性（特定于团队的看板、容量和仪表板）与项目群治理（Delivery Plans、依赖关系和里程碑）之间取得了平衡。Azure Boards 提供分层规划和分析，GitHub Projects 通过与 Issues 和 PRs 绑定的自动化简化了开发人员的日常跟踪，而 DORA 指标则将规划与运营成果联系起来，以实现可信的、数据驱动的承诺。

← 包管理与工件管理 · 所有领域

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →