Seu Template de Dados do Ciclo de Vida de Desenvolvimento de Software

Azure DevOps
Seu Template de Dados do Ciclo de Vida de Desenvolvimento de Software

Seu Template de Dados do Ciclo de Vida de Desenvolvimento de Software

Este template oferece um roteiro claro para preparar os dados do seu Ciclo de Vida de Desenvolvimento de Software para o Process Mining. Ele detalha os atributos de dados essenciais que você precisa coletar, as principais atividades para monitorar e fornece orientações práticas sobre como extrair essas informações especificamente do Azure DevOps. Aproveite este recurso para garantir que seus dados estejam perfeitamente estruturados para análises profundas e otimização de processos.
  • Atributos recomendados para coletar
  • Principais atividades para monitorar no seu SDLC
  • Guia detalhado de extração para Azure DevOps
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos do Ciclo de Vida de Desenvolvimento de Software

Estes são os campos de dados recomendados para inclusão no seu log de eventos para uma análise e otimização abrangente do seu SDLC.
5 Obrigatório 8 Recomendado 6 Opcional
Nome Descrição
Item de Desenvolvimento
DevelopmentItem
O identificador exclusivo para uma única unidade de trabalho, como uma feature, bug ou user story, que serve como o identificador de caso para o processo.
Descrição

O Item de Desenvolvimento representa uma unidade de trabalho distinta rastreada no Azure DevOps. Cada item, identificado por seu ID exclusivo, é o objeto central em torno do qual giram todas as atividades do processo, desde a criação e o planejamento até o desenvolvimento, testes e implantação.

Na análise de Process Mining, este atributo é fundamental para correlacionar todos os eventos relacionados em uma única jornada de caso. Ele permite a reconstrução do ciclo de vida ponta a ponta para cada item de trabalho, possibilitando a análise de tempos de ciclo, desvios de processo e loops de retrabalho de forma individual.

Por que é importante

Este é o identificador principal que conecta todas as etapas do processo em um caso coerente, possibilitando a análise de ponta a ponta do ciclo de vida de desenvolvimento de software.

Onde obter

Isso corresponde ao campo 'ID' de um Item de Trabalho no Azure DevOps Boards. Ele é acessível através da API REST do Azure DevOps para rastreamento de itens de trabalho.

Exemplos
10234102351023610237
Nome da Atividade
ActivityName
O nome do evento ou tarefa específica que ocorreu em um ponto no tempo dentro do ciclo de vida de desenvolvimento de um item de trabalho.
Descrição

O Nome da Atividade descreve uma etapa ou marco específico no processo, como 'Desenvolvimento Iniciado', 'Pull Request Criado' ou 'Implantado em Produção'. Essas atividades são derivadas de mudanças no estado do item de trabalho, eventos vinculados como builds ou pull requests, ou eventos personalizados.

Este atributo é essencial para construir o mapa de processo, que representa visualmente o workflow. Ele permite que os analistas entendam a sequência de eventos, identifiquem caminhos comuns, descubram gargalos entre atividades específicas e analisem a frequência de cada etapa.

Por que é importante

Define as etapas do processo, formando a espinha dorsal do mapa de processo e permitindo a análise de workflow, gargalos e desvios.

Onde obter

Isso geralmente é derivado de alterações no campo 'Estado' (State) de um item de trabalho ou de eventos vinculados, como builds, commits e pull requests. O Histórico do Item de Trabalho fornece os dados brutos para esses eventos.

Exemplos
Desenvolvimento IniciadoPull Request ConcluídoTeste de QA ReprovadoImplantado em ProduçãoItem de Trabalho Fechado
Tempo do Evento
EventTime
O registro de data e hora (timestamp) preciso indicando quando uma atividade ou evento específico ocorreu para um item de desenvolvimento.
Descrição

O Event Time captura a data e a hora de cada atividade no ciclo de vida de desenvolvimento. Este timestamp é o elemento temporal fundamental usado para ordenar os eventos cronologicamente e calcular as durações entre eles.

