Ponto de função hoje faz sentido?

Quando você vai fazer uma estimativa de prazo que tipo de coisa você usa?

Aquele baralho de tarô, aham, “Planning Poker”, que é habitual quando se usa o processo do Scrum, ou você prefere algo que exija menos interação entre os participantes da equipe e possa ser feito por um especialista que nunca olhou na cara de um desenvolvedor e é especialista em pontos de função?

O problema é que alguns clientes não aceitam prazos dados pelo Planning Poker e exigem que as estimativas de prazo e custo sejam feitas por métodos conhecidos, como Function Points. Isso é muito comum quando um cliente grande (como um banco) discute prazo com um fornecedor grande (como uma consultoria) a respeito de um sistema com tecnologia conhecida (como um sistema web).

Não. Pontos de função é utilizado para extimar a complexidade de uma atividade de programação! Ela é utilizada pela método cascata, mas não inerente dele!

A principio, a cada nova tarefa ou mudança, se faz os calculos necessários para estimar sua complexidade!

Para mim o problema dos pontos de função não é como eles são aplicados, mas a validade da informação obtida com sua utilização! Não acredito que seja possível medir a complexidade para o desenvolvimento de um software dando pesos as entradas e e saídas e contabilizando isso! Para min a complexidade esta envolvida em conhecer a linguagem, a arquitetura e, principalmente, conhecer o dominio com o qual está lidando!

Uma abordagem utilizada por XP para estimar o tempo necessário para o desenvolmento de algo é perguntar ao programador quanto tempo ele levaria para fazer aquilo. O problema nessa abordagem é que se torna impossivel estimar efetivamente, quanto tempo se levará para comprir uma atividade especifica!

A minha frase sublinhada não está correta, o que eu queria ter tido é quanto tempo levará para comprir o projeto todo!

x@ndy:

…

Uma abordagem utilizada por XP para estimar o tempo necessário para o desenvolmento de algo é perguntar ao programador quanto tempo ele levaria para fazer aquilo. O problema nessa abordagem é que se torna impossivel estimar efetivamente, quanto tempo se levará para comprir uma atividade especifica!

Mas temos que ver também que o tempo que o tempo necessário para executar determinada função, independente de qual ela seja, depende do desenvolvedor. Tratando-se de metodologia ágil, não creio que haja uma maneira melhor de avaliar.

Claro que o cliente pode não aceitar e pode pedir algo mais “oficial”, mas visando que nenhum desenvolvedor é igual ao outro, isso pode ser uma estimativa ainda pior do que a resposta do desenvolvedor.

Trabalhei pouco com pontos de função mas como foi dito deixar um espeficialista em pontos de função que muitas vezes nunca colocou a “mão na massa” fazer a estimativa é totalmente desaconselhável, por outro lado as metodologias ágeis estão ai, no entanto a diferença na eficacia da estimativa não é tão significamente usando o Scrum(“Planning Poker”) , são muitas variantes para se alcançar algo perto da realidade, como experiência do desenvolvedor na linguagem, no projeto, etc.
Não estou aqui para questionar as metodologias agéis, mas ao meu ver as estimativas só trocaram de mão, mas o ganho muitas vezes não são tão significativos como deveriam ser, pelo menos no quesito prazo para o cliente.

Acho que o grande problema nem é o sistema de estimativas em si, mas estipular um cronograma completo com base em uma estimativa inicial. Independente do sistema, uma boa estimativa depende diretamente do conhecimento dos requisitos do sistema, que no início do projeto, são praticamente hipóteses. Sendo assim, qualquer estimativa sobre hipóteses serão tão ruins quanto as mesmas.

Eu penso que o ideal é manter um histórico estória X previsto X realizado e estimar por comparação.

Olha pra mim remete sim, pelo simples fato de prever o futuro.

Essa análise é feita antes de fechar o projeto normalmente, ou seja, sem trabalhar em informação nenhuma, sem o projeto fechado nenhum GP vai colocar um analista para trabalhar nos requisitos, a não ser dar só aquela passada e tal, fazer aquele plano de projeto que a consultoria assume como custo operacional pois é do interesse dela pegar projetos. Mas é tudo muito superficial.

