Prática: melhore a qualidade do código para evitar uma enchente de bugs

Sintoma: o número de bugs novos que são abertos é maior do que o número de bugs fechados a cada iteração. O backlog é dominado por bugs e cada vez menos funções novas são adicionadas ao projeto.

Ação: Por muito tempo acreditou-se que aumentando o número de desenvolvedores aumentaria a produtividade de uma equipe em um projeto, crença hoje combatida pelos métodos ágeis.

O primeiro fator para combater a sensação de fracasso na luta contra os bugs é criar uma medida que incentive a equipe a melhorar a qualidade do código.

Uma maneira fácil de criar essa métrica é medir o número de bugs novos abertos e de bugs fechados no último ciclo. A cada ciclo novo meça novamente esses valores. A medida pode ser tirada automaticamente através da criação de plugins para determinadas plataformas online ou de maneira bem simples durante o review de seu projeto – manualmente.

Para aqueles que usam o pivotal tracker, o projeto Buggie integra com o processo de build e pode gerar os dados a cada novo build executado no servidor de integração, mantendo o gráfico sempre atualizado. A tabela a seguir mostra o gráfico de um projeto durante as seis meses, gerado com o Buggie:

Aguardando algo acontecer para testar

Features sendo entregues e corrigidas continuamente até o momento da grande entrega de muitas novas funcionalidades: um grande impacto no número de bugs, mas em número absoluto é o mesmo que anteriormente.

Fica visualmente claro que os bugs vinham em um ritmo natural e corrigidos também da mesma maneira. Mas de repente uma avalanche de bugs aparece – e são corrigidos proporcionalmente. O feedback é instantâneo, e o time percebe que algo precisa mudar nessa parte do processo de desenvolvimento para melhorar a qualidade de seu código.

Para melhorar a qualidade do código devemos adotar práticas como o pareamento, mais comunicação com o cliente e evitar adivinhar como as funcionalidades deveriam funcionar. A análise do gráfico de bugs junto com o histórico da equipe nos diz o que acontece e o que podemos fazer.

Desafio para o leitor

1. Cite motivos pelos quais o time acima possui um acúmulo de bugs próximo a iteração 18?

2. Quais motivos levam outro time a ter um gráfico diferente, como o a seguir?

Fazendo a entrega contínua

Executando a entrega contínua de um projeto, mesmo que sem o processo de deploy totalmente automatizado em um clique.

3. E o seu projeto controlado pelo Pivotal? Gere seu gráfico com o Buggie e envie via twitter ou email. Se preferir basta compartilhar o acesso ao pivotal.

Veja também: pontos de bug contam na velocidade de meu time?

3 Comentários

  1. Celso Martins 15/10/2010 at 12:26 #

    Oi Guilherme. Muito bom o texto.

    A Lei de Brooks já combatia a suposta “ação” sugerida no início do artigo pelo menos 14 anos antes de surgir qualquer metodologia ágil. Estou considerando o surgimento da XP em 1999 e do manifesto ágil em 2001. Estou deixando isso claro, porque sempre aparece alguém dizendo que em 1900 já tinha gente falando sobre TDD, por exemplo.

    Quanto ao desafio, o próprio texto não respondeu? Não seria a baixa qualidade do código acumulando débitos técnicos?

    Abraços

  2. Guilherme Silveira 16/10/2010 at 09:37 #

    Oi Celso!

    Com certeza. Creio que o livro do Brooks esteja no post de recomendação de leitura aqui no blog e não é a toa mesmo.

    Realmente é um possível motivo para um gráfico daquela maneira (o primeiro) – para ter certeza que eram débitos técnicos, precisamos conversar com a equipe. Nesse caso específico na iteração 16 entrou um novo “módulo” do sistema. Algo jamais pensado antes. Com a produtividade forte de antes mas sem o conhecimento do domínio específico, o número de bugs foi alto. Isso também mostrou uma falta razoável de comunicação para pegar os bugs antecipadamente.

    Abraço!

Deixe uma resposta