Realizando estimativas de valor com Wideband Delphi

Estimar não é uma tarefa fácil e muito menos precisa. Se fosse fácil e 100% precisa essa técnica iria ser utilizada sempre por apostadores da Mega-Sena. :) Mas nem por isso podemos simplesmente virar as costas para a questão. Nesse caso não estimar não resolve o problema!

Nos posts anteriores:

• http://diego-pacheco.blogspot.com/2008/11/o-cho-de-um-projeto.html
• http://diego-pacheco.blogspot.com/2008/08/estimativa-no-exatimativa.html
  

Comentei de uma forma geral como poderíamos estimar utilizando outra abordagem, uma abordagem voltada ao comprometimento! Quais seriam os ganhos se adotarmos essa abordagem? Bom seriam vários mas posso destacar:

• Mais envolvimento com pessoas do negócio
• Informações mais realistas para tomadas de decisões
• Alinhamento total ao Planejamento Estratégico
• Visão de um horizonte maior facilita muito o planejamento ao curto prazo
• Melhor desempenho de *previsto* vs *Realizado*

Se você não der uma data para o Sponsor ou para o Cliente ele vai pensar em uma para você! Estimar não significa prever o dia exato da entrega, mas significa sim:

• Ter um contexto para saber como escalar o projeto (Número de Recursos)
• Ter uma noção do tamanho/complexidade/tempo do projeto
• Dar subsídios para ver se aumenta ou diminui o escopo
• Melhorar o ambiente de trabalho

Isso mesmo quando temos um planejamento, seja ele diário ou de duas semanas como é no SCRUM nos sentimos parte de algo maior e é mais proveitoso para os membros do projeto. Porem esse planejamento não é o suficiente, você pode usar apenas o planejamento do SCRUM se o projeto é pequeno, por exemplo se é um projeto de 1 ano.

Mas se o projeto é de mais de 2 anos, um planejamento de curto prazo como o do SCRUM se usado sozinho vai dar dor de cabeça para você! Precisamos de um planejamento de médio prazo, talvez 3, 4 ou até 6 meses a frente.



Pare agora mesmo!

Não estou falando de PERT. A questão aqui não é implementar uma gerencial tradicional para contruir software como se fosse navios. Também não estou indo ao extremo do agilista que quer acabar com planejamento maior que de 30 dias.

A questão é, você fazer palnejamentos de 30, 60, 6 mêses , 1 ano , 3 anos , 5 anos e não errar! Mas como? O grande segredo mora no nível de detalhamento, quanto mais ao longo prazo for o planejamento menos detalhes deve ter, quanto mais detalhes você tiver em um planejamento de longo prazo mais será a chance de você errar!

Surge o Wideband Delphi

Não tem nada a ver com a Linguágen de programação Delphi :). Se você deseja fazer uma planejamento de médio prazo e não possui muitas informações sobre o que se está planejando o Wideband delphi é uma boa técnica para você usar!

A técnica surgiu por volta de 1970, criada pelo grande Barry Boehm a técnica é classificada como uma técnica de esatimativas em grupo. As suas principais caracteriasticas são:

• Vários rounds de estimativas
  
• Anonimato
• Discutir os fatos, não persoadir as pessoas
• Diminuição da influencia politica
• Precisão em forma de intervalos
• Registro de premissas

Entre tantas outras vantagens, o método é muito livre, você poderia usar qualquer medida de valores, as pessoas estimariam usando essas medidas de valores, exemplo:

• Horas
• Dias
• Meses
  
• Pontos
• Linhas de Código
• Número de Requisitos

Entre outros, eu particularmente prefiro utilizar a técnica usando dias. E SEMPRE eu arrendo tudo pra cima, se deu 23,01 horas vira 1 dia. É sempre melhor arredondar pra cima. O ideal é acertar mas se você jogar pra baixo isso pode gerar um efeito devastador no projeto.

Por isso jogar para cima nos arredondamento em dias é uma boa idéia. A grande jogada do Wideband é que com ele o foco é no domínio da tarefa e na sua complexidade e não em quantas tarefas vão ser necessárias para se finalizar o item e nem em quem vai fazer.

Papéis

São só dois papéis o coordenador e os estimadores. O coordenador não deve estimar e deve ser o mais imparcial possível, deve evitar que as pessoas influenciem as outras. Os estimadores vão trabalhar em duplas.

Recomendo pelo menos 3 duplas, mas com 2 duplas já é possível realizar esse trabalho, acima de 4 duplas a coisa pode ficar complicada, você verá por que ao ler o 'como funciona'.

