Glossário de métricas de engenharia e agile
Os termos que equipes de engenharia usam para planejar, estimar, medir e melhorar — definidos em linguagem simples, com leitura aprofundada vinculada onde existe em nossos cursos gratuitos e blog.
34 termos · 6 seções · Publicado em julho de 2026
Entrega e Fluxo
7 termosTempo de ciclo
Tempo de ciclo é o tempo desde quando o trabalho começa em um item até que esse trabalho seja finalizado: o cronômetro inicia quando alguém começa o item e para quando ele está completo. Ele mede a eficiência interna da equipe, e sua variação importa tanto quanto sua média. Uma equipe cujos itens variam de 3 a 5 dias é muito mais previsível do que uma que varia de 1 a 30.
Lead time
Lead time é o tempo total desde quando o trabalho é solicitado até ser entregue ao cliente. Ele equivale ao tempo de ciclo mais o tempo de fila, e as filas frequentemente representam 80% ou mais dele. Lead time é o que os clientes experimentam; tempo de ciclo é o que a equipe controla diretamente. Ambos importam, e equipes que veem apenas o tempo de ciclo subestimam drasticamente quanto tempo a entrega realmente leva.
Throughput
Throughput é o número de itens de trabalho que uma equipe completa por unidade de tempo, como oito funcionalidades por sprint. Ele mede a taxa de saída e capacidade de um sistema de entrega. Diferente da velocidade, throughput conta itens finalizados em vez de pontos estimados, o que o torna uma quantidade medida em vez de estimada.
Mais: Throughput e Envelhecimento de Itens de Trabalho (Fundamentos do Kanban)
Limite de WIP
Um limite de WIP é um teto sobre quantos itens de trabalho uma equipe permite em progresso ao mesmo tempo. É a prática kanban mais contraintuitiva: ao fazer menos de uma vez, você finaliza mais no geral, porque a Lei de Little vincula o lead time diretamente à quantidade de trabalho no sistema. Limites de WIP são experimentos, não cálculos; comece em algum lugar e ajuste.
Lei de Little
A Lei de Little é uma relação da teoria de filas, provada por John Little em 1961, afirmando que lead time é igual ao trabalho em progresso dividido pelo throughput. Para qualquer sistema estável, reduzir WIP encurta o lead time sem que ninguém trabalhe mais rápido. Uma equipe finalizando 10 itens por semana com 40 em progresso tem média de 4 semanas por item; limitar WIP a 20 reduz isso pela metade para 2.
Mais: Lei de Little: A Matemática do Fluxo (Fundamentos do Kanban)
Bloqueio
Um bloqueio é qualquer coisa que impede um item de trabalho ou uma pessoa de progredir: uma dependência de outra equipe, uma falha técnica, requisitos pouco claros, recursos ausentes ou um fornecedor externo. Bloqueios que não são mencionados ou pouco discutidos estão entre os maiores assassinos de metas de sprint, e é por isso que trazê-los à tona é a parte mais valiosa de qualquer standup.
Débito técnico
Débito técnico é o custo acumulado de tomar atalhos no código, cada "vou limpar isso depois" que nunca acontece. Como dívida financeira, ele acumula juros: código bagunçado leva mais tempo para mudar, esconde bugs e desacelera novos membros da equipe. Refatoração contínua é como as equipes pagam o débito antes que ele se transforme em uma base de código impraticável.
Estimativa e Planejamento
4 termosStory points
Story points são uma unidade de estimativa relativa que combina esforço, complexidade e incerteza em vez de tempo. Uma história de 5 pontos é aproximadamente o dobro do esforço de uma história de 2 pontos, mas não necessariamente o dobro das horas. Escalas comuns incluem Fibonacci (1, 2, 3, 5, 8, 13), potências de 2 e tamanhos de camiseta, onde as lacunas entre os valores forçam uma escolha genuína.
Velocidade
Velocidade é o número de story points que uma equipe completa por sprint, usado para transformar estimativas relativas em previsões. A lógica é "o tempo de ontem": uma equipe que teve média de 25 pontos provavelmente completará cerca de 25 no próximo sprint. Velocidade é uma ferramenta de planejamento, não uma métrica de produtividade; defina metas sobre ela e as equipes simplesmente inflarão suas estimativas.
Planning poker
Planning poker é uma técnica de estimativa na qual todos estimam um item de trabalho de forma privada e revelam ao mesmo tempo, o que elimina a ancoragem no primeiro número falado. A dispersão é o sinal: um 3 unânime significa entendimento compartilhado e você segue em frente, enquanto uma divisão entre 2 e 13 significa que duas pessoas estão imaginando trabalhos fundamentalmente diferentes.
Mais: A Estimativa Mínima Útil (Fundamentos de Entrega de Software)
Sprint
Um sprint é uma iteração de duração fixa de um mês ou menos que serve como o batimento cardíaco do scrum e contém todos os outros eventos do scrum. Sprints acontecem consecutivamente sem intervalos, cada um carrega uma meta de sprint que fornece foco, e cada um deve terminar com um incremento potencialmente entregável. A duração consistente do sprint constrói ritmo e previsibilidade.
Cerimônias
5 termosRetrospectiva
Uma retrospectiva é uma reunião recorrente da equipe que examina como a equipe trabalhou junta durante o último sprint e produz um plano de melhoria. Os participantes são apenas a equipe, sem stakeholders, e o resultado é um pequeno conjunto de melhorias acionáveis. É o coração da melhoria contínua: pule-a e a equipe para de melhorar.
Standup (daily scrum)
Um standup, chamado de daily scrum no scrum, é um evento diário de 15 minutos onde os desenvolvedores inspecionam o progresso em direção à meta do sprint e adaptam o plano para o dia. É coordenação, não relatório de status: o resultado é um plano atualizado, e bloqueios surgem aqui mas são resolvidos depois, não durante a reunião.
Standup assíncrono
Um standup assíncrono é um standup que acontece sem uma reunião síncrona: atualizações são geradas automaticamente a partir de atividades já registradas em ferramentas como Jira, Linear, GitHub e GitLab, ou enviadas por escrito no próprio horário de cada pessoa. A premissa é simples: se o trabalho já está registrado em algum lugar, humanos não deveriam ter que recitá-lo.
Item de ação
Um item de ação é um compromisso específico e atribuído de mudar algo, tipicamente produzido por uma retrospectiva. A maioria morre silenciosamente: uma pesquisa da comunidade PMI descobriu que quase dois terços das equipes implementam menos de 25% dos seus itens de ação de retrospectiva. Cada item abandonado é uma pequena promessa quebrada, e promessas quebradas suficientes ensinam uma equipe a parar de levantar questões.
Segurança psicológica
Segurança psicológica é a crença de que você pode se manifestar com perguntas, preocupações, erros ou discordâncias sem punição ou humilhação. Não se trata de ser gentil; trata-se de permitir franqueza. O Projeto Aristotle do Google descobriu que a segurança psicológica era o principal preditor de equipes de alto desempenho, mais importante que o talento individual.
Mais: Criando Segurança Psicológica (Fundamentos do Scrum Master)
Medição e Métricas
10 termosMétricas DORA
Métricas DORA são quatro medidas de desempenho de entrega de software: frequência de deployment, lead time para mudanças, taxa de falha de mudanças e tempo médio para restaurar. Elas vêm do programa DevOps Research and Assessment por trás da pesquisa Accelerate e dos relatórios anuais State of DevOps, que consistentemente descobrem que performers de elite entregam mais rápido com menos falhas. Medidas isoladamente, são instrumentação em vez de insight.
Frequência de deployment
Frequência de deployment é a métrica DORA que mede com que frequência uma equipe envia código para produção. Pode ser calculada automaticamente a partir de pipelines de CI/CD como GitHub Actions, GitLab CI/CD e Bitbucket Pipelines. Além do número bruto, é evidência de throughput real: uma equipe fazendo deployment frequentemente com qualidade estável está demonstrando entrega, não apenas fechando tickets.
Tempo de entrega de mudanças
O tempo de entrega de mudanças é a métrica DORA que mede quanto tempo o código leva para ir do commit até estar rodando em produção. Tempos de entrega longos geralmente têm origem em WIP alto, tamanhos de lote grandes ou gargalos de revisão, e não em codificação lenta, então essa métrica é melhor interpretada junto com os sinais de fluxo já presentes nos seus dados de gerenciamento de projetos.
Taxa de falha de mudanças
A taxa de falha de mudanças é a métrica DORA que mede a porcentagem de deploys em produção que causam uma falha que precisa de remediação. É um sinal de qualidade: picos frequentemente se correlacionam com cronogramas apressados, novos contribuidores ou mudanças de infraestrutura, por isso o número é mais útil quando conectado ao contexto do sprint que o explica.
Tempo médio de restauração (MTTR)
O tempo médio de restauração, ou MTTR, é a métrica DORA que mede quanto tempo leva para recuperar o serviço após uma falha em produção. Recuperação rápida sinaliza resposta forte a incidentes e familiaridade profunda com a base de código, por isso o MTTR funciona como um sinal de ownership e operações, e não como um número puro de velocidade.
Efetividade de desenvolvedores
A efetividade de desenvolvedores é uma medida de se o trabalho de um engenheiro cria resultados duráveis, não de quanta atividade ele gera. O Simyl Flow pontua isso em seis dimensões: Entrega, Fluxo, Qualidade, Colaboração, Ownership e Adaptabilidade. A pontuação multidimensional resiste a manipulação, e a medição permanece orientada a resultados: sem rastreamento de teclas digitadas, sem vigilância de uso de ferramentas, e perfis individuais são privados por padrão.
Produtividade de desenvolvedores vs. efetividade de desenvolvedores
Produtividade de desenvolvedores e efetividade de desenvolvedores são medidas diferentes: produtividade conta atividade (commits, linhas de código, tickets fechados) enquanto efetividade mede resultados, se o trabalho entregue criou valor durável. A distinção importa porque métricas de atividade convidam vigilância e manipulação, enquanto efetividade infere a partir de resultados em vez de rastrear uso de ferramentas e favorece coaching em vez de julgamento.
Pontuação de saúde
Uma pontuação de saúde é uma classificação de 0 a 100, com notas de A a F, que resume a saúde do sprint de um equipe nas seis dimensões de efetividade. Seu trabalho é fechar o ciclo de melhoria: depois que uma retrospectiva muda como o equipe trabalha, a tendência da pontuação de saúde mostra se essa mudança realmente fez diferença.
Lei de Goodhart
A lei de Goodhart é a observação, nomeada em homenagem ao economista britânico Charles Goodhart, de que "quando uma medida se torna uma meta, ela deixa de ser uma boa medida." Na engenharia, isso aparece como manipulação de métricas: defina velocity como meta e as estimativas inflam; defina stories fechadas como meta e o trabalho é marcado como concluído antes de estar realmente pronto. O dashboard fica verde enquanto a entrega sofre.
Métricas de vaidade
Métricas de vaidade são números que aumentam sem correlação com resultados de negócio: commits por dia, linhas de código, story points concluídos, PRs mesclados. São tentadoras porque são fáceis de coletar e geram gráficos satisfatórios, mas criam incentivos perversos e uma ilusão de visibilidade. O teste: se esse número dobrar, o valor de negócio dobra?
Métodos
5 termosScrum
Scrum é um framework ágil leve para desenvolver produtos complexos, fundamentado no empirismo: transparência, inspeção e adaptação. Define três papéis (product owner, scrum master, desenvolvedores), cinco eventos incluindo o sprint e a retrospectiva, e três artefatos. O Guia do Scrum tem apenas 13 páginas porque o scrum é intencionalmente incompleto: um framework com diretrizes, não uma metodologia passo a passo.
Kanban
Kanban é um método adaptativo para gerenciar trabalho de conhecimento que visualiza o fluxo de trabalho, limita o trabalho em andamento e evolui o processo de forma incremental. Sua filosofia é "comece de onde você está": sem papéis prescritos, sem eventos obrigatórios, sem iterações fixas. Surgiu do Sistema Toyota de Produção e foi adaptado para software por David J. Anderson nos anos 2000.
Extreme Programming (XP)
Extreme Programming (XP) é uma metodologia ágil, estabelecida pelo livro de Kent Beck de 1999 Extreme Programming Explained, que é prescritiva sobre práticas de engenharia onde o scrum permanece silencioso: escreva testes primeiro, programe em par, refatore continuamente e integre várias vezes ao dia. Seus cinco valores são comunicação, simplicidade, feedback, coragem e respeito.
Programação em par
Programação em par é quando dois desenvolvedores trabalham juntos em uma estação de trabalho: um digita (o driver) enquanto o outro observa, pensa adiante e navega. Pesquisas citadas na literatura de XP mostram que pares produzem código com aproximadamente 15% menos defeitos enquanto levam apenas cerca de 15% mais tempo, efetivamente revisão contínua de código mais disseminação de conhecimento pela equipe.
Desenvolvimento orientado a testes (TDD)
Desenvolvimento orientado a testes (TDD) é a prática de escrever um teste que falha antes de escrever código de produção, repetido em um ciclo vermelho-verde-refatorar: escreva um teste que falha, escreva o código mínimo para fazê-lo passar, depois limpe enquanto os testes permanecem verdes. TDD é uma técnica de design disfarçada de técnica de teste; o pensamento que produz os testes é o ponto principal.
Mais: Desenvolvimento Orientado a Testes (Fundamentos do XP)
IA e Ferramentas
3 termosMCP (Model Context Protocol)
MCP, o Model Context Protocol, é um protocolo aberto que permite que assistentes de IA como Claude e ChatGPT se conectem diretamente a ferramentas e fontes de dados externas. O Simyl Flow expõe 17 ferramentas MCP somente leitura em 8 domínios, cobrindo standups, retrospectivas, métricas e itens de ação, para que os assistentes de IA que uma equipe adota possam consultar se estão realmente ajudando.
Exaustão de fluxo de trabalho
Exaustão de fluxo de trabalho são os dados estruturados que suas ferramentas existentes já emitem como efeito colateral do trabalho normal: histórico de commits, revisões de PR, transições de tickets e execuções de pipeline de CI/CD. O princípio por trás do termo: os dados necessários para medir a entrega já existem; o problema nunca foi a disponibilidade, mas sim que eles ficavam em silos desconectados do contexto que os torna significativos.
Entregar e manter
Entregar e manter é um enquadramento de medição que faz duas perguntas sobre qualquer mudança na forma como uma equipe trabalha, seja uma nova ferramenta, processo ou assistente de IA: o trabalho foi entregue e continuou criando valor em produção? Seus sinais vitais incluem taxa de retrabalho (reverts e hotfixes), trajetória de qualidade ao longo do tempo e previsibilidade da entrega, lidos em conjunto em vez de isoladamente.
Definições são a parte fácil
Saber o que cycle time significa não é o mesmo que conhecer o seu. O Simyl Flow calcula essas métricas a partir das ferramentas que sua equipe já usa e mostra se suas mudanças estão funcionando.