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 作為執行層級的項目。子連結 (Child links) 用於捕捉分解過程 (User Story → Task)，而 Bug 可以與 User Stories 在同一個待辦項目層級上管理，或根據團隊政策獨立進行分類處理。連結類型至關重要：

父/子 (Parent/Child)：捕捉分解階層，並驅動進度與心力的彙總。
前置/後續 (Predecessor/Successor)：表達工作項目之間的排程與相依性關係；這些關係會以相依性線條的形式呈現在 Delivery Plans 中。
相關/重複/被…阻擋 (Related/Duplicate/Blocked by)：建立非階層式關係與障礙的模型。
成品連結 (Artifact links)：將工作項目連結到程式碼 (commits、branches、PRs)、建置 (builds) 與發行 (releases)，實現端對端的可追溯性。

Azure DevOps 流程範本定義了狀態、欄位與 WIT (工作項目類型) 的命名：

Agile：需求層級的項目是 User Story；快速行動的團隊通常會選擇此範本。
Scrum：需求層級的項目是 Product Backlog Item (PBI)；衝刺 (sprints) 與 Scrum 成品是第一級支援的項目，且 Bug 可被設定為像 PBI 一樣運作。
CMMI：需求層級的項目是 Requirement，並包含用於 Change Request、Risk 與 Review 的 WIT——當您必須追蹤風險與正式審查時，請選擇此範本。
自訂 (繼承) 流程：在 Azure DevOps Services 中，可透過繼承 (Inheritance) 來擴充系統流程，以新增自訂的 WIT、狀態、規則與欄位，同時保持服務相容性。使用類別 (categories) 將自訂的 WIT 放置在正確的待辦項目層級。避免過度自訂而破壞報表的一致性；應標準化 Story Points 和 Remaining Work 等欄位。

團隊是透過以下方式設定的輕量級分區：

區域路徑 (Area paths)：界定所有權範圍與篩選待辦項目；團隊可選取一個或多個區域路徑 (並可選擇性地包含子區域) 來定義「他們的」工作。
迭代路徑 (Iteration paths)：代表發行節奏與衝刺 (sprints)；團隊會為規劃挑選預設與當前的迭代。
團隊待辦項目與看板：每個團隊可各自選擇要顯示哪些組合管理層級 (Epic、Feature)、卡片樣式與欄位對應，而不會影響其他團隊。
團隊儀表板：使用 Velocity、Burndown/Burnup、Cumulative Flow Diagram (CFD)、Lead/Cycle Time 圖表與自訂 Analytics 檢視等小工具，來策劃共享的可見性。

以流程為基礎的交付與 Kanban 及治理

Azure Boards 中的 Kanban 建立了從承諾到完成的持續流程模型。設定欄位以對應到工作流程的各個狀態，並可選擇性地將關鍵狀態分割為「進行中/已完成」(Doing/Done) 的子欄，以改善產出量計算並減少隱藏的佇列。為每個欄與每個泳道 (swimlane) 設定明確的 WIP (進行中工作) 限制；並在操作上強制執行——超出限制會觸發改善的對話，而不是讓待辦項目無聲無息地增長。使用專用的泳道 (例如，急件 Expedite) 來視覺上區分高優先級項目，並為該泳道設定更嚴格的 WIP。

完成的定義 (Definition of Done, DoD) 鞏固了品質與可預測性；可將其編碼為看板原則、特定轉換上的必要欄位或檢查清單，以及驗收測試的連結。例如，要求在移至「完成」(Done) 狀態前，必須有一個指向通過的 Test Case 的「Tested By」連結，並在移至「已發行」(Released) 時，捕捉部署驗證的步驟。

使用分析功能來管理流程的健康狀況：

Cumulative Flow Diagram 可驗證 WIP 的平衡狀態，並在帶狀區域擴大時偵測瓶頸。
Lead Time 衡量從建立到完成所經過的總時間；Cycle Time 則專注於從進入「作用中」(Active) 狀態到完成的時間。Cycle Time 圖表小工具會報告工作項目轉換到「作用中」之後所經過的時間，這與瓶頸分析相符。
Throughput charts 追蹤每個時間單位內完成的項目數；用以監控穩定性與趨勢。

迭代規劃、待辦項目精煉與基於速率的預測

衝刺規劃 (Sprint planning) 將優先順序轉換為有時間限制 (timeboxed) 的承諾。衝刺待辦清單 (sprint backlog) 列出了被拉入該迭代的 PBI 或使用者故事 (User Stories)，並分解為帶有「剩餘工時」(Remaining Work) 的任務 (Tasks)。使用「衝刺容量」(Sprint Capacity) 來模擬人員可用性：

按活動 (開發、測試、使用者體驗) 劃分的每人每日容量 (小時)。
個人和團隊的休假日，以反映假日和請假。
透過將任務與活動建立關聯，並檢視容量與計畫工作的對比，來進行活動層級的負載平衡。

速率 (Velocity) 總結了每個衝刺交付的故事點 (story points)。使用速率圖 (Velocity chart) 建立一個穩定的區間；避免「點數通膨」(point inflation)。在產品待辦清單上，啟用「預測」(Forecasting) 功能，以根據團隊的歷史平均速率 (基於最近幾個衝刺) 和迭代長度，來預估需要多少個未來的迭代才能燃盡 (burn down) 待辦項目。透過排除部分完成的工作並維持嚴格的 DoD (完成的定義)，來保持預測的真實性。

待辦項目精煉 (Backlog refinement) 強調清晰度和相對規模估算：

驗收標準 (Acceptance criteria)：在工作項目的「驗收標準」欄位中記錄清晰、可測試的陳述；偏好使用 Given-When-Then 格式以減少模糊性並加速測試設計。
故事點 (Story points)：在需求層級估算相對複雜度和不確定性；不要將點數轉換為小時——任務 (tasks) 帶有「剩餘工時」(Remaining Work)。
相對估算 (規劃撲克 Planning Poker)：使用共享的基準和一個序列 (費波那契或修改過的費波那契) 來快速收斂。團隊可以使用 Marketplace 擴充功能在 Azure Boards 中執行規劃撲克，將估算值寫入 Story Points/Effort 欄位，以實現一致的報告。

錯誤 (Bugs) 應進行分類，然後像需求一樣處理 (用點數估算並在待辦清單上規劃)，或在衝刺中作為任務處理；每個團隊應選擇一種策略以保持速率的一致性。

← 套件管理與成品管理 · 所有領域

練習這些題目 → · 在 ExamRoll.io 上限時練習 →