Dominar as métricas DORA: Um guia prático para medir e melhorar a entrega de software

Medir as métricas DORA

Recolha de dados: manual vs. automatizada

A recolha automatizada de dados é a melhor forma de evitar métricas imprecisas, que, por sua vez, conduzem a decisões empresariais erradas. No entanto, a automatização de todos os parâmetros envolvidos no cálculo de uma métrica pode não ser possível devido a restrições. Nesses casos, deve-se chegar a um acordo sobre uma abordagem manual que seja razoável e esteja em conformidade com as normas do setor.

Prazo de entrega:

Medido com base no tempo que uma funcionalidade demora a passar da fase de pedido da empresa para a produção. Isto pode ser medido através da utilização de várias ferramentas em cada etapa.

• Automatizar testes e implementações(pipelines de CI/CD).
• Reduzir o tamanho dos lotes(mudanças menores e mais frequentes).
• Melhorar os processos de revisão e aprovação de código.
• Monitorizar pontos de estrangulamento(por exemplo, QA demorados, aprovações manuais)

Método manual:

Quando as ferramentas ou plug-ins necessários para o cálculo automático do tempo de execução não estiverem disponíveis, pode ser adotada uma abordagem manual. É possível calcularmanualmente o tempo de execuçãono Azure DevOps (ADO) ou em sistemas semelhantes , utilizando extrações de dados brutos. Aqui está um guia passo a passo:

Extração de dados

• Fonte: Consulta de itens de trabalho ADO ou API.

Âmbito:

• Filtrar porfuncionalidades/histórias de utilizador marcadascomoconcluídas (ou seja, implementadas em produção).

Extrato:

• Data de criação(quando o item de trabalho foi solicitado).
• Data de encerramento/conclusão(quando marcado como «Concluído»).

Fórmula para o tempo de execução de uma funcionalidade/história de utilizador:

• Prazo de entrega ( por artigo) = Data de encerramento - Data de criação

Fórmula para a média ao nível do projeto

• Prazo médio de entrega = Soma (Prazo de entrega por artigo) ÷ Número total de artigos

* Nota: Nos casos em que as funcionalidades planeadas são criadas antecipadamente, a métrica do tempo de preparação não refletirá a realidade; nessas situações, o tempo de ciclo pode ser utilizado como métrica alternativa.

Frequência de implementação:

• Conte o número de implementações em produção durante um determinado período (por exemplo, por dia, semana ou mês).

Extração de dados:

• Utilize ferramentas de CI/CD (por exemplo, GitHub Actions) para registar o número de implementações.

Fórmula para a frequência de implementação:

• Número total de implementações/Número de meses

Fórmula para a média ao nível do projeto:

• Número de implementações do projeto / Número de meses

*Nota: De acordo com a definição do setor, as implementações de hotfixes não são incluídas na contagem de implementações.

Taxa de falhas na troca:

O que se considera uma «implementação falhada»?

• Revertidas (revertendo uma versão devido a problemas).
• Correções de emergência (correções urgentes após a implementação).

Método de rastreamento:

• Integrar com falhas de implementaçãodo pipeline de CI/CD (por exemplo, Jenkins, GitHub Actions) para sinalizar essas falhas.
• Utilizar ferramentas de gestãode incidentes (por exemplo, ADO, Jira, ServiceNow).

 Fórmula para calcular a taxa de falhas na mudança:

• Número de alterações com falha ÷ Número total de alterações × 100.

Método manual:

Para calcular o número de alterações com falhas, pode-se utilizar o número de incidentes de suporte classificados como «Errode software». Ao dividir este valor pelo número total de alterações lançadas, obtém-se o CFR.

As organizações precisam de classificar os incidentes periodicamente para que a métrica seja precisa.

Tempo médio de reparação (MTTR):

O que se considera «tempo de recuperação»?

• Início:Quando a falha é detetada (alerta acionado).
• Fim:Quando o sistema estiver totalmente restaurado (por exemplo, reversão concluída, correção de emergência implementada).

Método de rastreamento:

• Ferramentas de gestão de incidentes(por exemplo, ADO, Jira).
• Sistemas de monitorização(por exemplo, CloudWatch, Prometheus) para registar os tempos de resolução.

Fórmula para calcular o MTTR:

• Soma dos tempos de recuperação ÷ Número de falhas

Método manual:

A soma dos tempos de restauração pode ser calculada com base nos incidentes de suporte classificados como«Erro de software». A diferença entre a «Data de criação» e a «Data de encerramento», expressa em dias, pode ser utilizada como numerador.

