Tamanho ideal de sprint/iteração (Scrum/XP)
Antes que comecem as críticas, quero deixar claro que o título escolhido foi proposital. Não por provocação, pelo contrário, mas para tentar abrir os olhos de quem ainda acredita que seguir à risca a bibliografia é sempre a melhor solução. E acaba ferindo (mesmo que cegamente) um dos princípios mais importantes da Agilidade: Adaptação.
Não me recordo o número, mas posso afirmar que não foram poucas as vezes que ouvi ou li alguém questionando sobre o tamanho dos sprints ou iterações. Se eram obrigados a trabalhar com 30 dias, ou se optando por um valor diferente estariam certos ou errados.
Para quem esperava uma solução simples e objetiva, sinto muito. A verdade é que não existe bala de prata, nem certo ou errado. Não existe um tamanho ideal que se aplique a todas as ocasiões. Cada caso é um caso. Mesmo em uma equipe que não sofre alterações de pessoal, um tamanho adequado para um projeto, pode não ter a mesma eficiência em outro.
O Scrum sugere sprints com 30 dias (um mês) de duração (“Do I need to stick to a month time frame?” em Scrum FAQ, ou na versão traduzida). O XP sugere ciclos semanais. Durante meu treinamento Certified ScrumMaster foi proposto sprints de 28 dias, pois facilita visualização em termos de semanas. Além desses, eu já tive oportunidade de trabalhar com sprints de 1 e 2 semanas. O que eu sugiro pra você: Experimente! Só assim você vai ser capaz de dizer o que é apropriado para cada ocasião. No mais, eu só posso citar alguns pontos que devem ser levados em consideração para a sua decisão:
- Escolha uma duração a qual seja agradável trabalhar, tal que a equipe consiga manter um ritmo sustentável. Sprints muito longos podem levar à procrastinação (Síndrome do Estudante). Já sprints muito curtos conseguem ser bem estressantes quando algum imprevisto acontece;
- Requisitos mudam com freqüência (i.e., o cliente muda os planos constantemente ou é incapaz de especificar com clareza o que deseja). Se for pra algo dar errado, que seja agora e não daqui 15 dias. Ou seja, quanto antes você perceber que esta no caminho errado, o esforço para voltar atrás é menor. E você só conhece esse caminho a partir do feedback, o que (geralmente) acontece mais frequentemente em sprints curtos;
- Semelhante as incertezas do cliente, deve-se ponderar as incertezas da equipe. Pois esta pode ser incapaz de dizer o quanto consegue trabalhar por iteração ou desconhece de aspectos técnicos do projeto;
- Da mesma forma que os requisitos podem mudar, o mesmo pode acontecer com suas prioridades. O seu tempo de resposta para eventuais mudanças esta intimamente ligado à duração dos sprints;
- Preparação (overhead) para os sprints. Suponha que antes de cada sprint todo o sistema precise passar por uma bateria de testes, ou que todo desenvolvedor deva reinstalar seu sistema e ambiente de desenvolvimento por medidas de segurança da empresa. Sem dúvida sprints curtos não são a melhor escolha nesse caso. O ideal seria reduzir ou eliminar estes impedimentos, mas nem sempre isso é possível.
Bem, se você tinha dúvidas com relação o tamanho dos seus sprints, espero esses tópicos sirvam como ponto de partida para uma possível mudança. Mas não esqueça que até mesmo as mudanças visando melhorias têm seus efeitos colaterais. Portanto, uma vez definida uma duração apropriada para seus sprints, respeite esse valor, pois só assim você será capaz de manter um ritmo (velocidade) de trabalho.
Inspect and Adapt!