Microsoft AZ-400: Planejamento Ágil e Gerenciamento de Trabalho — Guia de estudos

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

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O planejamento ágil e o gerenciamento de trabalho no Azure DevOps se concentram em um modelo de dados claro, práticas disciplinadas de fluxo e iteração, e visibilidade entre as equipes. O Azure Boards fornece uma hierarquia robusta de tipos de item de trabalho e configurações flexíveis por equipe, enquanto o GitHub Projects oferece um planejamento moderno, orientado por automação e totalmente integrado com Issues e Pull Requests. A adoção eficaz depende de definições rigorosas (Definição de Pronto, critérios de aceite), estimativas consistentes (story points e dimensionamento relativo) e insights acionáveis (consultas, planos de entrega e métricas, incluindo DORA). As seções a seguir detalham como projetar, implementar e operar essas práticas em escala.

Modelo de Dados do Azure Boards, Templates de Processo e Configuração de Equipe

Os tipos de item de trabalho e a hierarquia formam a espinha dorsal do planejamento. No processo Agile padrão, a hierarquia de portfólio é Epic > Feature > User Story, com Task e Bug como itens de nível de execução. Links do tipo ‘Child’ (filho) capturam a decomposição (User Story → Task), e os Bugs podem ser gerenciados no mesmo nível de backlog que as User Stories ou triados de forma independente, com base na política da equipe. Os tipos de link são essenciais:

Parent/Child (Pai/Filho): captura a hierarquia de decomposição e impulsiona o rollup de progresso e esforço.
Predecessor/Successor (Predecessor/Sucessor): expressa relações de agendamento e dependência entre itens de trabalho; elas aparecem nos Delivery Plans como linhas de dependência.
Related/Duplicate/Blocked by (Relacionado/Duplicado/Bloqueado por): modela relações não hierárquicas e impedimentos.
Links de artefato: conectam itens de trabalho ao código (commits, branches, PRs), builds e releases, permitindo rastreabilidade de ponta a ponta.

Os templates de processo do Azure DevOps definem estados, campos e a nomenclatura dos WITs (Work Item Types):

Agile: O item de nível de requisito é a User Story; equipes que se movem rapidamente costumam escolher este.
Scrum: O item de nível de requisito é o Product Backlog Item (PBI); sprints e artefatos do Scrum são de primeira classe, e os Bugs podem ser configurados para se comportarem como PBIs.
CMMI: O item de nível de requisito é o Requirement e inclui WITs para Change Request, Risk e Review — escolha este quando precisar rastrear riscos e revisões formais.
Processos personalizados (herdados): No Azure DevOps Services, estenda um processo do sistema via Herança (Inheritance) para adicionar WITs, estados, regras e campos personalizados, preservando a compatibilidade do serviço. Use categorias para colocar um WIT personalizado no nível de backlog correto. Evite personalização excessiva que fragmente os relatórios; padronize campos como Story Points e Remaining Work.

As equipes (Teams) são partições leves configuradas via:

Area paths: definem o escopo de propriedade e a filtragem do backlog; as equipes selecionam um ou mais area paths (e, opcionalmente, incluem áreas filhas) para definir “seu” trabalho.
Iteration paths: representam a cadência de releases e sprints; uma equipe escolhe iterações padrão e atuais para o planejamento.
Backlogs e quadros da equipe: cada equipe escolhe quais níveis de portfólio (Epic, Feature) exibir, estilos de cartão e mapeamentos de coluna por equipe sem impactar outras equipes.
Dashboards da equipe: organize a visibilidade compartilhada usando widgets para Velocity, Burndown/Burnup, Cumulative Flow Diagram (CFD), gráficos de Lead/Cycle Time e exibições personalizadas do Analytics.

Entrega Baseada em Fluxo com Kanban e Governança