Como funciona?

1. É necessário criar os formulários de estimativas. Você pode pegar meu template!
2. O coordenador seleciona as duplas e apresenta o formulário de estimativas
3. Cada estimador vai estimar individualmente item a item, esse é a estimativa inicial
4. Cada estimador entrega sua estimativa inicial anonimamente ao coordenador.
5. O coordenador soma as estimativas e faz a média (Total de Dias/Total de Estimadores)
6. O coordenador mostra os resultados para os estimadores, mas só o total final em dias
7. Agora sim o coordenador monta as duplas e elas discutem e estimam item a item
8. Quando todas as duplas terminarem o coordenador faz a médias te todos os itens e mostra o total em dias.
9. Agora cada dupla escreve em um papel se concorda ou não, caso alguém discorde é iniciado outra rodada, se ninguém discordar o jogo terminara.
10. No Caso de existir um não o coordenador escolhe duas pessoas para falar sobre os problemas e as complexidades dos itens e voltamos ao passo 7.
    

Observações sobre os passos

1. Essa preparação inicial pode levar algum tempo, o gerente de projetos pode se envolver
nessa etapa. O Gerente de projeto ou até mesmo um Arquiteto pode ser o coordenador des
de que o mesmo não use o seu poder para influenciar as pessoas.

2. O coordenador que deve formar as duplas e sempre duplas diferentes, isso evita
panelinhas.

3. Esse passo é importante por que assim as pessoas pensam nos problemas de cada item,
isso vai facilitar na hora que elas formarem as duplas.

5. Isso deve ser feito item a item e o total deve ser a soma da media de todos os itens.

6. Isso pode ser mostrado em um quadro da seguinte forma, os números representam dias.

______________________________[I]____________________
+++++5+++++10+++++20+++++100+++++500+++++1000+++++5000

Onde o I são as estimativas iniciais. A primeira estimativa tende a ser a mais longa em dias,
depois a medida que os rounds vão passando as coisas tendem a se ajeitar.

8. A representação pode ser a mesma da anterior, porem é interessante manter as rodadas
anteriores, então a coisa ficaria assim.

____________________[R1]_______[I]____________________
+++++5+++++10+++++20+++++100+++++500+++++1000+++++5000

R1 indica que foi o primeiro round de estimativas.

9. Faça tipo de uma urna ou um chapéu e deposite os fotos das duplas lá, a pessoa deve
escrever "SIM" ou "NÃO" no papel. Se são 3 duplas, 3 SIM acabam com o jogo e temos
a estimativa final, se tiver um NÃO estimamos de novo.

Você pode mostrar as estimativas finais com um X.

____________________[R1]__[2X]__[I]____________________
+++++5+++++10+++++20+++++100+++++500+++++1000+++++5000

O Desenho a cima indica que em 2 rodadas se definiu a estimativa que será 100 dias.

Pontos Importantes

• Não realize esse processo perto do: horário de almoço ou da saida.
• Quanto melhor a quebra dos itens mais fácil é de acertar e mais demorado fica a sessão.
• Se não for bem balanceado esse processo pode demorar dias, bem balancedo você faz em meio turno.
• Todos podem e devem estimar: Desenvolvedores, Arquitetos, Analistas, Testadores, DBAs.
• As várias sessões nos dão um range e é muito provavel que o resultado final fique dentro desse range.

Sobre a Data final

No Wideband é impossível mexer na data final, sendo que a data final é a média de todos os itens estimados por todas as duplas, logo para mexer a data final devem ser mexidos nos itens de cada dupla. Isso é perfeito por que elimina a possibilidade daquele gerente malandro vir mexer na data com achometros, ele quer mexer na data? OK existem duas possibilidades.

Mexendo na Data Final

A data final é em dias, mas você terá algo do tipo 300 dias. Mas esses dias estão sem alocação de recursos, ou seja, é como se uma pessoa fizer-se sozinha todo o trabalho de forma cascata. Ai entra o gerente ele pode alocar os recursos e paralelizar algumas coisa e logo esses 300 dias de repente podem virar 190!

Cuidado! Colocando muitas pessoas não faz com que os dias caiam pela metade ou menos da metade, desconfie se você ver esse tipo de coisa.

E por fim a outra possibilidade que falei seria mexer nos itens, como?

• Eliminado itens
• Postergando o desenvolvimento de alguns itens
• Diminuindo requisitos ou funcionalidades de itens

Se você realizar alguma mudança que nem esse ultimo tipo de mudanças que mostrei você terá que estimar de novo. As estimativas feitas já não são mais válidas nesse contexto.