Seu Template de dados do ciclo de vida do desenvolvimento de software

Azure DevOps
Seu Template de dados do ciclo de vida do desenvolvimento de software

Seu Template de dados do ciclo de vida do desenvolvimento de software

Este Template oferece um roteiro claro para preparar os dados do ciclo de vida do desenvolvimento de software para Process Mining. Ele apresenta os atributos essenciais que você precisa coletar, as principais atividades a acompanhar e orientações práticas para extrair essas informações do Azure DevOps. Use este material para estruturar os dados e obter insights úteis para analisar e otimizar o processo.
  • Atributos recomendados para coleta
  • Principais atividades para acompanhar no ciclo de vida do desenvolvimento de software
  • Orientações detalhadas para extração no Azure DevOps
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos do ciclo de vida do desenvolvimento de software

Estes são os campos de dados recomendados para incluir no Event Log e fazer uma análise abrangente do ciclo de vida do desenvolvimento de software e identificar oportunidades de otimização.
5 Obrigatório 7 Recomendado 6 Opcional
Nome Descrição
Data e hora do evento
EventTime
Data e hora exatas em que uma atividade ou um evento específico ocorreu para um item de desenvolvimento.
Descrição

Data e hora do evento registra a data e a hora de cada atividade no ciclo de vida de desenvolvimento. Esse registro de data e hora é o elemento temporal fundamental para ordenar os eventos cronologicamente e calcular o tempo entre eles.

Na análise, este atributo é essencial para calcular todas as métricas baseadas em tempo, incluindo tempo de ciclo, tempo de processamento e tempo de espera. Ele permite criar um Event Log ordenado por data e hora, necessário para qualquer análise de Process Mining. Também é usado para diagnosticar atrasos, medir a performance em relação aos SLAs e acompanhar tendências ao longo do tempo.

Por que isso importa

Este registro de data e hora estabelece a ordem cronológica dos eventos, essencial para calcular todos os KPIs de duração e entender o fluxo do processo e seus gargalos.

Onde encontrar

Corresponde ao campo 'Changed Date' de cada atualização no histórico de um item de trabalho. Para eventos externos, como builds ou implantações, corresponde à data e hora de conclusão do evento.

Exemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Item de desenvolvimento
DevelopmentItem
Identificador exclusivo de uma unidade de trabalho, como uma funcionalidade, um bug ou uma história de usuário. Ele funciona como identificador do caso no processo.
Descrição

O Item de Desenvolvimento representa uma unidade de trabalho específica acompanhada no Azure DevOps. Cada item, identificado por um ID exclusivo, é o objeto central em torno do qual giram todas as atividades do processo, da criação e do planejamento ao desenvolvimento, aos testes e à implantação.

Na análise de Process Mining, este atributo é fundamental para relacionar todos os eventos em uma única trajetória do caso. Assim, é possível reconstruir o ciclo de vida completo de cada item de trabalho e analisar o tempo de ciclo, os desvios do processo e os ciclos de retrabalho de cada item.

Por que isso importa

Este é o identificador principal que conecta todas as etapas do processo em um caso coerente e permite analisar de ponta a ponta o ciclo de vida de desenvolvimento de software.

Onde encontrar

Corresponde ao campo 'ID' de um item de trabalho no Azure DevOps Boards. Ele pode ser acessado pela API REST do Azure DevOps para acompanhamento de itens de trabalho.

Exemplos
10234102351023610237
Nome da atividade
ActivityName
Nome do evento ou da tarefa específica que ocorreu em determinado momento do ciclo de vida de desenvolvimento de um item de trabalho.
Descrição

O Nome da atividade descreve uma etapa ou um marco específico do processo, como 'Desenvolvimento iniciado', 'Pull request criada' ou 'Implantado em produção'. Essas atividades são identificadas a partir de mudanças no estado do item de trabalho, de eventos vinculados, como builds ou pull requests, ou de eventos personalizados.

Este atributo é essencial para criar o mapa do processo, que representa visualmente o fluxo de trabalho. Ele permite que 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 isso importa

Define as etapas do processo, forma a base do mapa do processo e permite analisar o fluxo de trabalho, os gargalos e os desvios.

Onde encontrar

