A produtividade é um dos grandes fatores que motivam a adoção de metodologias ágeis. Porém, o conceito de produtividade é bem amplo e em alguns casos pode ser difícil de definir e medir. O dicionário define produtividade como:

1 Qualidade ou estado de produtivo; faculdade de produzir. 2 Rendimento de uma atividade econômica em função de tempo, área, capital, pessoal e outros fatores de produção. 3 Fecundidade, fertilidade.

Neste post, meu objetivo é explanar o conceito de produtividade no contexto do desenvolvimento ágil e discutir um pouco sobre três fatores que podem interferir no cálculo da produtividade, fazendo com que, involuntariamente, essa medida não represente fielmente o panorama da situação em que se encontra o projeto. O objetivo é enfatizar que se deve ter muito cuidado ao calcular essa medida, a fim de que a equipe possa identificar possibilidades de melhoria no processo de desenvolvimento, na qualidade do produto e, consequentemente, o aumento real da produtividade. Pois só poderemos ter certeza da melhoria se conseguirmos medi-la!

Recentemente, em uma Reunião de Retrospectiva da equipe que faço parte surgiu o comentário “Acho que a produtividade da nossa equipe é alta…”. Neste momento iniciou-se uma discussão sobre o que é produtividade, como medir, etc. De fato, à primeira vista, a produtividade da nossa equipe pode parecer alta, pois ultimamente temos conseguido cumprir todos os pontos planejados para a Sprint e, às vezes, até mais do que o planejado. Mas será que isso necessariamente significa que temos alta produtividade? A produtividade é a relação entre a produção e os fatores de produção. No nosso caso, a produção seriam as histórias implementadas e talvez o principal fator de produção sejam as horas trabalhadas.

Bugs e Retrabalhos

Simplesmente olhar para os pontos implementados pode dar uma noção equivocada sobre a produtividade alcançada no projeto. Pois, destes pontos, quantos foram bugs? Quantos foram retrabalho?  Estes pontos devem ser considerados como produção da mesma forma que os outros pontos referentes a novas funcionalidades, por exemplo?  Em minha opinião bugs e retrabalhos devem ser considerados com um peso diferente das outras histórias no cálculo da produtividade. Pois bug e retrabalho são sempre sobre itens que já foram implementados, portanto, já tiveram histórias associadas a estes itens. E os pontos destas histórias já foram contabilizados como produção em alguma Sprint no passado. Não existe uma fórmula mágica para fazer essa diferenciação, mas uma maneira seria contabilizar apenas uma porcentagem dos pontos relativos às histórias de bug e retrabalho para o cálculo da produtividade. Fazendo esta diferenciação, teríamos um cálculo mais interessante da produtividade, pois estaríamos levando em conta a qualidade do que está sendo produzido. A produtividade nesse caso, estaria representando a capacidade de produção levando em conta a qualidade do que está sendo entregue.

Dificuldades técnicas

Acho que uma quantidade alta de pontos implementados não significa que a equipe tenha alta produtividade. Nem sempre a história que tem mais pontos é a história que vale mais para o projeto e para o PO, pois quem faz as estimativas em pontos é a própria equipe. Se ela tem alguma dificuldade técnica para implementar alguma história ela vai atribuir pontos mais altos para esta história. Deste modo,  se olharmos unicamente para os pontos implementados ao medir a produtividade poderemos estar mascarando esta dificuldade técnica. A equipe sempre vai produzir aquela quantidade de pontos e sempre demorando o mesmo tempo, quando na verdade, se ela resolvesse esse débito técnico, ela conseguiria atribuir pontos menores pra essa história e poderia incluir mais histórias na Sprint. Aí sim teríamos um aumento na produtividade. Em resumo, o que quero dizer é que o fato de entregar muitos pontos muitas vezes pode ocorrer porque a equipe tem dificuldade em alguma área e atribuiu pontuações altas para determinadas histórias por conta dessa dificuldade. Não faz sentido dizer que esta equipe é altamente produtiva, pois ainda que ela entregue muitos pontos ao final do ciclo, esses pontos na verdade só são altos porque representam a dificuldade que a equipe tem de implementar as histórias.

Estimativas erradas

Algumas vezes deparamos com situações em que antes mesmo do final da Sprint a equipe já finalizou todas as histórias. Isto pode até ser sinal de aumento na produtividade, pois a velocidade da equipe realmente pode estar aumentando. Porém, pode ser que isso tenha ocorrido porque as histórias tenham sido superestimadas. Ou seja, o número de pontos entregues na realidade não estaria representando a velocidade real da equipe, e por consequência, não estaria representando a real produtividade.

Para finalizar, acredito que consegui deixar claro nesse post que não podemos medir a real produtividade da equipe olhando somente para os pontos entregues ao final da Sprint. Talvez levar em conta o valor que a história tenha para o projeto e o valor que ela tem para o PO seja uma forma de fazer com que a produtividade seja uma medida mais justa e fiel a real situação do projeto. Acredito que medir produtividade não se trata apenas de contabilizar a capacidade de esforço da equipe, mas sim a capacidade da equipe transformar esforço em produto de qualidade.

E você, como mede a produtividade no seu projeto? Compartilhe conosco nos comentários! E até o próximo post!