Como medir a produtividade da equipe de software

Por que é importante

Aplicar a Análise de Pontos de Função em uma granularidade incompatível com a variabilidade da produtividade em indicadores, que a usam como base na medição da produção, é uma das principais causas de fracasso em iniciativas que buscam os benefícios da medição funcional de software. “APF não funciona” é o estigma residual para os envolvidos nessas situações. Este artigo é importante para que se entenda melhor como a APF pode ser usada de maneira consistente na avaliação de equipes.

Quando se aplica

O material (de 2015) ainda se mantém atual (em 2020), porque com o advento e a conscientização de que o desenvolvimento Ágil não se trata de uma “moda”, mas de algo que veio para ficar, o monitoramento do desempenho passa a ter um posicionamento até mais relevante do que as aplicações da APF para estimativas.

Síntese publicada em Julho/2015 na Revista FATTO em foco Ano 01 I Nº 01

“Muitas vezes o interesse não é avaliar se uma equipe é produtiva ou não, mas: quanto mais produtiva a equipe precisa ser? como é o desempenho em comparação com outras no mercado?”

Organizações que desenvolvem ou contratam o desenvolvimento de software deveriam ter como um de seus objetivos alcançarem níveis máximos de produtividade nas equipes mobilizadas nessas iniciativas.

Para esse fim, há importantes reflexões que devem ser feitas pelos executivos responsáveis pela gestão do desenvolvimento nessas organizações. São elas: conhecer e avaliar diferentes alternativas para garantir que aquelas equipes sejam produtivas, e ter estratégias de como melhorar o desempenho do grupo para alcançar maiores níveis de eficiência e qualidade.

Todas as reflexões citadas serão discutidas neste artigo.

O que significa uma equipe de software ser produtiva?

As pessoas me perguntam: “O que significa uma equipe de software ser produtiva?”. A resposta: “É uma equipe que produz resultados!”. Essa resposta parece simples demais como a clássica resposta “42” de Deep Thought no livro The Hitchhiker’s Guide to the Galaxy ao ser questionado sobre a resposta para a pergunta para vida, o universo, e tudo mais. Por isso, podemos explorar esta pergunta um pouco mais antes de chegar a uma conclusão.

O termo Software pode se referir a uma variedade de diferentes produtos que têm naturezas distintas, como programas de computador, scripts de configuração, especificações de interface com o usuário, documentos de requisitos, planos de design e arquitetura, casos de teste, entre outras representações do software. Por isso, ao realizar o planejamento e a avaliação da produtividade, é necessário estabelecer um panorama mais amplo e completo a fim de avaliar de maneira consistente o quão produtiva é uma equipe quando comparada a uma escala de referência.

A escala de referência é uma parte necessária desse panorama, porque muitas vezes o interesse não é avaliar se uma equipe é produtiva ou não, mas: “o quão produtiva é a equipe? quanto mais produtiva a equipe precisa ser? como é o desempenho da produtividade da equipe em comparação com outras no mercado?”.

Caso a administração escolha por uma escala de referência baseada em uma perspectiva de negócio, ao invés de uma perspectiva técnica (que requer muito mais detalhes sobre o projeto e a implementação do software, problemas relativos a esses itens já resolvidos e refinados em um nível que permite a sua compreensão detalhada), então a escolha apropriada é a funcionalidade

entregue ou impactada por um projeto. Para atividades de manutenção de software, isso é possível em determinados casos e a funcionalidade no escopo daquela atividade de manutenção seriam as funcionalidades adicionadas, excluídas, modificadas ou testadas pelo projeto associado.

“Há atividades de manutenção em que o resultado de sua realização não está associado à produção de algo novo ou ao aperfeiçoamento de algo existente. Nesses casos, o resultado está associado à manutenção de níveis de serviço oferecidos pelo produto de software em produção”

Atividades de manutenção e produtividade

Existem diferentes tipos de atividade de manutenção de software. Entre elas, a correção de bugs na resolução de incidentes, a introdução de melhorias que modificam a configuração das funcionalidades oferecidas pelo software, a atualização de um produto para suportar uma nova tecnologia de hardware ou software, etc. É possível medir a produtividade associada a todas elas. No entanto, primeiro, é preciso determinar o que se espera receber e quais resultados relativos a cada tipo de manutenção.

Há atividades de manutenção em que o resultado de sua realização não está associado à produção de algo novo ou ao aperfeiçoamento de algo existente. Nesses casos, o resultado está associado à manutenção de níveis de serviço oferecidos pelo produto de software em produção. O principal interesse da administração nesses casos é a capacidade de resposta em um curto intervalo de tempo. Para isso, deve haver disponibilidade de recursos ainda que não haja necessariamente trabalho planejado para mobilizar esses recursos. Atividades de manutenção como esta são as correções de bugs (quando já não são cobertas por garantias), a prestação de serviços de help-desk de terceiro nível e outras atividades de suporte à aplicação após a sua transição do desenvolvimento para produção plena.

Quando não há ocorrências ou incidentes que demandem essas atividades, a equipe não consome esforço direto para atingir o resultado desejado. Contudo, quando o faz, ele deve ser rápido o suficiente para restaurar a normalidade do funcionamento dos sistemas em um tempo que diminua o impacto negativo nos negócios. Normalmente, esses resultados são definidos anteriormente na forma de acordos de níveis de serviço (ou SLA).

