Certo dia um diretor, muito sagaz exclama a seguinte frase;
“Agora já sei como justificar os prazos de nossos projetos!!! ANALISE DE PONTO DE FUNÇÃO!”

Entendendo a pressão que ele deva sofrer para justificar o investimento na área de TI e tendo que fugir obrigatoriamente do chutômetro, “acho que levarei 312 jornadas para fazer isso…” ¬¬

Será que a Analise de Ponto de Função realmente ajudaria nesse caso? Alguém já aplicou essa teoria na pratica? Existem outras formas de se assegurar o tempo estimado para um projeto?

Abs

Tenho a APF como estimativa de custo. De prazo ainda não me convenceram.

Desenvolvimento de sistemas, ao menos no meu ponto de vista, é algo empírico e pronto! Não acredito numa correta mensuração em um processo empírico e não acho necessário.

É a velha história da “fábrica de software”…

Aprendi um pouco de pontos de função antes de aprender OOP. Na época já achava complicado demais porém via valor.

Com linguagens OOP nunca consegui entender vantagens de aprender coisa tão complexa. Prefero o tradicional, mais fácil de aprender e que incorpora a experiência de cada um, Cálculo Heurístico Unificado com Tratamento Estatístico.

Na minha opnião o problema é que qualquer métrica vai te falar sobre o que tem que ser feito, mas o que é mais importante é o outro lado, quem vai fazer.
Saber que o projeto tem 1337 pontos de [funcao, caso de uso, estoria,..] significa muito pouco se não for comparado com algo semelhante.

Se voce tem uma equipe que historicamente faz 100 pontos por semana e o novo projeto é semelhante e vai ser feito pela mesma equipe, até dá pra confiar na estimativa. Se o projeto ou a equipe forem diferentes, melhor chamar a estimativa de chute pra não ter risco de confiar nela.

Olá Luca,

Aí sim heim Cálculo Heurístico Unificado com Tratamento Estatístico o famoso C.H.U.T.E. rssr…

é… começo a achar que é mais uma nova maneira de fazer algo – que como diz o dito popular – “Para inglês ver…”

Abraços e obrigado pelas opiniões!

Estava discutindo sobre APF e Planejamento Ágil onde trabalho.

Chegamos a conclusão que, mesmo usando Ágil, APF pode ajudar em contratos de escopo fechado para dar uma estimativa de alto nível.

Escrevi sobre isso no meu blog:
http://alexandreaquiles.wordpress.com/2011/01/1…

Alexandre, acho que APF pode ajudar a dar uma estimativa de alto nível tão boa quanto o já falecido polvo Paul.

O bom uso da experiência de desenvolvedores bons participando da estimativa produzem o melhor resultado, acredito eu.

Acho que o problema é um pouco mais embaixo, estimativa por sí só já é algo “aproximado”, ou seja, utilizar algo aproximado para cálculo de qualquer coisa que envolve dinheiro vai dar merda…

A saída é contrato de escopo aberto, mas pra governo, defesa nacional e coisas assim não dá… então, qualquer coisa serve, já que é aproximado, é contar com o innevitável, o contratado será diferente do executado, a questão é se o cliente ou fornecedor vai ter prejuízo.

Na boa, APF serve pra jogar o custo do projeto na estratosfera pra de dar uma boa “gordura”. Uma mesma funcionalidade pode ser uma tela simples com alguns campos ou uma tela monstruosa, com drag’n’drop, ajax, validação no cliente, etc. Por isso é impossível fazer uma correlação entre funcionalidade => numeros de pontos de função => horas necessárias para desenvolver a funcionalidade sem detalhar a funcionalidade…
APF só serve para você dar a impressão pro seu cliente que você esta usando algum método cientifico para estimar o “esforço” do seu projeto (o me venha com essa que esforço != custo != prazo… no fim a estimativa vai de esforço vai virar custo e prazo, principalmente por que quem acredita em APF acredita que 9 mulheres fazem 1 filho em 1 mes…)
Você pode ser honesto com o seu cliente e dizer que não tem como estimar o projeto se ele for muito grande. Ou você pode tentar enganar ele (e a si mesmo) com APF.

Bom vamos lá.

Estimativa = Chute. não importa o que digam e que tipo de processo/métricas você faça. (como já disse o Luca)

Com APF, você chuta mas com o diferencial de gastar horas/dias analisando coisas esdrúxulas e complicadas, e que no final você jogar tudo fora e levar em consideração algumas coisas como experiência da equipe, sua experiência como líder, o tamanho do projeto, a complexidade do cliente e da empresa dele, enfim, ao meu ver APF não serve para muita coisa.

