O mercado hoje, em especial no âmbito da administração pública sob a esfera do SISP, busca por alternativas ao modelo de preço unitário por ponto de função. Apesar de todos os problemas que já se conhece, ganha força e há pressão por um modelo de alocação.

Na esfera pública, se remunera o serviço realizado. No caso do desenvolvimento de software, isso significa que se remunera pela entrega de “software pronto”. Ou seja, software funcional, testado, validado e que pode ser colocado em produção. Essa é toda a dificuldade de se encontrar uma métrica para remunerar esse serviço.

O Ágil pressupõe iterações contínuas que refinam, tanto do ponto de vista técnico quanto do funcional, o escopo do projeto. Além disso, a equipe de desenvolvimento necessita de uma métrica que ajude a acompanhar o trabalho da equipe, mantendo a produção em um “ritmo sustentável” com entregas previsíveis.

O maior erro é pensar que essas duas métricas podem se fundir em uma. Objetivos diferentes, complexidades diferentes e atores diferentes não permitem que usemos uma única métrica para atender aos dois conjuntos de necessidades. Aceitar isso é a condição primária para encontrar uma solução.

Métrica de pagamento

O objetivo da métrica de pagamento é verificar se a “quantidade de produto” encomendada foi entregue, nas condições contratadas. A complexidade de se medir isso é a natureza do serviço que é imaterial, visto que ele é a transformação de um desejo abstrato em uma funcionalidade operacional com todas as características de segurança, usabilidade e qualidade. Os atores são os fiscais, os prepostos e gerentes de contrato que tem compromisso com características como rastreabilidade, auditoria e formalidade, afinal, estamos falando de dinheiro público.

Métrica de desenvolvimento

A métrica de desenvolvimento tem o objetivo de ajudar o Time a se manter em um “ritmo sustentável”, não deixando que os desenvolvedores se comprometam com mais nem menos entrega do que podem realizar em cada Sprint e que possam ter previsibilidade temporal para a realização do “Backlog do projeto” que sempre está em transformação. Está métrica tem que levar em conta a senioridade da equipe de desenvolvimento, o tamanho desta equipe e a complexidade do serviço, seja do ponto de vista tecnológico, seja do ponto de vista da interação entre os diversos atores e o contexto em que estão inseridos.

Requisitos para as métricas

Para termos métricas viáveis, o fluxo de serviço precisa ser simples, tanto para o pagamento quanto para o planejamento da execução de um Sprint. Ele parte da inclusão e priorização de Histórias em um Backlog, passa pelo planejamento do Sprint, construção das histórias, verificação do Pronto das histórias e pagamento pela entrega realizada no Sprint.

Uma história contada várias vezes

Como ocorrem refinamentos sucessivos ao se desenvolver uma funcionalidade, tanto do ponto de vista da construção do código, quanto do entendimento da funcionalidade, uma História pode entrar no backlog várias vezes. Na primeira vez ela é criada, depois pode entrar para ser alterada/refinada, ou excluída. Em cada uma das passagens ela é planejada pela equipe em um Sprint e o serviço é pago após a história ser dada como pronta.

Pontos de História ou Story Points e sua aplicabilidade

A métrica de “Pontos de História” tem como características o baixo formalismo, a incorporação da experiência da equipe como fator de contagem, que leva ao comprometimento com o resultado final, a possibilidade de haver o refinamento do resultado a partir das sucessivas contagens e por fim, proporciona um instrumento ágil, no sentido estrito da palavra, capaz de dar previsibilidade ao processo. Essa métrica é impregnada pela visão do Time, que usa sua experiência para aferir a complexidade tecnológica e as dificuldades operacionais intrínsecas ao projeto. Dois Times não terão a mesma contagem para uma História.

Com essas características poderíamos eleger os pontos de história como a métrica a ser usada pela equipe, mas não podemos usá-la como uma métrica de pagamento, principalmente em contratos “guarda-chuva”, que suportam vários projetos em seu objeto.

Pontos de função e sua aplicabilidade

A métrica de Pontos de Função se apresenta como tendo a capacidade de demonstrar a partir da visão do usuário a dimensão do que se vai entregar como pronto. Além disso, apresenta uma forma de medição que pode ser reproduzida por várias pessoas para uma mesma História encontrando um mesmo resultado ou algo muito próximo. Ou seja, existe um processo formal de contagem que é rastreável.

Sendo rastreável e independente da pessoa que realiza a contagem essa é uma métrica ideal para definir o tamanho do produto Pronto entregue ao final do Sprint.

Oportunidades de melhoria com Pontos de Função

Geralmente quando se fala de Pontos de Função em um ambiente de cultura ágil, são duas as principais críticas:

1. O formalismo torna a contagem excessivamente trabalhosa;
2. O resultado da contagem não consegue expressar a complexidade da construção de um software.

Dessa forma ela é rapidamente descartada, pois não seria uma métrica adequada para servir como base de cálculo da remuneração pela construção de um software.

Soluções

Para calcular os Pontos de Função diminuindo o trabalho envolvido sem perder um mínimo de formalismo que garanta a rastreabilidade, podemos usar a Contagem Estimativa da NESMA ou uma  simplificação maior com o Ponto de Função Simples.

Para contrato do tipo guarda-chuva podemos definir características do projeto (tecnologia e contexto organizacional), que permitam criar um fator de produtividade das equipes. O objetivo é agregar a fórmula de cálculo do preço um valor correspondente à complexidade de construção. Este fator é calculado baseado em um Time com formação básica de desenvolvimento.

Isso não é suficiente para resolver o problema, pois alguns impedimentos e tarefas não podem ser metrificadas em Pontos de Função e se forem agregados ao cálculo do fator de produtividade podem causar uma distorção. Podemos compor uma lista que atribui três níveis de complexidade para cada uma dessas tarefas, com parâmetros claros que possam definir em que nível uma tarefa será executada. Trata-se de um caso de Unidade de Serviço Técnico.

A fórmula de pagamento ficaria assim:

Pagamento = (Quantidade de PF * Fator de Produtividade) + Tarefas Não Metrificadas

Quantidade de PF: é o somatório de Pontos de Função das histórias que serão desenvolvidas em um Sprint.

Fator de Produtividade: é um fator de multiplicação que deve ser escolhido em uma tabela a partir de parâmetros relacionados a complexidade de desenvolvimento. Ele está expresso em HH/PF.

Tarefas Não Metrificadas: São tarefas descritas em uma tabela com correspondência a quantidade de horas estimadas para sua execução. São expressas em HH.

Simplificação do fluxo de trabalho com o Kanban

O processo de construção proposto se baseia no Kanban. Outrossim, o processo é um fluxo iterativo incremental. Forma-se um Backlog de Histórias priorizadas. Então, um conjunto de Histórias deve ser escolhido para ser desenvolvido em um Sprint. Finalmente, cada História deverá ser pontuada em Pontos de História pela equipe de desenvolvimento. Isso com objetivo de definir um conjunto de Histórias capaz de ser desenvolvido em um Sprint.

Para fins de gestão de mais alto nível, cada História criada deve ter seus Pontos de Função contados de maneira simplificada. Ao resultado, aplica-se o Fator de Produtividade do projeto como um todo.

Finalmente quando o Sprint termina, avaliam-se as Histórias prontas. Isso, para saber se há necessidade de recontagem ou de uso de um outro Fator de Produtividade.

Conclusão

Pode-se isolar a equipe de desenvolvimento do uso dos pontos de Função pelo Agile Master. Isso, porque a contagem usando a NESMA ou o Ponto de Função Simples tendo a História como escopo de medição é muito simples.