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

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

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

Guia completo para coletar dados e otimizar seu SDLC. Define atributos essenciais, atividades chave e dá orientações práticas para extração no ServiceNow DevOps. Use este recurso para criar logs de eventos robustos e análises profundas.
  • Atributos recomendados para coletar
  • Atividades-chave a monitorizar
  • Guia de extração para o ServiceNow DevOps
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos do Ciclo de Vida de Desenvolvimento de Software

Estes são os campos de dados recomendados para o seu log de eventos para uma análise completa do seu SDLC.
5 Obrigatório 8 Recomendado 5 Opcional
Nome Descrição
Hora de Início
EventTime
O registro exato de data e hora que indica quando uma atividade ou evento específico ocorreu.
Descrição

Data e hora em que cada atividade foi registrada. Essencial para ordem cronológica e análises temporais.

No Process Mining, o início é usado para calcular durações entre etapas, identificar esperas e medir o ciclo total. É vital para dashboards de desempenho e cálculo de KPIs como o Lead Time de Code Review.

Por que é importante

Timestamp essencial para ordenar eventos e calcular métricas: tempos de ciclo, durações e esperas.

Onde obter

Geralmente encontrado em campos de sistema como 'sys_updated_on' ou 'sys_created_on'.

Exemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
Item de Desenvolvimento
DevelopmentItem
O identificador exclusivo de uma unidade de trabalho, como funcionalidade ou bug, que avança pelo ciclo de desenvolvimento.
Descrição

O Item de Desenvolvimento serve como o identificador principal do caso, representando uma unidade de trabalho distinta. Ele conecta todas as atividades, da concepção inicial ao deploy desse item específico.

Na análise de Process Mining, este atributo é fundamental para reconstruir a jornada de ponta a ponta. Ele permite visualizar fluxos, calcular tempos de ciclo e identificar variantes de processo para cada funcionalidade ou correção. Todo evento deve estar associado a um Item de Desenvolvimento para formar um mapa de processo coerente.

Por que é importante

Identificador central que une todas as atividades em uma única instância, permitindo analisar o ciclo completo de cada item.

Onde obter

Identificador que costuma ser a chave primária das tabelas de stories, bugs ou tarefas (ex: 'rm_story', 'rm_bug' ou 'task') no ServiceNow.

Exemplos
STRY0010015BUG0034092TASK0050118
Nome da Atividade
ActivityName
O nome do evento específico do ciclo de vida que ocorreu, como 'Desenvolvimento Iniciado' ou 'Code Review Realizado'.
Descrição

Registra o nome de cada marco ou tarefa no SDLC. Essas atividades formam os passos sequenciais, da criação ao deploy.

Analisar a sequência e frequência delas é o cerne do Process Mining. Permite montar o mapa do processo, achar gargalos e apontar variações ineficientes. Inclui etapas como design, desenvolvimento, testes e deploy.

Por que é importante

Define as etapas no mapa do processo, permitindo a análise do fluxo, identificação de gargalos e descoberta de desvios em relação ao SDLC padrão.

Onde obter

Derivado mapeando mudanças de status ou auditoria para nomes de atividades padrão (ex: 'In Progress' vira 'Desenvolvimento Iniciado').

Exemplos
Desenvolvimento IniciadoCódigo ComitadoTestes de QA ConcluídosImplantado em Produção
Sistema de Origem
SourceSystem
Identifica o sistema de onde os dados foram extraídos, que neste caso é o ServiceNow DevOps.
Descrição

Especifica o sistema de origem (neste caso, 'ServiceNow DevOps').

Pode parecer estático, mas incluir a fonte é crucial para governança de dados, especialmente se houver fusão com dados de Jira ou Azure DevOps. Garante clareza sobre a procedência e ajuda a diagnosticar problemas de qualidade ou extração.

Por que é importante

Garante a rastreabilidade dos dados e é essencial para manter a integridade das informações, especialmente ao integrar dados de várias ferramentas de desenvolvimento.

Onde obter

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

Exemplos
ServiceNow DevOps
Última Atualização de Dados
LastDataUpdate
Timestamp da última atualização dos dados deste log a partir do sistema de origem.
Descrição

Registra quando o dataset foi extraído ou atualizado. Vale para todo o conjunto de dados.

Este timestamp é vital para saber o quão recente é a análise. Informa sobre a atualidade dos insights e ajuda a agendar atualizações. Exibir isso nos dashboards dá contexto às métricas, garantindo decisões baseadas em dados atualizados.

Por que é importante

Fornece um contexto crucial sobre a atualidade dos dados, garantindo que os usuários saibam o quão atualizada está a análise do processo.

Onde obter

Timestamp gerado durante a extração, marcando quando o processo foi executado.

Exemplos
2023-11-15T08:00:00Z
Desenvolvedor Atribuído
AssignedDeveloper
O nome ou ID do desenvolvedor ou usuário atribuído ao item no momento da atividade.
Descrição

Identifica quem executa a tarefa. É dinâmico e muda conforme o item avança entre estágios e equipes.

Crucial para analisar alocação, carga de trabalho e handoffs. Suporta dashboards de carga de trabalho e KPIs de volume por desenvolvedor. Ao rastrear mudanças aqui, mede-se tempos de handoff e identifica-se falhas de colaboração entre devs ou entre dev e QA.

Por que é importante

Essencial para análise de recursos, distribuição de carga, eficiência de handoff e padrões de performance por equipe.

Onde obter

Informação geralmente armazenada no campo 'assigned_to' das tabelas de tarefas do ServiceNow.

Exemplos
David MillerAnna WilliamsJames Brown
É Retrabalho
IsRework
Um sinalizador booleano que é verdadeiro se a atividade for parte de um loop de retrabalho, como retornar ao desenvolvimento após o teste.
Descrição

Atributo derivado que identifica voltas para estágios anteriores. Se o 'Desenvolvimento Iniciado' ocorre após o 'QA Concluído' no mesmo item, é marcado como retrabalho.

Vital para quantificar e visualizar o retrabalho. Suporta o dashboard de 'Análise de Fluxo de Rejeição' e o KPI de 'Taxa de Retrabalho pós-Teste'. Permite filtrar e analisar causas e impactos do retrabalho no ciclo total.

Por que é importante

Esta flag facilita a quantificação e análise do retrabalho, ajudando a medir a qualidade do processo e identificar causas de tarefas repetidas.

Onde obter

Este atributo é calculado na ferramenta de Process Mining analisando a sequência de atividades para detectar movimentos de retorno no fluxo.

Exemplos
verdadeirofalse
Estado do Item de Desenvolvimento
DevelopmentItemState
O status ou estado do item no momento do evento, como 'Open', 'In Progress' ou 'Closed'.
Descrição

Reflete o status oficial do item no ServiceNow. Enquanto atividades são passos derivados, o estado é a etapa formal no workflow.

O estado costuma ser a fonte para as atividades. Serve para validação e visões de alto nível. Analisar o tempo em cada estado pode mostrar gargalos diferentes da análise entre atividades, além de identificar itens parados ou resolvidos.

Por que é importante

Fornece o status oficial de um item de trabalho no sistema, que serve como base para derivar atividades e pode ser usado para validação e análise de status de alto nível.

Onde obter

Campo padrão, normalmente chamado 'state' ou 'stage', no ServiceNow.

Exemplos
PendenteTrabalho em AndamentoPronto para TesteFechado Concluído
Grupo de atribuição
AssignmentGroup
A equipe ou grupo responsável pelo item no momento da atividade.
Descrição

Identifica a equipe atribuída (ex: 'Frontend', 'Backend' ou 'QA'). Conforme o item avança, ele passa por diferentes grupos.

Rastrear o grupo é essencial para entender a colaboração cross-funcional. Ajuda a achar atrasos sistêmicos na transição entre times. Suporta a análise de desempenho por equipe e carga de trabalho, identificando quais times são gargalos no fluxo geral.

Por que é importante

Rastreia a equipe responsável, permitindo analisar performance, balanceamento de carga e eficiência nos handoffs.

Onde obter

Informação armazenada no campo 'assignment_group', padrão em tabelas de tarefas no ServiceNow.

Exemplos
Engenharia de PlataformaEquipe de App MobileGarantia de QualidadeDevOps
Módulo/Componente Afetado
ModuleComponentAffected
O módulo, aplicação ou componente específico ao qual o item de desenvolvimento se refere.
Descrição

Categoriza o trabalho pela parte do sistema impactada (ex: microserviço, componente de UI ou backend).

Segmentar por módulo é crucial para achar gargalos locais. Dashboards de insights por componente e KPIs de duração média usam este atributo para identificar se certas áreas do código têm ciclos mais longos, mais retrabalho ou falhas de deploy, direcionando melhor as melhorias.

Por que é importante

Permite que a análise seja segmentada por aplicação ou componente, ajudando a isolar gargalos ou problemas de qualidade específicos de certas partes do sistema.

Onde obter

Geralmente um campo customizado ou referência ao CMDB. Veja a documentação do ServiceNow DevOps.

Exemplos
Serviço de FaturamentoUI de Autenticação de UsuárioBanco de Dados de RelatóriosAPI Gateway
Prioridade
DevelopmentItemPriority
O nível de prioridade do item, como 'Alta', 'Média' ou 'Baixa'.
Descrição

Categoriza itens pela urgência de negócio. Níveis de prioridade focam as equipes no essencial e gerenciam SLAs e expectativas.

No Process Mining, a prioridade é vital para análise comparativa. Permite filtrar o mapa para ver se itens urgentes seguem caminhos mais rápidos. É essencial para dashboards de tempo de entrega de alta prioridade, validando se itens críticos estão sendo agilizados.

Por que é importante

Permite filtrar e comparar processos para diferentes níveis de prioridade, ajudando a verificar se itens de alta prioridade são processados com mais rapidez e eficiência.

Onde obter

Campo padrão, geralmente chamado 'priority', nas tabelas de tarefas do ServiceNow.

Exemplos
1 - Crítico2 - Alto3 - Moderada4 - Baixo
Tempo de Ciclo do Item de Desenvolvimento
DevelopmentItemCycleTime
O tempo total decorrido desde a criação do item até o seu fechamento final ou deploy.
Descrição

Métrica calculada que representa a duração total de um item, da primeira à última atividade.

É um KPI primário para o SDLC total, suportando o indicador de 'Tempo Médio de Ciclo'. Oferece uma medida de alto nível da velocidade e eficiência. Analisar isso ao longo do tempo por prioridade ou equipe ajuda a medir o impacto das melhorias de processo.

Por que é importante

Representa a duração total de ponta a ponta de um item, métrica fundamental para medir a eficiência e velocidade geral do processo.

Onde obter

Não é um campo nativo. Calculado subtraindo o StartTime inicial do final para cada CaseId.

Exemplos
15 dias e 4 horas3 dias e 12 horas32 dias 8 horas
Tipo de Item de Desenvolvimento
DevelopmentItemType
A classificação do item de trabalho, como 'Feature', 'Bug', 'Technical Debt' ou 'Task'.
Descrição

Distingue os tipos de trabalho no SDLC. Corrigir um bug crítico pode ser bem mais rápido que desenvolver uma nova funcionalidade.

Analisar por tipo de item permite entender o desempenho de forma granular. Ajuda a responder se bugs têm mais retrabalho ou se o tempo de redução de dívida técnica está aceitável, oferecendo insights mais profundos do que uma visão genérica.

Por que é importante

Distingue entre diferentes tipos de trabalho, como funcionalidades e bugs, que podem ter diferentes caminhos de processo, prioridades e durações esperadas.

Onde obter

Pode ser determinado pela tabela de origem do registro (ex: 'rm_story' vs 'rm_bug') ou por um campo de tipo em uma tabela de tarefas genérica.

Exemplos
FuncionalidadeBugTarefaSpike
End Time
EventEndTime
O timestamp exato que indica quando uma atividade foi concluída. Para eventos instantâneos, é igual ao Horário de Início.
Descrição

Data e hora de conclusão de cada atividade. Útil para medir durações como 'Code Review' ou 'Testes de QA'.

Ter horários de início e fim permite calcular tempos exatos de processamento, separando-os do tempo de espera. Isso ajuda a saber se o atraso vem de tarefas longas ou falta de recursos. Para eventos instantâneos como 'Build disparado', o fim é igual ao início.

Por que é importante

Permite o cálculo preciso do tempo de processamento da atividade, o que ajuda a diferenciar entre o tempo gasto trabalhando versus o tempo gasto esperando.

Onde obter

Pode ser derivado do início da próxima atividade ou de um campo de 'data final' no sistema de origem.

Exemplos
2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
ID do Commit
CommitId
O identificador exclusivo do commit de código-fonte associado ao trabalho de desenvolvimento.
Descrição

Link direto do item para a mudança de código no repositório (ex: Git), capturado no evento de 'Code Committed'.

No Process Mining, o ID do Commit enriquece a análise unindo dados de processo e engenharia. Permite rastrear deploys problemáticos até o código exato ou correlacionar complexidade de código com tempos de ciclo, oferecendo uma análise de causa raiz técnica e profunda.

Por que é importante

Vincula o evento do processo a uma alteração de código específica, permitindo uma análise de causa raiz mais profunda ao correlacionar métricas de processo com detalhes do código.

Onde obter

Capturado via integrações com SCM (Git, SVN). Os dados ficam em tabelas relacionadas vinculadas ao item.

Exemplos
a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
Motivo do retrabalho
ReworkReason
Uma classificação ou descrição do porquê um item de desenvolvimento precisou de retrabalho após o teste.
Descrição

Captura o motivo da falha no QA ou UAT (ex: categoria de bug, erro de requisito ou ambiente).

Dá contexto crítico para análise de retrabalho. Em vez de apenas saber que houve erro, entende-se o porquê. Isso permite melhorias focadas em definição de requisitos, testes unitários ou estabilidade de ambientes para baixar a taxa de retrabalho.

Por que é importante

Oferece insights qualitativos sobre o porquê do retrabalho, permitindo melhorias focadas para elevar a qualidade e reduzir loops de correção.

Onde obter

Pode estar em 'close_notes' ou campos dedicados como 'rework_reason'. Consulte a documentação do ServiceNow.

Exemplos
Requisito Mal InterpretadoBug de RegressãoTeste de Performance FalhouProblema de UI/UX
Status da Implantação
DeploymentStatus
Indica o resultado de uma atividade de implantação, normalmente 'Success' ou 'Failure'.
Descrição

Registra o resultado do deploy em um ambiente. Vital para entender a confiabilidade da release.

Essencial para dashboards de tendências de sucesso/falha e o KPI de Taxa de Falha de Deploy. Analisando esses padrões, as empresas acham problemas em testes, infraestrutura ou coordenação, focando esforços para garantir entregas mais estáveis.

Por que é importante

Mede diretamente o sucesso das atividades de implantação, o que é fundamental para calcular a taxa de falha de implantação e analisar a estabilidade da release.

Onde obter

Status registrado em tarefas de deploy ou execuções de pipeline integradas ao ServiceNow DevOps.

Exemplos
SucessoFalhaConcluído com avisos
Versão de Release Planejada
PlannedReleaseVersion
A versão ou release de software em que a entrega do item está planejada.
Descrição

Vincula o item a uma release planejada (ex: 'v2.3' ou 'Release Q4'). Vital para gestão de projetos.

No Process Mining, é crucial para dashboards de aderência ao plano de release. Comparando datas reais com o planejado, as equipes medem o cumprimento do cronograma e analisam causas de atrasos, ligando o desenvolvimento operacional aos objetivos de negócio.

Por que é importante

Conecta o trabalho de desenvolvimento a releases específicas, permitindo a análise da adesão ao cronograma e o impacto dos atrasos de processo nos prazos de lançamento.

Onde obter

Informação geralmente guardada nos campos 'release' ou 'planned_release'. Consulte a documentação do ServiceNow DevOps.

Exemplos
v3.4.1Lançamento Q1 2024Go-Live do Projeto Phoenix
Obrigatório Recomendado Opcional

Atividades do Ciclo de Vida de Desenvolvimento de Software

Estes são os principais passos e marcos do processo que devem ser capturados no seu Event Log para descobrir e otimizar o processo com mais precisão.
7 Recomendado 9 Opcional
Atividade Descrição
Desenvolvimento Iniciado
Marca o ponto em que o desenvolvedor começa a codificar. Geralmente inferido pela mudança de status para 'In Progress', 'Development' ou 'Coding'.
Por que é importante

Marco crucial que sinaliza o início da fase de construção. Essencial para medir o lead time do desenvolvedor e ciclos de code review.

Onde obter

Inferido a partir do timestamp de quando o campo 'State' no registro do item de desenvolvimento (ex: Story [rm_story]) é atualizado para 'In Progress' ou status equivalente.

Captura

Baseado no timestamp de uma mudança de estado para 'In Progress' ou valor similar.

Tipo de evento inferred
Implantação Falhou
Indica que a tentativa de implantar o item de desenvolvimento em produção não teve sucesso. Isso é capturado explicitamente pelo ServiceNow DevOps quando o pipeline de CI/CD reporta uma falha.
Por que é importante

Ponto final crítico de falha. Analisar sua frequência e causas é a chave para estabilizar releases e reduzir taxas de erro no deploy.

Onde obter

Capturado do 'completion_status' de um registro de Pipeline Execution [sn_devops_pipeline_execution]. Um status 'Failed' no horário de término marca este evento.

Captura

Registrado quando o pipeline de deploy em produção reporta um status de falha.

Tipo de evento explicit
Implantado em Produção
Marca a conclusão bem-sucedida do deploy em produção. Capturado quando a ferramenta de CI/CD reporta que o pipeline terminou com sucesso.
Por que é importante

Ponto final de sucesso do processo SDLC. Conclui o fluxo de valor e é vital para o cálculo do ciclo total.

Onde obter

Capturado do 'completion_status' de um registro de Pipeline Execution [sn_devops_pipeline_execution] ou de seu Stage Execution Run associado. Um status 'Success' no horário de término marca este evento.

Captura

Registrado quando o pipeline de deploy em produção é concluído com sucesso.

Tipo de evento explicit
Item de Desenvolvimento Criado
Marca a criação de um novo item (story, bug, epic) no ServiceNow. Geralmente capturado quando um novo registro é inserido em tabelas como Story [rm_story].
Por que é importante

Evento inicial do processo SDLC. Permite medir o tempo total de ciclo e rastrear a entrada da demanda.

Onde obter

Registrado nas tabelas sys_audit ou sys_history_line na criação de um registro em uma tabela de desenvolvimento, como Story [rm_story], Epic [rm_epic] ou Defect [rm_defect]. O timestamp de criação geralmente está no próprio registro.

Captura

Capturado a partir do timestamp de criação do registro do item de desenvolvimento.

Tipo de evento explicit
Revisão de Código Realizada
Indica a conclusão de um code review por pares, geralmente associado a um pull ou merge request. Pode ser capturado por integrações DevOps ou inferido por mudanças de status.
Por que é importante

Barreira de qualidade crítica. Analisar sua duração ajuda a achar gargalos no review, causa comum de atrasos no SDLC.

Onde obter

Pode ser capturado a partir do evento 'Merged' ou 'Completed' de um registro de Pull Request na integração Git do ServiceNow, ou inferido a partir de uma mudança de status no item de desenvolvimento para 'Code Review Complete'.

Captura

Registrado quando um Pull Request vinculado ao item de trabalho é mesclado.

Tipo de evento explicit
Testes de QA Concluídos
Indica que a equipe de Garantia de Qualidade concluiu os testes com sucesso. Geralmente inferido quando o estado do item sai da fase de testes para status como 'Ready for UAT' ou 'Done'.
Por que é importante

Conclusão de uma etapa de qualidade importante. Pré-requisito para UAT ou preparação de release.

Onde obter

Inferido a partir do timestamp de uma mudança de estado de um status de teste (ex: 'In QA') para um status pós-teste (ex: 'Ready for UAT' ou 'Resolved').

Captura

Baseado no timestamp de uma mudança de estado de 'Testing' para um estado subsequente.

Tipo de evento inferred
UAT Aprovado
Indica que as partes interessadas do negócio aprovaram formalmente o item de desenvolvimento após o Teste de Aceitação do Usuário. Este é um marco importante inferido de uma mudança de status, como a transição de 'Em UAT' para 'Pronto para Release' ou 'Aprovado'.
Por que é importante

Aprovação final de negócio antes do deploy em produção. Checkpoint crítico de qualidade e governança.

Onde obter

Inferido de uma transição de estado no registro do item de desenvolvimento que significa a conclusão bem-sucedida do UAT. Isso é registrado no histórico de atividades do item.

Captura

Inferido de uma mudança de estado de 'UAT' para um estado aprovado ou pronto para release.

Tipo de evento inferred
Build Acionado
Sinaliza o início do build no pipeline CI/CD, geralmente disparado por um commit. O ServiceNow DevOps registra isso como uma execução de pipeline vinculada aos itens de origem.
Por que é importante

Atividade que une o desenvolvimento aos testes automatizados ou deploy. Analisar o tempo entre commit e o início do build revela atrasos no processo de CI/CD.

Onde obter

Registrado explicitamente na tabela Pipeline Execution [sn_devops_pipeline_execution] quando um build inicia na ferramenta CI/CD integrada (ex: Jenkins, Azure DevOps).

Captura

Capturado a partir do horário de início de um registro na tabela Pipeline Execution.

Tipo de evento explicit
Código Comitado
Representa um desenvolvedor fazendo o commit de código em um repositório vinculado ao item de desenvolvimento. O ServiceNow DevOps captura esses eventos de ferramentas SCM integradas, como Git ou GitHub.
Por que é importante

Rastrear commits dá visibilidade granular do progresso e frequência, correlacionando mudanças de código ao item pai.

Onde obter

Capturado como um evento explícito na tabela ServiceNow DevOps Commits [sn_devops_commit], que é alimentada por webhooks do sistema de gerenciamento de código-fonte integrado.

Captura

Registrado quando um webhook de commit é recebido da ferramenta SCM.

Tipo de evento explicit
Design Iniciado
Representa a fase de criação do design técnico ou arquitetura da solução. Geralmente inferido por uma mudança no campo de status ou estado do item para valores como 'Design' ou 'Solutioning'.
Por que é importante

Analisar a duração da fase de design ajuda a identificar gargalos na tradução de requisitos e no planejamento da solução antes do início do desenvolvimento.

Onde obter

Inferido a partir das transições de estado no registro do item de desenvolvimento (ex: Story [rm_story]). Procure por mudanças no campo 'State' ou em um campo personalizado 'Stage' para um valor relacionado ao design.

Captura

Inferido de uma mudança de status para 'Design' ou estado similar.

Tipo de evento inferred
Implantação em Produção Iniciada
Marca o início do pipeline de deploy para o ambiente de produção. O ServiceNow DevOps captura isso quando o estágio de produção de um pipeline CI/CD começa a ser executado.
Por que é importante

Início da fase final e crítica. Rastrear isso ajuda a analisar durações de deploy e achar chances de automação.

Onde obter

Registrado explicitamente na tabela Stage Execution Run [sn_devops_stage_execution], filtrado para estágios relacionados ao ambiente de produção.

Captura

Capturado a partir do horário de início de uma etapa de implantação em produção em um Pipeline Execution.

Tipo de evento explicit
Item de Desenvolvimento Cancelado
Representa o encerramento de um item antes da conclusão. É um estado final alternativo, geralmente inferido quando o estado do item é definido como 'Cancelled' ou 'Closed Incomplete'.
Por que é importante

Rastrear cancelamentos ajuda a ver esforços perdidos e entender mudanças de escopo, dando uma visão completa dos desfechos do processo.

Onde obter

Inferido a partir do timestamp de quando o campo 'State' no registro do item de desenvolvimento é atualizado para um status terminal e não concluído, como 'Cancelled'.

Captura

Inferido de uma mudança de estado para 'Cancelado' ou estado terminal equivalente.

Tipo de evento inferred
Preparado para Lançamento
Indica que o item passou por todos os critérios de qualidade e está em uma release específica. Inferido ao associar o item a um registro de Release ou mudança para 'Ready for Deployment'.
Por que é importante

Indica que o item está pronto técnica e funcionalmente. O tempo aqui pode ser fila aguardando a janela de deploy.

Onde obter

Inferido quando o campo 'State' muda para 'Ready for Release' ou ao rastrear quando o campo 'Release' no registro do item de desenvolvimento é preenchido ou atualizado.

Captura

Inferido de uma mudança de status ou associação com um registro de Release.

Tipo de evento inferred
Retrabalho Identificado
Indica que um problema foi encontrado durante o teste, exigindo que o item retorne ao desenvolvimento. Este evento é inferido ao observar um movimento de retrocesso no fluxo do processo, como uma mudança de status de 'Em QA' de volta para 'Em Andamento'.
Por que é importante

Rastrear o retrabalho é vital para achar falhas de qualidade. Alta frequência indica problemas no desenvolvimento ou nos requisitos.

Onde obter

Inferido a partir da análise do histórico do campo 'State' nas tabelas sys_audit ou sys_history_line. Uma mudança de um status de estágio avançado (ex: 'Testing') para um anterior (ex: 'In Progress') indica retrabalho.

Captura

Inferido de uma transição de status de retrocesso, ex: 'Testing' -> 'In Progress'.

Tipo de evento inferred
Testes de QA Iniciados
Marca o início da fase formal de testes de Garantia de Qualidade. Isso quase sempre é inferido pela mudança do estado do item de desenvolvimento para valores como 'In QA', 'Testing' ou 'Ready for Test'.
Por que é importante

Sinaliza o handoff do desenvolvimento para a equipe de QA. Permite medir a duração da fase de testes e identificar gargalos de capacidade.

Onde obter

Inferido a partir do timestamp de quando o campo 'State' no registro do item de desenvolvimento (ex: Story, Defect) é atualizado para um status específico de QA.

Captura

Baseado no timestamp de uma mudança de estado para 'Testing' ou equivalente.

Tipo de evento inferred
UAT Iniciado
Representa o início do Teste de Aceitação do Usuário (UAT), onde stakeholders validam a funcionalidade. Capturado ao inferir uma mudança de status para 'UAT', 'In UAT' ou 'User Acceptance Testing'.
Por que é importante

Fase crítica para garantir que a feature atende ao negócio. Analisar sua duração revela falhas de engajamento ou de requisitos.

Onde obter

Inferido de uma transição de estado no registro do item de desenvolvimento. Isso depende do modelo de estados do cliente, que deve incluir um status distinto para UAT.

Captura

Inferido de uma mudança de estado para status 'UAT'.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do ServiceNow DevOps