Portanto, nesse segmento da manutenção, gerenciar a produtividade é observar os acordos de nível de serviço; não se trata de uma linha de montagem sujeita a um planejamento e controle da produção como acontece no desenvolvimento de sistemas ou nos demais tipos de manutenção.

Produtividade como um atributo de processo

O conceito de medir a produtividade de uma equipe é, de fato, uma simplificação. Na verdade, o interesse mais amplo da administração é avaliar o desempenho de um processo produtivo (no caso, um processo de software). Portanto, não se devem misturar dados relativos à medição de atividades de sustentação, como as descritas anteriormente com um projeto de desenvolvimento para um novo sistema.

Cada processo produtivo de software tem fatores de custo únicos e as produtividades derivadas desses fatores de custo seguem uma distribuição de probabilidade específica. Por exemplo, os processos de desenvolvimento de uma nova aplicação e a ma nutenção em aplicação existente são diferentes.

Para que uma única métrica seja mais bem utilizada em ambos os processos, a Associação de Medição e Análise de Software da Holanda (NESMA) desenvolveu o Ponto de Função de Melhoria (EFP) e o Ponto de Função de Teste (TFP). O EFP nada mais é que o Ponto de Função padrão ajustado por um fator de impacto conforme o grau de mudança em uma funcionalidade e o TFP considera em seu escopo as funcionalidades incluídas, alteradas e testadas (desconsiderando as excluídas que, afnal, não poderiam ser testadas).

De modo similar, a Q/P Management Group disponibilizou a solução adotada por sua empresa na medição de demandas que não envolvem criar ou modifcar funcionalidade da aplicação. Ele denomina a unidade resultante da medição usando essa solução de Ponto de Impacto e consiste em aplicar o método padrão considerando não a funcionalidade incluída, alterada ou excluída, mas a funcionalidade impactada por aquela atividade.

Um exemplo muito completo da segmentação de processos produtivos em que se mantêm uma mesma unidade de produto é o Roteiro de Métricas de Software do SISP, que bebe de todas essas fontes citadas. Esse Roteiro é aplicado na melhoria do desempenho do software em terminadas funcionalidade

Alguns processamentos levam até 48 horas para serem concluídos. A missão é reestruturar a arquitetura e a implementação de programas, de modo que após sua conclusão, esses mesmos processamentos (considerando uma perspectiva funcional) não demorem mais de 24 horas.

O processo associado não é aquele de um projeto de melhoria e,por isso, o padrão do IFPUG orienta que esse tipo de atividade não seja medida como tal. A funcionalidade não muda. Mudam itens de configurações do software associados ao projeto (à arquitetura interna) e à implementação.

Em um cenário como esse poderia comparar esse tipo de processo ao método padrão de desenvolvimento e concluir que ele representa, digamos, 70% do esforço que demandaria um novo desenvolvimento. Daí, se o escopo impactado é medido como 100 PF; considera-se para avaliação do desempenho nesse processo uma produção equivalente a 70 PF.

“Um exemplo muito completo da segmentação de processos produtivos em que se mantêm uma mesma unidade de produto é o Roteiro de Métricas de Software do SISP que bebe de todas essas fontes citadas”

Vantagens de usar APF em medição de produtividade

É importante indicar que a Análise de Pontos de Função (APF), técnica que produz unidades representativas de medição do tamanho funcional, é um método com um alto nível de maturidade, conta com maior número de profissionais qualificados em sua aplicação e possui uma vasta gama de organizações que a utilizam. Não há qualquer outro método no mercado que se compare a ela nesses três pontos destacados.

Há também o Grupo Internacional de Usuários de Ponto de Função (IFPUG), organização responsável pela sua manutenção e evolução desde 1986.

O uso de medição funcional utiliza como entrada os requisitos funcionais – relacionados às tarefas e serviços do usuário – como definido na segregação de papéis e responsabilidades pela estrutura organizacional; como organizados pelo fluxo operacional que descreve os processos de negócio. São informações disponíveis cedo quando de um desenvolvimento em contraste às decisões de implementação ou projeto tomadas bem mais tarde comparativamente.

Se algum outro método de medição que considera aspectos internos ou técnicos fosse usado, então não seria possível para o cliente auditar os resultados apresentados pela equipe de desenvolvimento. Isso por si só já é uma razão grande o sufciente para desencorajar a sua utilização para fns de avaliação de produtividade.

Usar uma métrica funcional equilibra as diferentes tendências em ação quando se planeja e avalia a produtividade. Há uma tendência, natural, por parte da equipe de desenvolvimento, para inflar o uso de recursos, enquanto o cliente tem uma tendência de impor pressão em sentido oposto para aumentar a produção. Sem uma métrica funcional como a APF, não há referência com um significado comum para todos os envolvidos.

UM PROFISSIONAL QUE NÃO SEJA DA ÁREA DE TI PODE USAR A APF?

Alguns podem pensar que se a pessoa não é da área de Tecnologia da Informação (TI), então ela não poderá usar APF. Este pensamento está equivocado. Eu tenho treinado milhares de pessoas em APF há mais de 20 anos e posso dizer, com segurança, que cerca da metade do tempo gasto foi dedicado a apoiar profissionais de TI a desaprenderem a ter apenas uma visão técnica de software e aprenderem a ter uma visão do software no âmbito de um procedimento operacional no negócio.