Depois lá no meio do projeto, começam a serem feitas adaptações para respeitar o prazo e principalmente o orçamento estipulado, ai pra mim, se tinha alguém fazendo agile nesse ponto não está mais.

Outra coisa até hoje só vi estimativas overpriced. A APF deveria servir para obter métrica de software, mas em um projeto existem muitos outros custos ao redor, os GP’s dão um jeito de enfiar esse custo na APF e ai pra mim isso já não representa verdade nenhuma, é mentira, e se basear em algo assim não é muito bom.

Mas a verdade é que o cliente precisa de algo definido de fato, e a essência do agile é totalmente oposta, é se adaptar as mudanças, mas o cliente tem um budget e precisa de aprovação de patrocinador do projeto, etc…precisa de algo concreto. É complicada a questão mesmo.

Também tenho muito interesse de saber como vender projetos com agile. A impressão que eu tenho é que os projetos sairiam mais baratos para os clientes, mas e para consultoria como fica, pode não ser interessante, talvez por isso ainda exista muita gente utilizando o cascatão inchado no mercado.

x@ndy:

Uma abordagem utilizada por XP para estimar o tempo necessário para o desenvolmento de algo é perguntar ao programador quanto tempo ele levaria para fazer aquilo. O problema nessa abordagem é que se torna impossivel estimar efetivamente, quanto tempo se levará para comprir uma atividade especifica!

Então o ponto de função permite estimar melhor que o conhecimento especialista? :roll:

fzampa:

x@ndy:

Uma abordagem utilizada por XP para estimar o tempo necessário para o desenvolmento de algo é perguntar ao programador quanto tempo ele levaria para fazer aquilo. O problema nessa abordagem é que se torna impossivel estimar efetivamente, quanto tempo se levará para comprir uma atividade especifica!

Então o ponto de função permite estimar melhor que o conhecimento especialista? :roll:

Desculpe, não fui claro, o que eu queria dizer é que não dá para especificar quanto tempo levara para concluir o projeto inteiro, vou retificar lá!

Pois é x@ndy, da mesma forma que eu não acredito que PF dê uma estimativa real para o projeto inteiro.

As coisas mudam, a necessidade e foco do cliente são outros em muito pouco tempo. Como o PF garante esta estimativa?

Acho que e valido como estimativa… e estimativa não é prever o futuro! É tentar dar um chute o mais proximo possivel do gol.

fzampa:

Pois é x@ndy, da mesma forma que eu não acredito que PF dê uma estimativa real para o projeto inteiro.

As coisas mudam, a necessidade e foco do cliente são outros em muito pouco tempo. Como o PF garante esta estimativa?

PF não garante nada, é uma métrica! Se as necessidades do cliente mudaram, você tem que recalcular os PFs para ter uma nova estimativa.

O problema dos pontos de função é “o quanto é válido essa estimativa”! É possivel calcular a complexidade de um software dando pesos para entradas e saídas? Na minha opinão não!

Oi x@andy, na sua opinião, quanto é válida esta estimativa? (no geral)

x@ndy:

fzampa:

Pois é x@ndy, da mesma forma que eu não acredito que PF dê uma estimativa real para o projeto inteiro.

As coisas mudam, a necessidade e foco do cliente são outros em muito pouco tempo. Como o PF garante esta estimativa?

PF não garante nada, é uma métrica! Se as necessidades do cliente mudaram, você tem que recalcular os PFs para ter uma nova estimativa.

O problema dos pontos de função é “o quanto é válido essa estimativa”! É possivel calcular a complexidade de um software dando pesos para entradas e saídas? Na minha opinão não!

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?

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?

E um projeto inteiro é feito de que, senão pequenas tarefas?

fzampa:

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?

E um projeto inteiro é feito de que, senão pequenas tarefas?

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?

Bom, pra deixar bem claro qual é a minha opinião:

Não sou totalmente contra contagem de pontos de função. Apenas não concordo que seja associada a esforço.

