Scrum é uma mecânica agil de gerenciamento um pouco mais dura que os processos tradicionais e menos leniente que as metodologias ageis de desenvolvimento. Afinal é para gerenciamento.
Gerenciar significa prever e corrigir a rota antes que o dano aconteça. Para isto funcionar é preciso ter capacidade de previsão. Veremos o que Scrum oferece nesta área.
Scrum é baseado no Produto Backlog que é um conjunto de estorias que têm tamanho. Portanto um produto backlog tem tamanho igual à soma das suas estorias. Este tamanho é estimado antes de começar o processo de desenvolvimento pela equipa de desenvolvedores em Story Points.
As previsões se baseiam em dois pilares : custo e prazo.
Para um sistema de prazo fixo, que é a maioria, não ha que estimar o prazo, já que ele é conhecido e fixo. Portanto resta aqui prever quanta funcionalidade será possível implementar nesse prazo.
Para sistemas de prazo aberto ele vai depender de implementar todas as funcionalidades do backlog. É sabido que nem todas serão implementadas, porque mudarão, mas o tamanho do backlog é fixado.
Com prazo fixo, o backlog é dividido em 1 ou mais releases tal que o ultimo release coincida com o prazo final. Isto gera N releases de tamanho fixo.
Se o prazo é aberto, o tamanho é fixado , o que também gera N releases de tamanho fixo.
Portanto, veja-se como se vir, em Scrum sempre trabalhamos com 1 ou mais releases de tamanho fixo. Tamanho fixo significa que a soma das estorias de cada realease é fixada. As historias em si podem entrar e sair do backlog livremente. Por exemplo, se temos um backlog com as estorias A (10), B(30) , C(100) e D(20) teremos um tamanho de 150 SP. Se quisermos introduzir a estoria E(20) temos que fazê-lo às custas de retirar ou remanegar as outras. Por exemplo , podemos retirar D e colocar E. Podemos retirar B e colocar E, ficando um espaço de 10 SP que pode ser depois alocado para uma futura estoria F. Podemos partir a estoria C em C1(30) e C2(70) e excluir C1. Tudo é remanejável, excepto o tamanho do backlog.
Após todo este remanejamento ha o estabelecimento de um compromisso de que aquele tamanho final será aquele que será executado. Isto significa que na prática o tamanho pode até aumentar, mas o compromisso, o contrato, é entregar aquele numero de pontos.
Entenda-se que tudo isto é uma estimativa. Na prática estes valores irão sendo ajustados devido às correções de rota , mas o que estamos interessados agora é poder estimar quando será o final da viagem.
Bom, temos o tamanho do Product Backlog, T em Story Points. Precisamos de uma forma de converter isto em tempo. O Scrum define períodos fixos de tempo em que o desenvolvimento será dividido chamados Sprints. Normalmente a duração,D, do Sprint será de 15 a 30 dias uteis.
Para cada Sprint a equipe irá implementar estorias. Os pontos destas estórias serão contabilizados e removidos do backlog. É como uma vela que derrete à medida que o fogo queima o pavio. O backlog diminui à medida que a equipa implementa as funcionalidades relativas às estorias.
Portanto, para cada Sprint a equipa terá uma Velocidade, V. A velocidade é o numero de pontos de estoria (SP) que a equipa remove do backlog por sprint e mede-se em SP/Sprint.
Primeiro calculamos quantos Sprints , S, serão necessários .
S = T / V
Cada sprint conta com 1 dia de planejamento do inicio e no fim para as reuniões de inicio e de fim de sprint. Portanto, para cada Sprint necessitamos de D +2 dias. Estes dias de reunião podem ser mais ou menos na prática pois cada equipe tem uma dinâmica diferente, mas nunca podemos desprezá-los. Algumas empresas dão um periodo de um dia para “alivio” da equipa. Neste dia cada membro comparece como nos outros, mas dedica-se a alguma projeto pessoal, ou alguma prova de conceito, ou a qualquer trabalho que queira e a empresa permita. São dias de laboratório, de palestras, apresentações, etc.. que uns membros fazem com/para os outros e entre equipas. A finalidade é abrir a comunicação e disseminar o conhecimento e as experiências.
Portanto a quantidade de dias uteis necessária é :
U = S * (D +2)
Colocando isso no calendário real, tendo cuidado com feriados, pontes, fins de semana e demais dias não úteis, chegaremos na data prevista para o fim do projeto.
Nas metodologia tradicionais métricas são usadas. Pela própria definição de métrica é algo calculado baseado em inputs numéricos. Os pontos de função ou os pontos de caso de uso são exemplos destas métricas. Estas métricas são frias, ou seja, elas não levam em consideração a equipa e a tecnologia que será utilizadas. Em Scrum isto é levado em consideração pois é a equipa que estima o tamanho das estorias. Ela faz isso porque se conhece e sabe do seu conhecimento das tecnologias.
As métricas tradicionais exigem que se faça uma analise prévia e microscópica para poder aplicar os critérios. Quanto mais detalhada é esta analise melhor a acurácia da métrica. Contudo existe um trade-off entre o tempo que é usado para levantar esses detalhamento e o detalhamento. Isso sempre nos coloca na posição de não poder ir até ao fundos dos detalhes. Scrum aceita isto e não pretende ir até ao detalhe. Contudo em scrum também é feita uma analise. Esta analise é a própria criação do Product Backlog. um produto backlog com a estoria “Fazer um sistema de contabilidade” é obviamente pouco detalhe. Um com 1000 estorias é com certeza detalhado demais. Aqui o tamanho das historias pode ajudar a saber se está detalhado o suficiente. Valores acima de 20 SP indicam que a estoria não é compreendida o suficiente e precisa ser mais detalhada. Mas às vezes colocar historias com tamanho grande é feito de propósito ( os temas).
O ponto é que tanto em Scrum como nas metodologias tradicionais é preciso conversar com o interessado no software e chegar a um nivel de detalhamento que nos mostre o que o software terá que fazer e os principais riscos/desafios que teremos que enfrentar.
Toda e qualquer estimativa está sujeita ao Cone de Incerteza e as estimativas Srum não são diferentes. O ponto é que , embora seja uma metodologia ágeis, Scrum permite fazer previsões e aceitar compromissos a longo prazo. Afinal, compromisso é a alma mater do Scrum.
Conhecer e dominar a metamática por detrás do Scrum permite fazer estimativas poderosas de forma simples. O problema só se coloca que a equipa é nova e não se conhece a sua velocidade. Nesse caso a estimativa de dias ideais pode ajudar.
É um conceito errado que Agil não provê mecanismos deterministas. Bem pelo contrário. Os mecanismos ágeis são mais deterministas que os tradicionais. Scrum tira proveito disso de forma eximia para auxiliar a gestão do projeto.