O exame AZ-400 pergunta como projetar fluxos de trabalho e medir o desempenho da equipe. Que tipo de work item vai em qual nível do Azure Boards, como o GitHub Issues se conecta ao Azure DevOps, e o que as quatro métricas DORA realmente dizem: entender o porquê de cada escolha é mais eficaz do que apenas memorizar nomes.
Hierarquia de Work Items: Até Onde Detalhar?
Pense na construção de um prédio: o projeto inteiro, depois por andares, depois por cômodos. O Azure Boards organiza o trabalho da mesma forma. é o maior bloco, abrangendo vários trimestres. é uma capacidade entregável. é o que um time conclui em um sprint — a menor unidade de valor de negócio. Abaixo estão e .
Os nomes variam conforme o template. usa User Stories, usa Product Backlog Items (PBI). O template é o único que inclui Change Request, Requirement, Risk e Review como tipos nativos, ideal para organizações com ISO 9001 ou auditoria formal. tem apenas Issue e Task, para times pequenos.
"Autonomia do time e rastreamento de sprint" → Agile + User Story. "Conformidade regulatória e controle formal de mudanças" → CMMI.
Boards, Backlogs e Sprints: Três Visões, Uma Realidade
Pense na cozinha de um restaurante durante o horário de pico. O chef principal precisa ver todos os pedidos de uma vez (o backlog), os cozinheiros precisam saber qual prato estão preparando agora (o board), e o gerente precisa ver quantos pratos foram servidos esta noite em comparação ao planejado (métricas de sprint). O Azure Boards dá a cada pessoa exatamente essa visão.
A visão é seu mural Kanban. Os work items são cartões que se movem por colunas representando transições de estado. Você pode aplicar limites WIP (Work in Progress) a cada coluna, o que evita que muitos itens fiquem "em andamento" simultaneamente e força a equipe a terminar antes de começar novo trabalho.
A visão é uma lista priorizada de tudo que a equipe planeja fazer. O Product Owner organiza os itens por prioridade de negócio. O Sprint Backlog reduz isso ao trabalho comprometido do sprint atual.
permitem filtrar work items por condições personalizadas. Salvar uma consulta como dá a cada desenvolvedor uma lista de tarefas pessoal com um clique. Os resultados de consultas também podem ser fixados diretamente como widgets de dashboard, fazendo com que uma consulta bem elaborada seja a base de qualquer dashboard útil.
O fluxo de estados dos work items também aparece regularmente nos exames. No processo Agile, o fluxo padrão é . Se um desenvolvedor fez merge do código na branch principal mas os testes de QA ainda estão pendentes, o estado correto é , não . Um work item chega a somente quando toda validação e aprovação estão concluídas. Os cálculos de velocidade do sprint incluem apenas itens .
GitHub Issues e a Ponte ABDesenvolvedores vivem no GitHub — código, pull requests e discussões estão lá. Mudar para um sistema separado só para registrar tarefas gera fricção desnecessária.
O GitHub Issues mantém o rastreamento no mesmo ambiente do código. O GitHub Projects adiciona uma camada Kanban com visões de Board, Tabela e Roadmap. Para times totalmente no GitHub, é a escolha natural.
Para quem usa Azure DevOps e GitHub juntos, é a ponte. Escrever em um commit ou PR vincula automaticamente o work item 1234 no Azure Boards. Quando o PR é mesclado, o work item passa automaticamente para .
Essa rastreabilidade bidirecional é o que o exame chama de "rastreabilidade de ponta a ponta": qualquer incidente pode ser rastreado até o PR, o User Story e o Feature correspondentes.
Times focados em GitHub preferem GitHub Issues; organizações já no Azure DevOps se beneficiam da hierarquia mais rica e dos relatórios de conformidade do Azure Boards.
As Quatro Métricas DORA: Saúde em Números
Um médico não adivinha: ele mede pressão, frequência cardíaca e temperatura. As métricas DORA fazem o mesmo para um time DevOps — convertem "achamos que estamos melhorando" em números rastreáveis.
: com que frequência a equipe faz deploy em produção. Times Elite fazem deploy várias vezes ao dia; nível Low é uma vez por mês.
: tempo do commit ao deploy em produção — quanto menor, mais rápido o valor chega ao usuário.
: tempo médio para recuperar o serviço após um incidente. Times Elite: menos de 1 hora.
: percentual de deploys que causam incidentes, rollbacks ou hotfixes. Quanto menor, melhor.
Memorize em pares: = velocidade; = estabilidade. DevOps Elite combina os dois.
!As 4 métricas do DORA
Design de Dashboards: Tornando os Números Visíveis
Dados invisíveis não mudam decisões. Um bom dashboard é como o painel de um carro: exibe os números críticos de relance para que se possa agir antes que algo falhe.
Os Azure DevOps Dashboards são baseados em widgets. Arraste widgets de Deployment Frequency, Lead Time e resultados de consultas para montar o painel da equipe. Como os widgets de consulta usam consultas salvas diretamente, uma query bem escrita alimenta o dashboard automaticamente.
Permissões relevantes: criam e gerenciam dashboards. O grupo pode visualizar, mas não editar widgets. Acesso tem restrições em certos tipos de widget.
Para times no GitHub, o GitHub Insights oferece métricas por repositório: tempo de ciclo de PR, tempo de resposta de revisão e atividade de contribuidores. Azure DevOps Dashboards cobrem a organização inteira; GitHub Insights foca em um repositório.
Resumo do Exame
"Rastreamento de sprint em nível de equipe, menor unidade de valor de negócio" -- User Story do template Agile
"Auditorias regulatórias, rastreamento formal de Change Request e Risk" -- Template CMMI
"Visão que suporta limites WIP" -- Board (Kanban)
"Estado de work item contabilizado na velocidade do sprint" -- Closed
"Commit do GitHub ou corpo de PR → work item do Azure Boards vinculado automaticamente" -- menção AB#<id> (ex. fixes AB#1234)
"Tempo do commit de código até produção" -- Lead Time for Changes
"Tempo médio de recuperação de um incidente em produção" -- MTTR (Mean Time to Restore)
"Porcentagem de deploys que causam rollbacks ou incidentes" -- Change Failure Rate
"Com que frequência a equipe faz deploy em produção" -- Deployment Frequency
"Permissão necessária para criar ou gerenciar widgets de dashboard" -- Project Administrators
"Tempo de ciclo de PR e métricas de contribuidores em nível de repositório" -- GitHub Insights
Par de velocidade DORA = Deployment Frequency + Lead Time | Par de estabilidade DORA = MTTR + Change Failure Rate