Na análise, este atributo é crucial para calcular todas as métricas baseadas em tempo, incluindo tempos de ciclo, processamento e espera. Ele permite a criação de um Event Log ordenado, requisito para qualquer análise de Process Mining. É usado para diagnosticar atrasos, medir a performance em relação a SLAs e acompanhar tendências.

Por que é importante

Este timestamp fornece a ordem cronológica dos eventos, o que é essencial para calcular todos os KPIs baseados em duração e entender o fluxo do processo e seus gargalos.

Onde obter

Esta é a 'Data de Alteração' associada a cada atualização no histórico de um item de trabalho. Para eventos externos, como builds ou implantações, é o timestamp de conclusão desse evento.

Exemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Sistema de Origem
SourceSystem
O sistema do qual os dados do processo foram extraídos, que neste caso é o Azure DevOps.
Descrição

Este atributo identifica o sistema de origem dos dados. É particularmente útil em ambientes onde dados de múltiplos sistemas são combinados para uma visão mais ampla do processo. Para este modelo específico, o valor é consistentemente Azure DevOps.

Embora possa parecer estático em uma análise de sistema único, ele fornece o contexto essencial sobre a origem dos dados, o que é fundamental para a governança de dados, solução de problemas e futuras integrações com outros sistemas como ServiceNow ou SAP.

Por que é importante

Fornece um contexto crucial sobre a origem dos dados, o que é importante para a governança de dados, validação e análise de processos em múltiplos sistemas.

Onde obter

Este é um valor estático que deve ser adicionado durante o processo de extração e transformação de dados para rotular o conjunto de dados.

Exemplos
Azure DevOps
Última Atualização de Dados
LastDataUpdate
O registro de data/hora que indica a última vez que os dados deste processo foram atualizados a partir do sistema de origem.
Descrição

Este atributo registra quando o conjunto de dados foi extraído e atualizado pela última vez a partir do Azure DevOps. Ele fornece uma indicação clara da atualidade dos dados e do período de tempo coberto pela análise.

Em qualquer análise de processo, saber o quão recentes são os dados é fundamental para tomar decisões informadas. Este timestamp ajuda os usuários a entenderem se estão vendo informações em tempo real ou um recorte histórico, o que afeta a relevância das descobertas.

Por que é importante

Informa aos usuários sobre a atualização dos dados, garantindo que as análises e decisões sejam baseadas em um intervalo de tempo conhecido.

Onde obter

Este é um timestamp de metadados gerado e armazenado durante o processo de extração, transformação e carga (ETL) dos dados.

Exemplos
2024-05-20T08:00:00Z
Atribuído A
AssignedTo
O usuário ou membro da equipe ao qual o item de desenvolvimento está atribuído no momento.
Descrição

Este atributo identifica a pessoa responsável pelo item de trabalho em uma determinada etapa do processo. A atribuição pode mudar várias vezes ao longo do ciclo de vida do item, por exemplo, de um desenvolvedor para um tester e depois para um gerente de release.

Analisar pelo campo 'Atribuído a' (Assigned To) é crucial para o dashboard de Visão Geral da Carga de Trabalho de Desenvolvedores e Testers. Ajuda a entender a alocação de recursos, identificar membros da equipe sobrecarregados e analisar diferenças de desempenho entre indivíduos ou equipes.

Por que é importante

Permite a análise baseada em recursos, ajudando a entender a distribuição da carga de trabalho, identificar gargalos específicos de recursos e gerenciar a capacidade da equipe.

Onde obter

Isso corresponde ao campo 'Atribuído a' (Assigned To) em um Item de Trabalho no Azure DevOps. O valor é capturado do histórico do item de trabalho para cada evento.

Exemplos
jane.doe@example.comjohn.smith@example.comnão atribuído
É Retrabalho
IsRework
Um sinalizador booleano indicando se um item de desenvolvimento retornou a um estágio anterior do seu ciclo de vida.
Descrição

Esta sinalização (flag) é definida como verdadeira se um item de trabalho apresentar um loop de retrabalho, por exemplo, movendo-se de 'Teste de QA Concluído' de volta para 'Desenvolvimento Iniciado'. É calculado analisando a sequência de atividades de um caso e detectando progressões não lineares.

