No post passado aprendemos como estimar nossas funcionalidades para dar ao cliente um prazo. Somando as estimativas chegamos a um número final. Porém, como levamos em consideração o tempo que 1 desenvolvedor sozinho seria capaz de concluir cada tarefa, devemos agora dividir esse número pela quantidade de programadores na equipe
Finalmente, esse é o nosso prazo! Mas não se anime, o cliente quase nunca concorda.
Suponhamos que ele exija proponha um prazo menor. Teremos então que re-planejar nosso cronograma, ou seja, estabelecer o tempo de nossas iterações. Mas como saber se nossa equipe é capaz de fazer no tempo que ele pediu?
Com a certeza de que ninguém é produtivo por todo o tempo, usaremos uma fórmula baseada na velocidade da equipe para saber quanto tempo levaríamos para terminar um trabalho.
Na fórmula, a velocidade significa a porcentagem produtiva do tempo que temos. Por exempo, 0.7 significa que 70% do nosso tempo é realmente produtivo. Alguns livros dizem que esse é um bom número para começarmos. Depois conforme vamos obtendo os resultados, podemos reajustar o valor.
Vamos a um exemplo numérico para facilitar.
O cliente nos deu um prazo de 90 dias para entregar o sistema a desenvolver. Então podemos fazer 3 iterações de 1 mês. No entanto, tirando os finais de semana, nossa iteração de 1 mês equivalerá a 20 dias de trabalho.
Levando em consideração que temos 3 desenvolvedores na equipe, utilizaremos o seguinte cálculo:
O número acima é a capacidade real que nossa equipe tem de produzir num ciclo de 1 mês (20 dias úteis). E é com esse número que escolheremos as tarefas de cada iteração, não esquecendo a priorização feita pelo usuário.
Cada iteração deverá ter no máximo 42 dias de tarefas a realizar. Podemos colocar 4 tarefas de 10 dias e 1 de 2 dias, por exemplo.
Controlando o andamento do projeto.
Existe uma ferramente muito útil para saber como estamos nos saindo a cada dia que passa da nossa iteração. Essa ferramenta é o gráfico Burndown.
Burn Down Chart (Gráfico Burn Down)
O gráfico é utilizado para cada iteração que se inicia, colocando no eixo y (vertical) os dias de trabalho a realizar naquela iteração e no eixo x (horizontal) a quantidade de dias da iteração. A cada término de expediente o gráfico é utilizado ou então logo pela manhã quando o expediente começa.
Nele podemos observar o trabalho realizado, o que resta e quanto tempo já se foi. Além de nos dar uma visão de como anda nossa iteração.
Utilizando os métodos descritos acima, nossas chances de terminar o projeto a tempo aumentam.
Esse post foi escrito com base na leitura do livro Use a Cabeça: Desenvolvimento de Software e continua.
Bom Post
Mas, acho que o mais prudente seria dar peso aos programadores individualmente tendo em vista que eu sou mais rápido que vc e mais lento que o gabriel (kkkk), talvez devêssemos alterar a formula dando numero de 0.1 a 1.0 para cada programador, assim saberíamos com um pouco mais de assertividade, e com o tempo saberíamos melhor o numero individual e o de equipe.
Fala Wenderson, agora sim tá ficando legal! hehe
Até pensei nisso que você disse quando estava lendo o livro. Só que lembrei do que um professor de Métricas me disse sobre medir a produtividade da equipe. Cada funcionário é diferente dos demais e tem uma produtividade diferente. Temos dias bons e ruins, e medir a produtividade individual é algo mais complexo e tão inexato quanto medir da equipe como um todo. Se o “Corinthians” perder o cara vai vir trabalhar sem vontade, se brigou com a namorada também. Outra coisa é o fato de que quando profissionais sabem que estão sendo monitorados eles costumam entrar em “modo de segurança” e trabalham de forma diferente a qual seria no seu dia-a-dia. Portanto a medição não compensaria, já que medir a velocidade de cada desenvolvedor demanda muito mais esforço. Além do que, monitorá-los pode geral algum mal-estar não esperado.
Se o “Corinthians” perder o cara vai vir trabalhar sem vontade
o unico corintiano que trampa é o gabriel
mas mesmo gerando um desconforto eu, creio que esse desconforto é inicial, pois todo mundo sempre esta sendo medido, o programador vai acabar se acostumando e se motivando a aumentar seu índice, e de quebra ainda ganha um parâmetro para pleitear seu aumento, pois vamos pensar no Gabriel, lembra quando ele entrou no projeto da PMS? Ele nem sabia javascript? Sua produtividade era 0.1!!! cada vez que ele vai vendo esse numero aumentar ele vai se motivando a estudar mais, hj ele deve estar em um nível melhor que muitos programadores pleno!! (o orgulho do grupo Haw).
Se a monitoração não vier com postura de cobrança e sim simplesmente como forma métrica, eu sou plenamente a favor!
Sim, mas a grande questão não foi o desconforto e sim o fato de a falta de precisão em medir as pessoas individualmente ser igual a de se medir por equipe e fazê-lo dá muito mais trabalho do que na equipe como um todo. Claro que é uma questão de bom senso, se conseguir um processo rígido a ponto de tornar sua medição muito próxima da realidade deve valer a pena. Porém é complicado fazê-lo.
Abraços.
Pingback: Cat Suits For Women
Pingback: OpenOffice Download