Scrum + Pontos de Função. O que acham?

Assuntos Gerais Agile
#1

Ola pessoal

Como acho que já comentei em alguns posts aqui pelo forum, estou fazendo meu TCC de aplicação de métricas em Scrum (aplicando planning poker e pontos de função)
E como estou no final dele, gostaria de saber a opinião, criticas e sugestões da vocês

Sei que tem livros que falam sobre estimativas em Scrum, mas estou fazendo mesmo assim
Estou aplicando num caso real e estou descrevendo em um estudo de caso que considero a parti crucial para o meu TCC
Pelo que estou vendo, estou tendo que fazer umas adaptações para conseguir aplicar, como por exemplo, estou tendo que usar o modelo de classes do UML para estimar o AIE e o ALI (estou colocando isso na analise do estudo de caso que isso n deve fazer parte do Scrum, o que acham?)

Achei já umas discussoes pela internet, que não recomendam utilizar pontos de função, mas acho que assim, para o meio academico vai ser bom, porque vai ser considerado um estudo cientifico baseado na aplicação pratica

Resumido
Estou meio que inseguro sobre oque estou fazendo e queria saber o que vocês acham

#2

[quote=mateushim]
Estou meio que inseguro sobre oque estou fazendo e queria saber o que vocês acham[/quote]

Eu acho um contra-senso. Pontos de função é coisa dos anos 70. A ideia (muito comum nos anos 70 e 80)
de que vc pode estimar através de calculos baseados em “métricas” é furada. A prova são as centenas de projetos
que falham. Projetos que falham são aqueles que explodem o prazo,o custo ou têm pouca qualidade.

Scrum é baseado em uma métrica relativa. O fato dela ser relativa é de extrema importancia porque é isso que realmente
importa para a matemática do scrum pois ele é baseado em razões e não em numeros absolutos.

Um Story Point pode ser equivalente a muitas coisas (1 dia ideal, o esforço da operação X, etc), mas tem que ser relativo e tem que ser proporcional.

Outro fator é escala. A escala de SP é descontinua (aka quantificada). É esta descontinuidade que faz tudo dar certo porque vc não consegue incluir estimativas subjetivas demais. Por exemplo, ou algo tem esforço 3 ou 5 não pode ter 4. A descontinuidade torna o processo quantificado e isso significa que ha uma matemática de inteiros sendo usada. Não é incrivel que esta seja melhor que as outras porque esse tipo de matemática já humilhou a mtemática decimal em outros campos, como na Mecânica Quantica, por exemplo - oferecendo resultados mais exatos que a prespectiva continua e decimal.

Ou seja, existem propriedades nas métricas de SP que têm sempre que estar presentes para a matemática do scrum funcionar corretamente. Acho que PF não atente essas propriedades. Para começar não é descontinua.

#3

Como o sérgio falou, pontos de função é uma tentativa de prever as coisas Up-Front e saber o custo real antes do tempo. Vai totalmente contra a filosofia Agile. E não estou falando isso de orelhada, pois alguns anos atrás fiz um curso disso numa empresa que trabalhei e cheguei a aplicar. Te digo: tem tudo a ver com Waterfall.

[]s

#4

Olá

Como já disseram e por sinal muito bem: tire tudo que se refere a pontos de função. Se seu professor insiste que tenha isto então deixe mas queime seu TCC logo após aprovado.

[]s
Luca

#5

há um tempo atrás fiz algumas perguntas a respeito sobre apf, e minha opnião é de que APF só vem a ter algum sentido de uso, se o seu cliente tem interesse em utilizá-lo, e ainda mesmo assim deverão entrar em acordo com a tabela de ajuste.

esta tabela é uma bela arma para aumentar o valor do software, ou seja, esta tabela é “bolsa marsupial de lucro” que a empresa tira de convencimento do cliente(em uma situação feliz o cliente pode impor limites e pontuações), de que certos pontos de ajustes devem ser maiores cá e lá, ganhando mais aqui e ali. tudo tem um jeitinho, quem já participou de projetos com APF sabe disto!

perguntei no meu post, sobre a média cobrado pelas empresas, mesmo sabendo que esta tabela pode variar, mas por curiosidade.

quanto a outra pergunta que mencionei se valeu a pena, acho que quem poderia responder melhor esta pergunta é o cliente. a resposta dele é soberana acima da resposta da empresa!

antigamente era utilizado um contrato de escopo fechado, empurrando 150% de gordura para o cliente e 0,75% de lucro para equipe. com ponto de função acontece o mesmo, sendo que o cliente acaba sabendo onde está a gordura, mas não sabe que a equipe não desbanja deste custo pago, e o pior, que de 10 membros, [5-6] são estagiários!

resumindo a abordagem de uma métrica não deve influenciar o desenvolvimento da equipe, nem mesmo em estimativas. isto acaba atrapalhando.
alguns tentam fazer tabela de comparações dizendo que x horas = y pontos de funcao, depois querendo buscar medidas de produtividade para reportar a superiores externos.

a contagem é papel para o analista de negócio!

se você está utilizando scrum, se preocupe mais com o calo atual(este post traduzido do akita menciona alguns) do scrum do que com métricas.

talvez por razões contratuais e regimento imposto pelo governo, de todas as métricas, achei esta a menos ruim como um metodo organizado para medir um determinado conjunto de funcionalidades de software, e, que se possa negociar do ponto de vista do usuário.

#6