Este atributo é essencial para o dashboard de Frequência de Retrabalho e Reteste e para o KPI de Frequência de Loop de Retrabalho. Ele permite filtrar e quantificar o retrabalho facilmente, ajudando a identificar problemas de qualidade, falhas de comunicação ou testes insuficientes que levam a ineficiências.

Por que é importante

Identifica e quantifica diretamente o retrabalho, ajudando a destacar problemas de qualidade e ineficiências de processo que prolongam os tempos de ciclo.

Onde obter

Este é um atributo calculado, derivado da análise da sequência de atividades no log de eventos para cada caso.

Exemplos
verdadeirofalse
End Time
EndTime
O timestamp que indica quando uma atividade foi concluída. É usado para calcular o tempo de processamento de uma atividade.
Descrição

O Horário de Término (End Time) marca a conclusão de uma atividade. Em muitos logs de eventos, o horário de início da próxima atividade serve como o horário de término da anterior. No entanto, ter um horário de término distinto permite um cálculo mais preciso tanto do tempo de processamento da atividade quanto do tempo de inatividade entre as atividades.

Este atributo é crucial para calcular o KPI de ProcessingTime e para realizar uma análise detalhada de gargalos. Ele ajuda a diferenciar o tempo gasto trabalhando ativamente em uma tarefa do tempo gasto esperando o início da próxima etapa, o que é fundamental para o dashboard de Análise de Handoff entre Etapas.

Por que é importante

Permite o cálculo preciso dos tempos de processamento das atividades e dos tempos de inatividade, o que é fundamental para a análise de gargalos e melhorias de eficiência.

Onde obter

Isso é frequentemente derivado. Pode ser o horário de início do evento subsequente para o mesmo caso ou pode ser registrado explicitamente se o sistema de origem capturar os horários de início e término das tarefas.

Exemplos
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Estado
State
O status atual do item de desenvolvimento no seu workflow, como 'Novo', 'Ativo', 'Resolvido' ou 'Fechado'.
Descrição

O atributo Estado (State) representa o status formal de um item de trabalho em qualquer momento, conforme definido pelo template de processo do projeto. As transições entre esses estados são a fonte primária para gerar as atividades no log de eventos.

Embora o atributo 'Atividade' seja frequentemente uma versão mais descritiva de uma mudança de estado, o atributo 'Estado' bruto é útil para filtragem e análise. Ele ajuda a entender quanto tempo os itens passam em estados específicos e é fundamental para construir o dashboard de Duração da Etapa e analisar handoffs.

Por que é importante

Indica o status do item de trabalho no ciclo de vida, o que é fundamental para entender o fluxo do processo e calcular o tempo gasto em várias etapas.

Onde obter

Isso corresponde ao campo 'Estado' (State) em um Item de Trabalho no Azure DevOps.

Exemplos
NovoAtivoEm QAResolvidoEncerrado
Nome da Equipe
TeamName
O nome da equipe de desenvolvimento responsável pelo item de trabalho.
Descrição

O Nome da Equipe identifica o time específico ao qual um item de trabalho está atribuído. No Azure DevOps, o trabalho é frequentemente organizado por equipes, que podem ser subconjuntos de um projeto maior.

Este atributo permite que a análise do processo seja segmentada por equipe. É valioso para comparar processos e desempenhos entre times diferentes, identificando boas práticas em equipes de alto desempenho e encontrando áreas onde equipes específicas possam precisar de suporte ou melhorias de processo.

Por que é importante

Permite a análise comparativa entre diferentes equipes, ajudando a identificar variações de desempenho e a compartilhar as melhores práticas em toda a organização.

Onde obter

Isso é frequentemente derivado do 'Caminho da Área' (Area Path) de um item de trabalho, já que as equipes são geralmente mapeadas para caminhos de área específicos no Azure DevOps.

Exemplos
Time PhoenixOmega SquadPlatform CoreEquipe de Frontend
Prioridade
Priority
Uma classificação numérica ou descritiva da importância do item de desenvolvimento em relação a outros itens.
Descrição

A Prioridade indica a importância do agendamento de um item de trabalho. Uma prioridade mais alta sugere que um item deve ser resolvido mais rapidamente do que itens de prioridade mais baixa. Os valores comuns são numéricos, como 1, 2, 3, 4, sendo 1 o mais alto.

Este atributo é essencial para o dashboard de Throughput e Cycle Time Baseado em Prioridade. Analisar os dados com este atributo ajuda a determinar se o sistema de priorização é eficaz, ou seja, se os itens de alta prioridade realmente se movem pelo processo mais rápido do que os de baixa prioridade.

Por que é importante

Permite analisar se o processo acelera itens de alta prioridade de forma eficaz, o que é fundamental para avaliar o sucesso das estratégias de priorização.

Onde obter

Isso corresponde ao campo 'Prioridade' em um Item de Trabalho no Azure DevOps.

Exemplos
1234
Tempo de Ciclo de Desenvolvimento
DevelopmentCycleTime
O tempo total decorrido desde a criação de um item de desenvolvimento até sua implantação em produção.
Descrição

O Tempo de Ciclo de Desenvolvimento é um KPI que mede a duração de ponta a ponta do processo de desenvolvimento para um único item de trabalho. É calculado como a diferença entre o timestamp da atividade 'Implantado em Produção' e o da 'Item de Trabalho Criado'.

Essa métrica é o principal KPI para o dashboard de Tempo de Ciclo de Ponta a Ponta e tendências históricas. Ela fornece uma medida holística da velocidade e eficiência do processo, e seu acompanhamento ao longo do tempo demonstra o impacto das iniciativas de melhoria.

Por que é importante

Este é um KPI crítico que mede a velocidade e eficiência geral do processo de desenvolvimento, do início ao fim.

Onde obter

Isso é calculado pegando o timestamp do evento de implantação final e subtraindo o timestamp do evento de criação para cada caso.

Exemplos
10 dias 4 horas 30 minutos25 dias 8 horas 0 minutos5 dias 2 horas 15 minutos
Tipo de Item de Trabalho
WorkItemType
A classificação do item de desenvolvimento, como Bug, Feature, User Story ou Task.
Descrição

O Tipo de Item de Trabalho categoriza a natureza do trabalho realizado. Diferentes tipos de itens de trabalho geralmente seguem caminhos de processo distintos e têm diferentes expectativas de desempenho ou SLAs. Por exemplo, um 'Bug' pode seguir um caminho acelerado em comparação com uma 'Feature'.

Este atributo é essencial para análise comparativa. Ele permite filtrar o mapa de processo ou os KPIs pelo tipo de trabalho para entender se certos processos são mais eficientes para bugs em relação a features, ou para rastrear tendências históricas de tempo de ciclo para diferentes categorias de trabalho.

Por que é importante

Permite a segmentação da análise de processo, possibilitando a comparação de workflows e desempenho para diferentes categorias de trabalho, como bugs e features.

Onde obter

Isso corresponde ao campo 'Tipo de Item de Trabalho' (Work Item Type) em um Item de Trabalho no Azure DevOps.

Exemplos
BugFeatureUser StoryTarefa
Caminho da Iteração (Iteration Path)
IterationPath
A sprint de desenvolvimento ou o período de tempo (timebox) ao qual o item de trabalho está atribuído.
Descrição

O Caminho da Iteração (Iteration Path), ou sprint, representa um período de desenvolvimento com tempo definido. Os itens de trabalho são atribuídos a uma iteração para serem concluídos dentro desse prazo.

Analisar pelo Caminho da Iteração ajuda a entender o desempenho do processo sprint a sprint. Pode ser usado para rastrear se os tempos de ciclo estão melhorando ao longo das sprints, analisar o trabalho que sobrou (carry-over) e avaliar a previsibilidade do planejamento de cada sprint.

Por que é importante

Permite a análise baseada em sprints, ajudando as equipes a avaliarem seu desempenho ao longo do tempo e aprimorarem suas práticas ágeis.

Onde obter

Isso corresponde ao campo 'Caminho da Iteração' (Iteration Path) em um Item de Trabalho no Azure DevOps.