Em uma analogia (que talvez não deva ser feita): a construção de um apto de 100m² pode custar 10 ou 1.000, dependendo do acabamento e outros fatores que não alteram o tamanho. Ter torneira de ouro não faz o banheiro maior.

Tamanho é uma coisa, custo e esforço outras. O ponto de função calcula tamanho. Daí partir para custo e esforço são outros 500.

luistiagos:

fzampa:

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?

E um projeto inteiro é feito de que, senão pequenas tarefas?

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?

Você fez a pergunta certa. E aí?

Ai, eu que pergunto: se vc não conhece o contexto todo, vai calcular PF com base em que? Já vai dar o prazo final nessa etapa já? Não conhecemos tudo, como sabemos quanto vai custar e quanto tempo vai levar?

Não é arriscado?

Pra mim é válida em pequenos projetos! CRUDs simples. Ai é possivel ter uma estimativa mais próxima da realidade! Agora em dominios complexos qualquer estimativa feita com FP é chute (claro que isso é minha opinião).

O problema é que o desenvolvimento de software é encarado como sendo uma atividade fabril e não uma atividade de projeto de engenharia. Processos fabris podem ser medidos, mas como se estima o tempo para criar um novo produto? Já trabalhei com engenharia um tempo e até hoje não conheço uma técnica eficaz para isso!

fzampa:

luistiagos:

fzampa:

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?

E um projeto inteiro é feito de que, senão pequenas tarefas?

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?

Você fez a pergunta certa. E aí?

Ai, eu que pergunto: se vc não conhece o contexto todo, vai calcular PF com base em que? Já vai dar o prazo final nessa etapa já? Não conhecemos tudo, como sabemos quanto vai custar e quanto tempo vai levar?

Não é arriscado?

Sim. Mas isto acontece muito, chega o cliente e da um prazo extremamente curto para a empresa montar uma proposta em base a informações vagas…
Eu prefiro a abordagem por ondas sucessivas, que nem no Scrum que vc estima sprints por sprint e a estimativa de um novo sprint vc tem a experencia dos antigos, então a estimativa tende a ficar mais correta a cada novo sprint. Porem tem cliente que quer tudo de uma vez. e Não aceita o modo “Jaque” por partes…

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!

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.

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?

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?

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

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.

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?

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?

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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?
  

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!

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

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.

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.

luistiagos:

fzampa:

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?

E um projeto inteiro é feito de que, senão pequenas tarefas?

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?

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

fredferrao:

Em suma, se é TÃO inutil assim como dizem, porque continuam usando e acabam tendo algum resultado?

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

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

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.

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 , 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.

Eles continuam usando porque deu certo e hoje podem contratar programador tão fácil quanto ajudante de pedreiro.

Link interessante: http://blog.8thlight.com/uncle-bob/2012/04/20/Why-Is-Estimating-So-Hard.html

Hermanoz:

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 , 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.

Eles continuam usando porque deu certo e hoje podem contratar programador tão fácil quanto ajudante de pedreiro.

Não, nunca deu certo, mas eles insistem nisso na esperança de não precisarem de programadores caros, tendo assim a ilusão de que uma ferramenta vai pensar em quanto um ser humano executa o trabalho.

Esses que contratam programador a preço de ajudante de pedreiro ainda não perceberam que a causa da falta de confiabilidade dos seus produtos é justamente essa. Programador inexperiente provoca bugs, e aos montes e não sabe estimar porque não tem experiência pra isso.

Quanto tempo as pessoas vão levar pra aprender que os pedreiros da nossa área são as máquina que constroem (build) os nossos projetos (códigos)?

Quanto tempo vão levar pra aprender que programador bom produz software bom e programador ruim produz software ruim?

Muitas empresas que tem a visão de que quanto menos pagar um programador melhor não vão sobreviver por muito tempo. As coisas estao melhorando, muitos empresarios ja se deram conta disso e já estão começando a fazer software melhor a custo mais baixo justamente fazendo o contrário, pagando mais, por gente mais capacitada.

A diferença de produtividade dos bons programadores em relação aos mais fracos é muito grande, tanta que muitas vezes um só pode valer por uma equipe toda.