BT

É mesmo possível estimar software?

por Eder Ignatowicz em 01 Mar 2013 |

Em um post recente do seu blog, Martin Fowler questiona o propósito das estimativas em software. O propósito das estimativas é resumido no seguinte cenário:

Digamos que uma estimativa seja solicitada aos desenvolvedores para um determinado trabalho. Esses desenvolvedores, que são naturalmente otimistas, tendem a estimar para baixo. Isso acontece mesmo que não sofram, pelo menos explicitamente, pressão para reduzir suas estimativas. Em seguida, as tarefas estimadas se tornam planos de desenvolvimento, monitoradas por um gráfico de burn-down.

Fowler lembra o gasto de tempo e esforço para monitorar o progresso do desenvolvimento com relação ao plano inicial, e que todos se frustram quando o trabalho realizado é maior que o estimado. E em muitas situações, para adequar o ritmo do desenvolvimento às estimativas, a qualidade é sacrificada deixando as coisas ainda piores.

Fowler aponta dois efeitos colaterais das estimativas: devoção a funcionalidades e geração de expectativas. A devoção a funcionalidades ocorre quando a equipe de desenvolvimento começa a valorizar mais a conclusão de tarefas do que a entrega de valor real ao cliente. E a divulgação de estimativas tem como subproduto a geração de expectativas no cliente. Além disso, existe o risco das estimativas serem inferiores ao trabalho real e, qualquer que seja o aumento do tempo ou redução escopo, acarretará frustração ao cliente.

Esse ciclo vicioso de estimar, falhar e sacrificar a qualidade, segundo Fowler, produz em alguns agilistas a visão de que estimativas são nocivas, e que parte da comunidade ágil acredita que um profissional que realiza estimativas não é verdadeiramente ágil.

Embora Fowler apresente em seu texto cenários em que a estimativa é benéfica ao projeto e, em muitos casos, excelentes ferramentas de apoio a decisões, é importante também realizar uma análise ampla e apontar questionamentos às estimativas, especialmente em projetos de software.

No trabalho Limites amplos na estimativa de software de J.P. Lewis, é apresentado um modelo matemático que prova que é impossível medir software com precisão. Resumidamente, a proposta do autor é baseada na ideia de que especificações são compostas de strings arbitrárias. O artigo demonstra que é impossível o cálculo de complexidade de um algoritmo que gere strings arbitrárias. Com base nessa premissa, o autor conclui que, a partir de uma especificação, não é possível medir o tamanho de um software, sem que seja admitido certa imprecisão; ou seja, não existe estimativa de software 100% precisa.

No artigo Uma revisão das pesquisas em estimativas de esforço em software (Kjetil Moløkken and Magne Jørgensen), foi realizado o estudo de técnicas de estimativas de software, e os autores apresentaram conclusões interessantes:

A maioria dos projetos apresenta problemas de estimativas de esforço ou prazo..., mas o tamanho desses problemas é menor do que apresentado por algumas consultorias. O método de estimativas mais utilizado é o sentimento ou instinto de especialistas. Isto é resultado da falta de evidências formais provando que modelos de estimativas geram estimativas mais precisas.

Embora dignos de atenção, esses fatos não invalidam necessariamente o processo de estimativa de software. Voltando ao texto do Fowler, são apresentados alguns cenários em que a estimativa é útil e muitas vezes valiosa. Exemplos dessa aplicação seriam cenários de tomada de decisões e esclarecimento de requisitos durante as reuniões de estimativas.

Siobhan Keaveney e Kieran Conboy, no artigo Custo de estimativas no desenvolvimento de projetos ágeis, demonstram que quanto menores as iterações (tanto em escopo quanto em tempo), maior será a precisão das estimativas de um projeto.

Através da análise de quatro projetos, os autores afirmam que estimativas em iterações curtas, são mais produtivas e eficientes do que estimativas de longo prazo. No trabalho, os autores ainda recomendam projetos com orçamento fixo, na qual a variação ocorre ou em escopo ou em prazo. O autor ainda segue com algumas recomendações:

  • Modelos ou metodologias de estimativas não são pré-requisitos do processo de estimativa;
  • Preço fixo é a melhor opção para desenvolvedores e consumidores;
  • Os fatores determinantes à precisão de uma estimativa são: a experiência do profissional que realizará a estimativa do projeto e a existência de dados relativos a projetos semelhantes executados anteriormente na empresa.

Fowler afirma que estimativas não devem ser classificadas nem como benéficas nem como nocivas ao software, pois são fortemente dependentes do contexto aplicado. Contudo, deve-se ter em mente que quanto menor o escopo estimado e maior a experiência do profissional que irá estimar, maiores são as chances dessa estimativa se transformar em realidade dos projetos.

E você? Qual a sua experiência com o sucesso de estimativas? Em quais cenários acredita que estimativas são benéficas? E em quais contextos seriam nocivas?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Experiência legal by ROGERIO OLIVEIRA

Acredito e vivi tudo que está descrito no artigo. Não sei precisar o percentual, mas em um projeto ágil que trabalhei lembro-me das estimativas ficaram sempre(a cada sprint) muito próximas do real. Os pacotes de trabalho planejados pela equipe eram pequenos e a equipe era basicamente formada por seniors.

Estimar ou não estimar... by Leandro Guimarães

Ao meu ver o grande problema dessa discussão em torno da estimativa foi o momento em que se tomou uma estimativa como verdade. Aí ferrou. Sou bem curioso, por exemplo, para vivenciar um cenário com Kanban aonde não se utiliza estimativa.

Estimar, por exemplo, com a utilização de story points, ou qualquer outra prática que parta do pressuposto de não ser exata e fazendo-a de uma forma que envolva diversas visões, proporciona à equipe no mínimo uma discussão a respeito daquilo que precisa ser feito / realizado. Ah, mas e o esforço de se estimar? Eu ainda tendo a enxergar que, se bem feito, serve muito bem para alinhamento e remoção de ruídos no entendimento.

Talvez, não consigo afirmar muito dessa minha ideia, ter estimativas seja algo "inerente" ou "natural" à natureza humana. Penso que não estimar porque é comprovado cientificamente que estimativas são imprecisas (!!) ou porque quem comprará seu desenvolvimento encarará a estimativa como um compromisso firmado soa, pra mim, como tirar o seu da reta e querer empurrar a bucha pra alguém caso a bomba exploda.

PS: Que fique claro que eu acho e enxergo que existam outros argumentos que levem a um cenário de que não seja possível realizar uma estimativa naquele momento.

Cone da Incerteza by Giulliano Morroni

Acho que o problema todo ocorre no ínicio de cada projeto onde não podemos medir nem afirmar tempo e esforço. Ao mesmo passo de que é no ínicio que o cliente precisa dessas informações para dizer se aceita ou não seu trabalho.

Cabe aí uma explicação do cone da incerteza para o cliente, deixando claro a ele que no começo a chance de errar é alta, porém com o tempo chegaremos mais próximos da realidade.

link para matéria: www.acarlos.com.br/blog/2008/02/cone-da-incerte...

Re: Estimar ou não estimar... by Rogerio J. Gentil

Concordo com o Leandro Guimarães. Estimativa é uma aproximação, um cálculo de um valor não absolutamente exato. Estimativas foram criadas para orientar, não para serem exatamente executadas.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

4 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT