Texto de Célio Junior
Como quase tudo que envolve métodos ágeis a questão não é técnica e sim conceitual.
O principal objetivo das metodologias ágeis é entregar valor para o cliente. E como isso ocorre? Cliente e Time (ágil) irão colaborar para entregar o máximo de "software" possível que implique ao cliente o maior retorno de investimento (ROI) possível.
O que é PF? É o tamanho funcional de um sistema.
PF mede valor de negócio? Não (só se for indiretamente e olhe lá).
Então por que um time/cliente ágil vai utilizar PF em um projeto ágil? Não faz sentido...
Quero dizer, o cliente pode pagar por 10PF hoje e ter um ROI imenso, e pagar por 10PF amanhã e não ter ROI nenhum. Ou seja, PF não pode ser usado como uma métrica útil para times ágeis a não ser para ser usada como ela é hoje, para "precificar" o software. Ai é que conceitualmente mora o perigo pois da forma como PF é usada estaremos agora observando preço ao invés de valor.
Nessa visão de preço o time e o cliente não mais colaboram e sim concorrem, afinal o cliente quer ter o minimo de PFs com o máximo de software (pagando menos), enquanto o time quer ter o mínimo software com o máximo de PFs (recebendo mais) e o foco da minha negociação deixa de ser vantagem competitiva do cliente para ser preço de PF e detalhamento de requisitos (histórias do usuário...) e isso não tem mais nada a ver com agilidade.
Por isso que métodos ágeis funcionam melhor com contrato de custo fixo (pagando por mês por exemplo) e escopo variável, enquanto que na conjectura atual, PF + escopo variável = preço variável e nesse cenário negociação de contratos é mais importante do que colaborar com o cliente (O contrário disto está na 3ª declaração do manifesto ágil).
E pra variar, PF não tem culpa disso ;)
