Como medir a produtividade em um time de desenvolvimento de software

Tudo bem com vocês? Venho trazer nesse artigo algumas experiências ao longo da minha carreira, assim como a ciência, esse simples artigo é de todo refutável.

A vantagem competitiva de uma empresa depende da qualidade do seu produto e da velocidade com que você pode entregá-lo, trazendo assim um dos principais trade off do desenvolvimento de software: como medir a qualidade e produtividade de um time de desenvolvimento e ainda assim ser veloz nas entregas.

Muitos adeptos de go horse vão apresentar uma defesa de que, quanto antes nosso MVP estiver na mão do cliente, mais fácil de conseguirmos atacar o mercado. Isso acaba se tornando em uma das maiores ilusões que os desenvolvedores acreditam, pois escrever um código bagunçado que permite fazer tudo mais rápido a curto prazo só diminui o ritmo a longo prazo.

Então como ser ágil, ter qualidade e medir a produtividade do time?

Nesse artigo irei apresentar para vocês cinco áreas em que podemos medir a produtividade no desenvolvimento de software.

Cycle Time:

Quanto tempo você gasta trabalhando em cada task? Dependendo dos seus objetivos de desenvolvimento, você pode achar útil dividir os dados do tempo de ciclo por tipo, verificando quanto tempo seus desenvolvedores estão gastando em cada tipo de projeto (features, bugs, etc). Outra forma de abordagem pode ser feita em relação ao tempo que cada task passa em cada status (to do, in progress, review, QA, read to ship, shipped) até ser concluído o ciclo da entrega.

Analisando o Cycle Time podemos encontrar gargalos de processos, saber como agir e melhorar a produtividade de cada time.

Release Cycle Time:

Intimamente relacionado ao Cycle Time, o Release Cycle Time calcula especificamente quanto tempo sua equipe gasta em cada nova release. Nesse caso você deve avaliar desde o início do desenvolvimento até a implementação em produção da nova feature.

Difficulty of Feature Implementation:

Essa métrica é uma ótima maneira de avaliar o quão desafiador é uma nova feature para ser desenvolvida pelo seu time. Quando seus desenvolvedores relatam consistentemente que as adições de recursos foram pesadas, temos alguns pontos a analisar, se o esforço for baixo para uma nova feature ser implementada durante toda a vida do sistema podemos afirmar que temos uma boa arquitetura de software, se o esforço é alto a cada novo release a arquitetura é ruim. Como trabalhar a moral do time para lidar com essa situação, sem afundar a moral do time se elevarmos a “pressão” ou deixá-los entediados com o atual cenário. Essa é uma das métricas que acho mais importante e decisiva na evolução de todo produto.

Open Pull Request:

Quando os desenvolvedores concluem uma alteração, é feito um Pull Request ao repositório de código e é feito uma solicitação de code review ao restante da equipe para que seja feito uma revisão do trabalho feito. Cada uma das solicitações permanecerá aberta até que outros desenvolvedores tenham fornecido um feedback e marque como fechada essa solicitação. Ter muitos Pull Requests abertos indica que muito trabalho está sendo feito, mas também pode indicar que está demorando para o código ser revisado e ser enviado para produção. É fundamental analisar a quantidade e solicitações abertas e o tempo que leva para serem aprovadas no code review.

Velocity:

Usar a métrica de Velocity é uma das melhores maneiras de rastrear as contribuições reais de sua equipe de desenvolvimento. É uma medida do número de recursos prontos para envio (ou pelo menos pronto para teste) que sua equipe entregou dentro de um período de tempo específico. Mas vale lembrar que velocidade não exclui qualidade, é possível desenvolver com qualidade e agilidade em times de alta performance, mas para que isso seja feito é necessário ter todos os seus processos controlados e garantir que sejam feitos de ponta a ponta.

Cada time é um organismo vivo e portanto cada métrica deve ser analisada de forma adaptada para cada realidade; não é um ciência exata onde iremos aplicar uma determinada fórmula e teremos 100% do resultado esperado.

Analise cada um dos seus times de forma singular, reconheça seus erros de processos, ache os gargalos, trabalhe a moral como equipe e colha os frutos de um time com alta performance e apaixonado.