Idealmente, no mundo perfeito do Scrum, você não precisa se preocupar ao lançar um novo incremento, uma vez que os deploys gerados ao final de cada Sprint já estão prontos para a produção. Bem, no mundo real não é bem assim. E é isto o que veremos neste artigo.
Chegamos ao final da Sprint 1 e… um incremento bugado 1.0.0 é lançado. Daí, durante a Sprint 2, os bugs do incremento anterior começam a ser notificados, a equipe gasta grande parte do tempo corrigindo-os e é forçada a lançar uma versão intermediária 1.0.1 no meio da Sprint 2. Então, ao final da Sprint 2, um incremento 1.1.0 com novas funcionalidades é disponibilizada.
Provavelmente esta versão 1.1.0 estará ainda mais bugada que a versão 1.0.0, já que o tempo nela investido foi prejudicado devido à necessidade urgente de correção do incremento 1.0.0.
E o caos se instaurou
Acha que isso não vai te acontecer? Ah! Vai sim…isso eu posso te garantir.
A má notícia, entretanto, é que este problema permanecerá mesmo se você tiver uma equipe só para testes de aceitação. A única diferença será que a maioria dos relatos de bugs virão da equipe de teste, e não de usuários raivosos. Sob a perspectiva de negócios, isso já faz uma grande diferença. Para os programadores, contudo, dá na mesma. Talvez a única exceção seja o fato de que geralmente testadores são menos agressivos que os usuários. Geralmente.
Não existe uma solução simples para este problema, mas posso te dar algumas ideias do que pode ser feito.
Primeiro de tudo, maximize a qualidade do código que a equipe gera. O custo de encontrar e corrigir bugs cedo, durante a Sprint, é extremamente menor se comparado ao mesmo custo após o término da iteração. E para isso, não adianta prometer entregar 50 itens em duas semanas se o time só consegue entregar 20. Isso é suicídio coletivo.
Bom, mas mesmo melhorando a qualidade de código, erros ainda vão existir. Em menor quantidade, claro, mas ainda estarão lá prontos a estourar. Como lidar com isso?
Abordagem 1: “Usar uma Sprint só para correção”
Parece bom não? Mas não é. Por alguns motivos:
- O cliente não vai receber nada novo nesse período, pois você estará corrigindo coisas que já deveriam estar prontas.
- Quem é que garante que uma Sprint é suficiente?
- E como ter certeza que, as correções vão se encaixar no time-box da Sprint?
- E como saber se a correção não vai gerar mais erros? (Acredite, vai gerar sim!). E aí você faz o quê? Vai parar mais uma Sprint para corrigir os erros gerados pela Sprint de correção?
Você está com aquela sensação de estar perdido no meio do Jurassic Park prestes a ser devorado pelo T-Rex? Eu já me senti várias vezes assim…
Abordagem 2: “Acrescentar itens de correção junto com novos”
Basicamente quando terminamos uma Sprint, vamos para a próxima. Mas esperamos gastar algum tempo desta próxima Sprint consertando coisas da última Sprint. Se as próximas Sprints se tornarem severamente prejudicadas por causa do gasto excessivo de tempo na correção de bugs do última Sprint, devemos avaliar por que isto aconteceu e como podemos melhorar a qualidade: Automatizar testes? Revisão de código? Refatoração?
Também devemos ter a certeza de que as Sprints têm a duração suficiente para não serem impactadas por um punhado de tempo gasto consertando bugs da Sprint anterior.
Gradualmente, após um período de muitos meses, a quantidade de tempo gasto consertando bugs da Sprint anterior tende a diminuir.
Abordagem 3: “Montar uma equipe só para trabalhar com correções”
A ideia não é ruim, mas você vai precisar justificar porque vai precisar mais dois ou três recursos adicionais. E quando for falar que é porque os erros precisam ser corrigidos, pode ser que não receba uma resposta muito amigável do seu chefe.
Abordagem 4 – “Foco em construir novas coisas”
Esta é a abordagem que eu chamo de suicídio com requintes de crueldade. Ela simplesmente replica o modelo cascata, ou seja, vai construindo aí, e no final a gente vê no que dá.
É uma doença relacionada a pressão do projeto. Muitos Donos de Produto vindos do mundo cascata realmente não compreendem que quando toda a codificação terminar, você geralmente estará muito longe do release de produção. Então esse Dono do Produto pede para a equipe continuar adicionando novas funcionalidades enquanto a carreta de código das coisas “quase prontas” se torna cada vez mais e mais pesada, diminuindo a velocidade de tudo. E ao final, tudo vai pelos ares, porque é quase certo que o time levará o mesmo tempo que levou para construir só para corrigir os erros.
