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.
Fora de tópico Mostrar Código Esconder Código Mostrar EmoticonEsconder Emoticon