Em geral, é derivado de mudanças no campo '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 desses eventos.

Exemplos
Desenvolvimento iniciadoPull request concluídaTestes de QA reprovadosImplantado em produçãoItem de trabalho fechado
Sistema de origem
SourceSystem
Sistema do qual os dados do processo foram extraídos, neste caso, o Azure DevOps.
Descrição

Este atributo identifica o sistema de origem dos dados. Ele é especialmente útil em ambientes que combinam dados de vários sistemas para oferecer uma visão mais ampla do processo. Neste modelo, o valor é sempre Azure DevOps.

Mesmo que pareça estático em uma análise de um único sistema, ele fornece um contexto essencial sobre a origem dos dados, importante para a governança de dados, a resolução de problemas e futuras integrações com outros sistemas, como ServiceNow ou SAP.

Por que isso importa

Fornece um contexto essencial sobre a origem dos dados, importante para a governança e a validação dos dados e para a análise de processos que envolvem vários sistemas.

Onde encontrar

É um valor estático que deve ser adicionado durante a extração e transformação dos dados para identificar o conjunto de dados.

Exemplos
Azure DevOps
Última atualização dos dados
LastDataUpdate
Data e hora da última atualização dos dados deste processo 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 indica com clareza o nível de atualização dos dados e o período coberto pela análise.

Em qualquer análise de processo, saber quando os dados foram atualizados pela última vez é essencial para tomar decisões fundamentadas. Este registro de data e hora ajuda a entender se as informações são atuais ou se representam um recorte histórico, o que afeta a relevância dos resultados.

Por que isso importa

Informa quando os dados foram atualizados pela última vez, ajudando a garantir que as análises e decisões considerem um período conhecido.

Onde encontrar

Este registro de data e hora de metadados é gerado e armazenado durante o processo de extração, transformação e carregamento (ETL) dos dados.

Exemplos
2024-05-20T08:00:00Z
Atribuído a
AssignedTo
Usuário ou integrante da equipe a quem o item de desenvolvimento está atribuído no momento.
Descrição

Este atributo identifica a pessoa responsável pelo item de trabalho em cada etapa do processo. A atribuição pode mudar várias vezes ao longo do ciclo de vida do item, por exemplo, de uma pessoa desenvolvedora para uma pessoa testadora e, depois, para uma pessoa responsável pelo lançamento.

Analisar o campo 'Atribuído a' é essencial para o Dashboard de visão geral da carga de trabalho de desenvolvimento e testes. Isso ajuda a entender a distribuição dos recursos, identificar integrantes da equipe sobrecarregados e analisar diferenças de performance entre pessoas ou equipes.

Por que isso importa

Permite analisar os recursos para entender a distribuição da carga de trabalho, identificar gargalos relacionados a recursos específicos e gerenciar a capacidade da equipe.

Onde encontrar

Corresponde ao campo 'Assigned To' de um item de trabalho no Azure DevOps. O valor é registrado no histórico do item para cada evento.

Exemplos
jane.doe@example.comjohn.smith@example.comsem atribuição
É retrabalho
IsRework
Indicador booleano que informa se um item de desenvolvimento voltou a uma etapa anterior do ciclo de vida.
Descrição

Esse indicador recebe o valor verdadeiro quando um item de trabalho passa por um ciclo de retrabalho, por exemplo, quando volta de Testes de QA concluídos para Desenvolvimento iniciado. O valor é calculado pela análise da sequência de atividades de um caso, identificando avanços não lineares.

Esse atributo é essencial para o Dashboard de frequência de retrabalho e novos testes e para o KPI de frequência de ciclos de retrabalho. Ele facilita a filtragem e a quantificação do retrabalho, ajudando a identificar problemas de qualidade, falhas de comunicação ou testes insuficientes que causam ineficiências.

Por que isso importa

Ele identifica e quantifica diretamente o retrabalho, ajudando a destacar problemas de qualidade e ineficiências no processo que aumentam o tempo de ciclo.

Onde encontrar

Esse atributo é calculado pela análise da sequência de atividades no Event Log de cada caso.

Exemplos
truefalse
Estado
State
O status atual do item de desenvolvimento no fluxo de trabalho, como Novo, Ativo, Resolvido ou Fechado.
Descrição

