A Arte deEstimar Um dos grandes desafios deprofissionais da area de desenvolvimento de software e como estimar o esforcopara a criacao de novas funcionalidades, tarefas ou estorias. O principalobjetivo de se estimar e ser criar uma metrica comum para definicao ecomparacao de esforcos, e consequentemente definicoes de prazos (e orcamentos)para projetos e/ou atividades.Temos diversas formas de estimarsoftware desde os antigos KLOCs ( KiloLlinesof Code ou mil linhas de codigo), homens hora, pontos de funcao entreoutras. Estimar e FUNDAMENTAL ! mas vemos que grande parte do esforco empreendidoem estimar com precisao e perdido, ou devido a alguma premissa que nao setornou verdadeira ou porque a medida que trabalhamos no projeto, com maisconhecimento, ajustamos nossa estimativa. As formas mais comuns emestimativas sao as apresentadas pelo PMBok, guia de Boas Praticas do Project Management Institute e sao apresentas abaixo:Estimativa de um ponto: Apresentaa estimativa por atividade. Pode ser baseada na opiniao especializada,informacoes historicas ou simplesmente adivinhacao.Estimativa Analoga (Top Down): Usam opiniaoespecializada e informacoes historicas para prever o futuroEstimativa Parametrica: Observaos relacionamentos entre as variaveis em uma atividade para calcularestimativas.Estimativa de Tres Pontos(Analise PERT): Considera a mediaentre a estimativa no melhor cenario (O), adicionada a quatro vezes aestimativa mais provavel (M), mais a estimativa do pior cenario (P) , dividopor seis. ( P + 4M +O ) / 6Atividades de desenvolvimento de software geralmente sao bem maiscomplexas do que atividades da construcao civil (como uma pintura de corredor),pois em um novo projeto de software, os requisitos nunca serao completamente conhecidosate que o usuario os tenha utilizado, assimo grande desafio nas estimativas de software esta relacionado as dificuldadesda clara definicao do escopo do produto, da definicao da estrategia de como umaatividade sera realizada e pelo simplesfato que em um grupo distinto, a experiencia, conhecimento tecnico, cultura,etc. irao influenciar na estimativa de cada um, por isso todas as estimativastendem a apresentar erros. Lembre-se que quando utilizamos horas ou dias comounidade de medida, estamos estimando nao so o esforco necessario para a tarefamas tambem a velocidade individual dos membros que trabalharao nela.A comunidade adepta de Frameworks Ageis (como SCRUM ou o XP), geralmente, procura utilizar estimativas que levamem consideracao apenas o esforco para a realizacao de determinada tarefa, ondetodos os envolvidos no desenvolvimento, medem as diversas tarefas e assimdefinem estimativas comparativas (com margens de erro) entre todo o trabalhoque precisa ser realizado.Veja a historia relatada por JamesSurowiecki que em seu trabalho intitulado A Sabedoria dasMultidoes conta uma experiencia realizada em 1906, quando o cientistabritanico Francis Galton ficou chocadocom o resultado de um experimento que ele realizou em uma feira municipal. Odesafio era que um acougueiro profissional deveria adivinhar com precisao opeso de um boi abatido. Sua surpresa ocorreu ao descobrir que pessoas que visitavam a feira (com pouca ou nenhumaexperiencia em cortes de carne) eram capazes nao so de adivinhar o peso finaldo animal, mas eram capazes de adivinhar com grande precisao (inclusive comquilogramas e os detalhes em gramas).A expectativa de Sir Francis eraque os peritos (acougueiro profissional) estavam sempre bem e iria superar comfolga uma multidao, o que nao ocorreu.Quando estamos jogando o Planning Poker, nos igualmente estamosaproveitando