Scrum para Tradicionalistas – Previs√Ķes 

Nov/09
13

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.

Como isto se compara com as metodologias tradicionais ?

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.

Comente

Artigos