O atributo Estado representa o status formal de um item de trabalho em determinado momento, conforme definido pelo Template de processo do projeto. As transições entre esses estados são a principal fonte para gerar as atividades no Event Log.

Embora o atributo Atividade muitas vezes descreva uma mudança de estado com mais detalhes, o atributo Estado original é útil para filtrar e analisar os dados. Ele ajuda a entender quanto tempo os itens permanecem em determinados estados e é essencial para criar o Dashboard de duração das etapas e analisar as transferências.

Por que isso importa

Ele indica o status do item de trabalho no ciclo de vida, algo essencial para entender o fluxo do processo e calcular o tempo gasto em cada etapa.

Onde encontrar

Corresponde ao campo Estado de um item de trabalho no Azure DevOps.

Exemplos
NovoAtivoEm QAResolvidoFechado
Hora de término
EndTime
Data e hora em que uma atividade foi concluída. Esse dado é usado para calcular o tempo de processamento da atividade.
Descrição

A Hora de término marca a conclusão de uma atividade. Em muitos registros de eventos, a hora de início da atividade seguinte é usada como hora de término da anterior. No entanto, ter uma hora de término específica permite calcular com mais precisão tanto o tempo de processamento da atividade quanto o tempo ocioso entre atividades.

Este atributo é essencial para calcular o KPI de tempo de processamento e fazer uma análise detalhada de gargalos. Ele ajuda a diferenciar o tempo dedicado ao trabalho ativo em uma tarefa do tempo de espera até o início da próxima etapa, algo fundamental para o Dashboard de análise das transferências entre etapas.

Por que isso importa

Permite calcular com precisão o tempo de processamento das atividades e o tempo ocioso, algo fundamental para analisar gargalos e melhorar a eficiência.

Onde encontrar

Muitas vezes, esse dado é derivado. Pode corresponder à hora de início do evento seguinte no mesmo caso ou ser registrado explicitamente se o sistema de origem capturar as horas de início e término das tarefas.

Exemplos
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Nome da equipe
TeamName
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 costuma ser organizado por equipes, que podem fazer parte de um projeto maior.

Esse atributo permite segmentar a análise do processo por equipe. Ele é muito útil para comparar processos e performance entre equipes, identificar boas práticas nos times com melhor desempenho e encontrar áreas em que determinadas equipes precisam de apoio ou de melhorias no processo.

Por que isso importa

Ele permite comparar diferentes equipes, identificar variações de performance e compartilhar boas práticas na organização.

Onde encontrar

Esse dado costuma ser derivado do campo Caminho da área de um item de trabalho, já que as equipes geralmente são associadas a caminhos de área específicos no Azure DevOps.

Exemplos
Equipe PhoenixEsquadrão OmegaNúcleo da plataformaEquipe de frontend
Prioridade
Priority
Classificação numérica ou descritiva da importância do item de desenvolvimento em relação aos demais.
Descrição

A prioridade indica a importância de um item de trabalho para o planejamento. Uma prioridade mais alta sugere que o item deve ser tratado antes dos itens de prioridade mais baixa. Os valores costumam ser numéricos, como 1, 2, 3 e 4, sendo 1 a prioridade mais alta.

Esse atributo é essencial para o Dashboard de throughput e tempo de ciclo por prioridade. A análise dos dados com esse atributo ajuda a verificar se o sistema de priorização está funcionando, ou seja, se os itens de alta prioridade realmente avançam pelo processo mais rápido que os de baixa prioridade.

Por que isso importa

Ele permite avaliar se o processo acelera o andamento dos itens de alta prioridade, um aspecto fundamental para analisar a eficácia das estratégias de priorização.

Onde encontrar

Corresponde ao campo Prioridade de um item de trabalho no Azure DevOps.

Exemplos
1234
Tipo de item de trabalho
WorkItemType
Classificação do item de desenvolvimento, como bug, funcionalidade, história de usuário ou tarefa.
Descrição

O Tipo de item de trabalho classifica a natureza do trabalho realizado. Diferentes tipos de itens costumam seguir caminhos distintos no processo e ter expectativas de performance ou SLAs diferentes. Por exemplo, um 'Bug' pode seguir um caminho mais rápido do que uma 'Feature'.

