Hoje vou exemplificar como se processa o planejamento scrum de um projeto e de um sprint.

Projeto

Os requisitos são levantados em reuniões de planejamento onde desenvolvedores,  product owner e todos aqueles que podem ajudar discutem em sessões de brainstorm o que o software fará.  Numa primeira vaga os requisitos , escritos como histórias, não são filtrados. Tudo é aceito e adicionado no backlog. Repetições são eliminadas assim como sobreposições de features. O backlog é limpo até que as histórias são, tanto quanto possível,  independentes umas das outras.

O backlog final é passado à equipe de desenvolvedores estimarem o esforço em pontos de história (Story Points). Para isso a equipe usa dias ideais e 1 SP equivale ao esforço necessário a um programador sênior totalmente focado  durante 1 (um) dia de trabalho. Um  dia de trabalho equivale a 8 (oito) horas.

O esforço do projeto é estimado pela soma dos esforços das histórias. Tomemos como exemplo 1221 pontos.  A equipe é formada por um sênior, dois plenos e dois júniors sendo que um dos plenos está alocado também a outro projeto e nem sempre pode participar dos sprints.

Primeiro Sprint

A equipe não se conhece e a sua velocidade é desconhecida. É estabelecido que os sprints serão de 2 semanas (10 dias úteis).

Em 10 dias úteis, um sênior fará, no melhor caso 10 SP já que estamos usando dias ideias. Mas como é impossível que ele tenha 100% de foco, sabemos que 10 dias equivalem na realidade a menos que 10 SP. O factor de foco é quem determina a equivalência. O factor de foco é a razão entre o tempo real e o tempo ideal. Uma equipe mediana tem 6h de produtividade  em cada 8h o que significa que tem um fator de foco de 6/8 , ou seja,  75%.

Então, as nossas expectativas não devem ser muito elevadas, sendo que a equipe não se conhece, consideremos que terão um foco de 75% e, portanto, cada membro , em 10 dias de sprint fará, no melhor caso 7 SP. Veja que 75% de 10 é 7,5 mas não arredondamos para cima. Nunca. Na realidade é o mesmo que considerar 70% de foco.

O pleno que participa de outro projeto só poderá entrar neste na segunda semana do sprint, pelo que ele esperamos que ele ajude a completar , em 5 dias,  3 SP  (75% de 5)

Os pontos que cada membro pode completar (queimar) é a velocidade pessoal v,  que é estabelecida pelo seguinte cálculo :

v = A * S * F

Em que A é o fator de alocação. Normalmente é 100% , mas para menbros da equipe que nem sempre estão presentes, ele é menor, podendo ser zero. Também, quando o membro está de férias, doente ou tem que se ausentar por algum período tempo,  este fator é menor.

S é o tamanho do sprint em dias úteis e F o fator de foco do membro da equipe.  Normalmente o fator de foco da equipe toda é usado nesta fórmula, mas o fator de foco individual pode ser usado se ele for conhecido. Contudo, isso requer um microgerenciamento do elementos da equipe que pode atrapalhar a comunicação, o foco, e o comprometimento da equipe como um todo.

A velocidade máxima do sprint, V , será portanto a soma das velocidades de cada membro da equipe.  No caso temos 4 (quatro) membros com alocação 100% , e um a 50% para um sprint de 10 dias e fator de foco de 70%.

4 * 100% * 10 * 75% + 1 * 50% * 10 * 75% = 30 + 3 = 33 SP

O nosso sprint terá, p0rtando velocidade máxima estimada de 33 SP.  Estabelecemos portanto um primeiro sprint de 33 SP. Se esta velocidade de mantiver o projeto precisará de 1221/ 33 = 37 sprints , que a 10 dias cada um são 370 dias ( mais de um ano). 75% de fator de foco é muito pouco. Mas como estimativa inicial não queremos ser otimistas demais.

Segundo sprint

O primeiro Sprint correu bem. Algumas histórias prioritárias do backlog tiveram que ser puxadas para o sprint e foram feitos 35 SP.  Isto significa que a velocidade foi na realidade um pouco acima do previsto

Se mantivermos esta velocidade, precisaremos de (1221 – 35  )/ 35 = 340 dias. Veja que 2 pontos a mais na velocidade significam 30 dias uteis a menos para a complitude do projeto.

Para o segundo sprint temos o mesmo cenário que antes com um dos plenos apenas podendo participar durante uma semana.  Fazendo os mesmos cálculos que para o primeiro sprint obteriamos 33 SP de novo. Mas como a equipe fez 35 pontos no ultimo sprint, talvez agora consiga fazer 34.

