este é um pensamento que vêm me acompanhado já faz algum tempo e gostaria de saber a opinião de vocês. Depois de tanto tempo se falando do inferno que é trabalhar em um processo no estilo cascata, no tanto que processos ágeis são a coisa mais linda do mundo e tal, vira e volta os pontos de função me encaram.
Quando os vejo, imediatamente me vêm à cabeça as cataratas do Niagara, uma cascata monstro. Sei que é interessante termos uma métrica legal pra poder dar preço no nosso trabalho e tal, mas a contagem de ponto de função não implica numa cascata bruta não? Como ponto de função se adequa em ambientes em constante mudança? O que há além dos pontos de função pra executar nossas medições?
Gostaria muito de ouvir a opinião de vocês a respeito.
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!
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![/quote]
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.
[quote=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![/quote]
Então o ponto de função permite estimar melhor que o conhecimento especialista? :roll:
[quote=fzampa][quote=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![/quote]
Então o ponto de função permite estimar melhor que o conhecimento especialista? :roll:
[/quote]
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á!
[quote=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? [/quote]
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!
[quote=x@ndy][quote=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? [/quote]
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![/quote]
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=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=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?
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.
[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]
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?
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!
[quote=fzampa][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]
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?[/quote]
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…