Este atributo é essencial para análises comparativas. Ele permite filtrar o mapa do processo ou os KPIs por tipo de trabalho e entender se determinados processos são mais eficientes para bugs do que para funcionalidades, além de acompanhar tendências históricas do tempo de ciclo por categoria de trabalho.

Por que isso importa

Permite segmentar a análise do processo e comparar os fluxos de trabalho e a performance de diferentes categorias, como bugs e funcionalidades.

Onde encontrar

Corresponde ao campo 'Work Item Type' de um item de trabalho no Azure DevOps.

Exemplos
BugFuncionalidadeHistória de usuárioTask
Caminho da iteração
IterationPath
Sprint ou período de tempo definido ao qual o item de trabalho está atribuído.
Descrição

O caminho da iteração, ou sprint, representa um período específico de desenvolvimento com duração definida. Os itens de trabalho são atribuídos a uma iteração para serem concluídos nesse período.

A análise por caminho da iteração ajuda a entender a performance do processo sprint a sprint. Você pode acompanhar se o tempo de ciclo está melhorando ao longo das sprints, analisar o trabalho transferido para a próxima sprint e avaliar a previsibilidade do planejamento.

Por que isso importa

Ele permite analisar o trabalho por sprint, ajudando as equipes a avaliar a própria performance ao longo do tempo e melhorar as práticas ágeis.

Onde encontrar

Corresponde ao campo Caminho da iteração de um item de trabalho no Azure DevOps.

Exemplos
Plataforma de comércio eletrônico\Sprint 12Plataforma de comércio eletrônico\Sprint 13Relançamento do aplicativo móvel\Fase 2\Sprint 4
ID da pull request
PullRequestId
Identificador de uma pull request vinculada ao item de desenvolvimento.
Descrição

Esse atributo vincula um item de trabalho a uma pull request específica, usada para enviar e revisar alterações de código. Um item de trabalho pode estar associado a várias pull requests.

O ID da pull request permite analisar com mais detalhes a revisão e a integração do código no ciclo de vida. Você pode medir o tempo entre a criação e a conclusão da pull request e analisar com que frequência elas são rejeitadas ou exigem mudanças significativas, o que pode indicar problemas na qualidade do código ou requisitos pouco claros.

Por que isso importa

Ele relaciona o trabalho de desenvolvimento a atividades específicas de revisão de código, permitindo analisar em detalhes o processo de integração e garantia da qualidade.

Onde encontrar

Essa informação aparece na seção Links ou Desenvolvimento de um item de trabalho no Azure DevOps.

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

Esse atributo identifica o projeto específico da organização do Azure DevOps em que o item de trabalho está. Ele fornece contexto geral, principalmente em organizações com muitos projetos.

O nome do projeto é uma dimensão importante para filtragem e comparação. Ele dá suporte ao Dashboard de tendências históricas do tempo de ciclo, permitindo segmentar a análise por projeto e identificar se alguns projetos são mais ou menos eficientes que outros ou se as melhorias em um projeto tiveram impacto positivo.

Por que isso importa

Ele oferece um agrupamento geral para a análise, permitindo comparar a performance e as tendências entre diferentes projetos.

Onde encontrar

Corresponde ao campo Projeto da equipe de um item de trabalho no Azure DevOps.

Exemplos
Plataforma de comércio eletrônicoRelançamento do aplicativo móvelModernização do data warehouse
Severidade
Severity
Indica o impacto de um bug ou problema no sistema ou nos usuários finais.
Descrição

A severidade classifica o impacto de um bug, desde falhas críticas no sistema até problemas estéticos menores. Ela é diferente da prioridade, que define a ordem do trabalho. Um bug de alta severidade pode ter baixa prioridade se houver uma solução alternativa simples.

Esse atributo oferece outra dimensão para análise, especialmente no Dashboard de throughput e tempo de ciclo por prioridade. Com ele, você pode investigar questões como: Estamos corrigindo primeiro os bugs mais críticos? Ele também ajuda a entender o perfil de risco do trabalho em andamento.

Por que isso importa

Ele ajuda a classificar os itens de trabalho pelo impacto nos negócios e permite analisar a eficácia da equipe ao lidar com problemas de alto impacto.

Onde encontrar

