Medir o sistema de entrega

Comece pela decisão que precisa de tomar

Uma equipa quer saber se a IA melhora a entrega. Contar linhas geradas responde a outra pergunta. Defina o resultado útil e as condições de qualidade antes de escolher uma métrica.

Num serviço fictício de exportação, o resultado pretendido é entregar alterações aceites de forma fiável, com menos esforço total. Registe a preparação, a implementação, a revisão, a correção e a espera. Inclua alterações que falharam ou foram abandonadas.

Use um serviço com um limite claro. Combinar um website experimental e um serviço crítico de pagamentos pode produzir um número que não explica nenhum dos dois. Descreva o contexto antes de comparar períodos ou equipas.

Use definições atuais

O modelo atual de entrega da DORA contém cinco métricas. O seu âmbito é o desempenho da entrega, não o valor de cada funcionalidade nem o contributo individual. Definições das métricas DORA.

Um dashboard pode usar outra definição. Leia-a antes de interpretar o resultado. A documentação atual de deployment da Taiga descreve quatro métricas apresentadas, derivadas dos registos de deployment do fornecedor. A medida de recuperação usa um deployment bem-sucedido posterior. Não é um registo completo de todos os incidentes de produção. Definições da Taiga.

Examine uma sequência fictícia de alterações

Suponha que um serviço faz doze deployments num mês. Oito entregam alterações planeadas. Quatro corrigem problemas de lançamentos anteriores. A contagem é doze, mas a composição importa.

No mês seguinte, a equipa faz dez deployments: nove alterações planeadas e uma correção. Menos deployments podem coexistir com mais trabalho útil. Estes números ilustram a interpretação; não são uma referência de desempenho.

Examine também a distribuição. Uma espera longa por revisão pode desaparecer numa média. Uma medida de recuperação baseada numa única falha é uma evidência fraca de fiabilidade futura. Apresente o número de observações e as exceções relevantes.

Relacione o fluxo com as consequências

Use sinais do serviço para verificar se as alterações na entrega afetam os utilizadores. Um pipeline mais rápido não basta se os exports falharem mais vezes. Use um SLO adequado ou outra medida de resultado claramente definida. Orientações sobre SLOs.

O esforço de revisão e o retrabalho ajudam a explicar o resultado. Se a IA encurtar a implementação mas produzir diffs grandes, a revisão pode tornar-se a restrição. Se forem precisos dias para obter ambientes, programar mais depressa pode ter pouco efeito no tempo decorrido da entrega.

Escolha uma melhoria que responda à restrição observada. Por exemplo, disponibilize um ambiente de teste suportado ou reduza o tamanho de uma alteração. Defina uma métrica de qualidade complementar para a equipa detetar um aparente ganho de velocidade causado por verificações mais fracas.

Mantenha a medição útil

Evite classificações individuais baseadas na contagem de PRs ou no código gerado. Estas medidas podem recompensar quem divide artificialmente o trabalho, evita manutenção difícil ou transfere o esforço de revisão para colegas.

Reveja o resultado com as pessoas responsáveis pelo serviço completo. Registe o que mudou na ferramenta, no conjunto de trabalho, na equipa e no ambiente. Trate uma comparação antes e depois como evidência com limitações, não como prova automática de causalidade.

O objetivo é melhorar a decisão seguinte. Uma medição pequena e fiável que conduza a uma melhoria verificada é mais útil do que um dashboard grande sem significado acordado.

Pratique com dez alterações

Este conjunto fictício de dados, separado do exemplo anterior, regista dez alterações planeadas. Todas as horas estão em UTC na data indicada. Um campo de correção vazio significa que não foi registada uma correção neste conjunto de dados.

Compare o tempo entre o código pronto e o início da revisão e, depois, entre a aceitação e o lançamento. Identifique a espera visível mais longa. Investigue a causa antes de a considerar evitável. Estes registos temporais não medem o esforço ativo nem identificam quando começou um incidente. Um lançamento de correção, por si só, não permite determinar o tempo de recuperação de um deployment falhado.

Descarregar o conjunto fictício de dados (CSV)