Exemplos
Plataforma de E-Commerce\Sprint 12Plataforma de E-Commerce\Sprint 13Relançamento do App Mobile\Fase 2\Sprint 4
Gravidade
Severity
Indica o impacto de um bug ou problema no sistema ou para os usuários finais.
Descrição

A Severidade é usada para classificar o impacto de um bug, desde falhas críticas no sistema até pequenos problemas cosméticos. Isso é diferente da prioridade, que dita a ordem do trabalho. Um bug de alta severidade pode ter prioridade baixa se houver uma solução alternativa disponível.

Este atributo fornece outra dimensão para análise, especialmente para o dashboard de Throughput e Cycle Time Baseado em Prioridade. Ele permite investigar questões como 'Estamos corrigindo primeiro os bugs mais críticos?' e ajuda a entender o perfil de risco do trabalho que está sendo processado.

Por que é importante

Ajuda a categorizar itens de trabalho pelo seu impacto no negócio, permitindo analisar com que eficácia a equipe lida com problemas de alto impacto.

Onde obter

Isso corresponde ao campo 'Severidade' em um Item de Trabalho, tipicamente para bugs, no Azure DevOps.

Exemplos
1 - Crítico2 - Alto3 - Médio4 - Baixo
ID do Pull Request
PullRequestId
O identificador de um Pull Request vinculado ao item de desenvolvimento.
Descrição

Este atributo vincula um item de trabalho a um Pull Request específico, que é o mecanismo para enviar e revisar alterações de código. Um único item de trabalho pode estar associado a vários pull requests.

Ter o ID do Pull Request permite uma análise mais granular da parte de revisão e integração de código do ciclo de vida. Pode ser usado para medir o tempo desde a criação até a conclusão do pull request e para analisar com que frequência os pull requests são rejeitados ou exigem mudanças significativas, o que pode ser um indicador de qualidade do código ou requisitos pouco claros.

Por que é importante

Conecta o trabalho de desenvolvimento a atividades específicas de revisão de código, permitindo uma análise detalhada da integração do código e do processo de garantia de qualidade (QA).

Onde obter

Esta informação é encontrada na seção 'Links' ou 'Desenvolvimento' de um item de trabalho no Azure DevOps.

Exemplos
452145334589
Nome do Projeto
ProjectName
O nome do projeto no Azure DevOps ao qual o item de desenvolvimento pertence.
Descrição

Este atributo identifica o projeto específico dentro da organização do Azure DevOps onde o item de trabalho está localizado. Ele fornece um contexto de alto nível, especialmente em organizações com muitos projetos.

O Nome do Projeto é uma dimensão crítica para filtragem e comparação. Ele alimenta o dashboard de Tendências Históricas de Tempo de Ciclo, permitindo que a análise seja segmentada por projeto, revelando se certos projetos são mais ou menos eficientes que outros, ou se as melhorias de processo em um projeto tiveram um impacto positivo.

Por que é importante

Fornece um agrupamento de alto nível para análise, permitindo a comparação de desempenho e a análise de tendências em diferentes projetos.

Onde obter

Isso corresponde ao campo 'Team Project' em um Item de Trabalho no Azure DevOps.

Exemplos
Plataforma de E-CommerceRelançamento do App MobileModernização de Data Warehouse
Tempo de Espera por Aprovação
ApprovalWaitingTime
O tempo que um item de desenvolvimento passa esperando por uma aprovação após a solicitação ter sido feita.
Descrição

Esta métrica mede a duração de períodos de espera específicos onde um item de trabalho está pendente de aprovação. Um exemplo clássico é o tempo entre 'UAT Iniciado' e 'UAT Aprovado'. É calculado medindo o tempo entre essas duas atividades específicas para um determinado caso.

Este atributo calculado alimenta diretamente o dashboard de Análise de Tempo de Espera por Aprovação e o KPI correspondente. Ao isolar esses atrasos específicos, as equipes podem focar na melhoria dos processos de comunicação e tomada de decisão para reduzir o tempo ocioso e acelerar o ciclo de vida geral.

Por que é importante