Corresponde ao campo Severidade de um item de trabalho, geralmente usado para bugs, no Azure DevOps.

Exemplos
1 - Crítico2 - Alto3 - Médio4 - Baixo
Tempo de espera por aprovação
ApprovalWaitingTime
Tempo que um item de desenvolvimento espera por uma aprovação após o envio da solicitação.
Descrição

Essa métrica mede a duração de períodos específicos em que um item de trabalho aguarda aprovação. Um exemplo é o intervalo entre UAT iniciado e UAT aprovado. O cálculo mede o tempo entre essas duas atividades para um determinado caso.

Esse atributo calculado dá suporte direto ao Dashboard de análise do tempo de espera por aprovação e ao KPI correspondente. Ao isolar esses atrasos, as equipes podem melhorar a comunicação e a tomada de decisões para reduzir o tempo ocioso e acelerar o ciclo de vida como um todo.

Por que isso importa

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

Onde encontrar

O cálculo identifica atividades específicas de início e fim da aprovação no Event Log, como UAT iniciado e UAT aprovado, e mede a diferença de tempo entre elas.

Exemplos
3 dias e 2 horas1 dia, 8 horas e 30 minutos4 horas
Tempo de transferência entre etapas
StageHandoffTime
Tempo de inatividade entre a conclusão de uma etapa importante e o início da seguinte.
Descrição

O tempo de transferência entre etapas mede o período de espera entre etapas sequenciais do processo, por exemplo, entre Desenvolvimento concluído e Testes de QA iniciados. O cálculo identifica essas transições importantes e mede o intervalo entre o fim da primeira atividade e o início da segunda.

Essa métrica é o foco do Dashboard de duração das etapas e análise de transferências. Isolar e medir o tempo de transferência é fundamental para identificar gargalos ocultos, quando o trabalho fica parado, muitas vezes por falta de recursos, atrasos na comunicação ou processos ineficientes.

Por que isso importa

Ele quantifica o tempo de espera entre as etapas do processo, revelando gargalos ocultos e atrasos que não fazem parte do trabalho ativo.

Onde encontrar

Esse atributo é calculado. É preciso identificar pares de atividades sequenciais que representam uma transferência e, em seguida, calcular a diferença de tempo entre elas.

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

Atividades do ciclo de vida do desenvolvimento de software

Estas são as principais etapas e marcos do processo que você deve registrar no Event Log para descobrir o processo com precisão e identificar gargalos.
7 Recomendado 8 Opcional
Atividade Descrição
Desenvolvimento iniciado
Esta atividade indica que uma pessoa desenvolvedora começou a trabalhar ativamente no item. Ela é identificada quando o estado do item de trabalho muda para 'Active', 'In Progress' ou 'Committed'.
Por que isso importa

Marca o início da fase de desenvolvimento ativo. Analisar o tempo entre 'Created' e 'Development Started' revela quanto tempo os itens ficam na fila do backlog.

Onde encontrar

Identificado no histórico do item de trabalho quando o campo System.State muda de 'New' ou 'Approved' para 'In Progress'.

Coleta

Identificado quando o campo State muda para 'Active' ou 'In Progress'.

Tipo de evento inferred
Implantado em produção
Marca a implantação bem-sucedida em produção do código associado ao item de trabalho. Este evento é registrado explicitamente nos logs de lançamento do Azure Pipelines.
Por que isso importa

Esta é uma etapa crítica que representa a entrega de valor. Ela marca o ponto final para calcular o lead time e o tempo de ciclo.

Onde encontrar

Registrado a partir dos dados do pipeline de lançamento do Azure Pipelines, especificamente do evento de conclusão de uma implantação em uma etapa 'Production' vinculada ao item de trabalho.

Coleta

Registrado a partir de um evento de conclusão de implantação do pipeline de lançamento.

Tipo de evento explicit
Item de trabalho criado
Esta atividade marca o início do ciclo de vida de desenvolvimento e representa a criação de um novo item de trabalho, como uma história de usuário, um bug ou uma tarefa. O evento é registrado quando um novo registro é salvo no Azure DevOps Boards.
Por que isso importa

Este é o principal evento de início do processo. Ele é essencial para medir o tempo de ciclo de desenvolvimento de ponta a ponta e entender de onde vem o trabalho.