Aqui, a maioria dos clientes são contratos de escopo fechado. Sabemos que no final o projeto vai atrasar, tentamos errar menos na estimativa para atrasar menos. Para estimar, usamos experiências anteriores, opinião de mais de uma pessoa, contatamos os clientes para dúvidas e no final tentamos fechar o cerco. Mas acertar… nunca, sabemos disso e trabalhamos com este risco.

Faça a estimativa inicial com os dados que você possui, faça reuniões diárias, planejamento de sprint, review, boas práticas e etc… isso sim ajuda.

Quase cinco anos atrás (meu Deus!) eu escrevi sobre isso:

http://blog.michaelnascimento.com.br/2006/06/08…

Puts Rubem, cortou na carne heim… rs…
Mas o pior é que concordo com vc… o problema é quando trabalhamos com clientes/diretores que não compreende que a estimativa de tempo para desenvolvimento de sistemas é algo empírico!!!
Aí é aonde mora o problema… O cara pede para que vc conte uma “historinha” pra ele e que ainda mostre provas destas “historinha”…. rsrs

Abs a todos e obrigado pelos comentários!!

A verdade é que a verdade importa muito pouco :)
Voce vai fazer APF (ou AP*) pra pegar um projeto grande do governo e mamar enquanto pode e foda-se o depois ou tentar convencer o governo que APF não serve pra nada e eles fizeram uma cagada?
Escopo fechado é sempre assim, muito engodo e um processo de fachada que, quando apertar e cada lado tiver que defender o seu, vira jogo do bixo (vale o que ta escrito) e ai não tem software que sobreviva. Mas até isso acontecer muito dinheiro troca de mãos, que é o objetivo maior.

Como o Rubem citou, uma estmativa é uma estimativa. Como ela não é baseada em experiências anteriores (não se analisa os erros de estimativa da mesma equipe no projeto anterior para acertar nessa), os mesmos erros se repetem a cada nova estimativa de projeto. As mesmas falhas surgem, o mesmo atraso, a mesma reclamação.

Por isso que a velocidade, que diz algo de acordo com os erros e acertos da equipe atual, é mais realista.

Abraço

Bem, como muitos acima disseram, uma estimativa de tempo de projeto de software é basicamente um chute.
Mas um chute pode ser dado a esmo, eu ser embasado em alguma coisa. APF pra mim não serve.

O que custumo fazer, e vem dando certo é primeiro levantar os requisitos/Stories do sistema, depois dividi-la em partes e cada uma destas partes tem os seguinte atributos:

*Tecnologia (Java, C#, SQL, HTML, Javascript, Ruby, XML, etc)
*Escopo (Novo, Alteração, Refatoração)
*Complexidade(Alta, media, baixa, etc)
Cada atributo tem um peso, que foi dados por experiencia minha e da equipe (ai á parte critica, e onde é dado o chute)

Com soma ponderada destes valores obtenho o esforço de desenvolvimento, os outros esforços (teste, homologação, analise (entendimento), etc) é um percentual sobre o valor do esforço de desenvolvimento. Soma-se tudo e pronto, tenho um numero mágico para entregar ao comercial da empresa. :-)

Bem, é um chute, mas com algum embasamento, e tem funcionado bem.

Bem muito legais as respostas dadas por vocês, mais mesmo com o empirismo ainda recomendo adicionar um desconto de 30% a cada estimativa realizada, isso faz com que crie uma margem boa para eventuais atropelos.

Se você terminou o projeto ou tarefa antes do estimado, ótimo, melhor adiantar o do que atrasar.
Se você teve algum problema, (Doença, Internet, etc), ainda tem algum tempo para solucionar.

Bom, valeu galera. Acho que falei bobeira… hehe

Estava querendo achar uma maneira interessante de trabalhar com contratos de escopo fechado.

Mas talvez valha mais a pena explicar os problemas do modelo tradicional, de escopo fechado e das estimativas mágicas para os nossos clientes. E vender a idéia de colaboração e contratos de escopo aberto.

Mas é difícil!

Será que é possível trabalhar com contratos de escopo fechado?

Seguindo a lógica do Alexandre Almeida seria muito interessante, mas na maioria senão todos os projetos que trabalho eu não tenho nenhum das 3 variáveis, e mesmo assim ainda tenho que trabalhar com escopo fechado.

Na boa… se o cara tiver fazendo APF e ao mesmo tempo metendo a mão na massa. .tranquilo… senão, não ajuda nada do mesmo jeito e no final sempre temos a impressão que o cara que só faz APF é só um enrrolão…

Na verdade, em escopo aberto ainda é preciso fazer estimativas de tempo: pelo menos uma estimativa bem grosseira para ver se dá pra entregar a visão do projeto no deadline/custo disponível.

Achei a técnica do Alexandro Almeida muito boa pra isso. E APF ajuda também, mas pode complicar demais as coisas.