Estimando com Scrum

É possível ter um certo nível de predicatibilidade utilizando Scrum. Podemos realizar estimativas de valor com o método. Isso pode ser atingido mesmo com uma certa rotatividade de recursos humanos da equipe. O único requisito é que as iterações tenham o tamanho fixo.

Falando de iterações com tamanho fixo isso é variável de projeto a projeto, empresa a empresa. O Recomendável é que isso fique de 1 a 4 semanas, pelo Scrum. Falando de RUP ou EVO por exemplo podemos ter iterações maiores, mas iterações mais curtas já se provaram mais produtivas.

A grande questão a se balancear é o overhead de se fazer a retrospectiva do Scrum e abrir a nova Sprint pois esses processos comem tempo! Mas uma vez você escolhendo o tamanho de sua iteração ou como o Scrum chama: Sprint, você deve utilizar esse padrão sempre.

Agora podemos estimar, o Scrum recomenda que utilizemos a sua medida abstrata que são os pontos, muitas pessoas utilizam isso em conjunto com User Stories ou até mesmo features. Eu particularmente prefiro utilizar Casos de Uso. Independentemente desta questão é a forma de estimar o Scrum por ser utilizando em iterações relativamente curtas utiliza uma medida abstrata como padrão mas você pode utilizar outra como Linhas de Código, Horas, Dias, Número de Telas, UCP, Etc...



Podemos realizar estimativas utilizando a técnica da temperatura do dia passado, no caso a Sprint passada. O processo funciona assim, no dia do planejamento da Sprint você precisa contar quantas pessoas e por quantos dias elas vão trabalhar.

Supondo que você utilize Sprints de 2 semanas e que você tenha 4 colaboradores trabalhando os dias da Sprint então teríamos uma tabela do tipo:



Aqui todos menos o Zelano estão trabalhando todos os dias da Sprint, veja que ele trabalha 4 dias a menos que os outros, isso pode ser por que ele tem que ira ao médico ou qualquer outro compromisso que ausenta ele do projeto. Essa tabela irá variar de Sprint a Sprint ora podem ter mais colaboradores ora menos ora mais dias ora menos e assim por diante.

Somando tudo vamos chegar o ManDays que significa a quantidade de Pessoas que vão trabalhar em tantos dias. Aqui nesse exemplo o total é de 36. Então aplicamos as formulas a baixo:



Sendo que a primeira Sprint é diferente pois você não tem Sprint passada para utilizar como entrada para essa, a sugestão que dou é colocar o fator de foco entre 40% e 60% ai depende da sua confiança quanto a essa sprint.

Então com o fator de foco podemos calcular o SEV(Estimativa de Velocidade da Sprint) que é calculado com a soma de todos os pontos da Sprint * o fator de foco. Lembrando que essa é a primeira estimativa, é difícil de acertar. Bom as coisas variam de projeto a projeto mas entre 3 e 5 Sprints é para as coisas se estabilizarem e o SEV tende a ser muito preciso ou muito próximo da precisão.

Agora da segunda a ultima Sprint do projeto você pode pegar o fator de foco da Sprint passada, lembre-se que a tabela de Mandays foi feita no inicio da sprint, então pode ser que alguém ficou doente ou saiu do projeto logo você deve atualizar essa tabela. Para calcular o Fator de Foco(FF) da Sprint passada você pega o total de pontos entregues e divide pelo Mandays realizado da Sprint passada então esse FF você pode usar na estimativa da próxima Sprint.

O FF é como se fosse a sua produtividade, falando de um modo geral. E esse valor vai se ajustando para mais ou para menos de Sprint a Sprint, a vantagem de utilizar esse mecanismo é saber se os pontos ou a maioria deles vão ser entregues nessa Sprint. Isso pode ser utilizado como dita o Scrum em sua forma pura para estabelecer se tais funcionalidades do sistema vão estar disponíveis ou não e pode ajudar na priorizarão, ou seja, saber se você pode entregar os pontos que o usuário deseja.

Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java