Microsoft AZ-400: Agile-планирование и управление работой — Руководство по подготовке

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

Часть Microsoft DevOps Engineer Expert AZ-400 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Планирование итераций, проработка бэклога и прогнозирование на основе скорости

Планирование спринта преобразует приоритеты в обязательства с ограниченным сроком. Бэклог спринта содержит элементы бэклога продукта (PBI) или пользовательские истории (User Stories), взятые в итерацию и разбитые на задачи (Tasks) с указанием оставшейся работы (Remaining Work) в часах. Используйте емкость спринта (Sprint Capacity) для моделирования доступности людей:

• Емкость каждого участника в часах/день по видам деятельности (разработка, тестирование, UX).
• Индивидуальные и командные выходные для учета праздников и отпусков.
• Балансировка нагрузки на уровне видов деятельности путем связывания задач с деятельностью и сравнения емкости с запланированной работой.

Скорость (Velocity) — это сумма story points, выполненных за спринт. Используйте диаграмму скорости (Velocity chart) для определения стабильного диапазона; избегайте «инфляции очков». В бэклогах продукта включите прогнозирование (Forecasting), чтобы спрогнозировать, сколько предстоящих итераций потребуется для выполнения бэклога при исторической средней скорости команды (на основе нескольких последних спринтов) и заданной длине итерации. Чтобы прогнозирование было точным, исключайте частично выполненную работу и строго придерживайтесь критериев готовности (DoD).

Проработка бэклога обеспечивает ясность и относительную оценку размера:

• Критерии приемки: записывайте четкие, проверяемые утверждения в поле Acceptance Criteria рабочего элемента; отдавайте предпочтение формату Given-When-Then, чтобы уменьшить двусмысленность и ускорить разработку тестов.
• Story points: оценивайте относительную сложность и неопределенность на уровне требований; не переводите очки в часы — задачи имеют поле Remaining Work.
• Относительная оценка (Planning Poker): используйте общую базовую оценку и последовательность (Фибоначчи или модифицированную Фибоначчи) для быстрого достижения согласия. Команды могут использовать расширения из Marketplace для проведения Planning Poker в Azure Boards, записывая оценки в поля Story Points/Effort для единообразной отчетности.

Ошибки (bugs) следует анализировать и либо рассматривать как требования (оценивать в story points и планировать в бэклоге), либо обрабатывать как задачи в рамках спринта; выберите единую политику для команды, чтобы поддерживать стабильную скорость.

Межкомандное планирование, запросы, отчётность, GitHub Projects и метрики DevOps

Крупные программы требуют прозрачности между командами и репозиториями:

• Планы поставки (Delivery Plans): создавайте межкомандные временные шкалы, фильтруемые по путям области/итерации. Визуализируйте работу по итерациям с линиями зависимостей (из связей Predecessor/Successor) и маркерами для ключевых этапов (даты релизов, внешние обязательства). Отображайте сводный прогресс по эпикам (Epics) и компонентам (Features) и выводите настраиваемые поля (например, Risk) для проверок управления.
• Запросы и отчётность: создавайте запросы в виде плоского списка (Flat list), чтобы отвечать на вопрос «какие элементы соответствуют этим фильтрам», дерево рабочих элементов (Tree of work items) для навигации по иерархии со сводными данными и запросы прямых связей (Direct links), чтобы анализировать один переход по ссылке (например, Feature → Stories или Bug → коммиты). Сохраняйте и делитесь запросами, добавляйте диаграммы (круговые, столбчатые, трендовые) и закрепляйте их на панелях мониторинга. Для отчётности аналитического уровня используйте сервис Azure DevOps Analytics и OData с Power BI для создания диаграмм сгорания портфеля, тепловых карт рисков зависимостей и визуализаций DORA. Встроенные отчёты включают Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time и использование ёмкости спринта (Sprint Capacity).

GitHub Projects интегрирует планирование с Issues и PR:

