Ponto de função hoje faz sentido?

Assuntos Gerais
#21

Minha opnião… já usei APF, atualmente não estou usando…

Serve para 2 coisas:

  1. Ter uma ordem de grandeza do software (em questão de pouco tempo, você sabe se o software vai ter muitos pontos de função ou não e saber mais ou menos o tamanho da encrenca).
  2. Justificar a cobrança de um trabalho , ex:

Imagina que você vai fazer um orçamento de reformar sua casa, em qual pedreiro você confiaria mais?
a) A reforma vai custar R$ 25 mil
b) A reforma vai custar R$ 10 mil para a sala, R$ 10 mil para a cozinha e R$ 5 mil para o banheiro
c) A reforma vai custar R$ 15 mil para a sala, pois você possui 4 paredes, no total de 20 metros quadrados e mais 8 metros quadrados de piso. Como eu cobro X para o metro quadrado do piso e Y para o metro quadrado da parede, este é valor e assim por diante.

Óbvio que isso não quer dizer nada… pode ser que o que cobrou mais barato faça o serviço até mesmo melhor e tenha lucro… como pode largar na metade e deixar na mão! Entretanto ter um argumento do porque do custo acaba ajudando em muitos casos (digo por experiência que a APF realmente já me ajudou)…

Entretanto, alguns cuidados são precisos:

  • Você também pode subestimar a APF
  • O preço do ponto de função terá de ser de acordo com a complexidade do projeto, equipe, etc…

Algumas coisas por ai que não concordo:

  • Usar preço fixo de APF… as vezes são poucos pontos de função mais muita complexidade… o contrário também acontece!
  • Chegar no cronograma a partir do ponto de função… são 100 pontos de função, 8 horas por PF, total de 800 horas, 5 desenvolvedores… 1 mês de trabalho… isso costuma dar muito errado!

O ideal que vejo é quebrar as atividades, fazer um cronograma baseado na dependência das mesmas e chegar e um tempo necessário (e assim medir o custo), isso tudo de acordo com as pessoas e recursos que forem utilizados no projeto.
Conflitar isto com a APF é bom pois usando as 2 técnicas, você consegue chegar em um chute um pouco mais preciso (se a apf ta muito alta você esta subestimando o trabalho… o contrário também pode ser verdade).

Não acredito em APF para utilização em projetos internos… Acho que ninguem melhor que o desenvolvedor para estimar e o coordenador para dar o aval!

#22

APF é uma forma ESTÚPIDA de se medir Sistemas.
No APF, 2 telinhas de Cadastro Básico valem mais do que uma funcionalidade super complexa de cruzamentos de Indivíduos (no caso de um Sistema Criminal).

Nao sei como alguem pode achar isso bacana ainda hoje. Isso é coisa da década de 80 e nao sei pq raios as insituições do Governo agora so podem licitar com ela.

Resultado: fica aquele cabo de guerra, e no geral a empresa fica puxando o máximo possivel pra fazer Cadastro pra tudo que é lado pq é isso que dá dinheiro.

Na maioria dos casos vc terá q fazer, logo na primeira fase, o “coração” de um Sistema - no caso de um RUP por exemplo onde vc levanta inicialmente os pontos críticos do Sistema pra saber se vai ter algo que inviabilize - de 1000 pontos de função, usando 200 deles (pra depois ir atacar o POTE de OURO do APF que são cadastros básicos). E esse início como todos nós sabemos, ainda mais se tratando de projeto NOVO, é complicado e no APF vc só fatura pelo que entrega pronto. Se o cliente é complicado e não sabe o que quer, vc leva um tempo até receber (claro, depois vc vai receber tudo pq todas as mudancas sao pagas). Resumindo: Só da pra entrar em coisas assim empresas que tem CAIXA pra manter a equipe por uns 6 meses pelo menos até engrenar. E caixa forte.

Palavras de alguém que passou 2011 inteiro num projeto APF junto à Presidencia da Republica.

Conselho: RUN TO THE HILLS.