Mede especificamente os atrasos causados pela espera de decisões ou aprovações, destacando oportunidades para melhorar a comunicação e os processos de tomada de decisão.

Onde obter

Isso é calculado encontrando atividades específicas de início e fim de aprovação no log de eventos (ex: 'UAT Iniciado' e 'UAT Aprovado') e calculando a diferença de tempo.

Exemplos
3 dias e 2 horas1 dia 8 horas 30 minutos4 horas
Tempo de Handoff entre Etapas
StageHandoffTime
A duração do tempo de inatividade entre a conclusão de uma etapa principal e o início da próxima.
Descrição

O Tempo de Handoff entre Etapas mede o período de espera entre etapas sequenciais do processo, por exemplo, o tempo entre 'Desenvolvimento Concluído' e 'Início do Teste de QA'. Ele é calculado identificando essas transições-chave e medindo o intervalo de tempo entre o fim da primeira atividade e o início da segunda.

Esta métrica é o foco do dashboard de Análise de Duração de Etapa e Handoff. Isolar e medir o tempo de handoff é fundamental para identificar gargalos ocultos onde o trabalho está parado, muitas vezes devido à indisponibilidade de recursos, atrasos na comunicação ou processos ineficientes.

Por que é importante

Quantifica os tempos de espera entre as etapas do processo, expondo diretamente gargalos ocultos e atrasos que não fazem parte do trabalho ativo.

Onde obter

Este é um atributo calculado. Requer a identificação de pares de atividades sequenciais que representam um handoff e, em seguida, o cálculo da diferença de tempo entre elas.

Exemplos
2 horas 15 minutos1 dia 4 horas0 horas e 30 minutos
Obrigatório Recomendado Opcional

Atividades do Ciclo de Vida de Desenvolvimento de Software

Estas são as principais etapas do processo e marcos a serem capturados no seu log de eventos para uma descoberta precisa de processos e identificação de gargalos.
7 Recomendado 8 Opcional
Atividade Descrição
Desenvolvimento Iniciado
Esta atividade indica que um desenvolvedor começou a trabalhar ativamente no item. É capturada ao inferir uma mudança no estado do item de trabalho para 'Ativo', 'Em Andamento' ou 'Comprometido'.
Por que é importante

Marca o início da fase de desenvolvimento ativo. Analisar o tempo de 'Criado' até 'Desenvolvimento Iniciado' revela os tempos de espera no backlog.

Onde obter

Inferido do histórico do item de trabalho quando o campo System.State muda de um estado 'Novo' ou 'Aprovado' para 'Em Progresso'.

Captura

Inferido a partir da mudança do campo de Estado para 'Ativo' ou 'Em Progresso'.

Tipo de evento inferred
Implantado em Produção
Marca a implantação bem-sucedida do código associado ao item de trabalho no ambiente de produção. Este é um evento explícito capturado dos logs de release do Azure Pipelines.
Por que é importante

Este é um marco crítico que representa a entrega de valor. Ele serve como o ponto final para o cálculo do lead time e do tempo de ciclo.

Onde obter

Capturado de dados de pipeline de release do Azure Pipelines, especificamente o evento de conclusão de um deployment para um estágio de 'Produção' vinculado ao item de trabalho.

Captura

Capturado de um evento de conclusão de implantação de pipeline de release.

Tipo de evento explicit
Item de Trabalho Criado
Esta atividade marca o início do ciclo de vida de desenvolvimento, representando a criação de um novo item de trabalho, como User Story, Bug ou Task. É capturada explicitamente quando um novo registro é salvo no Azure DevOps Boards.
Por que é importante

Este é o principal evento de início do processo. É essencial para medir o tempo de ciclo de desenvolvimento de ponta a ponta e entender as fontes iniciais de trabalho.

Onde obter

Este evento é capturado a partir da 'Data de Criação' no próprio item de trabalho. A tabela de histórico do item de trabalho também registra essa transição de estado inicial.

Captura

Capturado do campo 'Data de Criação' do item de trabalho.

Tipo de evento explicit
Pull Request Concluído
Representa a conclusão bem-sucedida de uma revisão de código, onde o Pull Request é aprovado e o código é mesclado ao branch de destino. Este evento é registrado explicitamente no Azure Repos.
Por que é importante