O número de incidentes classificados como«Erro desoftware»pode ser utilizado como denominador.

Ligar o ADO, o CI/CD e os sistemas de monitorização

A recolha periódica destas métricas e a sua otimização ajudam as organizações a alcançar eficiência na forma como lançam software.

Dispor de ferramentas e plugins eficazes e integrá-los ajuda a automatizar a maioria destas tarefas, a gerar métricas e a tomar as decisões adequadas.

O Azure DevOps (ADO) fornece os metadata necessários para capturar os dados brutos para o cálculo destas métricas. A equipa de DevOps necessita de uma avaliação cuidadosa, tendo em conta as necessidades futuras do negócio.

Ferramentas de visualização e painéis

O Azure DevOps (ADO) oferece funcionalidades de painel com estes metadata e widgets para capturar algumas dessas métricas. No entanto, garantir que metadata atualizados para cada item de trabalho é essencial para gerar métricas precisas.

Podem ser utilizadas ferramentas alternativas , como o Power BI e o Grafana, para melhorar a visualização e a elaboração de relatórios destinados às partes interessadas.

Desafios e considerações para as organizações

Recolha de dados e utilização de ferramentas

Integridade dos dados e limitações das ferramentas

Desafios:

• Fontes de dados inconsistentes:os pipelines de DevSecOps extraem dados de ferramentas díspares (sistemas de CI/CD, scanners, sistemas de acompanhamento de incidentes), o que leva a cronologias incompatíveis, falsos positivos ou lacunas.
• Viés de relato manual:as métricas compiladas manualmente (por exemplo, relatórios de incidentes) carecem frequentemente de padronização, o que distorce tendências comoo MTTR(Tempo Médio de Recuperação).

Solução:

• Garantir a rastreabilidade:utilize metadata imutáveis metadata por exemplo,IDs de pipeline do Azure DevOps, commits do Git) para extrair dados relacionados com alterações no código.
• Validar através da correlação entre ferramentas:Combinar dados do SonarQube (qualidade do código), do ADO para identificar anomalias e de normas do setor para validar dados métricos

Disponibilidade de ferramentas e plug-ins

Desafio:

• As organizações podem não ter acesso a ferramentas integradas de DevSecOps (por exemplo, scanners SAST/DAST, sistemas de acompanhamento de implementação) ou enfrentar dificuldades com os custos de licenciamento.

Solução:

• Aproveiteo Azure DevOps Marketplacepara obter plug-ins (por exemplo,OWASP ZAP,SonarQube).
• Recorra aalternativas de código aberto quando os orçamentos forem limitados.

Configurar o ADO para a captura Metadata

Desafio:

• Os dados brutos do ADO (compilações, lançamentos, itens de trabalho) requerem uma etiquetagem/ligação adequada para gerar métricas comoo tempo de execuçãooua frequência de implementação.

Solução:

• Impor campos obrigatóriosnos itens de trabalho e nas atualizações periódicas
• Utilizeas vistas do ADO Analyticsouos conectores do Power BIpara consultar metadata do pipeline.

Atualizações efetivas sobre alterações no estado dos itens de trabalho

Desafio:

• As atualizações manuais de estado (por exemplo, Concluído → Aprovado) atrasam métricas comoo Tempo de Ciclo.

Solução:

• Automatize transiçõesutilizandowebhooksADO ouAzure Functions(por exemplo, atualização automática quando os PRs são fundidos).
• Associar os estados aospontos de controlo do DevSecOps(por exemplo, o estado de revisão de segurança antes da implementação).

Dados insuficientes para gerar métricas

Desafio:

• Dados escassos (por exemplo, implementações pouco frequentes, baixo número de incidentes por projeto) distorcem as tendências.

Solução:

• Definir limites mínimos(por exemplo, «Monitorizar apenas se >5 incidentes da categoria de erros de software»).

Métricas que não são conclusivas para a tomada de decisões

Desafio:

• As métricas de vaidade (por exemplo, «MTTR de 120 dias») não levam à ação.

Solução:

• Concentre-se emindicadores orientados para os resultadose apoiados por dados suficientes

Resistência organizacional e uso indevido

Resistência organizacional

Desafios:

• Medo da exposição:as equipas podem resistir à adoção de métricas que revelem ineficiências (por exemplo,umaelevadataxa de falhas nas alteraçõesdevido a rejeições por motivos de segurança).
• Sobrecarga de ferramentas:A introdução de novas ferramentas de DevSecOps, metadata capturar e plug-ins (por exemplo, scanners SAST) pode suscitar resistência se for vista como perturbadora ou desnecessária.
• Incentivos desajustados:a liderança privilegia um indicador em detrimento de outro. O «tempo de execução», por si só, pode induzir em erro

Estratégias de mitigação:

• Métricas de estrutura como ferramentas de melhoria:
  • Saliente como estes indicadores ajudam a organização a longo prazo e permitem comparar ou avaliar o desempenho
• Métricas do projeto-piloto:
  • Comece por projetos não críticos para demonstrar o valor antes da implementação em toda a organização e concentre-se em métricas que ofereçam valor comercial.

Objetivos a longo prazo da organização vs. resultados derivados de métricas

Desafio:

• Desalinhamento:A otimização de métricas a curto prazo (por exemplo, melhorara frequência de implementação) pode entrar em conflito com os objetivos a longo prazo (por exemplo, redução da dívida técnica, maturidade em matéria de conformidade).
• Métricas de vaidade vs. criação de valor:as equipas podem dar prioridade a métricas que parecem boas em detrimento de resultados significativos.

Solução:

Relacionar métricas com temas estratégicos:

• Relacione os indicadores (por exemplo,o tempo de execução) aos objetivos empresariais (por exemplo, «Redução do tempo de lançamento no mercado para produtos essenciais em termos de conformidade»).

Desafio:

Armadilha das métricas na definição do roteiro: concentrar-se excessivamente numa única métrica (por exemplo,o MTTR) pode levar a ignorar problemas sistémicos (por exemplo, uma automação de testes inadequada).

Solução:

Carteiras métricas ponderadas:

• Equilibre os indicadores com os objetivos a longo prazo da organização (por exemplo, frequência de implementação), a estabilidade (taxa de falhas nas alterações) e o tempo de execução

Equilibrar os indicadores com a cultura da equipa

Os riscos culturais do excesso de métricas

Desafios:

• Medo da avaliação:as equipas podem interpretar as métricas como uma forma de vigilância, o que pode causar stress e esgotamento.
• Manipular o sistema:a pressão para cumprir metas (por exemplo,a frequência de implementação) pode incentivar atalhos (por exemplo, ignorar verificações de segurança).
• Sufocamento da inovação:uma ênfase excessiva nas métricas pode desencorajar a experimentação (por exemplo, o receio de que implementações mal sucedidas afetema taxa de falhas nas alterações).

Solução:

• A segurança psicológica em primeiro lugar:
  • Saliente que os indicadores sãoferramentas de diagnóstico, não avaliações de desempenho.
  • Valorize a «aprendizagem com os erros» (por exemplo, análises pós-incidente que melhoramo MTTR).
• Concepção de métricas liderada pela equipa:
  • Envolva os engenheiros na seleção das métricas (por exemplo, deixe-os escolher entreo tempo de execuçãoouo tempo de ciclocomo prioridade em detrimento da taxa de falhas nas alterações).

Métricas vs. Capacidade da equipa e necessidades de formação

Lacunas nas capacidades que impedem a medição

Desafio:

As equipas não possuem as competências necessárias para melhorar os indicadores-chave (por exemplo,tempos de execuçãolentos devido à falta de familiaridade com as ferramentas de segurança)

Soluções:

• Segmentação métrica baseada em competências:
  • Exemplo: Acompanhar separadamenteo tempo de respostadas equipas que adotam novas ferramentas SAST
• Formação «Just-in-Time»:
  • Automatizar os gatilhos de formação (por exemplo, sea taxa de falhas no pipeline devido a questões de segurançafor superior a 15%, atribuir formação modular).
• Indicadores de mentoria:
  • Medir a percentagem de sessões de programação em parespara promover a partilha de conhecimentos.

Métricas que ignoram o crescimento da equipa

Desafio:

• A ênfase excessiva nas métricas de resultados (por exemplo,a frequência de implementação) subestima a importância do desenvolvimento de capacidades.

Soluções:

• Equilibrar os indicadores de resultados e de crescimento:
  • Relacionara frequência de implementaçãocom a percentagem da equipa que contribui para o código do pipeline.
• Indicadores de percurso profissional:
  • Exemplo: Acompanhar a percentagem de engenheiros que lideram revisões de segurançapara incentivar o sentido de responsabilidade.

Referências

• Accelerate, de Forsgren, Humble e Kim
• Documentação do Azure DevOps
• Relatórios de Investigação e Avaliação de DevOps (DORA)