quanto testar

Adverência: esse post não responde de forma objetiva ao seu título. É mais subjetivo, para provocar reflexão.

Observem o seguinte gráfico:

Ele mostra a relação entre o esforço gasto com desenvolvimento em si (novas funcionalidades), com testes e com correções de bugs. É claro que a separação entre funcionalidades e testes é muito difícil, quiçá impossível, de ser estabelecida. Mas façamos um pequeno esforço mental para entender essa separação.

Os pontos A e C são extrapolações, não existem no mundo real. No A, não há qualquer teste. Seria o caso do desenvolver simplesmente escrever o código, compilar, não realizar o obscuro “teste do desenvolvedor” e entregar para o cliente. No C, todo o esforço é gasto com testes (“Testar o quê, se nenhuma funcionalidade foi produzida?”). Existe o lance das provas formais, que não conheço direito, mas até onde sei é algo impraticável em 999.999.999 de cada bilhão de softwares.

Por observação, boa parte das equipes se encontra entre A e B. Uma pena, já que isso se mostra uma tremenda estupidez. Na verdade, estupidez não é nem estar entre A e B; é não querer sair de lá. Por quê? Simples: o ponto B é o de maior produtividade. Ou seja: teste um pouco mais e será mais produtivo. Não é nem uma questão de fazer tão bem feito, com poucos bugs. É uma questão simples de produtividade. O curioso é que qualquer equipe deveria no mínimo se posicionar em B. E por que muitas não se posicionam? Assunto para outro post. Lembrei de uma frase que a mamãe costumava repetir: “O preguiçoso trabalha mais que o trabalhador.”

Sendo assim, os menos atentos diriam: “O ideal então é se posicionar em B, que é o ponto de maior produtividade.” Não é bem assim. Pergunto: seria certo se posicionar em B uma equipe que está produzindo um software embarcado que guia um míssil ao seu alvo? Claro que não! É preciso observar o nível de bugs no ponto B. Um erro nesse software poderia ser catastrófico. Ou seja, esse software deve ser virtualmente perfeito, sem bugs. Essa equipe deve se posicionar o mais próximo possível de C.

“Resolvido, então. Devemos sempre nos posicionar o mais próximo possível de C, correto?” Também não. Depende da natureza do software. A tolerância a erros de um software de um míssil é totalmente diferente da tolerância de um software gratuito para comunidades virtuais, por exemplo. Um erro neste nunca seria catastrófico. “Mas mesmo não sendo catastrófico, não seria melhor não ter erro nesse software?” Seria. Mas devemos observar outro fator: produtividade (funcionalidades). A partir de B, à medida que nos aproximamos de C a produtividade cai, já que o investimento em testes aumenta. Na prática, a grande maioria dos softwares não comporta um posicionamento próximo de C devido à baixa produtividade.

Um aparte: a curva dos defeitos em relação aos testes é logarítmica. Isso é apenas minha opinião, apesar de achar fortemente que estou certo – minha experiência e intuição me gritam. Se souberem de alguma pesquisa ou estudo científico que mostre essa relação, ficaria muito grato se me indicassem.

“Onde se posicionar, então?” Infelizmente ainda não descobrimos resposta objetiva para isso. O que vale aqui é a experiência e o bom senso da equipe, além do próprio processo empírico. Algumas heurísticas também podem ajudar.

Uma última análise: de modo bem simplista, podemos dizer que o basicão do TDD (100% de cobertura) está no ponto G, em que o esforço de testes é igual ao esforço de funcionalidades. Nessa minha simulação, de B para G, há uma queda de 22% na produtividade e de 63% nos defeitos. Coisas como essa explicam por que os agilistas (especialmente os XPeiros) somos tão vidrados em testes.

P.S.: para efeito deste post, em “testes” incluem-se coisas como programação em par e inspeção.

P.P.S.: “defeitos” referem-se ao esforço que a equipe fez para corrigir erros depois de realizados os testes, depois do deploy. Ex.: num período de um ano de um projeto, a equipe gastou 10% do esforço para corrigir bugs encontrados em produção.

boliche, salto em altura, basquete… e TDD

Há alguns anos, uns amigos me convidaram para jogar boliche. Todos amadores, nunca havíamos jogado. Qual o objetivo do jogo? Derrubar o maior número de pinos. Eu já havia assistido a algumas partidas na tevê. Vi que os jogadores profissionais sempre utilizam a mesma técnica: arremessam a bola com efeito. Resolvi então fazer o mesmo. Resultado: desastre total. Perdi as primeiras partidas. Resolvi mudar a estratégia. Passei a jogar sem efeito, e passei a ganhar algumas partidas.

Certa vez, na escola técnica (atual CEFET) ou na universidade, não lembro direito, cheguei a praticar atletismo. Chegamos ao salto em altura. Alguns (os “seminovatos”) já haviam praticado uma ou duas vezes. Os demais eram absolutamente “novatos”, virgens no esporte, marinheiros de primeira viagem. Qual o objetivo da disputa? Passar o sarrafo o mais alto possível sem derrubá-lo. Todos os novatos queríamos passar o sarrafo com as costas viradas para o chão, como fazem os profissionais, da forma que sempre vimos na tevê. Já os seminovatos utilizavam uma técnica “especial”: passavam o sarrafo de frente, com o ventre voltado para o chão. Resultado: os seminovatos venceram-nos de lavada. Fiquei impressionado. Como eles ganharam de todos nós se utilizavam uma técnica menos eficaz? A melhor técnica para mim era a de costas, claro, já que era a que todos os profissionais usavam.

Noutra vez, brincando de jogar basquete na quadra do colégio, combinamos (todos do mesmo nível, seminovatos) uma disputa: quem acertaria mais lances livres. Qual o objetivo da disputa, então? Acertar no cesto o maior número possível de bolas. Alguns fizemos os primeiros arremessos como fazem os profissionais, impulsionando a bola apenas com uma mão, utilizando a outra como apoio. Outros, “não sei por quê”, utilizavam as duas mãos para impulsionar a bola. Foram motivo de chacota, no começo da disputa. Como podiam arremessar de forma tão desengonçada? Nunca haviam visto uma partida de basquete? Só que, à medida que a disputa se desenrolava, a chacota se transformou em perplexidade, pois os desengonçados nos venciam.

O que aprendi com essas historinhas? Que algumas técnicas são mais eficientes, mas só depois de muito treino. Para um novato, as técnicas “naturais” são melhores. Mas há técnicas que, depois de treino, são mais eficientes que as naturais.

Minha sensação é que o mesmo acontece com TDD.

Qual o objetivo de um programador? Entregar código com um bom desaine e coberto por testes unitários. A forma natural é escrever todo o código e depois ir refatorando e cobrindo por testes unitários. Se se pedir a um programador acostumado a fazer dessa forma para escrever código utilizando TDD, ele vai ser bem menos produtivo. Isso pode até ser verdade, mas só no princípio. Um programador fluente em TDD é mais rápido que um programador tradicional.

Infelizmente a analogia com as minhas peripécias esportivas não é perfeita – como qualquer analogia. No esporte, é fácil provar que técnica é mais eficiente: no boliche, quantidade de pinos derrubados; no salto, altura atingida; no basquete, quantidade de lances convertidos. Em software dificilmente – de fato, acho que nunca – conseguiremos provar que TDD é mais eficiente, já que não temos como medir produtividade. Ficaremos pela percepção de cada um.

Pois bem… Certo dessa minha intuição, de que TDD é melhor, pedi para que meus programadores passassem a escrever código utilizando TDD. O resultado inicial foi tão desastroso que abandonaram a ideia à minha revelia.

Quando soube desse abondono, me falaram: “Tales, é um desastre. Ficamos bem mais lentos.” Perguntei: “Mas vocês acreditam que TDD é melhor?” Alguns acreditavam, outros não; mas todos não-convictos. Propus: “Vamos experimentar por algum tempo. Se não gostarmos, desistimos.” Retrucaram: “Mas, Tales, vamos ficar muito improdutivos.” Sugeri: “Façamos assim: comecem programando normalmente, como sempre fizeram, mas se obriguem a fazer TDD uma hora por dia. Depois de duas semanas, aumentem para duas horas. Depois de mais duas, para três horas. E assim sucessivamente, até vocês  se certificarem se TDD é melhor ou não.” Ou seja, a ideia era não ter uma queda brusca de velocidade no princípio.

Essa sugestão que dei para a equipe é recente e ainda não sabemos se a proposta deu certo. De qualquer forma, fica a ideia para os leitores, que era o que queria com esse post, lançar a ideia.

P.S.: cheguei a contar essas historinhas esportivas para uma nossas equipes. Um dos membros dessa equipe – Sávio, meu irmão – fez outra analogia. Ele contou que no princípio digitava apenas com os dois indicadores. Era até rápido. Mas ele intuía – uma obviedade, de fato – que digitaria mais rápido ainda se utilizasse todos os dedos. Só que sabia também que não seria tão produtivo no início. O que ele fez? Começou se forçando a digitar com todos os dedos meia hora por dia. A cada semana, aumentava meia hora, até chegar ao ponto de perceber que digitava mais rápido com todos os dedos que com os indicadores.

por que não estimar por pontos

Advertência: prefiro trabalhar com horas, turnos ou dias ideais (daqui pra frente, só chamarei de “dias-ideais”). Muitas pessoas se referem a dias-ideais como pontos. De fato, até aqui na Fortes chamamos os dias-ideais de pontos. Mas os pontos a que me refiro no título do post se referem àqueles em que as equipes atribuem um ponto para a história mais simples e estimam as demais histórias em relação a essa mais simples. É dessa abordagem que não gosto. Daqui pra frente neste post, quando falar em pontos, é dessa abordagem que estou falando, e não da de dias-ideais.

