A base do desenvolvimento ágil de software
O desenvolvimento ágil de software é, com exceção do caso mencionado abaixo, iterativo. Uma iteração é um período curto de tempo, de um mês até apenas uma semana. Na minha experiência, a duração média de uma iteração em diferentes equipes varia de um mês (o padrão do Scrum) até uma semana, que é a minha recomendação para um ciclo XP. Acredito que a tendência atual seja de duas semanas.
Mas estou fugindo do assunto. O elemento mais importante no Agile, a Conditio sine qua non, a condição necessária, o pré-requisito, aquilo que você deve fazer de qualquer forma, é:
A equipe deve entregar software funcionando, testado e integrado ao final de cada iteração; em Scrum, diríamos que ele deve estar "done-done"
Não há como escapar disso. Você não pode entregar algo apenas a cada duas iterações. Também não pode entregar software quase pronto e depois corrigi-lo na próxima iteração. Nem tente fugir disso. Você precisa entregar software.
Uma exceção
Se você pensou que encontraria aqui uma forma de escapar disso, pensou errado. A única exceção para entregar software funcionando em cada iteração é entregar ainda mais frequentemente. Algumas equipes de ponta trabalham atualmente em uma espécie de modo Kanban, onde entregam funcionalidades essencialmente de forma contínua, geralmente a cada poucos dias.
Desculpa, não tem como escapar disso
Software real, funcionando, integrada, testada, done-done – e isso em cada iteração, ou simplesmente de forma permanente. No caminho até lá, você vai precisar aprender o que tudo isso significa, e certamente vai encontrar dificuldades. Mas você também vai perceber que "done" significa mais do que você pensava. Claro que inclui o manual de instruções. Claro que inclui treinamentos para usuários. Claro que inclui tudo aquilo que você achava que não era possível.
Ninguém é perfeito
A sua equipe não é perfeita e provavelmente não vai conseguir fazer tudo isso em cada iteração. O que você definitivamente deveria fazer, no entanto, se ainda tem espaço para melhorar, é algo chamado "Inspect & Adapt" no Scrum. Kent Beck disse uma vez assim: "Encontre o seu maior problema, resolva-o à maneira do XP e repita o processo."
Se você precisar de ajuda com isso, busque essa ajuda.
E agora comece a entregar esse software!
Este texto é do blog de Ron Jeffries e foi traduzido por nós para o alemão.