Estimativa de Histórias: se eu fosse adivinho, adivinharia os números da Mega-Sena!

"Olha só, desenvolvedor! Eu tenho esse projetinho pequeno e super simples para fazer! São 3 telinhas em um site! É só cadastrar, clicar no botão para ativar e um painelzinho com um gráfico mostrando as ativações! Em quanto tempo tu faz isso?"

Se você desenvolve software e nunca passou por isso, você é privilegiado, sim!

Todo mundo aqui já conhece esse modo de operação dos pseudo-gerentes de projeto, né? Chegam como quem não quer nada. Já na explicação tentam te empurrar que a demanda é simples e rápida. Eles literalmente te espremem contra a parede te pedindo uma estimativa sem compromisso algum! Mas no segundo que o desenvolvedor comete o erro de dizer uma data... Pronto. Essa data está gravada em pedra. Magicamente a estimativa sem compromisso se transforma em um deadline inegociável.

E esses pseudo-gerentes de projeto acreditam que estão desenvolvendo um trabalho sério.

Os problemas desse modo de trabalho todo mundo sabe: péssimo levantamento, péssimo ou nenhum relacionamento com o cliente, exaustão do desenvolvedor, falta total de métricas e parâmetros de acompanhamento, falta de ações para sanar riscos, projeto entregue na data apenas com esforços heroicos ou contando com a sorte... E, é claro, falta total de qualidade na construção do software, ausência de testes automatizados, futura manutenção comprometida, etc, etc, etc...

É tão amador, que quase podemos chamar de "brincar de gerenciar projetos".

Bem, aí aparece o pessoal do ágil com o Scrum. "Vamos estimar em pontos para dar visibilidade no trabalho da equipe!" Mas estimar em pontos continua sendo previsão do futuro. Só que dessa vez com uma camada de abstração a mais: em vez de pedir data, pede-se um número da escala de Fibonacci (ou outra qualquer...). "Um, dois, três, já!" Todo mundo mostra cartinha, os números divergentes debatem sobre a tarefa, até o pessoal chegar em um número. Um número totalmente tirado da mais fina arte de previsão do futuro, geralmente precisando levar em consideração o Coeficiente de Cagaço*. Uma vez iniciada a atividade, o desenvolvedor vai diminuindo os pontos conforme vai completando ela. Não uma, não duas, não três vezes eu já vi as maravilhosas tabelas de-para entre pontos e horas. "Mas aqui na nossa equipe 8 pontos são mais ou menos 5 dias, geralmente fecha em uma semana!" E se o desenvolvedor ousa passar 6 dias com uma história de 8 pontos, o pseudo-gerente de projetos volta dos mortos para começar a reclamar do atraso no projeto.

E mesmo usando um framework ágil, novamente estamos praticando a ciência oculta da adivinhação... e sendo cobrados por errarmos estimativas sem a menor base de garantia.

Eu proponho um pacto, aqui e agora: sejamos todos nós um pouco mais profissionais, por favor?

Vamos nos comprometer em sermos menos charlatões. Deixemos os nossos poderes adivinhatórios para os números da Mega-Sena e passemos a usar matemática confiável para exorcizar o fantasma do pseudo-gerente de projetos!

Antes de mais nada: P.O., escreva histórias INVEST, SMART ou qualquer outro método que torne-as unidades específicas de valor. E lembre-se que sua responsabilidade é definir apenas O QUÊ deve ser feito. Concentre-se em levantar o problema e especificar O QUÊ você precisa que a aplicação faça para você considerar a história concluída. Garanta que nenhum desenvolvedor saia do Refinamento de Negócios com dúvidas sobre as histórias que precisam ser executadas.

Posto isso.

Assim como o P.O. chega com um documento pronto para o refinamento de negócio, os desenvolvedores devem chegar com um documento pronto para o planejamento. Deixar para fazer o planejamento durante a reunião de planejamento é muito amador, gente. Reservem um "tempo de estudo" para estudar as histórias. Abrir e inspecionar o código. Quebrar as histórias em tarefas, de acordo com a evolução das entregas possíveis.

Pense comigo por um instante: quanto tempo você levaria para pintar todo o prédio ou casa em que você se encontra? 1 mês? 2 meses? 3 meses? 6 meses? 1 ano? Você confia na estimativa que você está dando? Está com medo de todos os imprevistos que podem acontecer?

Então vamos fazer diferente: olhe a parede mais próxima de você. Agora tente estimar apenas essa parede. Só ela. Quanto tempo você demora para pintar apenas essa parede? 2 horas? Uma manhã? Um dia inteiro? Você se sente mais confiante para estimar essa tarefa de pintar uma parede que você está vendo, ou toda a empreitada de pintar o prédio inteiro?

O fato é que o ser humano é orientado a tarefas. Nós sabemos exatamente quanto tempo levamos para fazer coisas que são comuns ao nosso dia a dia. Temos confiança para dizer quanto tempo levamos para escovar os dentes ou para cozinhar um ovo. Temos certeza absoluta de quanto tempo levamos para ir para o trabalho, para comprar pão, para dar a volta no quarteirão com o cachorro ou para varrer a casa. Mas quando o assunto se torna grande e complexo demais, as previsões se tornam turvas. Porque é complicado saber quanto tempo leva para mantermos a saúde bucal, para cozinhar um banquete, para fazer o deslocamento urbano, para fazer as compras no supermercado para o mês inteiro, para deixar nosso animal de estimação totalmente feliz ou para limpar totalmente a casa inteira.

Há quem diga que esse é o segredo da vida: um pequeno gesto de amor e atenção de cada vez.

O mesmo se aplica aos projetos de software. Estimar o todo é turvo, nublado... uma tolice. Mas se quebrarmos o todo em pequenas atividades do dia a dia, conseguimos estimar com muito mais precisão essas pequenas tarefas.

Basta colocar a história no topo e ir perguntando: "O que é necessário fazer para dar essa história como pronta?" "Precisa fazer o frontend!" "Boa! E para fazer o frontend? Precisa fazer mais o quê?" "Esse frontend? Precisamos mexer no CSS e no HTML da página e..."

Abuse dos PostIts. Faça o time escrever. Colar. Arrumar. Desarrumar. Mexer de lá pra cá. Daqui pra lá. Tirar. Colocar. Rasgar. Reescrever. Colocar de novo. Deixe o time planejar de verdade como vão atacar a história inteira. Deixe eles criarem os cenários e pensarem nos problemas antes de atacá-los. E deixe-os distribuir tarefas, responsabilidades e marcarem quanto tempo cada um vai levar em cada pequena tarefa! "Colocar uma combo na tela? Eu faço em 15 minutos!" "Ah, eu deixo o endpoint dessa combo pronto em uma hora! É só comunicar com o banco para trazer os dados e deixar a lista pronta pra ti!" "Poxa, esqueci que vou ter que comunicar com o backend! Não são 15 minutos, vai levar pelo menos uma hora para deixar isso bem feito!"

Enquanto o time vai quebrando as histórias em um quadro, monte em um segundo quadro uma grade. Uma coluna para cada um dos dias do timebox da equipe. Coloque junto à data a capacidade de horas daquele dia. Leve em consideração cerimônias, eventos, cursos, folgas, médicos e tudo o mais que já foi anunciado com antecedência. Quando o time terminar de quebrar a primeira tarefa, peça para o time transferir os PostIts de tarefas para o quadro do planejamento.

Você vai ter um quadro mais ou menos como o da imagem acima.

Aqui, temos um planejamento rudimentar, mas muito mais próximo da realidade. O grande desafio desse quadro é instigar o time a trabalhar em pair programming na mesma história, fazendo com que as tarefas completadas a cada dia formem um pacote de valor que possa ser visto pelo P.O. no final do dia. Seja uma tela com dados fictícios, seja um endpoint que pode ser acessado via Postman ou Swagger, etc... Qualquer coisa que o P.O. já possa validar antes de acabar o timebox.

Mas nada disso até agora é planejamento de verdade. Nada disso envolve cálculo. Tudo isso ainda é previsão.

A matemática de verdade começa quando o primeiro desenvolvedor pega o primeiro PostIt para começar o primeiro desenvolvimento. Cada vez que um desenvolvedor pegar uma tarefa, anote o dia. A hora, se você quiser ser preciosista. O minuto se você quer ter precisão de relojoeiro suíço.

Anote a data cada vez que um desenvolvedor se comprometer com uma tarefa.

Do mesmo modo, toda vez que o desenvolvedor disser que terminou a tarefa, anote a data do final dela. Você terá uma tabela mais ou menos assim:

Bem, aí basta organizar a tabela em um gráfico de dispersão ou linha:

Ordene a coluna das tarefas desde a primeira que foi pega para ser feita, até a última. Crie uma linha de tendência ou de média. E pronto: você tem registro real do trabalho do time. Sem saber a complexidade ou o tamanho de cada tarefa, você sabe que com 50% de certeza no início do timebox o time demora em média pouco menos de 5 dias para entregar qualquer tarefa. 50% de certeza é pouco? Você quer certeza absoluta? Com 100% de certeza, o time demora 9 dias para entregar qualquer tarefa.

Faça esse acompanhamento de modo sistemático, linear, dia após dia, e a duração da próxima tarefa já está na ponta da língua. basta seguir as linhas de tendência.

Não é magia, é tecnologia.

Aqui tem trabalho duro, meu filho!