Não acho nada natural estimar uma história em relação a outra. Imaginemos que num sistema de controle de issues a história mais simples seja “registrar issue”. Imaginemos ainda que haja a história “tela de acompanhamento de issues”. Simplesmente não consigo – pode ser uma limitação minha – fazer qualquer relação direta de tamanho entre essas duas histórias. A única forma que conseguiria de fazer essa relação seria estimar ambas em dias-ideais e ver quantas vezes uma é maior que a outra.

Quando o Alexandre Magno esteve aqui na Fortes ministrando um treinamento, ele fez uma dinâmica para tentar explicar por que seria interessante trabalhar com pontos. Ele nos trouxe uma série de “livros”, de bem simples como um de histórias em quadrinhos, a bem complexos como um do Dostoiévski. Pediu para escolhermos o mais simples e para estimarmos a complexidade dos demais em relação a ele. Adivinha o que aconteceu na minha cabecinha? Para cada livro estimei quanto tempo levaria para lê-lo e fiz a relação entre eles a partir dessa estimativa. Foi a forma mais simples e natural que achei de fazer o que havia sido pedido.

Desde que o mundo é mundo, estimar atividades em tempo é a regra, é a forma mais natural.

Uma crítica comum que se faz ao modelo de dias-ideais é a seguinte: “Esforço não é mesma coisa que tamanho. Dias-ideais se referem a esforço, mas o que queremos saber é qual o tamanho das histórias.” Concordo que esforço não é igual a tamanho. Mas discordo quando dizem que dias-ideais se referem diretamente a esforço. Se eu estimar uma história em cinco dias-ideais, pode ser que a faça em dez. Quede a relação entre dias-ideais e esforço? Perguntariam: como faço então para resolver esse problema de erro de estimativa? Resposta: além do próprio aprendizado empírico, aplicando o conceito de “velocidade”.

Dias-ideais também não se referem diretamente a tamanho, pelo menos não em seu conceito canônico. Em tese, o tamanho deve ser o mesmo para o mesmo projeto independente da equipe que o meça. E isso realmente não dá para conseguir com dias-ideais. Duas equipes podem chegar – e normalmente chegam – a tamanhos diferentes quando medem um mesmo projeto em dias-ideais. Esse problema é em tese resolvido com o modelo de pontos. Mas ainda assim esse modelo não consegue resolver outro conceito – o mais importante – por trás do tamanho: a existência de uma unidade de medida universal para tamanho de projetos.

Iniciando um aparte.

Atualmente considero a técnica de Pontos-de-Função (PFs) o melhor – de fato, menos pior – modelo de tamanho, a melhor unidade de medida universal. Como disse, é o menos pior. A técnica de PFs apresenta ainda uma série de problemas: há alguma subjetividade, a faixa de tamanhos das funções em P, M e G é muito simplista, não pode ser aplicado a todo tipo de projeto de software e alguns dos fatores de ajuste deveriam ser aplicados por função. Ou seja, ainda estamos longe de conseguir uma boa unidade de medida universal para projetos de software (de fato, acho que nunca vamos conseguir; se até hoje nenhuma das chamadas indústrias criativas conseguiu isso, não vai ser a de software que vai conseguir). A questão é: que vantagem teríamos se houvesse essa unidade de medida universal? Várias: poderíamos por exemplo saber se uma equipe está ficando mais produtiva ao longo do tempo; poderíamos também saber se uma equipe é mais produtiva que outra. Essa última vantagem seria especialmente interessante para a contratação de projetos de software por órgão públicos, mas isso é assunto para outro post.

Voltando do aparte.

Um outro problema do modelo de pontos que vejo é o seguinte: não dá para aproveitar a velocidade obtida num projeto para estimar o tempo de desenvolvimento de outro projeto. A história mais simples de um projeto pode não ser do mesmo tamanho que a história mais simples de outro projeto. Responderiam: é só fazer a relação entre as histórias mais simples dos dois projetos, quantas vezes uma é maior que a outra. Tostines: se já acho difícil fazer a relação entre histórias do mesmo projeto, avalie entre histórias de projetos diferentes. Voltamos ao ponto inicial.

Atualização
O tema foi bastante aprofundado e estendido nos comentários.

oi

Venho há um bom tempo pensando em criar um blogue para divulgar meus pensamentos a respeito de desenvolvimento de software, metodologias ágeis e XP. Nunca tive coragem de começar por achar que iria acabar não tendo tempo de dar continuidade. Refletindo melhor, vi que se  isso acontecer, de não dar continuidade, não causaria problema a ninguém. Resolvi então começar.

Queria antes agradecer ao meu amigo e guru Vinícius Teles, que foi quem me iniciou de forma efetiva nesse mundo do desenvolvimento ágil de software e é para mim a mente mais brilhante no assunto no Brasil. Queria também agradecer aos meus colegas de trabalho, que, a despeito de todos os erros que cometi nessa jornada, abraçaram minha ideia de implantar XP aqui na Fortes. Queria agradecer ainda a todos aqueles que de alguma forma me ajudaram nesse trabalho, seja publicando conteúdo valioso na internet, participando de listas de discussão ou ministrando treinamentos aqui na Fortes.