A equipe concorda que 34 é bem possivel e se compromente a aceitar um sprint backlog de 34 pontos.

Próximos

O processo continua. Antes de cada sprint é avaliada a alocação de todos os membros. É possivel também variar o tempo do sprint.  Ha medida que a equipe ganha experiencia e entrosamento com o projeto e uns com os outros o fator de foco tende a aumentar assim como a velocidade.  Estratégias como pair programing podem ser utilizadas para aumentar o foco, pois ao trabalhar juntas as pessoas se dispersam menos.

O efeito de arco

O Scrum obriga a ter uma versão utilizável do software no fim de cada sprint. Isso singifica que a cada inicio de sprint os desenvolvedores começam a alterar o software e durante um periodo de tempo ele não mais funciona. No fim do sprint ele está resconstituido de novo e com todas as features funcionando , tanto as que já estavam lá, como as que foram colocadas neste ultimo sprint.

Isto causa uma relação entre os dias do sprint e o “caos” do software. Ou seja, a desordem do software aumenta até um ponto onde ela é máxima e depois cai bem perto do final do sprint quando ele é reconstituido. Este “feito de arco” é muito importante que seja entendido. É por causa dele que durante o software a equipe não pode ser interrompida com novos requisitos ou alterações, pois isso pode introduzir um efeito de desordem maior, que não poderá ser reconstituido até ao final do sprint.

O “efeito de arco”  influência na escola do tempo para o sprint. Uma semana é tempo de menos para desmontar e reconstituir o software , mais de 4 semanas pode ser tempo demais para desmontar o software, não sendo depois mais possivel reconstitui-lo em tempo hábil.  É como, quando você é criança, e desmonta um carrinho a pilhas, existe um ponto, a partir do qual, se vc desmontar não consegue mais montar de volta, ou demora muito mais tempo que o que levou para desmontar.  De 2 a 3 semanas é o tempo ideal para o sprint porque ha tempo suficiente para desmonstar,mas não o suficiente para desmontar demais, mantendo assim a equipe no foco que é entregar o software, todo, funcionando de novo.

Entregas e Lançamentos

Antes de acabar quero falar um pouco da diferença entre entregas e lançamentos (releases).

No final de cada Sprint o software está pronto para entrega, mas isso não significa que ele é entregue. Uma demonstração é disponibilizada para a reunião de fechamento de sprint e para a reunião de inicio de sprint para ajudara a ajustar as prioridades do backlog pelo dono do produto e até para possiveis demonstrações a grupos de opinião e enquetes de mercado.

Contudo, o software só é realmente entregue quando o backlog está vazio.
Porque o backlog nunca está vazio, é criada a noção de lançamento (release). Um lançamento é um  sub conjunto das histórias do backlog. O tamanho do lançamento é fixo e o seu backlog sim vai ficar vazio. Coisas novas ou alterações podem ser adicionadas ao backlog do projeto, mas não ao do lançamento. O lançamento funciona na mesma mecanica dos sprints sendo ele constituido por sprints.

Depois de 2 sprints ( um mês , mais ou menos) o dono do produto já tem uma visibildiade maior de quanto demorará para completar o projeto como um todo, e decide separar o projeto em dois lançamentos.  Normalmente esta decisão é feitas antes dos sprints começarem, mas um replanejamento é sempre aceitável em scrum.

As histórias dos 1150 pontos restantes  são dividas em dois release logs o primeiro de 700 pontos e o segundo de 450.  A uma velocidade de 35 pontos por sprint e sprints fixos de 10 dias uteis, para o primeiro lançamento precisaremos mais  22 sprints. O que equivale a 220 dias, que é mais ou menos de 7 a 8 meses. Este é um prazo bem mais interessante que os 12 meses de antes. O segundo release , se mantiver o tamanho ( o que é provável que não) necessitará de mais 4 a 5 meses depois do primeiro. Mesmo que ele inche até aos 700 pontos em 16 meses teremos 2 lançamentos.

Esta dinâmica de lançamentos pode ter interesse para outras áreas como marketing pois permite passar uma ideia de atualização , frescor e continuidade para quem utiliza o software, mantendo o cliente interessado.
Esta mecanica é mais interessantes para projetos de software próprio ou para software que suporta o negocio do cliente, mas pode ser utilizado também em projeto on demand onde cada lançamento pode ser entendido como uma fase do projeto.

Espero que este pequeno exemplo tenha ajudado a explicar melhor a matemática por detrás do scrum, e que mostre que scrum pode ser utilizado em um vasto espectro de projetos.