Scrum + Pontos de Função. O que acham?  XML
Índice dos Fóruns » Metodologias de Desenvolvimento e Testes de Software
Autor Mensagem
mateushim
Thread.start()

Membro desde: 28/10/2008 15:08:02
Mensagens: 25
Offline

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
sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

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


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.


JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
Emerson Macedo
Virtual Machine Man
[Avatar]

Membro desde: 01/08/2006 16:55:28
Mensagens: 689
Localização: Rio de Janeiro - RJ
Offline

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

Emerson Macedo Leite
PMP - Ping-pong Master Player
CSM - Counter-Strile Manager
http://codificando.com

"Porque, assim como o relâmpago sai do oriente e se mostra até o ocidente, assim será também a vinda do filho do homem." - Mateus 24:27
[Email] [WWW] [Yahoo!] [MSN] [ICQ]
Luca
Moderador
[Avatar]

Membro desde: 06/09/2002 14:30:10
Mensagens: 5818
Localização: São Paulo/SP ou Paraty/RJ
Offline

Olá

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


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

Dare Obasanjo (Program Manager at Microsoft)
"The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already "invested" in WS-* and want to defend that investment."


CEP, JMS, JMX e coisas afins (ou não)
http://lucabastos.blogspot.com/
[Email] [WWW]
faelcavalcanti
GUJ Ranger
[Avatar]

Membro desde: 03/05/2006 13:16:25
Mensagens: 960
Localização: Recife-PE
Offline

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.

This message was edited 1 time. Last update was at 26/09/2009 08:19:12



--
http://faelcavalcanti.wordpress.com/ :: http://pe.debianbrasil.org/
--
Acredite um pouco mais na força de sua própria intuição. Muitas vezes deixamos de realizar algo de bom ou que nos favoreça simplesmente porque achamos tudo muito difícil e por isso nem começamos. Moral da história: A vida é o caminho e não o destino, você é o arquiteto do seu caminho!
--
Obrigado, Rafa Rocha!
[WWW]
Luca
Moderador
[Avatar]

Membro desde: 06/09/2002 14:30:10
Mensagens: 5818
Localização: São Paulo/SP ou Paraty/RJ
Offline

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

Dare Obasanjo (Program Manager at Microsoft)
"The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already "invested" in WS-* and want to defend that investment."


CEP, JMS, JMX e coisas afins (ou não)
http://lucabastos.blogspot.com/
[Email] [WWW]
mochuara
GUJ Master
[Avatar]
Membro desde: 20/05/2009 11:21:32
Mensagens: 1776
Offline

Luca wrote: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


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.
marcosalex
GUJ Expert

Membro desde: 20/02/2008 12:32:59
Mensagens: 3615
Offline

Estudar pontos de função é interessante como contexto histórico, pra saber como eram as tentativas antigamente. Mas é a mesma coisa de você tentar achar um algoritmo pra administrar uma empresa, ou uma fórmula genérica pra criar uma política de marketing.

Métodos empíricos não existe bala de prata, é recomendável você conhecer boas práticas e ter experiência de saber quando é melhor usar qual delas pela situação.

Tanto é que não existe só Scrum de metodologias ágeis pra desenvolvimento.
[ICQ]
Emerson Macedo
Virtual Machine Man
[Avatar]

Membro desde: 01/08/2006 16:55:28
Mensagens: 689
Localização: Rio de Janeiro - RJ
Offline

mochuara wrote: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.

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

Emerson Macedo Leite
PMP - Ping-pong Master Player
CSM - Counter-Strile Manager
http://codificando.com

"Porque, assim como o relâmpago sai do oriente e se mostra até o ocidente, assim será também a vinda do filho do homem." - Mateus 24:27
[Email] [WWW] [Yahoo!] [MSN] [ICQ]
marcosalex
GUJ Expert

Membro desde: 20/02/2008 12:32:59
Mensagens: 3615
Offline

Emerson Macedo wrote:
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.



Também penso assim. Agilidade está na forma de trabalhar, um nível de abstração acima da linguagem usada.
[ICQ]
mateushim
Thread.start()

Membro desde: 28/10/2008 15:08:02
Mensagens: 25
Offline

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




wylkerb
Smalltalk

Membro desde: 16/04/2011 00:45:31
Mensagens: 2
Offline

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).
 
Índice dos Fóruns » Metodologias de Desenvolvimento e Testes de Software
Ir para:   
Powered by JForum 2.1.8 © JForum Team