Compreender o tempo até à qualidade

Atualmente, são utilizadas muitas métricas para acompanhar o progresso da garantia de qualidade. A maioria é bastante útil, mas todas tendem a ser unidimensionais, no sentido em que são retratos de um momento, ou de um ciclo de trabalho, no tempo. Isto aplica-se até às métricas de ritmo e de tendência, que são incrivelmente importantes, mas que, mais uma vez, são retratos de um momento no tempo.

Quando trabalhava na Symantec, reparei no seguinte:

Havia muitas métricas utilizadas para determinar o nível de qualidade alegadamente alcançado na data de lançamento. Mas não eram recolhidas quaisquer métricas, nem durante o processo nem retrospetivamente, para medir o custo de alcançar essa qualidade.

Por outras palavras, não nos preocupávamos com a eficiência com que essa qualidade era alcançada ao longo da vida do projeto.

O seu produto pode ter sido lançado com uma qualidade elevada, mas teria sido necessário despender tanto tempo e esforço para a alcançar?

Esta é uma questão de eficiência, não uma questão de qualidade propriamente dita, mas as duas estão muito relacionadas.

A interseção entre qualidade e eficiência

A qualidade e a eficiência cruzam-se porque uma das principais razões pelas quais os projetos de software ultrapassam frequentemente, e de forma significativa, o calendário acordado (e isto surge muitas vezes como uma surpresa inesperada na fase final do projeto) é a fraca qualidade do código. Não apenas a qualidade inicial do código, mas ao longo de todo o projeto.  

Outra razão, que é na realidade apenas uma consequência inevitável da fraca qualidade do código, são os defeitos que exigem vários ciclos de tentativa de correção, abrangendo várias execuções de testes ou ciclos de trabalho antes de o defeito ser efetivamente corrigido. Se é que fica corrigido.  

Estas iterações intermináveis de correção, teste e nova falha acrescentam inúmeras semanas de trabalho de pessoas a quase todos os projetos de software.

No entanto, curiosamente, este padrão de falha não é capturado de forma específica por nenhuma outra métrica de projeto ou de qualidade que eu tenha visto. Porque, como referido acima, todas estas métricas são retratos de um momento no tempo e, por isso, não conseguem capturar este fenómeno.

Ocorreu-me que havia uma forma simples de capturar este padrão de falha. Criei uma métrica a que chamei "Tempo até à qualidade", ou TTQ.

Apresentação de uma nova métrica: Tempo até à qualidade (TTQ)

A métrica em si é bastante simples. Funciona da seguinte forma:

Para cada execução de testes (independentemente da forma como é definida), registe não apenas quantos testes foram aprovados ou falharam, mas também quantos testes foram aprovados na primeira tentativa. E quantos exigiram duas, três ou mais tentativas antes de os mesmos testes serem finalmente aprovados.

Como exemplo simples, se executar 20 testes e 5 deles forem aprovados na primeira tentativa, o seu rácio TTQ é de 25%. Quanto maior for o número, melhor. É um indicador simples, calculável e facilmente acessível da qualidade geral do seu código.

Esta métrica é uma indicação muito boa da qualidade inicial do código.

Isso acontece porque, quanto maior for a qualidade do código, menos vezes terá de executar um teste sobre ele antes de este ser aprovado. E vice-versa. Esta métrica é muito mais precisa do que as contagens e tendências de erros.

A TTQ é também uma métrica de acompanhamento do projeto incrivelmente útil.

Por exemplo, se na primeira execução de testes 70% dos testes forem aprovados e 30% falharem, pode presumir razoavelmente que o seu projeto continua dentro do prazo previsto. Mas se, por exemplo, apenas 20% dos seus testes forem aprovados na primeira execução, então, para usar termos técnicos, "Miúda, estás metida em sarilhos! "

Porque isto significa que, na realidade, não executou uma primeira passagem bem-sucedida. E esse tempo terá de ser acrescentado novamente a uma execução futura como dívida de qualidade.

A métrica TTQ é extremamente útil como aquilo a que gosto de chamar uma métrica de "fio de disparo".

Se a utilizar de forma consistente, fornece dados muito precisos que permitirão ao gestor de projeto determinar se o projeto está a descarrilar muito antes de o comboio sair efetivamente da linha. 

Isto significa que podem ser tomadas medidas proativas muito mais cedo para voltar a colocar tudo sob controlo. Evitando confissões embaraçosas, já numa fase muito avançada, de que o calendário do projeto está completamente destruído. Por outras palavras, utilize um limiar de TTQ para definir se o projeto continua verde, está amarelo ou está prestes a ficar vermelho. Torne-o parte integrante do próprio estado do projeto.

Porque, sejamos realistas, uma das patologias constantes nos esforços de desenvolvimento de software é a negação persistente de que as coisas estão a correr mal, e de forma grave, quando isso se torna evidente pela primeira vez. Toda a gente tem medo de ser rotulada de “negativa”, ou de parecer demasiado preguiçosa ou pouco empenhada para resolver as coisas, ou de não ser um “jogador de equipa”. A comparação com famílias disfuncionais é desconfortavelmente óbvia.

Esta negação e repressão daquilo que todos sabem estar realmente a acontecer cria o padrão de falha de recusar reconhecer que o projeto está muito, muito atrasado até ao último minuto.

Quando isto já não pode ser escondido da administração de topo, a surpresa desagradável que tal situação lhes provoca apenas serve para minar, por vezes permanentemente, a confiança que depositam nas suas próprias equipas de desenvolvimento. E quem pode censurá-los?

Mas se incorporar consistentemente a TTQ nas suas métricas e na gestão do projeto—e agir de acordo com o que essa métrica lhe está a dizer—pode evitar isto.

Medir o Tempo até à Qualidade retira o caráter pessoal da decisão de reconhecer que os riscos relacionados com o prazo e a qualidade estão a aumentar no projeto desde as suas primeiras fases.

Torna-se uma questão muito clara e objetiva, baseada em números. Não uma questão de heroísmo pessoal, que muitas vezes acarreta um custo elevado para a pessoa. 

A métrica TTQ também é muito útil para a retrospetiva/análise pós-morte de um projeto

Permitirá à equipa identificar com precisão quais as secções do código que eram e permaneceram frágeis ao longo do projeto. E, por extensão, quão eficiente foi a equipa a produzir qualidade enquanto tal. Ou quão dispendioso foi.

Esta é uma questão amplamente evitada nas retrospetivas de projetos. Em parte porque as equipas não dispõem do vocabulário conceptual necessário para a formular e, em parte, porque é frequentemente politicamente sensível apontar uma qualidade de código consistentemente fraca por parte da engenharia.

Em resumo

O TTQ proporcionará uma enorme transparência e previsibilidade aos seus projetos, praticamente sem custos em termos de tempo ou esforço, uma vez que consiste simplesmente numa meta-análise de métricas que já recolhe.

Tenho utilizado o TTQ nos meus projetos de garantia da qualidade há duas décadas, e este foi amplamente aceite pelos gestores de projetos que formei na sua utilização, por todas as razões acima referidas.

Experimente e verá por si próprio. Será verdadeiramente um fator de mudança para a sua equipa. Como sempre, boa sorte.

P.S. Se quiser ouvir mais histórias de guerra e conhecer as razões por detrás do TTQ, falei com Jonathon Wright no podcast QAL.