O projeto está acabando mas vale lembrar de algumas experiências. Mesmo com XXX testes é normal que algum pequeno bug apareça, e antigamente quando isso acontecia era uma facada no orgulho: - “O que? Um bug!”. Claro, estávamos utilizando o melhor do TDD, escrevíamos os testes antes da implementação, criávamos testes de aceitação e etc. Resumindo, bugs acontecem. Então quando o cliente encontrava algum bug nossa sprint era interrompida no meio para que pudéssemos corrigir os problemas encontrados, isso era horrível por que tínhamos o código incompleto da sprint, tínhamos a pressão do cliente e o este ainda era pressionado para resolver aquilo em 2 minutos! o.O

Em uma determinada sprint, que eu não vou lembrar o número, nós tivemos a pior experiência com bugs, outras pessoas tinham acabado de se juntar a equipe, eles não tinham muita experiência, o que consumiu muito de nós pois tínhamos que explicar o funcionamento do TDD, que quando um teste quebrava o problema era da implementação do programa e NÃO do teste, e por ai vai. Tivemos o pior resultado de todos nessa sprint. Na retrospectiva levantamos esses problemas e “bolamos” uma solução que funciona com perfeição até hoje. Nós criamos a “quinta-feira da faxina”.
Hoje, quando o cliente encontra algum “bug”, se este não for muito, mas muito grave, ele escreve um post-it detalhando o problema e cola no espaço destinado a “faxina” sem ao menos interromper nosso trabalho para comunicar. Na quinta-feira nós damos uma pausa na sprint e pegamos todos os post-its relacionados a bug, melhoria, correção, além de rodar várias vezes os testes. É incrível como o volume de “bugs” encontrados diminuiu em 80% e nunca mais foi encontrado um “bug grave”, essa rotina funciona tão bem que nem é mais mencionada.

Por que escolhemos quinta-feira? Toda sexta-feira nós geramos uma tag e uma versão para o cliente, geralmente pela manhã, com isso ele pode realizar seus próprios testes, apresentar para seus superiores ou qualquer outra coisa que ele queira. Por isso ficou interessante corrigir os problemas antes de gerar a versão.

Nem sempre conseguimos corrigir todos os bugs na quinta-feira, então voltamos a trabalhar neles na próxima quinta e assim sucessivamente. Deixamos definida uma medida para o caso de ocorrer algum problema urgente, que seria:  parar a sprint, planejar a correção e replanejar a sprint.

Essa não é a solução ideal para todos os casos, mas é incrível como funciona bem nesse projeto, o cliente até começou a fazer isso com outros processos internos.