Geralmente desenvolvedores que defendem
metodologias Ágeis (e eu também defendo) torcem o nariz ao ouvirem sobre
estimativa de software através de Análise por Pontos de Função (APF).
Talvez seja uma questão de gato escaldado ter medo de água fria, uma vez
que a APF muitas vezes foi e é utilizada em conjunto com metodologias
não ágeis, partindo de uma especificação de requisitos detalhada, depois
de uma análise, projeto, etc., ou seja, um processo em cascata.

Apesar
de compreender a tendência de associarmos APF com processos não ágeis,
também percebo uma boa dose de puro desconhecimento. Boa parte da culpa é
da terminologia inadequada da APF, baseada em conceitos do
desenvolvimento de software da época do Mainframe. Mas se vencermos o
problema da terminologia, e entendermos bem a proposta da APF, vamos ver
que a coisa não é tão água e óleo como costumamos ouvir por aí.

Como qualquer outra coisa, você só deve pensar em incluir o uso de
APF em seu processo se isso for resolver alguma questão, ou seja, se
isso agregar valor ao seu processo ágil de desenvolvimento. Um motivo
muito forte para fazer isso é se você presta ou deseja prestar serviço
de desenvolvimento para o Governo, pois o TCU cita especificamente o uso
de APF para medição (item 9.4.1.1, TC-006.030/2007-4, Acórdão n°
1.999/2007-TCU-Plenário e item 9.2.2.2, TC-019.998/2007-7, Acórdão n°
2.024/2007-TCU-Plenário). Logo, quer gostemos ou não, hoje a principal
forma de medir software entregue para o governo é pontos de função.

Deixando o preconceito de lado

Pense comigo. Um dos principais valores do Ágil é a receptividade a
mudanças nos requisitos, e tudo o que nós NÃO queremos é um contrato de
escopo fechado, baseado em uma grande especificação de requisitos, para
qual nós teremos de dar um preço fechado e, ao final, entregar o que foi
contratado.

Mas APF hoje é exatamente a opção que temos de vender (ao
Governo) uma quantidade de serviço de desenvolvimento (medidos em pontos
de função, é claro) sem necessariamente termos os requisitos todos
definidos a priori. Em outras palavras, alguém pode comprar 1000 PF e
consumir esses recursos através de um processo ágil, de modo tal que
cada nova entrega seja medida através da APF, e os 1000 PFs sejam
utilizados para construir aquilo que mais agregue valor para o cliente.

É preocupante o fato de o Pregão Eletrônico se basear basicamente no
valor do ponto de função, pois isso tem feito com que o valor diminua
muito, chegando a patamares inexequíveis, o que inevitavelmente irá
provocar prejuízos tanto para a empresa contratada quanto para a
contratante. Outra questão a ser avaliada é a qualidade desses softwares
construídos com valores tão baixos.

Contudo, acredito que isso seja uma
questão de imaturidade das organizações, governamentais ou privadas, que
contratam por PF por ainda não serem capazes de adotar métricas de
qualidade adequadas como condição para o aceite do produto construído,
especialmente porque a APF mede o tamanho funcional do sistema (seu
tamanho/escopo em termos de requisitos funcionais), que não é afetado
por detalhes de implementação e requisitos de qualidade.

Concluindo, APF tem várias limitações no que diz respeito à
estimativa de trabalho, por não levar em consideração requisitos não
funcionais e de qualidade. Mas ela não está presa a um processo de
software em particular.

Muitos argumentam que a técnica é muito antiga e
inadequada para o desenvolvimento ágil, mas todos os comentários que
encontro nessa linha acabam expondo certo desconhecimento do objetivo da
APF. Acho honesto destacar também que as imprecisões/aproximações
inerentes à técnica (aqueles números empíricos justificadamente
questionáveis, p.e.) não são menos precisas do que nossos bons “chutes”
dados via Planning Pokker, quando definimos nossos “Story Points”.

Em
outro momento, pretendo falar um pouco mais sobre o que é e o que não é
APF, pois por causa de graves gaps semânticos nós, desenvolvedores,
somos os mais tendentes a compreender mal a técnica. Por hora, vale
apenas destacar que, dada a necessidade, não vejo grandes problemas em
adotarmos pontos de função para medição de software entregue dentro de
um processo ágil.

Se essa é a melhor forma, isso é outra conversa.