Uma vez que já escrevemos um conjunto de histórias e já as estimámos, podemos começar a pensar numa release. Ok, uma mini-release, mas não se esqueçam que é um exemplo, os nossos dois programadores estão atolados em trabalho por isso vão levar tempo a concretizar as histórias... extrapolem!! ;)
O facto é que uma vez tendo as histórias, a pergunta do cliente mais natural é: "Quanto é que temos isto pronto?". Ou, talvez mais provável, já temos uma data definida à priori e temos de ver como encaixar as histórias nessa data... :) De qq das maneiras, para podermos realizar o planeamento da release, falta-nos uma peça. Como mapear as estimativas, que são realizadas em dias ideais, em dias reais, em esforço real? É aqui que entra o conceito de Velocidade.
A Velocidade é o número de dias ideais que pode ser realizada numa iteração do projecto (uma release é constituída por um conjunto de iterações, mas estamos a adiantarmo-nos...), ou seja o esforço que pode ser dispendido numa iteração. Sabendo que uma iteração costuma ter a duração de uma a quatro semanas reais, é necessário estimar o número de dias ideais que cabem neste período. Muito bem, mas então como estimamos a velocidade??
A dificuldade está na primeira estimativa, dado que não temos nada de concreto (o projecto ainda não começou) em que nos basear. Existem pelo menos três soluções: Usar dados históricos; Fazer uma primeira iteração para chegar a um valor; Atirar um número para o ar.
Utilizar dados históricos é uma boa hipótese, mas tem alguns problemas. O principal é que é relativamente raro uma mesma equipa fazer projectos muito semelhantes consecutivamente. No entanto, se esse for o caso, tire-se partido disso! Atenção que um projecto semelhante feito por uma equipa diferente pode não ser uma boa base para definir a velocidade, dado que as características da equipa podem ser diferentes.
Realizar uma primeira iteração também seria uma boa hipótese, mas não será muito realista. Quantas vezes é que já conseguiram dizer a um cliente: "Olhe, vamos trabalhar umas semanitas e depois logo decidimos como será o desenrolar o projecto daí para a frente." e ele não se desatou a rir? Bom, mas se tiverem essa possibilidade aproveitem, potencialmente pode ser a melhor solução.
Atirar um número para o ar, não é mujito agradável, mas também não é o fim do mundo. Por vezes, não há outra possibilidade. Nesta situação, o facto de utilizarmos como estimativas dias ideais ajuda bastante. Para chegar a um número para a velocidade, ajuda tentar contabilizar a foram como os elementos da equipa têm gasto o tempo ultimamente - tarefas recorrentes; outros projectos em que estejam empenhados; trabalho ad-hoc - e com base nisso chegar a um número.
É importante tentarmos chegar a um valor minimamente realista, mas não tem de ser perfeito nem este número tem de ser um dogma. Se o fosse, deixava de ter qualquer relevância... quem consegue prever o futuro com 100% de correcção são os videntes, não somos nós, pobres informáticos.
Pegando no nosso exemplo, e dado que os nossos programadores estão assoberbados de trabalho, a velocidade definida é de 4 dias ideais. Ok, a velocidade estimada é uma miséria, mas é o possível... O chefe não quer contratar mais gente, dá nisto....
Uma vez obtida uma velocidade inicial, podemos começar a pensar em fazer um release plan.
Posted
12-2-2006 12:30
por
João Hugo Miranda