#23

O detalhe de telinhas valerem mais e exatamente oq nao concordo com apf, pois ela nao mede complexidade e esta eh adotada de forma unica.

Oq usar entao para dar um orcamento? Somente feeling baseado nas macro tarefas?

#24

[quote=jmmenezes]O detalhe de telinhas valerem mais e exatamente oq nao concordo com apf, pois ela nao mede complexidade e esta eh adotada de forma unica.

Oq usar entao para dar um orcamento? Somente feeling baseado nas macro tarefas?[/quote]

Para um chute inicial, acho que não tem muito remédio mesmo …

#25

Utilizar projetos anteriores como parâmetro de comparação é uma recomendação que até o PMI dá, se a empresa trabalha com projetos muito sob domínio, como por exemplo um determinado nicho de sistema financeiro, é muito válido.

#26

Nossa, gente, que bacana esta discussão. Uma série de opiniões divergentes que estão me ajudando bastante, valeu!

Agora, pelo visto, um ponto comum aqui é a dificuldade em se dar preço no esforço. Neste caso, como vocês fazem? Cobram preços diferenciados por “tipo de ponto de função”? Há alguma métrica interessante pra isto?

#27

[quote=jmmenezes]O detalhe de telinhas valerem mais e exatamente oq nao concordo com apf, pois ela nao mede complexidade e esta eh adotada de forma unica.

Oq usar entao para dar um orcamento? Somente feeling baseado nas macro tarefas?[/quote]

Podesse cobrar por funcionalidade implementada! Você faz os casos de uso, por exemplo e estima em cima do primeiro caso de uso, o mais simples! A medida que o sistema vai crescendo, cada nova funcionalidade representa um novo orçamento.

#28

Respondendo a pergunta do tópico, acho que não faz sentido.
Acredito que tenha um efeito placebo, dá uma falsa sensação de segurança que você tem uma previsão de entrega através de método cientifico.

Sobre estimativas em geral, acho que o principal motivo de não conseguirmos ser confiáveis é que não aprendemos e não lembramos dos nosso erros ou acertos.

Neste artigo tem um método usado por uma empresa que parece funcionar.
Ele leva em conta vários fatores usados aqui e conta com experiências anteriores pra aprimorar as próximas.

#29

[quote=AbelBueno]Respondendo a pergunta do tópico, acho que não faz sentido.
Acredito que tenha um efeito placebo, dá uma falsa sensação de segurança que você tem uma previsão de entrega através de método cientifico.

Sobre estimativas em geral, acho que o principal motivo de não conseguirmos ser confiáveis é que não aprendemos e não lembramos dos nosso erros ou acertos.
[/quote]

Tb acho que não, mas por outro motivo. Agile tb tem sua parcela de adeptos a medições e estimativas furadas.

[quote=AbelBueno]Neste artigo tem um método usado por uma empresa que parece funcionar.
Ele leva em conta vários fatores usados aqui e conta com experiências anteriores pra aprimorar as próximas.
[/quote]

Mas repare que no texto eles falam de estimar custos, não preço.

Obviamente preço é muito mais função do mercado e quanto ele está disposto a pagar, do que o esforço que fez e que acha que deve ser recompensado.

#30

[quote=AbelBueno]Respondendo a pergunta do tópico, acho que não faz sentido.
Acredito que tenha um efeito placebo, dá uma falsa sensação de segurança que você tem uma previsão de entrega através de método cientifico.

Sobre estimativas em geral, acho que o principal motivo de não conseguirmos ser confiáveis é que não aprendemos e não lembramos dos nosso erros ou acertos.

Neste artigo tem um método usado por uma empresa que parece funcionar.
Ele leva em conta vários fatores usados aqui e conta com experiências anteriores pra aprimorar as próximas.
[/quote]

Interessante o artigo, bastante mesmo.

