O Scrum possui 5 eventos ou cerimônias em seu framework, dos quais, todos são obrigatórios. Esses eventos são todos “Time-Boxed”, tem tempo máximo definido. Apenas o Sprint, uma fez definida a sua duração, ela é fixa e não pode ser encurtado e nem alongado, os demais eventos, podem ser encerrados antes, desde que o seu objetivo tenha sido alcançado.
Esses eventos servem para manter os 3 pilares do Scrum, que são a transparência, inspeção e adaptação, não realizar ou realizar somente parte dos eventos, irão prejudicar esses 3 pilares.
Se caso a empresa ou a equipe decidir não realizar algum destes eventos, por julgar desnecessário, deve-se repensar se a empresa está preparada para o Scrum ou as pessoas não entenderam o Scrum, pois retirar qualquer um destes eventos não é possível implantar o Scrum na empresa. Lembre-se, o Scrum é fácil de entender, mas difícil de dominar.
Os eventos são:
- Sprint
- Planejamento da Sprint (Sprint Planning)
- Reunião Diária (Daily Scrum)
- Revisão da Sprint (Sprint Review)
- Retrospectiva da Sprint (Sprint Retrospective)
Começaremos com o evento principal, o coração do Scrum: The Sprint.
The Sprint
A Sprint é o principal evento do Scrum, que significa em tradução literal como corrida de velocidade, arrancada. Esse evento trata-se de um ciclo de desenvolvimento (iteração), que tem um tempo determinado com dia para começar e dia para acabar. Esse tempo pode variar de 2 a 4 semanas, mas nunca exceder 30 dias. Uma Sprint começa ao final da Sprint anterior, sem intervalos.
O objetivo deste evento é transformar os itens do Backlog do Produto (funcionalidades descritas) em um software ou parte dele, totalmente funcional e pronto para uso, dentro do período definido para a Sprint.
O tempo da Sprint sempre será definido em dias corridos, sem descontar finais de semana e feriados. Deve ter uma duração de 2 semanas (14 dias corridos) à 4 semanas (30 dias corridos). Duração menor do que 14 dias pode ser insuficiente para construir um software ou parte dele, totalmente funcional e pronto para uso, por isso não é recomendável, porém é possível. Duração maior do que 30 dias, pode aumentar consideravelmente o risco, pois mais do que 30 dias alguns requisitos e prioridades poderão ser alteradas e o tempo para se obter um feedback do cliente é muito longo e a chance de descobrir que estava errado é grande.
Recomenda-se também que a duração seja constante do início ao fim do projeto, ou seja, uma vez definida a duração da Sprint, que esse seja o mesmo até que todo o Backlog do produto seja finalizado, assim ficará mais fácil calcular a velocidade do time e o tempo das liberações para produção.
Outra recomendação é que times mais novos no Scrum façam Sprints maiores, de 30 dias no início, pois terão mais tempo para se adequar as regras do Scrum e um tempo maior para entregar o que foi selecionado para a Sprint. Conforme o time ganha maturidade, esse tempo pode ser reduzido para 3 semanas e depois para 2, tornando assim as entregas mais constantes.
Um produto completo poderá ter inúmeras Sprints, quantas forem necessárias até que o backlog do produto seja finalizado (se é que ele for finalizado algum dia). Ao final de cada Sprint, é liberado um software ou parte dele, pronto para o uso, porém isso não quer dizer que será liberada uma versão final, que vai para produção.
Parece estranho, pois se já está pronto, porque não posso ir para produção direto?
Em empresas menores, normalmente Startups, a tendência é que no final de cada Sprint, seja realizado um deploy em produção. Contudo, em empresas maiores ou com arquitetura mais robusta, isso não é possível, pois existem períodos de atualização, elas não podem ocorrer a qualquer momento. É normal então, que nos casos de atualizações periódicas, as Sprints sejam programadas de forma a atender esse calendário de atualização, porém, não impede de que parte da solução seja entregue, pronta e funcional, em um ambiente de testes ou de treinamento.
Vou exemplificar melhor: supomos que estamos desenvolvendo uma solução para um cliente, no qual só atualiza a versão dos sistemas a cada 3 meses. O desenvolvimento completo da solução irá levar, pela estimativa inicial, 6 meses. Nesta situação, poderemos planejada da seguinte forma:
- Para entregar a solução serão necessárias 6 Sprints de 30 dias cada (6 meses).
- Iremos planejar as liberações para produção (releases) a cada 3 Sprints (3 meses).
Desta forma, a cada 30 dias, parte do software (incremento) é liberada em um ambiente de testes, para que o cliente possa ter contato com o sistema, avaliar se o mesmo está ficando da forma desejada. Além disso, a cada 30 dias ele poderá redefinir a prioridade dos itens do backlog do produto que ele deseja ter na primeira release que irá para produção.
Por alguns acreditarem que a cada final de Sprint o produto deve ir para produção é que fica a dúvida se o Scrum serve para grandes projetos em grandes corporações. A resposta é sim, e digo que e muito melhor fazer desta forma, incremental e iterativa, entregando parte da solução rapidamente, até para avaliar se o caminho está certo e se não haverá mudanças no caminho.
Por fim, o Sprint é a parte central do Scrum e envolve os outros 4 eventos, que são realizados dentro da Sprint.
Resumindo, Sprint é o principal evento do Scrum, seu coração. É um evento time-boxed, com duração fixa, que não pode ser encurtado ou alongado, que tem o objetivo de criar incrementos do software, com base no Backlog do Produto. Ao final do mesmo, é entregue um incremento do software totalmente funcional e pronto para o uso. A Sprint engloba todos os demais eventos, que devem ser realizados dentro do período de tempo da Sprint.
Até a próxima, onde escreverei sobre os demais eventos do Scrum.