Onde encontrar

Este evento é registrado a partir do campo 'Created Date' do próprio item de trabalho. A tabela de histórico do item também registra essa transição de estado inicial.

Coleta

Registrado a partir do campo 'Created Date' do item de trabalho.

Tipo de evento explicit
Pull request concluída
Representa a conclusão bem-sucedida de uma revisão de código: a pull request é aprovada e o código é integrado à branch de destino. Este evento é registrado explicitamente no Azure Repos.
Por que isso importa

Marca o fim da fase de revisão de código, que costuma ser um gargalo. Analisar o tempo entre a criação e a conclusão da PR revela a eficiência do ciclo de revisão.

Onde encontrar

Registrado a partir do evento de conclusão ou integração de uma pull request no Azure Repos vinculada a um item de trabalho.

Coleta

Registrado a partir do evento de integração de uma pull request vinculada a um item de trabalho.

Tipo de evento explicit
Pull request criada
Indica que a pessoa desenvolvedora concluiu a codificação inicial e enviou as alterações para revisão por meio de uma pull request. Este evento vincula o item de trabalho a uma alteração de código específica no Azure Repos.
Por que isso importa

Esta é uma transferência importante do desenvolvimento para a revisão de código. Acompanhar esse evento ajuda a medir a duração da codificação e identificar quando o código está pronto para revisão por pares.

Onde encontrar

Registrado a partir dos dados do Azure Repos, vinculando o evento de criação da pull request ao item de trabalho correspondente. Muitas vezes, a própria pessoa desenvolvedora faz esse vínculo.

Coleta

Registrado a partir do evento de criação de uma pull request no Azure Repos vinculada a um item de trabalho.

Tipo de evento explicit
Testes de aceitação do usuário aprovados
Esta atividade indica que as partes interessadas da área de negócios aprovaram as alterações após os testes de aceitação do usuário. Em geral, o evento é identificado quando o estado muda de 'In UAT' para 'UAT Approved' ou 'Ready for Release'.
Por que isso importa

Esta é uma etapa crítica de aprovação, que confirma que o item de trabalho atende aos requisitos de negócio e está pronto para implantação em produção.

Onde encontrar

Identificado no 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 lançamento.

Coleta

Identificado quando o campo State muda de 'In UAT' para 'Ready for Release'.

Tipo de evento inferred
Testes de QA iniciados
Representa o início da fase formal de testes de garantia da qualidade. Este evento é identificado quando o estado do item de trabalho muda para 'In QA', 'Testing' ou um valor semelhante.
Por que isso importa

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

Onde encontrar

Identificado no histórico do item de trabalho ao acompanhar a mudança do campo System.State para 'In QA' ou outro estado designado para testes.

Coleta

Identificado quando o campo State muda para 'In QA' ou 'Testing'.

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. O Azure Pipelines registra esse evento explicitamente.
Por que isso importa

Funciona como um critério crítico de qualidade, garantindo que o novo código se integre corretamente sem interromper o build. Falhas nesta etapa podem indicar problemas de integração.

Onde encontrar

Registrado a partir dos eventos de conclusão de build do Azure Pipelines. O build precisa ser vinculado ao item de trabalho, diretamente ou por meio da pull request correspondente.

Coleta

Registrado a partir do evento de conclusão de build do Azure Pipelines.

Tipo de evento explicit
Desenvolvimento concluído
Indica que todas as atividades de desenvolvimento e testes unitários foram concluídas e que o item está pronto para os testes formais. Em geral, esse evento é identificado quando o estado do item de trabalho muda para 'Resolved' ou 'Ready for Test'.
Por que isso importa

Marca uma transferência importante da equipe de desenvolvimento para a equipe de QA. Medir o tempo até 'QA Testing Started' ajuda a identificar atrasos nessa transferência.

Onde encontrar

Identificado no histórico do item de trabalho quando o campo System.State muda para um valor como 'Resolved' ou para um estado personalizado que indique que o item está pronto para QA.

Coleta

Identificado quando o campo State muda para 'Resolved'.

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. Em geral, esse evento é identificado quando o campo 'State' muda para um valor como 'Approved' ou 'Ready for Dev'.
Por que isso importa

