Há muitas frameworks e metodologias que visam melhorar a forma como construímos produtos e serviços de software. Com tanto material é necessário entender o que funciona e o que não funciona para nossa sua realidade. E existem métricas que são famosas, mas que estudos mostra como essas métricas famosas são ineficientes.
Google DORA
Vou iniciar explicado as mais famosas no momento, Google DORA (acrônimo para "Dev*Ops and **Research and **A*ssessment") são um conjunto de métricas que o famoso Google utiliza para realizar um benchmarking com equipes reais desde 2018, mas informação aqui. Dessa forma é fácil para aqueles gestores que desejam comparar a desempenho da sua equipe em relação a outras empresas.
Lead Time (Deploy Cycle Time)
A definição do Lead Time é o tempo entre a "promessa do time" até o "código funcionando com sucesso na produção". Essa métrica é utilizada para saber quanto tempo leva para implantar uma funcionalidade em um ambiente de desenvolvimento, teste ou produção. Tem o objetivo de melhorar os métodos, processos e ferramentas utilizado pela organização.
Deployment Frequency
A segunda métrica a ser considerada é o tamanho das entregas. A redução do tamanho da entrega é outro elemento central do paradigma Lean. A redução do tamanho das entregas reduz o tempo e a variação da cadência, acelera o feedback, reduz os riscos e as despesas gerais, melhora a eficiência, aumenta a motivação e a urgência e reduz os custos e o crescimento do cronograma.
Mean Time to Restore
Uma constante no desenvolvimento de software é que as falhas vão existir (Esse artigo comenta sobre como é inevitável existir software sem falhas). Um gestor de excelência precisa saber dessa verdade e se perguntar: Com que rapidez o meu time consegue restaurar o serviço?
Change Fail Rate
Essa métrica observa qual o impacto das mudanças no ambiente de produção, ou se preferir, qual a quantidade de falhas as novas funcionalidades estão entregando para os usuários. O quanto o serviço é degradado pelas novas funcionalidades?
Desempenho operacional (confiabilidade)
O relatório de 2022 foi apresentado uma quinta métrica, desempenho operacional ou se preferir a confiabilidade. A confiabilidade é a medida que busca entender como suas entregas atende a expectativa do dos usuários, tais como disponibilidade e desempenho. Engenharia de confiabilidade é um assunto bem vasto e cabe um artigo somente para esse assunto. O estudo expandiu seu conceito em 2021 para medir a confiabilidade, visando assim representar a disponibilidade, latência, desempenho e escalabilidade de forma mais ampla.
Relatório de 2022
O Google disponibilizou os resultados para o ano de 2022. Esta interessando de saber se sua equipe é de alto, médio ou baixo desempenho?
Métricas depreciadas (tente não usar essas métricas)
Agora apresento duas métricas para não utilizar. Essas métricas podem ser consideradas frágeis, e por essa razão não é uma boa indicação confiar decisões estratégicas com base em uma métrica que "depende" muito do contexto ou que possui um grau de confiança muito baixo.
Code Churn
Code Churn, é a medida que calcula a taxa de reescrita de um software ou a quantidade de linhas excluídas logo após ser escrito, é uma parte normal do processo de desenvolvimento.
Tem como premissa calcular se o desenvolvedor está tendo muito retrabalho ou se as solicitações não são claras o suficiente e está sobrecarregando o desenvolvedor e este esta gastando tempo com algo que não vai mais ser necessário.
Mas o é possível que os desenvolvedores apenas estão testando hipóteses e exploram várias soluções para um problema - especialmente para o início de um projeto, quando o problema ainda não tem uma solução clara.
Agora o problema pode estar relacionado com outros fatores que fogem do controle do desenvolvedor. Tais como requisitos que não estão claros, stakeholder indecisos, um problema realmente complicado, o desenvolvedor esta apenas criando um protótipo, o desenvolvedor está polindo (apenas uma mudança, pois essa pessoa tem um TOC), ou o código não tem um bom direcionamento e fica alternando o seu proposito com certa frequência.
De todo o modo, é complicado compreender o comportamento de uma pessoa ou equipe.
Lines of Code
Essa métrica apresenta um grande problema para as linguagens de programação atuais. Pois para ter um grau satisfatório existem várias variáveis que o desenvolvedor (alvo da métrica) pode manipular conforme desejar. Antigamente existiam ainda existem linguagens de programação que obrigava o desenvolvedor seguir um padrão de ideação (forma como escrevemos um código). Assim era possível medir a produtividade do desenvolvedor com base na quantidade de linhas que ele escrevia.
Mas atualmente as linguagens permitem mudar essa tal de indentação, ou seja, posso escrever todo um sistema em apenas uma linha ou escrever usando 1000 linhas.
Se um desenvolvedor sabe que sua produtividade está com base na quantidade de linhas, é possível que essa pessoa inclua linhas sem sentido ou faça da maneira mais complicada somente com o objetivo de inflar sua avaliação.
Olha esse exemplo, é possível escrever um simples programa que mostra a mensagem "Olá mundo".
Não tem como inferir que o com mais linha tem mais funcionalidade ou mais qualidade.
Top comments (1)
Interessante. Inclusive nunca tinha visto a questão do Churn nesse contexto. E ainda bem né?!