Olá

Fael, você escreveu muito bem mas preciso falar mais (mal) de pontos de função.

Este treco foi criado no tempo anterior ao desenvolvimento orientado a objetos. Naquele tempo pontos de função já não davam certo. Eram o que é ainda hoje um chute. Quem faz pensa que está se baseando em premissas. Mas mesmo com o desenvolvimento era feito em cascata, ninguém tinha a menor idéia de como seria o sistema. A diferença de hoje é que naquela época se gastava meses e um monte de papel para tentar definir algo que ainda não existia e que na prática nunca iria existir, que era o sistema tal como visto na primeira fase da cascata.

Com o advento de linguagens como o Java, a análise por pontos de função mudou, tentou se adaptar, deram uma guaribada mas continua a mesma e velha perda de tempo. Ainda assim há empresas que contratam sistema baseados em pontos de função. Como ainda existem faculdades que ensinam desenvolvimento de sistemas em cascata.

Acho muito mais útil aprender COBOL na faculdade do que aprender pontos de função e desenvolvimento em cascata. Pelo menos COBOL ainda serve para alguma coisa.

[]s
Luca

#7

[quote=Luca]Olá

Fael, você escreveu muito bem mas preciso falar mais (mal) de pontos de função.

Este treco foi criado no tempo anterior ao desenvolvimento orientado a objetos. Naquele tempo pontos de função já não davam certo. Eram o que é ainda hoje um chute. Quem faz pensa que está se baseando em premissas. Mas mesmo com o desenvolvimento era feito em cascata, ninguém tinha a menor idéia de como seria o sistema. A diferença de hoje é que naquela época se gastava meses e um monte de papel para tentar definir algo que ainda não existia e que na prática nunca iria existir, que era o sistema tal como visto na primeira fase da cascata.

Com o advento de linguagens como o Java, a análise por pontos de função mudou, tentou se adaptar, deram uma guaribada mas continua a mesma e velha perda de tempo. Ainda assim há empresas que contratam sistema baseados em pontos de função. Como ainda existem faculdades que ensinam desenvolvimento de sistemas em cascata.

Acho muito mais útil aprender COBOL na faculdade do que aprender pontos de função e desenvolvimento em cascata. Pelo menos COBOL ainda serve para alguma coisa.

[]s
Luca[/quote]

Duvido muito que quem criou o manifesto agil tava pensando em Java + OO. Java e sobre-especificação fazem um par perfeito. Quem vem de outras linguagens mais antigas encontram na Java um terreno fertil para perpertuarem o estilo waterfall. O contrário, ou seja, uma linguagem que tivesse mecanismos anti-waterfall seria mais apropriado para Scrum, e do contrário que outros possam imaginar, o fato de ser OO pouco importa aqui. Java pode ter trazido muitas evoluções, mas não como linguagem adequada para processos ágeis.

Quanto a Scrum + Pontos de função eu concordo ser estranho. Mas como é apenas um TCC não vejo problema, da pra viajar legal na maionese. :slight_smile:

#9

Eu não entendi muito bem a sua colocação. Poderia explicar?

O que a linguagem ter a ver com agilidade? Eu posso ser ágil com Java, C, C++, Ruby, Python, etc. Não consigo ver a linguagem como incentivadora de waterfall.

[]s

#11

Bom galera

Realmente estou aplicando e ta muito dificil, estou fazendo 0,3 h por PF, está meio viage sabe o tcc, mas vo fazer mesmo assim e mesmo saindo meia boca, pelo menos estou tendo um estudo caso e consiguindo tirar conclusões disso cientificamente e dizer o que vocês já sabem, que não da para utilizar
e nao como falaram para queimar o TCC

como disse o mochuara , é apenas um TCC e eu vou fazer uma analise, comparando com Ideal Day e Planning Poker
e espero que a banca entenda o ponto de vista disso e me aprove

Como estou fazendo:

Coloquei no product backlog a tarefa, ai no Sprint Backlog dividi essa tarefa em muitas tarefas menores para conseguir extrair os pontos de função, e também fui obrigado a utilizar um diagrama de classes e um diagrama de contexto.

Ai nassas tarefas menores coloquei uma coluna para definir o tipo (ALI, AIE, EE …) assim por diante
e apliquei pontos de função

é isso ai… espero mais argumentos sobre isso

grato pessoal

#12

Olá pessoal…peguei o bonde andando mas acho interessante dar um parecer na discussão.

Bem, a APF por sí só não define o prazo ou estimativas de tempo ou esforço, ela vai apenas somar informações para definição dos termos supracitados. Infelizmente, através do conhecimento empirico, tem-se informação de de velocidade e ou esforço de equipes, mas sem nenhum parametro formal, ou seja, story points medidos por esforço não informará em absolutamente nada quando for necessário medir produtividade inter equipes e em contratações (com esopo fechado). Não há, portanto, uma “medida” para determinrar tamanho de software em metódos puramente empiricos. Com a adoção de APF é possível encontrar uma medida comum para medir produtividade inter equipes. Mas como falei anteriormente, a APF por si so, quando utilizada para determinar o prazo de um projeto é furada, deve-se sempre medir o esforço necessário (em horas ideais) de uma equipe para realizar tal produto, para isso é saudavel utilizar o velho e bom planning poker. APF é coisa do passado? sim, mas está presente atualmente e pode somar informações importantes para organizações (qd utilizada da maneira correta).

#13