A Arte de Estimar
Autor: Rafael Ribeiro | Publicado: 2012-11-06T04:13:00-08:00



A Arte de
Estimar 









Um dos grandes desafios de
profissionais da área de desenvolvimento de software é como estimar o esforço
para a criação de novas funcionalidades, tarefas ou estórias. O principal
objetivo de se estimar é ser criar uma métrica comum para definição e
comparação de esforços, e consequentemente definições de prazos (e orçamentos)
para&nbsp; projetos e/ou atividades.



Temos diversas formas de estimar
software desde os antigos KLOCs ( KiloLlines
of Code ou mil linhas de código), homens – hora, pontos de função entre
outras. Estimar é FUNDAMENTAL ! mas vemos que grande parte do esforço empreendido
em estimar com precisão é perdido, ou devido a alguma premissa que não se
tornou verdadeira ou porque a medida que trabalhamos no projeto, com mais
conhecimento, ajustamos nossa estimativa. 



As formas mais comuns em
estimativas são as apresentadas pelo PMBok®, guia de Boas Práticas do Project Management Institute® e são apresentas abaixo:



Estimativa de um ponto: Apresenta
a estimativa por atividade. Pode ser baseada na opinião especializada,
informações históricas ou simplesmente adivinhação.



Estimativa Análoga (“Top Down”): Usam opinião
especializada e informações históricas para prever o futuro



Estimativa Paramétrica: Observa
os relacionamentos entre as variáveis em uma atividade para calcular
estimativas.



Estimativa de Três Pontos
(Análise PERT): Considera a média
entre a estimativa no melhor cenário (O), adicionada a quatro vezes a
estimativa mais provável (M), mais a estimativa do pior cenário (P) , divido
por seis. ( P + 4M +O ) / 6



Atividades de desenvolvimento de software geralmente são bem mais
complexas do que atividades da construção civil (como uma pintura de corredor),
pois em um novo projeto de software, os requisitos nunca serão completamente conhecidos
até que o usuário os tenha utilizado, &nbsp;assim
o grande desafio nas estimativas de software está relacionado às dificuldades
da clara definição do escopo do produto, da definição da estratégia de como uma
atividade será realizada &nbsp;e pelo simples
fato que em um grupo distinto, a experiência, conhecimento técnico, cultura,
etc. irão influenciar na estimativa de cada um, por isso todas as estimativas
tendem a apresentar erros. Lembre-se que quando utilizamos “horas ou dias” como
unidade de medida, estamos estimando não só o esforço necessário para a tarefa
mas também a velocidade individual dos membros que trabalharão nela.



A comunidade adepta de Frameworks Ágeis (como SCRUM ou o XP), geralmente, procura utilizar estimativas que levam
em consideração apenas o esforço para a realização de determinada tarefa, onde
todos os envolvidos no desenvolvimento, medem as diversas tarefas e assim
definem estimativas comparativas (com margens de erro) entre todo o trabalho
que precisa ser realizado.



Veja a história relatada por James
Surowiecki &nbsp;que&nbsp; em seu trabalho intitulado “ A Sabedoria das
Multidões” conta uma experiência realizada em 1906, quando o cientista
britânico Francis Galton &nbsp;ficou chocado
com o resultado de um experimento que ele realizou em uma feira municipal. O
desafio era que um açougueiro profissional deveria adivinhar com precisão o
peso de um boi abatido. Sua surpresa ocorreu&nbsp;
ao descobrir que pessoas que visitavam a feira (com pouca ou nenhuma
experiência em cortes de carne) eram capazes não só de adivinhar o peso final
do animal, mas eram capazes de adivinhar com grande precisão (inclusive com
quilogramas e os detalhes em gramas).



A expectativa de Sir Francis era
que os peritos (açougueiro profissional) estavam sempre bem e iria superar com
folga uma multidão, o que não ocorreu.



Quando estamos jogando o Planning Poker, nós igualmente estamos
aproveitando a sabedoria das multidões com relação a nossas estimativas.
Estamos apostando que o público será capaz de chegar a um &nbsp;melhor palpite do que qualquer indivíduo único.





O Planning Poker&nbsp; é uma técnica
de estimativa baseada no consenso de toda a equipe, onde é utilizado um
conjunto de cartas com valores específicos (pontos) relativos. Uma pessoa
apresenta a tarefa ou estória para o time, e, após uma breve discussão, cada um
escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as
cartas estiverem lançadas, elas são viradas e caso não haja consenso nos
valores escolhidos, as diferenças são discutidas de forma breve, geralmente
quem estimou com os maiores e menores valores explicam o motivo de sua
estimativa, e uma nova rodada acontece até que haja a convergência.





Cartas utilizadas no Planning Poker






O Planning Poker funciona porque&nbsp;
utiliza opinião de diversos especialistas ( que irão realmente realizar
a tarefa), promove o diálogo que permite maior acuracidade
das estimativas, principalmente em itens com maior incerteza. Além de ser uma
técnica de estimar considerando a experiência de todos da equipe, proporciona
um conhecimento do negócio mais homogêneo&nbsp;
e é mais atraente (e divertida) que as demais técnicas.







Gráfico da Sequência
de Fibonacci






Geralmente o baralho do Planning Poker apresenta cartas com
escala da sequência de Fibonacci, isso se deve ao fato da sequência de Fibonacci
ser uma função quadrática, ao invés de uma função linear, assim, as diferenças
entre valores são produzidas de forma muito rápida criando intervalos logo no
início da sequência, veja que as estimativas apresentam erros, mas quando
podemos comparar as tarefas (uma tarefa com 8 pontos não significa que ela tem
exatamente este tamanho mas é algo entre 5 e 13 pontos) conseguimos dimensionar
com mais precisão o esforço que deverá ser empreendido.





Rafael Dias Ribeiro

http://www.rafaeldiasribeiro.com.brMestre em Sistemas e Computação , IME

Project Management Professional, PMI

Certified Scrum Master, ScrumAlliance

Certified Scrum Product Owner, ScrumAllianceCertified COBIT, ISACA