Quanto ao item 1 essa eh uma pratica que eu pratico ha bastante tempo ja. Eu tento quebrar as funcionalidades propostas ao maximo possivel para ter uma boa ideia do que precisa ser feito. O resultado disso é excelente. E eu procuro normalmente quebrar em menos de um dia, 8 horas é o prazo maximo que eu dou para uma tarefa, mais do que isso eu quebro em subtarefas. As estimativas nesse caso sao bem mais proximas do que qualquer outro formato que eu ja conheci.

O problema é: isso funciona bem para estimar até daqui a duas, três semanas, no máximo um mes. Fora isso já começa a exigir um esforço muito grande desperdiçado com estimativas enquanto voce poderia ja estar trabalhando na implementação. Para fazer este tipo de previsao voce precisa detalhar cada funcionalidade proposta a ponto de poder depois quebrá-las em tarefas menores, detalhar novamente, quebrar e assim por diante. Em projetos longos é completamente inviável ou vai acabar sendo feito no chutão como qualquer outra forma de estimativa.

Quanto aos meio “automaticos” de medição, eles são ainda piores que o chutão puro e simples, voce fica horas preenchendo informações, poe coisa daqui, caminhos alternativos dali, e etc… e no final surge um número mágico maravilhoso, que na maioria das vezes você vai discordar. Aí voce vai la, altera os inputs das ferramentas de automatização de estimativas para que te dêem um número mágico mais próximo da realidade que você acredita. Ora, então chuta de uma vez o quanto você acha e pronto.

No fundo elas não passam disso, formas de chute automático.

#31

E algum dia fez?