Acompanhar as aprovações ajuda a analisar o tempo entre o envio de uma ideia e o compromisso de desenvolvê-la. Isso destaca possíveis atrasos no planejamento e na organização do backlog.

Onde encontrar

Identificado no histórico do item de trabalho quando o campo System.State muda para 'Approved' ou para um estado personalizado equivalente.

Coleta

Identificado quando o campo State muda para 'Approved'.

Tipo de evento inferred
Item de trabalho cancelado
Indica que o item de trabalho foi cancelado e não será concluído nem implantado. O evento é registrado quando o estado muda para 'Removed', 'Cancelled' ou um estado semelhante.
Por que isso importa

Representa um encerramento alternativo e malsucedido do processo. Analisar os itens cancelados pode revelar problemas de planejamento, priorização ou definição de requisitos.

Onde encontrar

Identificado no histórico do item de trabalho quando o campo System.State muda para um estado terminal da categoria 'Removed'.

Coleta

Identificado quando o campo State muda para 'Removed' ou 'Cancelled'.

Tipo de evento inferred
Item de trabalho fechado
Representa o fechamento definitivo do item de trabalho após a implantação e qualquer validação posterior. O evento é registrado quando o estado muda para 'Closed' ou 'Done'.
Por que isso importa

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 encontrar

Identificado no histórico do item de trabalho quando o campo System.State muda para 'Closed' ou para um estado terminal semelhante na categoria 'Completed'.

Coleta

Identificado quando o campo State muda para 'Closed'.

Tipo de evento inferred
Testes de aceitação do usuário iniciados
Representa o início dos testes de aceitação do usuário (UAT), nos quais as partes interessadas da área de negócios validam a funcionalidade. Em geral, esse evento é identificado quando o estado muda para 'In UAT' ou um status semelhante.
Por que isso importa

Marca o início da validação final antes do lançamento. É importante analisar a duração do UAT e o tempo de espera pela aprovação para otimizar o processo.

Onde encontrar

Identificado no histórico do item de trabalho quando o campo System.State é atualizado para um estado personalizado que representa o UAT, como 'In UAT'.

Coleta

Identificado quando o campo State muda para 'In UAT'.

Tipo de evento inferred
Testes de QA concluídos
Marca a conclusão bem-sucedida da fase de garantia da qualidade. O evento é identificado quando o estado do item de trabalho muda de um estado de teste para um estado como 'Ready for UAT' ou 'QA Approved'.
Por que isso importa

Este é um critério importante de qualidade que indica que o item está pronto para testes de aceitação do usuário ou para lançamento. Atrasos a partir deste ponto podem indicar gargalos nos testes de aceitação do usuário ou no planejamento do lançamento.

Onde encontrar

Identificado no histórico do item de trabalho quando o campo System.State muda de 'In QA' para um estado posterior, como 'Ready for UAT' ou 'Done'.

Coleta

Identificado quando o campo State muda de 'In QA' para 'Ready for UAT'.

Tipo de evento inferred
Testes de QA reprovados
Indica que o item de trabalho não passou nos testes de garantia da qualidade e está voltando para desenvolvimento. O evento é registrado quando o estado muda de um estado de teste para 'In Progress', 'Active' ou outro estado equivalente.
Por que isso importa

Esta atividade é essencial para identificar ciclos de retrabalho. A alta frequência desse evento aponta possíveis problemas na qualidade do código, nos requisitos ou nos processos de teste.

Onde encontrar

Identificado no histórico do item de trabalho ao detectar uma transição de um estado como 'In QA' para um estado como 'Active' ou 'In Progress'.

Coleta

Identificado quando o campo State muda de 'In QA' para 'Active'.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como obter seus dados do Azure DevOps

Pronto para começar?

Comece hoje a otimizar o ciclo de vida do desenvolvimento de software. Este Template é o primeiro passo para descobrir insights valiosos sobre o processo.

Otimize hoje o ciclo de vida do desenvolvimento de software no Azure DevOps!

Reduza o tempo de ciclo em 30% e elimine gargalos no fluxo de trabalho do ciclo de vida do desenvolvimento de software.

Começar o teste grátis

Não é necessário cartão de crédito. Comece em poucos minutos.