Seu Template de dados do ciclo de vida do desenvolvimento de software
Seu Template de dados do ciclo de vida do desenvolvimento de software
- 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
Atributos do ciclo de vida do desenvolvimento de software
| 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
|
|||
Atividades do ciclo de vida do desenvolvimento de software
| 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
|
|||
Guias de extração
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.
Não é necessário cartão de crédito. Comece em poucos minutos.