sábado, 16 de junho de 2012

E a Analise de Pontos de Função?

Como eu repito normalmente, APF para mim é uma forma pseudo-científica que tenta uma conciliação entre os envolvidos para algo incerto parecer que pode ser certo.

Resumindo: para mim, falha ao tentar resolver um problema, o da metrificação. Em vez de lidar com a incerteza da complexidade, tentar simplificar o que é complexo.


A criação de uma produtividade supõe que uma média de uma equipe avaliada em alguns meses, é a realidade do time para o desenvolvimento da demanda. E se metade da equipe mudar ou alguns herois adoecerem? Será que essa produtividade será a mesma.

Então já parte de uma premissa, que vai "reger" a equipe, medida em poucos meses.

Além disso, dizer que as discussões diminuem também é um mito. Não existe mais a discussão sobre Homem/Hora, mas agora existe a discussão sobre o que deve e o que não deve ser contado.

Existem pontos que não são contados, mas exigem esforço. Normalmente a APF resolve isso nos pontos contáveis, acreditando mais uma vez em uma média retirada em alguns meses, alguns casos.

Encontrar esse equilibrio é complicado, então temos novamente o cabo de guerra para decidir se a relação será win-lose ou lose-win.

Isso mata o que pode haver de mais positivo em uma relação: a confiança. Ninguém confia em ninguém. Não existe win-win.

Não acredito muito na compatibilidade dos métodos ágeis justamente por APF tentar simplificar um sistema complexo, e faz isso, como já disse, com a "produtividade".

Existe algo parecido com esta produtividade no Scrum: a velocidade do time. Mas a grande diferença é que ela pode ser ajustada com mais frequencia.

Outra diferença é que as equipes Scrum conhecem o ciclo de formação de times de Bruce Tuckman: forming, storming, norming, performing. Antes de chegar no último estágio, o time é apenas um grupo.

Uma equipe Scrum sabe que a velocidade medida nas duas primeiras fases deve ser ajustada. E ela é ajustada.

Outra diferença é o que define a velocidade do time é um processo transparente onde quem decide é o próprio time.

Equipes ágeis normalmente não cobram H/H e prefere inclusive contratos flexíveis. Tenho amigos que possuem empresa onde o contrato pode ser finalizado a cada iteração, o cliente fica até quando quiser.

Isso só é possível porque a empresa fornecedora tem certeza que recebeu o que era devido por aquela iteração e tem a preocupação de manter a qualidade do trabalho para manter o cliente. Ela confia que é capaz de manter o cliente com entregando bons serviços.

Se para o cliente é mais vantajoso ficar porque o fornecedor, de fato, se preocupa com o que está entregando, e se o fornecedor recebe o justo pelo serviço prestado, por que não tentar uma relação win-win?

O Kanban metrifica, principalmente, o Lead Time - tempo que as tarefas levam para percorrer o fluxo de valor - e com o Cumulative Flow Diagram - CFD - verifica quantas tarefas estavam em cada ponto do fluxo durante um dado período. Creio que no Kanban nada seja parecido com a velocidade do Scrum e a produtividade da APF.

Enfim, sempre me posicionei contra a APF, mas agora, depois de ter alguma experiencia com ela, estou dizendo por que.

A sua análise é diferente? Por que?

