Produtividade e Métricas de Software – Parte I

Discutir sobre produtividade e métricas pode ser muito divertido caso tenhamos no mesmo grupo representantes dos atuais mundos do desenvolvimento de software: o tradicional e o ágil. No entanto, acredito que o debate se tornará proveitoso caso as discussões evoluam para o comum acordo entre as partes, e não para a briga de egos ou apegos filosóficos! ;-)

É muito comum observarmos que tanto o cálculo da produtividade quanto a utilização de unidades de medida em projetos de software tem gerado polêmica em reuniões, palestras e listas de discussão. O principal motivo é que a medição de determinadas informações pode gerar desperdício no processo caso seu resultado não agregue valor em atividades de planejamento, controle ou melhoria do ambiente de produção.

No dia 4 de agosto de 2009, tive a oportunidade de conduzir um encontro de análise e resolução de problemas num cliente já aderente à cultura ágil, que incorporou com sucesso ações sistemáticas de melhoria contínua nas práticas mensais de sua unidade de desenvolvimento em Porto Alegre (RS). Naquela ocasião, optamos por não utilizar nossa ferramenta padrão de investigação de cenários de melhoria (Café Kaizen), pois o interesse da discussão, proposto pelo Gerente Geral de Desenvolvimento, estava focado na seleção de métricas para a avaliação da produtividade de suas equipes de software.

O assunto foi despertado devido ao interesse crescente da alta gerência em avaliar a capacidade produtiva das equipes de desenvolvimento com a utilização de uma “unidade padrão de medida” que fosse reconhecida pelo mercado internacional de software. A justificativa dos mesmos estava no interesse por uma avaliação de benchmarking que comparasse os custos e a produtividade das equipes localizadas em diferentes regiões do Brasil.

Fiquei surpreso com o fato dos gestores estarem propondo a utilização de Pontos de Função como unidade de medida do cálculo de produtividade (sob a orientação de outros consultores), pois esta decisão entraria em choque com as atuais práticas incorporadas na empresa que já utilizam Story Points como base para a medida de tamanho de produto e produtividade das equipes.

Diante desse cenário, utilizamos a reunião para analisarmos algumas métricas comuns do desenvolvimento de software, bem como suas vantagens e desvantagens na avaliação dos resultados das equipes de desenvolvimento. Este post relata a primeira parte das reflexões que fizemos sobre este tema durante o encontro. Começarei apresentando uma reflexão sobre produtividade baseada no cálculo de linhas de código, dado que este era um tema presente no ambiente de produção do cliente e ainda persiste em muitas empresas de software pelo país.

Investigando a Unidade de Medida "Linhas de Código"

Não vou me deter muito tempo sobre este tema dado que o entendimento do mesmo já deve ter evoluído bastante em nossa comunidade de software nos últimos anos. Pelo menos isso é o que eu espero das pessoas que evoluíram junto com os avanços da nossa querida Engenharia de Software! ;-)

Vou contar duas histórias para tentar transmitir minha opinião sobre produtividade calculada com linhas de código.

Caso #1: Produtividade Negativa de um Desenvolvedor Sênior

“Certo dia, acordei com muita disposição para trabalhar. Cheguei cedo no escritório, li meus e-mails e me dirigi para a reunião diária de atualização de projeto. De volta para a minha mesa, e de posse dos requisitos funcionais que eu desenvolveria naquele dia, preparei minha IDE para começar uma jornada de trabalho que seria a mais produtiva de minha vida! Fiz o update de meu projeto para ter a certeza de que eu teria todas as alterações de código realizadas por colegas de equipe desde o último commit no repositório. Analisei as demandas e identifiquei os componentes que seriam alterados e criados no sistema. Infelizmente, meu antigo colega havia feito um “espaguetão” quando desenvolveu os componentes que eu deveria atualizar naquele dia, demonstrando total desconhecimento de nossa arquitetura e conceitos básicos de programação orientada a objetos. Fui obrigado a realizar um belo refactoring em todas aquelas classes e desenvolver novos componentes que receberiam elogios dos maiores gurus da engenharia de software. Eliminei centenas de linhas reutilizando componentes e explorando design patterns, escrevi poucos métodos e linhas de código, mantive o código padronizado e intuitivo para os próximos colegas que utilizariam o mesmo, garantindo 100% de cobertura em testes de unidade para cada componente. Passei todo o dia refatorando os componentes existentes e criando novos elementos altamente enxutos. Sabe qual foi o resultado? Entreguei três novas funcionalidades num único dia e reduzi em mais de 1.000 linhas nosso código fonte, tendo passado em todos os testes de integração! Sinto-me realizado!”.

Comentário: Nosso amigo fez tudo isso e acabou tendo uma produtividade negativa calculada em linhas de código!

Caso #2: Produtividade do Fornecedor Mal Intencionado

"Pessoal, não se esqueçam de utilizar aquele sistema gerador de código que baixamos da Internet. Ele caiu como uma luva em nosso projeto, pois aumentou consideravelmente nossa produtividade! Para atender todas as necessidades de diferentes equipes de desenvolvimento, ele insere tudo que você pode imaginar no código fonte, gerando um monte de linhas inúteis e deixando o mesmo difícil de ser analisado. Como nossa equipe é remunerada por linhas de código, ele é perfeito! A propósito, não percam tempo estudando a API do sistema. Refaçam tudo o que for necessário! Não economizem na velha técnica de 'copiar e colar'! Afinal de contas, nosso cliente está pagando pela quantidade de linhas de código que entregamos semanalmente em seu repositório de aplicações. Até na correção de bugs nós ganhamos pela manutenção das linhas que não passam nos testes de aceitação. Ainda bem que eles não sabem realizar inspeção de código, automação de testes e integração contínua!”

Comentário: A quantidade de linhas de código pode ser uma excelente medida de desempenho para quem não é produtivo ou não dá valor ao dinheiro dos outros!

Observações:

Saber o tamanho de um produto de software em função de suas linhas de código pode ser útil para o entendimento do crescimento de um repositório de controle de versões ou identificação da complexidade de um sistema legado que entrará em manutenção de melhoria ou migração de plataforma tecnológica. Não podemos negar que os riscos associados a manutenção de um sistema de 1 milhão de linhas de código é muito maior que os riscos associados a um sistema com 100.000 linhas de código. Se você estiver utilizando um bom sistema de controle de versões, essa informação pode ser facilmente obtida de seu repositório de programas.

Por outro lado, calcular a produtividade da equipe ou remunerar profissionais pelo total de linhas de código produzidas por unidade de tempo (como foi feito na grande maioria dos projetos do “bug do milênio”) é completamente insano nos dias de hoje!

Talvez você diga que pode ser uma informação útil para definir a escolha de uma linguagem de programação ou plataforma tecnológica (com qual linguagem eu desenvolvo o mesmo número de funcionalidades com menos linhas de código). No entanto, gerar poucas linhas e não ser capaz de garantir a qualidade do que foi gerado por inspeção automática de código ou integração contínua com testes automatizados pode impactar diretamente nos ganhos de produção a médio prazo.

No próximo post, medidas de tempo e pontos de função ...