Seu Template de Dados do Ciclo de Vida de Desenvolvimento de Software
Seu Template de Dados do Ciclo de Vida de Desenvolvimento de Software
- Atributos recomendados para coletar
- Principais atividades para monitorar no seu SDLC
- Guia detalhado de extração para Azure DevOps
Atributos do Ciclo de Vida de Desenvolvimento de Software
| 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
|
|||
Atividades do Ciclo de Vida de Desenvolvimento de Software
| 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
|
|||