Marca o fim da fase de revisão de código, um gargalo comum. Analisar o tempo entre a criação e a conclusão do Pull Request (PR) revela a eficiência do ciclo de revisão.

Onde obter

Capturado do evento de conclusão ou merge de um pull request no Azure Repos que está vinculado a um item de trabalho.

Captura

Capturado de um evento de merge de pull request vinculado a um item de trabalho.

Tipo de evento explicit
Pull Request Criado
Indica que o desenvolvedor concluiu a codificação inicial e enviou as alterações para revisão via pull request. Este evento vincula o item de trabalho a uma mudança de código específica no Azure Repos.
Por que é importante

Este é um handoff importante do desenvolvimento para a revisão de código. O acompanhamento ajuda a medir a duração da codificação e identifica quando o código está pronto para a revisão por pares.

Onde obter

Capturado de dados do Azure Repos ao vincular o evento de criação de pull request ao seu item de trabalho associado. Geralmente é um link explícito feito pelo desenvolvedor.

Captura

Capturado de um evento de criação de pull request do Azure Repos vinculado a um item de trabalho.

Tipo de evento explicit
Teste de QA Iniciado
Representa o início da fase formal de testes de garantia de qualidade. Esta atividade é inferida quando o estado de um item de trabalho é alterado para 'Em QA', 'Testando' ou um valor similar.
Por que é importante

Marca o início do ciclo de QA. Analisar a duração desta fase é crucial para entender os gargalos de teste e a eficiência.

Onde obter

Inferido do histórico do item de trabalho ao rastrear uma mudança no campo System.State para 'Em QA' ou outro estado de teste designado.

Captura

Inferido a partir da mudança do campo de Estado para 'Em QA' ou 'Testando'.

Tipo de evento inferred
UAT Aprovado
Esta atividade indica que os stakeholders do negócio aprovaram as alterações após o Teste de Aceitação do Usuário (UAT). É tipicamente inferido de uma mudança de estado de 'Em UAT' para 'UAT Aprovado' ou 'Pronto para Release'.
Por que é importante

Este é um marco de aprovação crítico que confirma que o item de trabalho atende aos requisitos do negócio e está pronto para implantação em produção.

Onde obter

Inferido do histórico do item de trabalho ao detectar uma mudança no campo System.State de um estado de UAT para um estado aprovado ou pronto para release.

Captura

Inferido a partir da mudança do campo de Estado de 'Em UAT' para 'Pronto para Release'.

Tipo de evento inferred
Build Concluído com Sucesso
Esta atividade confirma que o código-fonte, incluindo as novas alterações, foi compilado e empacotado com sucesso por um pipeline de build. Este é um evento explícito registrado pelo Azure Pipelines.
Por que é importante

Funciona como um quality gate crítico, garantindo que o novo código se integre corretamente sem quebrar o build. Falhas nesta etapa podem indicar problemas de integração.

Onde obter

Capturado de eventos de conclusão de build do Azure Pipelines. O build precisa estar vinculado ao item de trabalho, seja diretamente ou via pull request associado.

Captura

Capturado de um evento de conclusão de build do Azure Pipelines.

Tipo de evento explicit
Desenvolvimento Concluído
Significa que todas as atividades de desenvolvimento e testes unitários foram concluídas e o item está pronto para testes formais. Isso é tipicamente inferido por uma mudança no estado do item de trabalho para 'Resolvido' ou 'Pronto para Teste'.
Por que é importante

Isso marca um handoff importante da equipe de desenvolvimento para a equipe de QA. Medir o tempo até o 'Início do Teste de QA' ajuda a identificar atrasos na passagem de bastão.

Onde obter

Inferido do histórico do item de trabalho quando o campo System.State muda para um valor como 'Resolvido' ou estado personalizado que indica prontidão para QA.

Captura

Inferido a partir da mudança do campo de Estado para 'Resolvido'.