• Доски проектов: создавайте представления Kanban или таблицы на уровне организации или репозитория, определяйте настраиваемые поля (Status, Iteration, Priority) и фильтруйте по командам.
• Правила автоматизации: настраивайте встроенные рабочие процессы для установки статуса (Status), когда Issue или PR открыт, смёржен или закрыт; автоматически архивируйте выполненные элементы; назначайте исполнителей или метки на основе изменений полей; и перемещайте элементы между представлениями. Комбинируйте с GitHub Actions для более сложных автоматизаций.
• Интеграция с Issues и PR: Issues и PR являются полноправными элементами в Projects. Используйте ключевые слова в описаниях PR (Fixes #123), чтобы связывать и автоматически закрывать Issues. Статус и рецензенты видны на доске, обеспечивая прослеживаемость от кода до плана.

Метрики DevOps должны связывать код, развёртывание и результаты:

• Метрики DORA:
  • Частота развёртывания: количество развёртываний в прод в день/неделю; источник — события релиза из конвейера.
  • Время выполнения для изменений: измеряется от коммита кода (или мёржа PR) до развёртывания в прод; убедитесь, что конвейеры генерируют временные метки развёртывания и соотносят их с коммитами.
  • Коэффициент сбоев при изменениях: отношение количества развёртываний в прод, которые привели к инциденту, затронувшему клиента, или к откату; интегрируйте с тегами управления инцидентами и результатами конвейера.
  • Среднее время восстановления (MTTR): время, прошедшее с начала инцидента до восстановления сервиса; определяется по оповещениям мониторинга и времени закрытия инцидентов. Сопоставляйте метрики DORA с аналитикой доски (Lead/Cycle time), чтобы определить, что является ограничением — планирование или поставка. Используйте панели мониторинга, чтобы предоставлять оба набора метрик одной и той же аудитории для непрерывного улучшения.

Практический сценарий

Подразделение Microsoft Advertising координирует работу восьми кросс-функциональных команд, поставляющих общую платформу для управления кампаниями. Кодовая база находится в GitHub; организации нужны надёжные квартальные обязательства, ясная видимость зависимостей и действенные метрики потока и DORA без разрастания инструментария.

1. Выберите процесс Azure DevOps Agile и настройте команды

• Зачем: Agile предоставляет иерархию Epic > Feature > User Story, которая сочетает простоту со сводными отчётами на уровне портфеля. Создайте восемь команд, каждая со своим путём области (area path) и текущими/будущими путями итераций (iteration paths), что обеспечивает автономию в досках и панелях мониторинга, сохраняя при этом возможность отчётности на уровне всей организации.

2. Определите управление Kanban и конфигурацию доски

• Зачем: Непрерывный поток между спринтами сокращает время ожидания. Настройте столбцы, сопоставленные с состояниями, с разделением на Doing/Done для In Progress и Code Review. Установите лимиты WIP для каждого столбца и добавьте дорожку Expedite с более низким WIP. Добавьте политики доски, определяющие Definition of Done (модульные тесты пройдены, PR одобрен, чек-лист проверки развёртывания выполнен), чтобы контролировать переход в состояние Done.

3. Внедрите дисциплину проработки бэклога и оценки

• Зачем: Предсказуемые обязательства требуют последовательной оценки размера и ясности. Фиксируйте критерии приёмки в формате Given-When-Then в User Stories. Стандартизируйте Story Points с помощью Planning Poker (Фибоначчи 1–13), используя расширение для Azure Boards, и ведите оценку задач в часах в поле Remaining Work для поддержки ёмкости спринта (Sprint Capacity).

4. Планируйте спринты с прогнозированием на основе ёмкости и скорости

• Зачем: Планирование ёмкости снижает риск избыточных обязательств. Введите индивидуальную ёмкость по видам деятельности и выходным дням. Используйте график Velocity за последние шесть спринтов, чтобы установить реалистичную цель спринта. Включите прогнозирование бэклога (Forecasting), чтобы спрогнозировать, сколько спринтов потребуется для достижения квартальных целей по эпикам (Epic), согласовывая ожидания заинтересованных сторон.

5. Создайте планы поставки (Delivery Plans) для межкомандной прозрачности

• Зачем: Зависимости и ключевые этапы должны быть видны на единой временной шкале. Создайте Delivery Plan, включающий все восемь команд и уровни портфеля. Добавьте маркеры ключевых этапов для дат квартальных релизов и рыночных событий. Используйте связи Predecessor/Successor, чтобы показать линии зависимостей и выявить риски, когда элементы охватывают несколько итераций.

6. Интегрируйте GitHub Projects для представлений выполнения, ориентированных на репозиторий

• Зачем: Разработчики живут в GitHub; Projects держит контекст выполнения близко к коду. Создайте GitHub Project на уровне организации с представлениями доски и таблицы. Добавьте правила автоматизации для установки статуса In Progress при открытии PR, Done при мёрже PR и автоматического архивирования закрытых Issues. Используйте “Fixes #<id>” в PR для закрытия связанных Issues и отражения статуса на доске.

7. Свяжите код и работу для обеспечения прослеживаемости

• Зачем: Сквозная прослеживаемость обеспечивает точную отчётность и аудиты. Внедрите обязательное указание ID рабочего элемента Azure Boards в сообщениях коммитов и описаниях PR; используйте связи с артефактами (artifact links) на рабочих элементах, чтобы Delivery Plans и аналитика могли сводить прогресс на основе активности в коде.

8. Настройте отображение метрик потока и DORA на панелях мониторинга

• Зачем: Общие автоматизированные метрики стимулируют улучшения. На панелях мониторинга команд закрепите графики CFD, Lead Time и Cycle Time для управления потоком. На панели мониторинга программы отобразите Velocity, сводку по Delivery Plan и метрики DORA: рассчитывайте частоту развёртывания и время выполнения, используя события развёртывания из конвейера для продуктивных сред; вычисляйте коэффициент сбоев при изменениях и MTTR, помечая инциденты тегами и соотнося их с развёртываниями. Этот единый вид показывает, где находятся ограничения: в планировании (lead/cycle time на доске) или в поставке (DORA).

Этот подход уравновешивает автономию команд (специфичные для команды доски, ёмкость и панели мониторинга) с управлением на уровне программы (Delivery Plans, зависимости и ключевые этапы). Azure Boards обеспечивает иерархическое планирование и аналитику, GitHub Projects упрощает ежедневное отслеживание работы разработчиков с помощью автоматизации, привязанной к Issues и PR, а метрики DORA связывают планирование с операционными результатами для формирования надёжных, основанных на данных обязательств.

← Управление пакетами и артефактами · Все домены

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →