Template de dados para o Ciclo de Vida de Desenvolvimento de Software (SDLC)
Template de dados para o Ciclo de Vida de Desenvolvimento de Software (SDLC)
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Orientação para Extração
Atributos do Ciclo de Vida de Desenvolvimento
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
Activity
|
O nome da etapa ou evento, como 'Issue Criada' ou 'Merge Request Mesclado'. | ||
|
Descrição
O atributo Atividade registra eventos reais do item (criação de issue, push, falha de pipeline, aprovação de MR). No GitLab, esses dados vêm de diferentes ações e campos de tempo. Ele é a base para montar o mapa de processo, ver o workflow e analisar sequências. Serve para achar desvios, gargalos e os caminhos mais comuns.
Por que é importante
Define as etapas no mapa de processo, permitindo a visualização e análise do workflow de desenvolvimento de ponta a ponta.
Onde obter
Derivado de tipos de eventos e mudanças de estado no fluxo do GitLab, ou interpretando campos de timestamp como 'created_at', 'merged_at' e 'closed_at' em Issues e Merge Requests.
Exemplos
Problema CriadoDesenvolvimento IniciadoMerge Request mescladoPipeline falhouImplantado em Produção
|
|||
|
Hora de Início
StartTime
|
O timestamp que indica quando uma atividade ou evento começou. | ||
|
Descrição
O StartTime registra exatamente quando uma atividade ocorreu no GitLab via campos de timestamp. Ex: para 'Issue Created', usa-se o Este é o dado temporal base para o Process Mining. Ele serve para ordenar eventos, calcular durações, medir o tempo de ciclo e analisar a performance do processo ao longo do tempo.
Por que é importante
Oferece a ordem cronológica dos eventos, base para calcular métricas de tempo e entender o fluxo.
Onde obter
Extraído de vários campos de timestamp no GitLab, como 'created_at', 'updated_at', 'closed_at' em issues e 'merged_at' em merge requests.
Exemplos
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Item de Desenvolvimento
DevelopmentItem
|
O ID único da tarefa (feature, bug ou task), usado como identificador principal do caso. | ||
|
Descrição
O Item de Desenvolvimento é a unidade rastreável no SDLC (no GitLab, o IID da Issue). Ele une todas as ações, do início ao deploy, em um caso único. Isso permite medir o tempo de ciclo total, achar gargalos e ver se o processo é seguido à risca, revelando a eficiência da entrega.
Por que é importante
ID do caso: essencial para unir todos os eventos e rastrear o ciclo de vida completo de uma tarefa.
Onde obter
Geralmente o IID da Issue do GitLab (campo 'iid' na resposta da API).
Exemplos
1024512PRJ-2345
|
|||
|
End Time
EndTime
|
O timestamp que indica quando uma atividade ou evento foi concluído. | ||
|
Descrição
O EndTime (Horário de Término) registra a data e hora precisas em que uma atividade foi concluída. Para eventos atômicos no GitLab, como "Issue Criada", o EndTime é igual ao StartTime. Para atividades com duração, como "Revisão de Código", representa o momento da conclusão (ex: quando a aprovação final é dada). Este atributo é essencial para calcular a duração exata de cada atividade (Tempo de Processamento). Ele ajuda na análise detalhada de gargalos, diferenciando o tempo de trabalho ativo do tempo de espera entre as tarefas.
Por que é importante
Permite o cálculo de durações precisas das atividades (tempos de processamento), fundamental para identificar etapas ineficientes.
Onde obter
Para eventos atômicos, este valor é igual ao StartTime. Para atividades com duração, ele deve ser derivado localizando o evento de conclusão correspondente nos dados.
Exemplos
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Gravidade
Severity
|
O nível de severidade, geralmente usado para bugs ou incidentes. | ||
|
Descrição
A severidade indica o impacto de um bug (de crítico a menor). Como o GitLab não tem esse campo nativo, costuma-se usar labels (ex: 'severity::1'). Este atributo é vital para o Dashboard de 'Tendências de Escalonamento' e seu KPI. Analisar mudanças na severidade revela problemas subestimados ou falhas no processo que agravam a situação.
Por que é importante
Auxilia na priorização e na análise de agilidade em itens de alta severidade. O acompanhamento de mudanças alimenta o KPI de 'Frequência de Escalonamento de Severidade'.
Onde obter
Derivado das 'labels' aplicadas a uma Issue do GitLab. É necessário um mapeamento para interpretar labels como 'S1', 'S2' como níveis de gravidade.
Exemplos
1 - Crítico2 - Alto3 - Médio4 - Baixo
|
|||
|
Nome do projeto
ProjectName
|
O nome do projeto no GitLab onde o item está. | ||
|
Descrição
Identifica o repositório ou projeto. No GitLab, toda issue/MR pertence a um projeto. Isso permite comparar a performance de diferentes serviços ou produtos, vendo quais projetos têm um SDLC mais saudável, além de facilitar filtros nos dashboards.
Por que é importante
Permite que a análise do processo seja segmentada por produto, aplicação ou componente, facilitando esforços de melhoria direcionados.
Onde obter
Obtido nos campos 'name' ou 'path_with_namespace' da API de Projetos, via 'project_id'.
Exemplos
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Responsável
Assignee
|
O usuário que era o responsável pela issue ou MR no momento do evento. | ||
|
Descrição
O Responsável (Assignee) é quem cuida do item em certa fase. No GitLab, fica nos campos Analisar por responsável é crucial para o Dashboard de 'Carga de Trabalho'. Ajuda a equilibrar recursos, achar times sobrecarregados e entender as passagens de bastão (handoffs).
Por que é importante
Registra quem executou o trabalho, permitindo a análise da carga de trabalho, eficiência na alocação de recursos e a identificação de atrasos causados por transferências entre equipes.
Onde obter
Obtido nos campos 'assignee.username' ou 'assignees' da API de Issues e Merge Requests do GitLab.
Exemplos
jdoeasmithr.williams
|
|||
|
Tipo do Item de Dev
DevelopmentItemType
|
Classificação do item: 'Feature', 'Bug', 'Tarefa' ou 'Manutenção'. | ||
|
Descrição
Categoriza o trabalho via labels (ex: 'Feature', 'Bug', 'Dívida Técnica'). Isso permite comparar o fluxo de cada tipo: bugs são resolvidos mais rápido que novas funções? Dívidas técnicas têm um processo de revisão diferente?
Por que é importante
Segmentar o processo por tipo de trabalho ajuda a ver quais categorias sofrem mais com atrasos, retrabalho ou desvios.
Onde obter
Geralmente derivado das 'labels' aplicadas a uma Issue do GitLab. É necessária uma lógica de mapeamento para converter labels específicas em tipos padronizados.
Exemplos
Funcionalidade (Feature)BugTarefaDívida técnica
|
|||
|
Branch de destino
TargetBranch
|
O nome da branch para onde o código será mesclado (merge request). | ||
|
Descrição
A Target Branch é o destino das mudanças (ex: 'main', 'develop'). É um dado chave do Merge Request. Analisar por branch revela como o processo muda conforme o destino: merges na 'main' podem ter aprovações mais lentas e rigorosas que em feature branches. Ajuda também a isolar o que é deploy real em produção.
Por que é importante
Ajuda a diferenciar diversos workflows de desenvolvimento e release, já que os processos mudam bastante dependendo da branch de destino.
Onde obter
Obtido no campo 'target_branch' da API de Merge Requests do GitLab.
Exemplos
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
É Retrabalho
IsRework
|
Um indicador booleano que sinaliza se uma atividade faz parte de um loop de retrabalho. | ||
|
Descrição
Sinaliza retrocessos, como voltar para desenvolvimento após iniciar os testes. A lógica detecta sequências como 'Development Started' vindo após 'Pipeline Failed'. Alimenta o Dashboard de 'Análise de Retrabalho' e o KPI de 'Taxa de Retrabalho'. Permite medir e entender a frequência e o impacto do retrabalho nos prazos.
Por que é importante
Sinaliza e quantifica diretamente o retrabalho, facilitando a análise das causas e do impacto das ineficiências e problemas de qualidade.
Onde obter
Calculado pela ferramenta de Process Mining analisando a sequência de atividades de cada caso e identificando padrões que indicam retrabalho.
Exemplos
verdadeirofalse
|
|||
|
Nome da Equipe
TeamName
|
A equipe de desenvolvimento ligada ao projeto ou responsável. | ||
|
Descrição
Nome da Equipe indica a squad responsável pelo item. Geralmente não é nativo do GitLab, sendo extraído via nomes de projetos, grupos ou tabelas externas de mapeamento. Este dado permite analisar a performance por equipe, comparar eficiência, carga de trabalho e conformidade, alimentando dashboards como a 'Análise de Gargalos por Estágio' sob a ótica de times.
Por que é importante
Permite a análise de desempenho e a comparação de processos entre diferentes equipes, ajudando a identificar gargalos específicos ou melhores práticas de cada time.
Onde obter
Geralmente obtido mapeando o nome do projeto ou o responsável para uma estrutura de equipe externa ou via hierarquia de grupos do GitLab.
Exemplos
Frontend-AlphaServiços-BackendPlatform-Infra
|
|||
|
Sistema de Origem
SourceSystem
|
Identifica o sistema de origem dos dados. | ||
|
Descrição
Indica a fonte dos dados (neste caso, 'GitLab'). Crucial se você combina dados de vários sistemas (ex: Jira para planos e GitLab para execução). Facilita o filtro, a segmentação e mantém o histórico de origem.
Por que é importante
Garante clareza sobre a origem dos dados, o que é fundamental para a governança de dados e integração de múltiplos sistemas corporativos.
Onde obter
Valor fixo 'GitLab', inserido na etapa de transformação dos dados.
Exemplos
GitLab
|
|||
|
Status do Item de Dev
DevelopmentItemStatus
|
O estado do item no momento do evento: 'Open', 'In Progress' ou 'Closed'. | ||
|
Descrição
Estado da Issue no GitLab ( Monitorar as mudanças é vital para entender o ciclo. Ajuda a ver quanto tempo as tarefas param em cada fase e permite filtrar trabalhos ativos no dashboard de 'Cycle Time'.
Por que é importante
Fornece um panorama do estado do caso, permitindo analisar o tempo gasto em cada fase e filtrar o que está em andamento ou concluído.
Onde obter
O status principal vem do campo 'state' ('opened', 'closed'). Status mais detalhados costumam vir das labels.
Exemplos
openedfechadoEm ProgressoEm Revisão
|
|||
|
Status do Merge Request
MergeRequestStatus
|
O status do merge request: 'Opened', 'Merged' ou 'Closed'. | ||
|
Descrição
Registra o estado do MR ('opened', 'closed', 'merged', 'locked'). É diferente do status geral do item. Monitorar isso é vital para analisar a fase de integração e alimenta Dashboards de 'Cycle Time de Revisão', mostrando atrasos entre criação, aprovação e mesclagem.
Por que é importante
Dá visibilidade à revisão e mesclagem de código, que costumam ser gargalos críticos no SDLC.
Onde obter
Obtido no campo 'state' da API de Merge Requests do GitLab.
Exemplos
openedmergedfechadolocked
|
|||
|
Status do pipeline
PipelineStatus
|
O status da rodada do pipeline: 'Success', 'Failed' ou 'Running'. | ||
|
Descrição
Indica o resultado do pipeline ('success', 'failed', etc.). Fundamental para a 'Análise de Retrabalho'. Falhas constantes atrasam o time; entender onde elas ocorrem ajuda a melhorar a eficiência e a qualidade do código.
Por que é importante
Monitora o sucesso e as falhas de builds e testes automatizados, destacando loops de retrabalho e problemas na qualidade do código ou na automação de testes.
Onde obter
Obtido no campo 'status' da API de Pipelines de CI/CD do GitLab.
Exemplos
successfalhourunningcancelado
|
|||
|
Tempo de Ciclo
CycleTime
|
O tempo total entre o início e a conclusão do item. | ||
|
Descrição
O Tempo de Ciclo (Cycle Time) é uma métrica calculada que mede a duração total de um caso. Geralmente é a diferença de tempo entre o primeiro evento (ex: "Issue Criada") e o último (ex: "Implantado em Produção") para um Item de Desenvolvimento. Este é o principal KPI para medir a eficiência global do processo. É a métrica central em dashboards como "Tempo de Ciclo SDLC Ponta a Ponta", servindo para monitorar melhorias e identificar casos muito longos que podem indicar falhas sistêmicas.
Por que é importante
KPI central de Process Mining que mede a eficiência total do ciclo de desenvolvimento.
Onde obter
Calculado pela ferramenta de Process Mining subtraindo o StartTime mínimo do StartTime máximo para cada CaseId exclusivo.
Exemplos
10 days 4 hours23 horas e 15 minutos35 dias
|
|||
|
Tempo de Espera em Handoff
HandoffWaitTime
|
Tempo de inatividade calculado entre duas atividades consecutivas realizadas por responsáveis diferentes. | ||
|
Descrição
Mede o intervalo entre atividades quando o responsável muda (ex: fim do dev até o início da revisão). Dado principal do KPI 'Tempo Médio de Espera no Handoff'. Expõe falhas de comunicação e alocação, focando em atrasos onde ninguém está agindo.
Por que é importante
Quantifica o tempo ocioso em passagens de bastão (handoffs) entre pessoas ou times, revelando atrasos e falhas de comunicação.
Onde obter
Calculado pela ferramenta de Process Mining. Requer a análise de eventos consecutivos em um caso, verificando se o Responsável (Assignee) mudou e calculando a diferença de tempo.
Exemplos
1 dia e 2 horas15 minutos8 horas
|
|||
|
Tempo de Processamento
ProcessingTime
|
A duração de uma única atividade, calculada como a diferença entre o horário de término e de início. | ||
|
Descrição
O tempo de processamento mede o trabalho ativo em uma atividade, diferindo do tempo de espera entre elas. É o cálculo de EndTime menos StartTime de um evento. Para eventos instantâneos, o valor é zero. Essa métrica é vital para analisar gargalos em estágios específicos. Ao somar os tempos de processamento de um estágio, como Revisão de Código, os analistas descobrem quanto tempo é realmente dedicado à tarefa, expondo etapas ineficientes.
Por que é importante
Mede a duração de cada atividade, ajudando a separar o tempo de trabalho ativo do tempo de espera para uma análise de gargalos precisa.
Onde obter
Calculado pela ferramenta de Process Mining como a diferença entre o Horário de Término (EndTime) e o Horário de Início (StartTime) de uma atividade.
Exemplos
2 horas e 30 minutos0 minutos3 dias e 8 horas
|
|||
|
Título do Milestone
MilestoneTitle
|
O nome do milestone ou sprint onde o item está alocado. | ||
|
Descrição
Um Milestone (Marco) no GitLab é usado para rastrear o trabalho em relação a um objetivo específico ou período (timebox), como um sprint ou uma versão de lançamento. Este atributo captura o nome ou título desse marco. Ele permite analisar o desempenho do processo no contexto de sprints ou períodos de planejamento específicos. Pode ser usado para verificar se os tempos de ciclo estão melhorando de um sprint para outro ou para filtrar a visão do processo e mostrar apenas o trabalho relacionado a um lançamento futuro.
Por que é importante
Conecta o desenvolvimento aos ciclos de planejamento (sprints ou releases), permitindo analisar o desempenho em relação aos prazos planejados.
Onde obter
Obtido no campo 'milestone.title' da API de Issues ou Merge Requests do GitLab.
Exemplos
Release Q4-2023Sprint 23.11Fase 1: MVP
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O carimbo de data/hora que indica quando os dados para este evento foram atualizados pela última vez no sistema de origem. | ||
|
Descrição
Data e hora da última extração ou atualização dos dados, não do evento em si. Essencial para saber se os dados estão atualizados. Isso dá segurança ao usuário de que os KPIs refletem o cenário atual e mostra o intervalo entre o GitLab e a análise.
Por que é importante
Garante transparência sobre a atualização dos dados, para que os usuários saibam quão recente é a análise.
Onde obter
Timestamp gerado pela ferramenta de extração ou ETL na hora da atualização dos dados.
Exemplos
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Versão da release
ReleaseVersion
|
A tag da versão de software (planejada ou real) usada no deploy. | ||
|
Descrição
Identifica a release do software (via Milestone ou Tag). Vital para o dashboard de 'Adesão ao Cronograma'. Ao comparar o deploy real com a data planejada, a empresa mede sua pontualidade e entende os motivos de possíveis atrasos.
Por que é importante
Conecta itens de desenvolvimento a um release específico, o que é fundamental para rastrear o progresso e o cumprimento do cronograma de lançamento.
Onde obter
Pode vir do GitLab Releases, do nome de uma git tag ou de um milestone de planejamento.
Exemplos
v1.2.0v3.0.0-beta2023.4.1
|
|||
Atividades do Ciclo de Vida de Desenvolvimento
| Atividade | Descrição | ||
|---|---|---|---|
|
Implantado em Produção
|
Implantação real em produção para o usuário final. Ocorre quando o job de 'deploy to production' do pipeline termina com sucesso. | ||
|
Por que é importante
Evento final: entrega de valor. Essencial para medir o tempo total do SDLC e a frequência de lançamentos.
Onde obter
Capturado do timestamp 'finished_at' de um job de CI/CD bem-sucedido designado para deploy em produção. O recurso de Ambientes do GitLab rastreia isso explicitamente.
Captura
Use o registro de data e hora 'finished_at' do job de CI de implantação em produção bem-sucedido.
Tipo de evento
explicit
|
|||
|
Merge Request criado
|
Indica que o desenvolvimento inicial está concluído e o código está pronto para revisão e integração. Este é um evento central explícito no workflow do GitLab, capturado quando um novo merge request (MR) é aberto. | ||
|
Por que é importante
Marco crítico: passagem de desenvolvimento para revisão/teste. É o ponto de partida para analisar o ciclo de revisão e o pipeline.
Onde obter
Evento explícito do timestamp 'created_at' na tabela de merge requests ou via API.
Captura
Use o registro de data e hora 'created_at' do merge request.
Tipo de evento
explicit
|
|||
|
Merge Request mesclado
|
Fim da revisão e integração. Evento explícito quando o MR é mesclado na branch de destino. | ||
|
Por que é importante
Marco importante: desenvolvimento e revisão concluídos. Finaliza a métrica de cycle time e inicia o lead time de deploy.
Onde obter
Evento explícito do timestamp 'merged_at' na tabela de merge requests.
Captura
Use o registro de data e hora 'merged_at' do merge request.
Tipo de evento
explicit
|
|||
|
Problema Criado
|
Início do ciclo: criação de uma nova tarefa (feature, bug ou task). Registrado no GitLab com o timestamp de criação da issue. | ||
|
Por que é importante
Evento inicial: permite ver o tempo total desde a criação da issue até o deploy (cycle time do SDLC).
Onde obter
Evento explícito do timestamp 'created_at' na tabela de issues ou via API.
Captura
Use o registro de data e hora 'created_at' da issue.
Tipo de evento
explicit
|
|||
|
Aprovação Adicionada
|
Representa a aprovação formal das mudanças de código por um revisor. Evento capturado explicitamente quando o botão 'Approve' é clicado no GitLab. | ||
|
Por que é importante
As aprovações são etapas críticas de qualidade (quality gates). Rastreá-las ajuda a analisar o tempo necessário para obter as validações exigidas e garante a conformidade com as políticas de revisão.
Onde obter
Capturado de eventos de aprovação de merge request. Estão disponíveis via API de Aprovações ou no histórico do MR.
Captura
Use o registro de data e hora do log de eventos de aprovação do merge request.
Tipo de evento
explicit
|
|||
|
Desenvolvimento Iniciado
|
Início da codificação ativa. Como não há um botão 'iniciar' no GitLab, identificamos pelo primeiro commit enviado para a branch vinculada. | ||
|
Por que é importante
Marca o início exato do trabalho de desenvolvimento que gera valor, permitindo medir a fase de codificação pura e separá-la do planejamento ou espera.
Onde obter
Identificado ao localizar o timestamp do primeiro commit em uma feature branch vinculada à issue. Exige que issues e branches estejam conectados, geralmente por convenção de nomes ou metadados.
Captura
Localize o timestamp do primeiro commit em uma branch vinculada ao ID do problema (issue ID).
Tipo de evento
inferred
|
|||
|
Implantação Iniciada
|
Marca o início da implantação do código em ambientes como staging ou produção. No GitLab, equivale ao início de um job de 'deploy' no pipeline. | ||
|
Por que é importante
Marcar o início do deploy ajuda a isolar quanto tempo essa fase leva, sendo vital para otimizar o lead time de entrega.
Onde obter
Capturado do timestamp 'started_at' de um job de CI/CD configurado como job de implantação. Faz parte do recurso de Ambientes e Implantações do GitLab.
Captura
Use o registro de data e hora 'started_at' do log do job de CI para uma tarefa de implantação.
Tipo de evento
explicit
|
|||
|
Pipeline falhou
|
Falha no pipeline (erro de build, teste, etc.). O GitLab salva o status final de cada rodada, facilitando a detecção. | ||
|
Por que é importante
Falhas no pipeline são grandes causas de retrabalho. Analisar sua frequência e motivos ajuda a detectar problemas de qualidade, testes instáveis e gargalos no feedback para o time.
Onde obter
Identificado pelo status 'failed' em um registro de pipeline na tabela 'ci_pipelines'. O timestamp 'finished_at' indica quando a falha ocorreu.
Captura
Filtre registros de pipeline com o status 'failed' e utilize o timestamp 'finished_at'.
Tipo de evento
explicit
|
|||
|
Pipeline iniciado
|
Início de um pipeline automatizado de CI/CD (builds, testes, etc.). O GitLab gera um registro com timestamp toda vez que o pipeline é disparado por um commit ou MR. | ||
|
Por que é importante
Acompanhar pipelines é essencial para ver a saúde dos testes e integração. Mostra quanto tempo se gasta em validações automáticas.
Onde obter
Capturado do timestamp 'created_at' ou 'started_at' de um registro de pipeline na tabela 'ci_pipelines' ou via API de Pipelines.
Captura
Use o registro de data e hora do registro de execução do pipeline associado à branch do MR.
Tipo de evento
explicit
|
|||
|
Problema Atribuído
|
Representa a entrega de uma issue a um desenvolvedor ou time. É um evento explícito registrado sempre que o campo de responsável (assignee) é preenchido ou alterado. | ||
|
Por que é importante
Monitorar atribuições é vital para gerir recursos e carga de trabalho. Ajuda a ver o tempo que uma tarefa leva para ser iniciada após criada.
Onde obter
Capturado das notas de sistema do GitLab para a issue, que registram quando um responsável (assignee) é adicionado ou alterado. O timestamp do evento fica registrado na nota.
Captura
Extraia eventos de "responsável alterado" das notas de sistema da issue.
Tipo de evento
explicit
|
|||
|
Problema Encerrado
|
Representa o encerramento administrativo do item, após deploy e verificação. Capturado quando a issue é fechada no GitLab. | ||
|
Por que é importante
Fechar uma issue geralmente marca o fim de todo o trabalho relacionado. Comparar isso com o tempo de deploy pode revelar atrasos na validação pós-implantação ou processos administrativos.
Onde obter
Evento explícito do timestamp 'closed_at' na tabela de issues ou de notas do sistema.
Captura
Use o registro de data e hora 'closed_at' da issue.
Tipo de evento
explicit
|
|||
|
Revisão de Código Iniciada
|
Marca o início da revisão por pares de um merge request. Este evento é identificado pela primeira ação de revisão, como o primeiro comentário feito por terceiros. | ||
|
Por que é importante
Medir o tempo entre a criação do MR e o início da revisão evidencia atrasos em fila. Reduzir essa espera é vital para agilizar o ciclo total de revisão.
Onde obter
Identificado pelo timestamp do primeiro comentário ou thread de revisão no merge request feito por alguém que não seja o autor. Disponível via system notes ou Notes API.
Captura
Encontre o timestamp do primeiro comentário de usuário em um MR que não tenha sido feito pelo autor.
Tipo de evento
inferred
|
|||