O Kanban no Azure Boards modela o fluxo contínuo desde o comprometimento até a conclusão. Configure colunas para mapear os estados do fluxo de trabalho e, opcionalmente, divida estados críticos em subcolunas Doing/Done (Fazendo/Feito) para melhorar a contabilidade da vazão (throughput) e reduzir filas ocultas. Defina limites explícitos de WIP (Work In Progress) por coluna e por raia (swimlane); aplique-os operacionalmente — violar um limite desencadeia uma conversa de melhoria em vez de um crescimento silencioso do backlog. Use raias (swimlanes) dedicadas (por exemplo, Expedite) para separar visualmente itens de alta prioridade e definir um WIP mais restrito para essa raia.

A Definição de Pronto (Definition of Done - DoD) ancora a qualidade e a previsibilidade; codifique-a como políticas do quadro, campos obrigatórios ou checklists em transições específicas e vinculação a testes de aceite. Por exemplo, exija um link ‘Tested By’ para um Test Case aprovado antes de mover para ‘Done’ (Pronto), e capture as etapas de verificação da implantação ao mover para ‘Released’ (Lançado).

Use o analytics para gerenciar a saúde do fluxo:

O Cumulative Flow Diagram (Diagrama de Fluxo Cumulativo) valida o equilíbrio do WIP e detecta gargalos quando as faixas se expandem.
O Lead Time mede o tempo decorrido da criação à conclusão; o Cycle Time foca no tempo desde a entrada no estado ‘Active’ (Ativo) até a conclusão.
O widget de gráfico de Cycle Time informa o tempo decorrido depois que um item de trabalho transita para ‘Active’ (Ativo), alinhando-se com a análise de gargalos.
Gráficos de Throughput (Vazão) rastreiam os itens concluídos por período de tempo; monitore a estabilidade e a tendência.

Planejamento da Iteração, Refinamento do Backlog e Previsão Baseada em Velocity

O planejamento do sprint converte a prioridade em um compromisso com prazo definido (timeboxed). O sprint backlog lista os PBIs ou User Stories trazidos para a iteração, decompostos em Tasks com o Remaining Work em horas. Use o Sprint Capacity para modelar a disponibilidade das pessoas:

Capacidade por pessoa em horas/dia por atividade (Desenvolvimento, Teste, UX).
Dias de folga individuais e da equipe para refletir feriados e licenças.
Balanceamento de carga no nível da atividade, associando tarefas a atividades e revisando a capacidade versus o trabalho planejado.

O Velocity resume os story points entregues por sprint. Use o gráfico de Velocity para estabelecer uma faixa estável; evite a “inflação de pontos”. Nos backlogs de produto, habilite o Forecasting para projetar quantas iterações futuras serão necessárias para consumir (burn down) o backlog na velocidade média histórica da equipe (com base em vários sprints recentes) e na duração da iteração. Mantenha a previsão honesta, excluindo o trabalho parcialmente concluído e mantendo um DoD (Definition of Done) rigoroso.

O refinamento do backlog impõe clareza e dimensionamento relativo:

Critérios de aceitação: registre declarações claras e testáveis no campo Acceptance Criteria do item de trabalho; prefira o formato Given-When-Then para reduzir a ambiguidade e acelerar o design dos testes.
Story points: estime a complexidade e a incerteza relativas no nível do requisito; não converta pontos em horas — as tarefas carregam o Remaining Work.
Estimativa relativa (Planning Poker): use uma linha de base compartilhada e uma sequência (Fibonacci ou Fibonacci modificada) para convergir rapidamente. As equipes podem usar extensões do Marketplace para executar o Planning Poker dentro do Azure Boards, gravando as estimativas nos campos Story Points/Effort para relatórios consistentes.

Os bugs devem ser triados e tratados como requisitos (estimados com pontos e planejados no backlog) ou como tarefas dentro do sprint; escolha uma política por equipe para manter o velocity consistente.

Planejamento entre Equipes, Consultas, Relatórios, GitHub Projects e Métricas de DevOps