Tipo de evento inferred
Item de Trabalho Aprovado
Representa a aprovação formal de um item de trabalho, confirmando que ele está bem definido e pronto para desenvolvimento. Isso é tipicamente inferido de uma mudança no campo 'Estado' para um valor como 'Aprovado' ou 'Pronto para Dev'.
Por que é importante

Rastrear as aprovações ajuda a analisar o tempo entre a submissão de uma ideia e o compromisso de desenvolvimento. Ele destaca possíveis atrasos nas fases de planejamento e refinamento do backlog (backlog grooming).

Onde obter

Inferido do histórico do item de trabalho ao detectar uma mudança no campo System.State para 'Aprovado' ou estado personalizado similar.

Captura

Inferido a partir da mudança do campo de Estado para 'Aprovado'.

Tipo de evento inferred
Item de Trabalho Cancelado
Indica que o item de trabalho foi cancelado e não será concluído nem implantado. Capturado por uma mudança de estado para 'Removido', 'Cancelado' ou similar.
Por que é importante

Isso representa um encerramento alternativo e sem sucesso do processo. Analisar itens cancelados pode revelar problemas com o planejamento, a priorização ou a definição de requisitos.

Onde obter

Inferido do histórico do item de trabalho quando o campo System.State é alterado para um estado terminal na categoria 'Removido'.

Captura

Inferido a partir da mudança do campo de Estado para 'Removido' ou 'Cancelado'.

Tipo de evento inferred
Item de Trabalho Fechado
Representa o encerramento final do item de trabalho após a implantação e qualquer validação pós-implantação. É capturado por uma mudança de estado para 'Fechado' ou 'Concluído'.
Por que é importante

Esta atividade marca a conclusão final e bem-sucedida de todo o processo para um item de trabalho. É o ponto final definitivo do ciclo de vida.

Onde obter

Inferido do histórico do item de trabalho quando o campo System.State é alterado para 'Fechado' ou estado terminal similar na categoria 'Concluído'.

Captura

Inferido a partir da mudança do campo de Estado para 'Fechado'.

Tipo de evento inferred
Teste de QA Concluído
Marca a conclusão bem-sucedida da fase de garantia de qualidade. Isso é inferido quando o estado do item de trabalho muda de uma fase de teste para algo como 'Pronto para UAT' ou 'QA Aprovado'.
Por que é importante

Este é um quality gate fundamental que indica que o item está pronto para o teste de aceitação do usuário ou lançamento. Atrasos após este ponto podem indicar gargalos no UAT ou no planejamento da release.

Onde obter

Inferido do histórico do item de trabalho quando o campo System.State muda de 'Em QA' para um estado subsequente como 'Pronto para UAT' ou 'Concluído'.

Captura

Inferido a partir da mudança do campo de Estado de 'Em QA' para 'Pronto para UAT'.

Tipo de evento inferred
Teste de QA Reprovado
Indica que o item de trabalho falhou no teste de garantia de qualidade (QA) e está sendo devolvido para desenvolvimento. Capturado por uma mudança de estado de teste para 'Em Progresso' ou 'Ativo'.
Por que é importante

Esta atividade é essencial para identificar loops de retrabalho. Uma alta frequência deste evento aponta para problemas na qualidade do código, nos requisitos ou nos processos de teste.

Onde obter

Inferido do histórico do item de trabalho ao detectar uma transição de um estado como 'Em QA' de volta para 'Ativo' ou 'Em Progresso'.

Captura

Inferido a partir da mudança do campo de Estado de 'Em QA' para 'Ativo'.

Tipo de evento inferred
UAT Iniciado
Representa o início do Teste de Aceitação do Usuário (UAT), onde os stakeholders do negócio validam a funcionalidade. Isso é tipicamente inferido de uma mudança de estado para 'Em UAT' ou status similar.
Por que é importante

Mede o início da validação final antes da entrega. A duração do UAT e os tempos de espera por aprovação são fundamentais para analisar a otimização do processo.

Onde obter

Inferido do histórico do item de trabalho quando o campo System.State é atualizado para um estado personalizado representando UAT, como 'Em UAT'.

Captura

Inferido a partir da mudança do campo de Estado para 'Em UAT'.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do Azure DevOps