Dushy tem ouvido falar sobre Sprints de Estabilização e ficou pensando se elas eram a norma no mundo ágil. Sprints de Estabilização são uma porção de sprints adicionais ao final do ciclo normal de desenvolvimento e antes da entrega do produto. Como o nome sugere, elas costumam ser incluídas como uma última oportunidade de explorar o produto numa última busca por bugs.
Ilja Preuss diz que: "Uma sprint de estabilização é um sinal de que sua definição de pronto está incompleta ou não está sendo seguida."
Sarath Kummamuru destaca que vê alguns casos em que sprints de estabilização sejam apropriadas:
1. Para cuidar do débito técnico que tenha sido acumulado devido à pressa para completar um sprint! (basicamente refatorando a base de código existente ou melhorando a cobertura de testes unitários, etc).
2. Para cuidar do débito de garantia da qualidade (QA) que as equipes podem ter acumulado devido à falta de automatização e de regressões completas a cada sprint. Muito comum em empresas que trabalhem sobre bases de código legado e que não tenham muita automatização.
3. Para testes e certificação do produto que está sendo entregue em várias plataformas (digamos para certificá-lo em diversos servidores de aplicação, ou para diferentes plataformas de sistemas operacionais, etc).
4. Se houver algum empacotamento que precise ser feito (digamos, Cds para serem entregues, etc), isto pode ser tipicamente feito nestas sprints de estabilização/entrega.
Este autor percebeu que a aceitação de sprints de estabilização como necessárias é semelhante á dar as pessoas uma muleta e nunca mais ajudá-as a andar novamente. Pode levar alguns anos para automatizar os testes de todo o código existente, mas não há desculpa para viver com as coisas do mesmo jeito que estão. Além disso, qualquer código que não tenha testes de aceitação e de unidade automatizados é algo de qualidade duvidosa. Nós sabemos que se existirem bugs escondidos no código – isso é efetivamente um desperdício (do ponto de vista de Lean).
Edward Arunaj aponta: "Normalmente, se qualquer coisa está pendente, então estamos acumulando débito. Muitas vezes você pode precisar de mais do que uma sprint de estabilização e isso pode levar a incerteza quanto ao lançamento do release. (uma coisa que os stakeholders detestam mais do que atraso, é a incerteza)."
Mark Woyna nos dá um exemplo em que não é economicamente viável eliminar as sprints de estabilização. Um dado ambiente de teste com 800 servidores (avaliados em dezenas de milhões de dólares) deve executar cerca de 300.000 operações por segundo. Testes nestes servidores levam de 3 a 4 semanas para executar tal como a equipe precisa para simular o que acontece quando uma atualização seja lentamente propagada para todos os servidores. Entretanto, Mark enfatiza que este é um caso especial: "Eu concordo com você que este trabalho executado durante a sprint de estabilização nada mais é do que trabalho que não foi feito … Se o software é defeituoso, seria melhor você ter encontrado os problemas o quanto antes"
rather than later”
Finalmente, Steve Gordon diz:
Corrigir as causas principais deste trabalho defeituoso é o que melhora as coisas. Sim, nós também precisamos corrigir o problema imediato, mas se isso é tudo que você faz, os problemas vão retornar e você vai estar sempre convivendo com trabalho incompleto e com defeitos 'inesperados'.
Aceitar "sprints de estabilização" como algo corriqueiro, como uma prática normal, é meramente corrigir o problema imediato e aceitar que os mesmos tipos de problemas certamente irão acontecer novamente.
Anteriormente no InfoQ: "Pronto" é o mesmo que "entregável"?