Grandes programas exigem visibilidade entre equipes e repositórios:

Planos de Entrega (Delivery Plans): crie cronogramas multiequipe filtrados por caminhos de área/iteração. Visualize o trabalho por iteração com linhas de dependência (a partir de links Predecessor/Successor) e marcadores para marcos (datas de lançamento, compromissos externos). Mostre o progresso consolidado em Features e Epics e exponha campos personalizados (ex: Risco) para revisões de governança.
Consultas e relatórios: crie consultas de lista plana (Flat list) para responder “quais itens correspondem a estes filtros”, Árvore de itens de trabalho para navegar na hierarquia com consolidações (rollups) e consultas de links diretos para analisar um salto de link (ex: Feature → Stories ou Bug → commits). Salve e compartilhe consultas, adicione gráficos (pizza, barra, tendência) e fixe-os em dashboards. Para relatórios de nível analítico, use o serviço Azure DevOps Analytics e OData com o Power BI para produzir burndown de portfólio, mapas de calor de risco de dependência e visualizações DORA. Os relatórios integrados incluem Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time e uso da Capacidade do Sprint.

O GitHub Projects integra o planejamento com Issues e PRs:

Quadros de projeto: crie visualizações Kanban ou de tabela no escopo da organização ou do repositório, defina campos personalizados (Status, Iteração, Prioridade) e filtre por equipe.
Regras de automação: configure fluxos de trabalho integrados para definir o Status quando uma Issue ou PR é aberta, mesclada ou fechada; arquive automaticamente itens concluídos; atribua ou rotule com base em alterações de campo; e mova itens entre as visualizações. Combine com o GitHub Actions para automações avançadas.
Integração de Issues e PRs: Issues e PRs são itens de primeira classe no Projects. Use palavras-chave nas descrições de PRs (Fixes #123) para vincular e fechar Issues automaticamente. O status e os revisores são visíveis no quadro, permitindo a rastreabilidade do código ao plano.

As métricas de DevOps devem conectar código, implantação e resultados:

Métricas DORA:
- Frequência de implantação: conte as implantações em produção por dia/semana; obtenha os dados de eventos de release do pipeline.
- Lead time para alterações: meça do commit do código (ou merge do PR) até a implantação em produção; garanta que os pipelines emitam timestamps de implantação e os correlacionem aos commits.
- Taxa de falha de alteração: proporção de implantações em produção que resultam em um incidente que impacta o cliente ou em um rollback; integre com tags de gerenciamento de incidentes e resultados do pipeline.
- Tempo médio para restauração (MTTR): tempo decorrido desde o início do incidente até a restauração do serviço; impulsione a partir de alertas de monitoramento e tempos de fechamento de incidentes. Correlacione as métricas DORA com a análise do Quadro (Lead/Cycle time) para detectar se a restrição está no planejamento ou na entrega. Use dashboards para expor ambos os conjuntos de métricas ao mesmo público para melhoria contínua.

Cenário de Problema Prático

A divisão de Publicidade da Microsoft está alinhando oito equipes multifuncionais que entregam uma plataforma compartilhada de gerenciamento de campanhas. A base de código está no GitHub; a organização precisa de compromissos trimestrais confiáveis, visibilidade clara de dependências e métricas de fluxo e DORA acionáveis sem aumentar a proliferação de ferramentas.

Escolha o processo Agile do Azure DevOps e configure as equipes

Por quê: O processo Agile fornece a hierarquia Epic > Feature > User Story que equilibra a simplicidade com as consolidações (rollups) de portfólio. Crie oito equipes, cada uma com seu próprio caminho de área e caminhos de iteração atuais/futuros, permitindo autonomia em quadros e dashboards, ao mesmo tempo que preserva os relatórios de toda a organização.

Defina a governança Kanban e a configuração do quadro

Por quê: O fluxo contínuo entre sprints reduz o tempo de espera. Configure colunas mapeadas para estados com divisões Fazendo/Feito (Doing/Done) para Em Andamento (In Progress) e Revisão de Código (Code Review). Defina limites de WIP por coluna e adicione uma raia (swimlane) de Expedite com um WIP menor. Adicione políticas de quadro que estabeleçam a Definição de Pronto (Definition of Done) (testes de unidade aprovados, PR aprovado, checklist de verificação de implantação concluído) para controlar a movimentação para Concluído (Done).

Implemente o refinamento do backlog e a disciplina de estimativa

Por quê: Compromissos previsíveis exigem dimensionamento consistente e clareza. Capture os critérios de aceitação usando Given-When-Then nas User Stories. Padronize os Story Points via Planning Poker (Fibonacci 1–13) usando uma extensão do Azure Boards e mantenha as estimativas de tarefas em horas de Trabalho Restante (Remaining Work) para suportar a Capacidade do Sprint.

Planeje sprints com capacidade e previsão baseada em velocity

Por quê: O planejamento de capacidade reduz o excesso de compromissos. Insira as capacidades individuais por atividade e dias de folga. Use o gráfico de Velocity dos últimos seis sprints para definir uma meta de sprint realista. Habilite a Previsão (Forecasting) do backlog para projetar quantos sprints são necessários para atingir os objetivos trimestrais do Epic, alinhando as expectativas das partes interessadas.

Estabeleça Planos de Entrega (Delivery Plans) para visibilidade entre equipes

Por quê: Dependências e marcos devem ser visíveis em um único cronograma. Crie um Plano de Entrega incluindo todas as oito equipes e os níveis de portfólio. Adicione marcadores de marcos para as datas de lançamento trimestrais e eventos de mercado. Use links Predecessor/Successor para mostrar linhas de dependência e expor riscos onde os itens abrangem várias iterações.

Integre o GitHub Projects para visões de execução centradas no repositório

Por quê: Os desenvolvedores vivem no GitHub; o Projects mantém o contexto de execução próximo ao código. Crie um GitHub Project no nível da organização com visualizações de quadro e tabela. Adicione regras de automação para definir o Status como Em Andamento (In Progress) na abertura de um PR, como Concluído (Done) no merge de um PR e para arquivar automaticamente Issues fechadas. Use “Fixes #<id>” nos PRs para fechar as Issues vinculadas e refletir o status de volta no quadro.

Vincule código e trabalho para rastreabilidade

Por quê: A rastreabilidade de ponta a ponta permite relatórios e auditorias precisos. Exija a referência ao ID do item de trabalho do Azure Boards nas mensagens de commit e nas descrições de PR; use links de artefato nos itens de trabalho para que os Planos de Entrega e as análises possam consolidar o progresso a partir da atividade de código.

Instrumente métricas de fluxo e DORA em dashboards

Por quê: Métricas compartilhadas e automatizadas impulsionam a melhoria. Nos dashboards da equipe, fixe gráficos de CFD, Lead Time e Cycle Time para gerenciar o fluxo. Em um dashboard de programa, exponha o Velocity, o resumo do Plano de Entrega e as métricas DORA: calcule a frequência de implantação e o lead time usando eventos de implantação do pipeline de estágios de produção; derive a taxa de falha de alteração e o MTTR marcando incidentes e correlacionando-os com as implantações. Essa visão unificada destaca se as restrições estão no planejamento (lead/cycle time do quadro) ou na entrega (DORA).

Essa abordagem equilibra a autonomia da equipe (quadros, capacidade e dashboards específicos da equipe) com a governança do programa (Planos de Entrega, dependências e marcos). O Azure Boards fornece planejamento hierárquico e análises, o GitHub Projects otimiza o acompanhamento diário do desenvolvedor com automação vinculada a Issues e PRs, e as métricas DORA conectam o planejamento aos resultados operacionais para compromissos confiáveis e baseados em dados.

← Gerenciamento de Pacotes e Gerenciamento de Artefatos · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →