Como Gerenciar e Observar as Filas do Azure dos Tickets de Desenvolvimento

Resumo do que será ensinado

Neste documento você aprenderá como acessar os projetos no Azure DevOps, visualizar as filas (quadros) de desenvolvimento, entender o significado de cada coluna/etapa, acompanhar o status dos cards (tickets) e como atuar nas colunas que são responsabilidade do suporte/qualidade (principalmente Teste e Impedimentos).

Segue um Vídeo explicativo do processo

Detalhamento do uso correto

Com este guia, você deve ser capaz de gerenciar e olhar as filas do Azure dos tickets de desenvolvimento, acompanhando as demandas dos programadores e atuando corretamente nas etapas que envolvem testes, impedimentos e comunicação com o cliente.

Segue o detalhamento de como gerenciar e olhar as filas do Azure dos tickets de desenvolvimento

1. Primeiro passo: Acessar o Azure com o login do suporte.

   • Abra o navegador de internet e acesse o endereço do Azure DevOps utilizado pela empresa.
   • Informe o usuário e senha do suporte (conta corporativa utilizada para acesso ao Azure).
   • Após o login, você será direcionado à página principal onde são listados os projetos disponíveis.
   • Ponto de atenção: utilize sempre o login oficial do suporte para que todo o registro de atividades fique vinculado ao usuário correto.

2. Segundo passo: Identificar os projetos disponíveis e sua finalidade.

   • Na tela inicial do Azure, será exibida a lista de projetos. No vídeo são citados:
     
     • Projeto ERP (ou mais de um projeto ERP, cada um com seu escopo).
     • Projeto PDV Light – onde estão os PDVs do Gestão e integrações com ERP (como ARPEx, MacOne, etc.).
     • Projeto PDV Plus – onde está o PDV do Plus.
   • O vídeo destaca que todos funcionam da mesma forma, ou seja, a organização das filas e colunas é semelhante em todos os projetos.
   • Ponto de atenção: saiba em qual projeto o ticket do seu cliente foi aberto (ERP, PDV Light, PDV Plus, etc.) para acessar o quadro correto.

3. Terceiro passo: Entrar em um projeto específico.

   • Clique sobre o nome do projeto desejado (por exemplo, ERP, PDV Light ou PDV Plus).
   • Ao entrar no projeto, utilize o menu lateral do Azure para navegar até a área de Boards (quadros) ou equivalente, onde ficam os cards de desenvolvimento.
   • Dentro dos boards, você visualizará as sprints ou períodos de trabalho, bem como os quadros de tarefas organizados por colunas.
   • Ponto de atenção: a estrutura é semelhante em todos os projetos, então aprenda o fluxo em um e aplique aos demais.

4. Quarto passo: Visualizar as sprints (passadas e atuais).

   • Dentro do board, o Azure exibe as sprints (períodos de trabalho) organizadas cronologicamente.
   • Para cada projeto, você verá:
     
     • A sprint atual, destacada em azul.
     • As sprints passadas, destacadas em cinza, geralmente com indicação de que são “passadas”.
   • Você pode navegar entre sprints para ver:
     
     • Demandas atuais (sprint azul).
     • Demandas concluídas ou trabalhadas anteriormente (sprints cinza).
   • Ponto de atenção: use as sprints passadas para consultar casos já finalizados ou para entender o histórico de demandas.

5. Quinto passo: Entender o layout das colunas (filas) do quadro.

   • Dentro de cada sprint, os cards (tickets) ficam organizados em colunas, que representam etapas do fluxo de desenvolvimento.
   • O vídeo cita algumas colunas importantes (podem variar de projeto para projeto, mas geralmente incluem):
     
     • Aprovado – onde ficam cards aprovados para desenvolvimento.
     • Workshop / Em Progresso – etapas de trabalho do desenvolvedor, onde o programador atua diretamente.
     • Em Teste – etapa onde o suporte/qualidade deve testar a entrega.
     • Impedimentos – etapa onde o card aguarda alguma informação, ação ou correção pendente.
     • Done (Concluído) – etapa de cards finalizados, aprovados e comunicados ao cliente.
   • Ponto de atenção: as colunas intermediárias (Aprovado, Workshop, Em Progresso) são mais manipuladas pelos programadores; o foco do suporte deve ser principalmente Teste e Impedimentos.

6. Sexto passo: Visualizar e entender o status dos cards (atividades).

   • Cada card representa uma demanda/ticket, que contém informações como:
     
     • Título/resumo da demanda.
     • Data de criação ou ativação.
     • Status atual (aprovado, em teste, em progresso, impedimento, etc.).
   • No vídeo é mostrado que a lista de cards pode ser ordenada ou visualizada por data de ativação, permitindo ver quais foram criados recentemente.
   • Os cards também possuem atividades e comentários internos, onde programadores e analistas registram o que foi feito.
   • Ponto de atenção: sempre leia os comentários e histórico do card antes de agir (mover coluna, testar, chamar cliente).

7. Sétimo passo: Compreender as filas “Aprovado”, “Workshop”, “Em Progresso” e “Done”.

   • Aprovado:
     
     • Cards que já foram avaliados (por exemplo, pelo Tiago) e aprovados para implementação.
     • Ficam aguardando o programador assumir a demanda.
   • Workshop / Em Progresso:
     
     • Colunas onde o programador trabalha efetivamente na demanda (codificação, ajustes, melhorias).
     • O card é movido para essas colunas quando a implementação está em andamento.
   • Done (Concluído):
     
     • Cards de demandas já implementadas, testadas e consideradas concluídas, com o cliente informado.
   • Ponto de atenção: embora o suporte veja todas essas colunas, o foco principal do seu trabalho está em verificar e movimentar cards em Teste e Impedimentos.

8. Oitavo passo: Atuar na coluna “Em Teste”.

   • Quando o programador finaliza o desenvolvimento, ele movimenta o card para a coluna Em Teste.
   • A partir daí, cabe ao suporte/qualidade:
     
     • Abrir o card.
     • Ler os comentários do programador (o que foi feito, quais telas, quais regras).
     • Testar a funcionalidade no ambiente adequado (homologação, teste, produção, conforme o caso).
     • Verificar se a correção ou melhoria foi realmente implementada e se está funcionando.
   • Se o teste for bem-sucedido:
     
     • Informar o cliente que a demanda foi implementada e está funcional.
     • Mover o card para a coluna Done (Concluído).
   • Se o teste não for bem-sucedido (erro, não implementado, não subiu, etc.):
     
     • Mover o card para Impedimento ou outra coluna de retorno para o programador, conforme o fluxo da equipe.
   • Ponto de atenção: somente mova o card para Done depois de testar e confirmar que a demanda está ok e o cliente foi informado.

9. Nono passo: Atuar na coluna “Impedimentos”.

   • A coluna Impedimentos concentra cards que não podem avançar por algum motivo, por exemplo:
     
     • Falta de informação do cliente (dados, acesso, cenário).
     • Dependência de outro time ou sistema.
     • Problema técnico que impede a continuidade.
   • Muitas vezes um card vai direto para Impedimento após ser analisado pelo programador, se ele identificar que faltam requisitos (por exemplo, card criado sem informação suficiente).
   • Ao encontrar um card em Impedimentos, o suporte deve:
     
     • Abrir o card e ler os comentários, onde o programador descreve o que está faltando ou o que impede o andamento.
     • Exemplo citado no vídeo: “Essa opção já existe, basta tirar o usuário o acesso cadastrado do produto” – neste caso, é necessário orientar o cliente.
     • Entrar em contato com o cliente para complementar as informações ou aplicar a orientação passada pelo programador.
   • Após resolver o impedimento (informação recebida, ajuste feito), o card pode ser movido novamente para a coluna apropriada (Aprovado, Em Progresso ou Em Teste), conforme o fluxo definido.
   • Ponto de atenção: sempre registre no card as ações realizadas (contato com cliente, retorno obtido, testes feitos) para manter a rastreabilidade.

10. Décimo passo: Fluxo completo do ciclo do card (do início ao fim).

    • O vídeo resume um fluxo padrão que se repete para todos os projetos:
      
      1. O suporte cria o card (ticket) no Azure.
      2. Aguarda o Tiago (ou responsável) aprovar o card e movê-lo para Aprovado.
      3. O programador assume o card, trabalha em Workshop / Em Progresso.
      4. Quando finaliza, move para Em Teste.
      5. O suporte/qualidade pega o card, realiza os testes adequados:
      • Se aprovado: chama o cliente, confirma funcionamento e move para Done.
      • Se reprovado ou faltando algo: move para Impedimentos e aciona o programador/cliente conforme o caso.
    • Ponto de atenção: esse ciclo vale para todos os projetos (ERP, PDV Light, PDV Plus etc.), utilizando o mesmo “cronograma” de colunas.

11. Décimo primeiro passo: Verificar se a demanda foi realmente “subida” (deploy).

    • Durante os testes, é importante verificar se a correção ou melhoria já foi disponibilizada no ambiente (deploy realizado).
    • O vídeo reforça que, mesmo que o card esteja em Teste, é preciso checar:
      
      • Se o ambiente foi atualizado.
      • Se a versão com a correção está em uso.
    • Se não tiver subido, o suporte deve:
      
      • Registrar no card que a versão ainda não foi aplicada.
      • Aguardar o deploy e, após, retomar o teste.
    • Ponto de atenção: não aprove (nem mova para Done) uma demanda que ainda não foi efetivamente colocada em produção/homologação.

12. Décimo segundo passo: Ler e registrar comentários de forma completa e clara.

    • O vídeo mostra o exemplo de um card em que o analista Márcio detalha toda a análise e o que foi feito.
    • Sempre que atuar em um card (testar, contatar cliente, verificar impedimentos):
      
      • Registre comentários claros no card, explicando:
      • O que foi testado.
      • Resultado do teste.
      • Orientações dadas ao cliente.
      • Qualquer retorno recebido.
      • Dessa forma, qualquer pessoa que abrir o card (outro analista, programador, gestor) entenderá o histórico completo.
    • Ponto de atenção: comentários bem detalhados facilitam a comunicação com o cliente e reduzem retrabalho e dúvidas internas.

13. Décimo terceiro passo: Quando mover o card para “Done” (Concluído).

    • Um card só deve ir para Done quando:
      
      • A correção/implementação foi testada e aprovada.
      • O cliente foi informado e está ciente da solução.
      • Não há pendências adicionais (nem técnicas, nem de informação).
    • Ao mover para Done, registre um comentário final, por exemplo:
      
      • “Demanda testada em ambiente X, cliente Y informado em DD/MM/AAAA, funcionamento validado.”
    • Ponto de atenção: Done significa “finalizado para o cliente”. Evite deixar cards em Done sem que o cliente tenha sido comunicado.

Informações Importantes

• Resumo das principais orientações.

  • Todos os projetos no Azure (ERP, PDV Light, PDV Plus, etc.) seguem o mesmo padrão de filas/colunas.
  • O suporte deve focar principalmente nas colunas Em Teste e Impedimentos.
  • O fluxo padrão: Criar → Aprovar → Desenvolver → Testar → Impedimentos (se necessário) → Done.

• Dicas de uso.

  • Consulte as sprints passadas para entender histórico de demandas similares.
  • Use sempre os comentários dos programadores como base para o teste e para a comunicação com o cliente.
  • Antes de mover qualquer card, leia todo o histórico para não perder contexto.
  • Priorize cards mais antigos em Teste ou Impedimentos para evitar atrasos.

• Recomendações gerais sobre o processo.

  • Mantenha sempre a comunicação clara entre suporte, desenvolvimento e cliente.
  • Em Impedimentos, não deixe cards “parados”: sempre identifique o que falta (dados, acesso, confirmação).
  • Utilize o Azure como fonte oficial de controle de status dos tickets, evitando controles paralelos que possam gerar desencontro de informações.

• Benefícios de seguir corretamente o procedimento.

  • Melhora o controle e organização das demandas de desenvolvimento.
  • Facilita a priorização e acompanhamento do que está em teste, em impedimento e concluído.
  • Garante que o cliente seja avisado no momento certo, reduzindo dúvidas e retrabalho.
  • Cria um fluxo padronizado para todos os projetos, aumentando a produtividade e transparência da equipe.

Basta copiar este texto para o Word e aplicar a formatação definida:

• Título do texto com fonte tamanho 34 e em negrito.
• Cabeçalhos principais (Resumo do que será ensinado, Segue um Vídeo explicativo do processo, Detalhamento do uso correto, Segue o detalhamento de como…, Informações Importantes) com fonte tamanho 18 e em negrito.
• Corpo do texto com fonte padrão menor (por exemplo, 12 ou 14).