Estimativa de tempo de desenvolvimento de requisitos

Então Orocildo,

Se você for partir pra um processo de estimativas bem formal, o padrão mais utilizado é a estimativa por pontos de função. Nela são consideradas questões como a quantidade de tabelas envolvidas em um requisito, entre outros. No fim ela gera uma quantidade de pontos que a sua empresa deve analisar quanto tempo demoraria.

Se você quiser algo mais informal, o Scrum tem algumas técnicas bem simples de aplicar: Poker Game e Velocity.

• O Poker Game é uma reunião onde todos os envolvidos no projeto fazem uma estimativa juntos dando pontos em uma escala numérica (decimal normal, logaritmica, fibonacci, etc). Caso hajam pontuações diferentes para um mesmo requisito, ele é discutido até que todos cheguem num consenso quanto a estimativa daquele requisito.
• O Velocity indica o quanto o time consegue desenvolver em um Sprint. A forma mais simples é ver quanto o time desenvolveu no Sprint anterior e assumir que esse é valor que time consegue desenvolver no novo Sprint.

Com o resultado do Poker Game e do Velocity, é feita uma reunião para definir quais estórias serão desenvolvidas no próximo Sprint.

Eu particularmente prefiro a opção com Scrum, pois ele envolve mais todos os participantes do desenvolvimento. Mas ae é ver a realidade do projeto que você está trabalhando para decidir qual a melhor opção.

eu sou meio leigo nisso também mas uma dica que posso te dar que me arrisco a acreditar ser uma regra de ouro é sempre colocar uma certa folguinha, sei la, uns 20% a mais de tempo, por que você vai ter seus imprevistos…

Orocildo:

Então pessoal, onde trabalho terei de começar a estimar o tempo de desenvolvimento de requisitos. Não sei se alguém trabalha assim, porém em empresas de grande porte é muito comum. Tu da a estimativa, o team lead e a gerente de projetos aceita ou não. Chegando em um consenso, tu começas a desenvolver.
Então tem alguma dica, truque ou algo que ajude a fazer estimativas de maneira mais eficiente e precisa ? É apenas investigação e experiência mesmo? Ou tem algo a mais que possa ajudar ? Queria uma dica dos “cancheiros”.

Thanks!

Métricas é um problema comum no desenvolvimento de software , com certeza os acertos só virão com a maturidade dos processos , equipe, etc… porém te adianto que senão houver um processo muito bem definido tais como ciclo, metodologia , etc…é meio complicado estimar … mas você pode pensando em usar UCP (Unit Case Point) ou APF (Ponto de Função) , a diferença entre ambas é que UCP não é tão difundida já a APF é aplicada bastante por ae, tem o planning poker do scrum que é bom tbm e da para medir o esforço …
Uma dica é … imagina que você desenvolva um projeto onde terão 5 entidades (pessoas, endereco, telefones, dependentes , pedidos) multiplique a quantidade de entidades por 7 , no nosso caso 5 x 7 = 35 … agora imagine que sua equipe consegue ter uma produtividade de 9 horas por exemplo … então 35 * 9 = 315 horas … é uma sugestão quando não se tem um plano de métrica bem deficinido … nesta quantidade de horas vc acrescenta uns 30% de gordura … ficando :

315 * 30 = 410(Arredondado) …

Os numeros e dicas são opinião pessoal e funciona …é claro que com o passar do tempo vc vai guardando uma base histórica e com isto vai refinando os números …para os próximos projetos e assim sucessivamente …

Obrigado aos ricos posts escritos por vocês . Tomarei eles como ponto de partida para aprofundar minha pesquisa nesse assunto.
Quem desejar acrescentar ao tópico novas informação é muto bem vindo.

Grato