2 comentários:

  1. Os pontos apresentados são reais e refletem, não um problema intrínseco da análise de pontos de função, mas equívocos sistemáticos em sua aplicação por parte de muitos profissionais.

    Talvez pelo ensino do método ser feito inicialmente em faculdades de cunho tecnológico, os próprios professores não tenham um entendimento claro da base da medição (as tarefas do usuário no plano da divisão do trabalho) e propaguem isso aos alunos que passam a implementar esquemas de medição que contribuem para os problemas que citou.

    O primeiro ponto equivocado é medir um SPRINT considerando o que nele se inclui, altera ou exclui em termos de funcionalidades. Isso NUNCA deve ser feito. Num projeto ágil o que deve ser medido e estimado é o PROJETO como um todo. Para avaliar o quanto deve ser pago pelo SPRINT deve-se avaliar o quanto já se agregou de valor ao projeto como um todo e remunerar a diferença entre esse último e o quanto já foi pago.

    Uma proposta para cálculo desse valor agregado está em fase de prova de conceito em uma empresa multinacional e resumidamente descrita em nosso blog da FATTO ( http://www.fattocs.com.br/blog/?p=155 ). A lógica do Kanban pode ser usada nesse processo.

    Quanto a questão da APF não capturar toda a complexidade, qualquer outra métrica faz isso. O que faz o uso de uma métrica funcionar é o fenômeno da normalidade. Uma coisa compensa a outra no volume. Um projeto tem centenas de funcionalidades, algumas demandarão mais esforço, outras menos esforço; mas na média, teremos uma tendência central que seja representativa.

    O técnico tem uma ânsia de conseguir que isso aconteça no micro, em uma tela, em uma pequena parte do software. Ai está o equivoco! Deve-se manter uma perspectiva do projeto.

    Outro ponto que depreendi da manifestação é a dificuldade de aceite da apropriação indireta de custos. A APF não mede uma série de coisas que dão trabalho. E ai... Como fica isso? Fica no preço! O preço do PF deve pagar por o que a APF não mede.

    Nesse sentido, recomendo ler (assistir):

    - Quem paga pelos dados de código (http://www.fattocs.com.br/blog/?p=258);
    - Quanto pagar por um ponto de função - http://apf.locaweb.com.br/mod/page/view.php?id=3016

    Um grande abraço e sucesso!

    Carlos Eduardo Vazquez (Cadu)

    ResponderExcluir
  2. Olá Celso, tudo bem?

    Como eu repito normalmente, APF para mim não é essa cocada toda que andam dizendo por aí... Mas também está longe de ser este demônio todo que outros também falam...

    Resumindo: Para mim, serve para resolver um problema específico, o da metrificação do tamanho *funcional*!! Mas... there's no silver bullet!! APF não é a solução de todos os problemas existentes... longe disso... e nunca se propôs a ser... E erra quem diz que é...

    APF serve para algo específico e muita gente passou a usar APF para algo que ela não serve...

    Isso faz com que muita gente odeie a APF, por algo que ela não é e nunca se propôs a ser... Deviam odiar quem disse que APF serve para isso...

    No seu caso você argumenta que "A criação de uma produtividade supõe que uma média de uma equipe avaliada em alguns meses, é a realidade do time para o desenvolvimento da demanda". Agora quem te falou isso? Onde a APF se posiciona assim? Onde o IFPUG orienta a fazer dessa forma? Quem falha nesse caso não é a APF, mas sim quem te orientou a acreditar que uma produtividade média avaliada com APF deve ser encarada como a realidade do time...

    Novamente, quem "parte de uma premissa, que vai 'reger' a equipe, medida em poucos meses" não é a APF. Falha quem orienta que a APF deve partir dessa premissa para 'reger' a equipe.

    É possível usar APF em um contexto ágil, estimando e medindo um projeto como um todo, como o colega Cadu, citou. E ainda assim medir/estimar a sprint com Kanban, Scrum, ou como vc preferir...

    APF serve para quê? Para medir tamanho funcional.
    Preciso medir tamanho funcional para quê? Pode servir como um dos pilares para a precificação ou estimativa de prazo.

    Repare que pode servir como "um dos pilares", ou seja nunca deve ser utilizado só APF na definição de preço ou estimativa de prazo e esta é a recomendação do IFPUG.

    A ISO diz que um sistema tem 3 dimensões de tamanho, o tamanho funcional, o tamanho técnico e o tamanho de qualidade. E que uma medida de tamanho deveria contemplar essas 3 medidas. APF se propõe a medir tamanho funcional... Quer usar APF? Assegure-se de não considerar apenas o tamanho funcional e considerar também as questões técnicas e de qualidade para chegar em um TAMANHO!!

    Vai usar APF para custo? Avalie outros aspectos necessários para a precificação. Usar APF por si só é besteira.

    Vai usar APF para produtividade? Tem certeza? Ok, avalie outros aspectos que impactam a produtividade... Encarar hora/PF como uma única medida válida e "regra geral" é besteira...

    Ninguém obriga ninguém a usar APF... É uma proposta, que serve bem em alguns cenários... E não serve para outros ;-)

    E o mais importante... Decidiu usar APF? Use da maneira correta, conforme as regras e melhores práticas do IFPUG, mantendo um baseline, para facilitar a vida do analista de métricas e evitar retrabalhos.

    Abs,
    Bruno Torquato

    ResponderExcluir