Para mim, pontos de função são uma forma de mostrar “técnica na hora de chutar”. Os modelos matemáticos mais precisos levam em conta parâmetros como existência ou não de iterações, variáveis de controle, etc… variáveis que você só terá quando o software estiver pronto (dã). Modelos usados na hora da estimativa usam dados menos precisos como “grau de dificuldade” (que são tão relevantes quanto os chutes que damos ao fazer o Planning Poker".

A diferença entre pontos de função e o planning poker também não é a precisão do método, mas a distância do gol. É muito mais fácil chutar, se você estiver com o gol perto, do que tentar marcar aquele ponto do meio do campo (ou pior, tentar fazer o famoso “gol de goleiro”).

Você pode substituir o planning poker por pontos de função se estiver com iterações curtas. Não duvido que a taxa de acerto seja praticamente a mesma, especialmente se você também fizer a realimentação do seu processo com base na velocidade da equipe.

#32

[quote=ViniGodoy]E algum dia fez?

Para mim, pontos de função são uma forma de mostrar “técnica na hora de chutar”. Os modelos matemáticos mais precisos levam em conta parâmetros como existência ou não de iterações, variáveis de controle, etc… variáveis que você só terá quando o software estiver pronto (dã). Modelos usados na hora da estimativa usam dados menos precisos como “grau de dificuldade” (que são tão relevantes quanto os chutes que damos ao fazer o Planning Poker".

A diferença entre pontos de função e o planning poker também não é a precisão do método, mas a distância do gol. É muito mais fácil chutar, se você estiver com o gol perto, do que tentar marcar aquele ponto do meio do campo (ou pior, tentar fazer o famoso “gol de goleiro”).

Você pode substituir o planning poker por pontos de função se estiver com iterações curtas. Não duvido que a taxa de acerto seja praticamente a mesma, especialmente se você também fizer a realimentação do seu processo com base na velocidade da equipe.[/quote]

Eu acho que o ponto é justamente esse.

Eu penso que estimativas iniciais devem ser, bem, como o nome diz, iniciais. Seria algo do tipo “dura 6 meses”, “leva mais do que 1 ano”, “leva 10 anos”. Dá até para aplicar uma aritmética simples para chegar a esse número. Por exemplo, você pode classificar as estórias em Simples, Médias e Complexas. Podemos atribuir um peso em dias para cada tipo, algo como S=5, M=15, C=40. Se temos 30 simples, 40 médias e 8 complexas , temos 5 x 30 + 15 x 40 + 8 x 40 = 1070 dias = 35 meses.Se considerarmos ainda o princípio de Pareto , podemos estimar ainda que em 1 ano, as estórias de maior interesse podem ficar prontas. E temos aí uma estimativa: de 1 a 3 anos.

Agora, seria uma insanidade estabelecer um cronograma a partir dessas “continhas”, por um motivo muito simples: quanto maior o horizonte de previsão maior será o erro. Essa é a grande ignorância que paira no mercado, não distinguir uma estimativa de um cronograma. A própria palavra estimativa já traz em si uma conotação de probabilidade, e não de compromisso.

No fim, pontos de função nada mais são do que “continhas mais complicadas”, para determinar o mesmo chutão inicial.

#33

Não sou especialista em PF, alias nunca fiz PF, mas vou jogar algumas indagações, até para gerar mais discussão e todos chegarmos as nossas conclusões:

  • Sempre que vejo falarem sobre PF, e previsões, geralmente a opnião é a mesma, somente mãe diná e walter mercado conseguem prever algo, mas então por sera que, sim, existem empresas, estatais e etc, usando PF e por incrivel que possa parecer conseguem entregar + ou - dentro do prazo estipulado?? Em suma, se é TÃO inutil assim como dizem, porque continuam usando e acabam tendo algum resultado?

  • o caso dos pedreiros, eu prefiro com certeza o que especificou, experiencia propria e recente :P, o cara chega, olha pra tua cara, olha pra tua casa e diz quanto vai ser, outro chegou e ja falou logo: olha eu cobro 12,00 o metro para colocar a ceramica e 10,00 o metro pra rebocar o muro, pronto, basta eu medir tudo e ja sei quanto vou gastar, jogo limpo.

  • ah mas o software muda no meio, ou entao tu nao sabe tudo que vai ter, olha sinto muito, mas cada vez que muda, mudam tambem os prazos e os preços, simples assim, se o cliente queria em 90 dias, mas a cada 10 dias pede algo diferente, ele tem que estar bem ciente que cada coisa que ele altera, o prazo e preço tambem são alterados. E bem facil discutir isto com o cliente: Ei tu falou que demorava X, agora ta dizendo X+Y, sim, tu disse que queria A e agora quer A + B.

O que penso até agora? Bom como disse nunca fiz PF, ja trabalhei numa estatal que usa até hoje PF, mas eu estava em outra área, nos outros lugares geralmente é o que chamam aqui de “chutão”, o chefe chega e diz, olha o sistema vai ter X, Y e Z, quanto tempo tu gasta? Acho que 30 dias, ok. E por incrivel que pareça, voce consegue concluir naqueles 30 dias. Entao vou discordar um pouco do termo chutão, se o programador tem um minimo de experiencia ele ja sabe ± quanto tempo leva para fazer determinadas coisas, logo poderiamos trocar chutao por “metricas baseadas em experiencia/historico”. Chutao seria mais se: o cara nao faz a menor ideia do que esta falando, nem do que será o sistema.

Resumindo, acho que experiencia/historico + PF(que vai detalhar a coisa) podem ser uma solução. mas teria que ser um PF dinânico, influenciado pelo know-how dos envolvidos, o cliente vai ficar satisfeito pq ta tudo detalhado do porque tu ta pedindo aquele preço/prazo, eu tu vai ter um “chute” mais perto do gol baseado na experiencia/historico.

#34

[quote=fredferrao]Não sou especialista em PF, alias nunca fiz PF, mas vou jogar algumas indagações, até para gerar mais discussão e todos chegarmos as nossas conclusões:

  • Sempre que vejo falarem sobre PF, e previsões, geralmente a opnião é a mesma, somente mãe diná e walter mercado conseguem prever algo, mas então por sera que, sim, existem empresas, estatais e etc, usando PF e por incrivel que possa parecer conseguem entregar + ou - dentro do prazo estipulado?? Em suma, se é TÃO inutil assim como dizem, porque continuam usando e acabam tendo algum resultado?
    [/quote]
    PF não tem nada haver com prazo de entrega! Tem haver com estimar a complexidade de uma parte do software.

Sim, isso é verdade. Se houver alteração do projeto, vai ter alteração nos PF e provalmente no prazo, mas como já disse, prazo e PF não tem nada haver.

Isso não é PF. Isso está mais para uma abordagem XP, na qual o prazo para conclussão de uma tarefa é determinado por quem vai faze-la com base em sua experiência. Muitas tarefas até ficam com prazo em aberto pois o desenvolvedor pode não conseguir estimar aquilo por nunca ter feito.

Ai não é PF.
PF visa medir a complexidade de um software basicamente pelas entradas e saídas que o software gera e pelas “consultas que ele faz”. Para um CRUD beleza, funciona bem. Mas para atividades mais complexas ele é furado. Não tem como medir complexidade de algo com base nesses tipos de dados!

Como disse PF não tem haver com prazo, os prazos podem ser calculados com base nela mas leva em conta outros fatores, como nivel de conhecimento dos desenvolvedores.
Prazos calculados com PF até podem dar certo no final, se você tem um grande número de tarefaz simples com grande numero de entradas e saidas, ou seja, basicamente cadastros e relatórios! Se você tem uma equipe experiente, ela pode levar menos tempo para fazer uma tarefa que foi determinada como super complexa por PF e utilizar esse tempo para compensar os atrasos ocorridos nas tarefas consideradas mais simples por PF, mas que se mostraram autamente complexas!

#35

Alem de PF e Planing Poker o que mais pode ser usado?

#36

[quote=fredferrao]Não sou especialista em PF, alias nunca fiz PF, mas vou jogar algumas indagações, até para gerar mais discussão e todos chegarmos as nossas conclusões:

  • Sempre que vejo falarem sobre PF, e previsões, geralmente a opnião é a mesma, somente mãe diná e walter mercado conseguem prever algo, mas então por sera que, sim, existem empresas, estatais e etc, usando PF e por incrivel que possa parecer conseguem entregar + ou - dentro do prazo estipulado?? Em suma, se é TÃO inutil assim como dizem, porque continuam usando e acabam tendo algum resultado?

  • o caso dos pedreiros, eu prefiro com certeza o que especificou, experiencia propria e recente :P, o cara chega, olha pra tua cara, olha pra tua casa e diz quanto vai ser, outro chegou e ja falou logo: olha eu cobro 12,00 o metro para colocar a ceramica e 10,00 o metro pra rebocar o muro, pronto, basta eu medir tudo e ja sei quanto vou gastar, jogo limpo.

  • ah mas o software muda no meio, ou entao tu nao sabe tudo que vai ter, olha sinto muito, mas cada vez que muda, mudam tambem os prazos e os preços, simples assim, se o cliente queria em 90 dias, mas a cada 10 dias pede algo diferente, ele tem que estar bem ciente que cada coisa que ele altera, o prazo e preço tambem são alterados. E bem facil discutir isto com o cliente: Ei tu falou que demorava X, agora ta dizendo X+Y, sim, tu disse que queria A e agora quer A + B.

O que penso até agora? Bom como disse nunca fiz PF, ja trabalhei numa estatal que usa até hoje PF, mas eu estava em outra área, nos outros lugares geralmente é o que chamam aqui de “chutão”, o chefe chega e diz, olha o sistema vai ter X, Y e Z, quanto tempo tu gasta? Acho que 30 dias, ok. E por incrivel que pareça, voce consegue concluir naqueles 30 dias. Entao vou discordar um pouco do termo chutão, se o programador tem um minimo de experiencia ele ja sabe ± quanto tempo leva para fazer determinadas coisas, logo poderiamos trocar chutao por “metricas baseadas em experiencia/historico”. Chutao seria mais se: o cara nao faz a menor ideia do que esta falando, nem do que será o sistema.

Resumindo, acho que experiencia/historico + PF(que vai detalhar a coisa) podem ser uma solução. mas teria que ser um PF dinânico, influenciado pelo know-how dos envolvidos, o cliente vai ficar satisfeito pq ta tudo detalhado do porque tu ta pedindo aquele preço/prazo, eu tu vai ter um “chute” mais perto do gol baseado na experiencia/historico.

[/quote]

Por isso que eu acredito que o prazo dado pelo desenvolvedor de uma tarefa especifica (não precisa nem ser tão quebrada, pois é possível estimarmos algo que irá demorar 1 semana e realizarmos em 1 semana), se feito por aquele desenvolvedor, é o mais próximo da realidade, mas isso pode levar um tempo e a PF pode dar uma “ordem de grandeza” em menos tempo… tipo bem ordem de grandeza se vai demorar 3, 6, 9 meses ou 1 ano… ou mais… coisa assim… No final confrontar os 2, consegue se ter um cheiro de falha em algum dos 2 métodos e tentar chegar em uma estimativa um pouco mais precisa…
Para cobrar, quando vai falar com pessoas que mal sabem o que é um if, mostrar também uma métrica APF, mesmo que elas não entendem nada de APF, mostra algo próximo da estimativa de uma “obra”… dependendo do cliente, quebrar as tarefas também vale… o detalhe que APF é uma norma bla bla bla… e dependendo do cliente isso conta, da impressão de você não estar “chutando”…

Claro que a PF é praticamente para CRUDs, mas no caso de alguem que trabalha como coordenador (meu caso) pensando em uma equipe com 10 desenvolvedores, e todo tipo de complexidade, no geral a maior parte da demanda são de cruds mesmo! E a excessão deve ser tratada como excessão!

Acho que da mesma forma que não podemos comparar o trabalho do pedreiro que vai pintar X metros de parede e assentar Y metros de piso, com um escultor que pode levar 1 semana, 1 mês ou 1 ano para fazer tal “obra de arte”, também acredito que no software existe essa divisão… tem aquilo que fica próximo da “obra do pedreiro”, tem aquilo que não se consegue estimar… e tem aquilo que não há fórmula mágica, mas a experiência do profissional consegue ditar um prazo que muitas vezes acontece.

#37

[quote=luistiagos][quote=fzampa][quote=luistiagos]
Alem do PF que outra estimativa existe? Planing Poker acho que é útil para estimar tarefas, mas e no caso do projeto inteiro e não apenas tarefas?[/quote]

E um projeto inteiro é feito de que, senão pequenas tarefas?[/quote]

Mas digamos que vc não conheça todas as tarefas a serem feitas, só conheça as principais o geralzão… e vc não tem tempo de especificar tudo e muito menos reunir a equipe pro planing poker das milhares tarefas que o projeto vai ter e dai?[/quote]

Pergunta interessante essa.Também é uma duvida que eu sempre tenho!!

#38

[quote=fredferrao] Em suma, se é TÃO inutil assim como dizem, porque continuam usando e acabam tendo algum resultado?
[/quote]

Eu imagino que seja pela FALSA sensação de segurança e certeza que esses artefatos geram.

#39

Meu professor é gerente de projetos, hoje ele não utiliza nenhuma tecnica de estimativa.

Disse que já quebrou muito a cara com projetos, principalmente usando pontos por função, ele disse que a experiencia que ele obteu e comparando com projetos semelhantes ele faz a estimativa de cabeça !

Não sei se é verdade, mas ele me pareceu bem confiante, outra coisa quando o cliente pede alguma tecnica ele utiliza pontos por caso de uso.

Essa foram as palavras dele, gostaria de saber se são validas ou ele simplesmente é louco.

Abraço

#40

Eu acho que ele não é louco.
Estimativas são sempre estimativas, pode-se usar muitos métodos que as tornem mais precisas. São úteis para uma previsão aproximada do trabalho a ser feito.
Mas durante o projeto é preciso ir refinando as estimativas, à medida que temos mais informações. Vai sendo verificada a produtividade da equipe e é possível ter estimativas cada vez melhores.