Prática: melhore a qualidade do código para evitar uma enchente de bugs
Postado em 14. out, 2010 por Guilherme Silveira em Agile
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:
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?
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?
Guilherme Silveira (Google+)
3 Respostas para “Prática: melhore a qualidade do código para evitar uma enchente de bugs”
Trackbacks/Pingbacks
-
-
dezembro 21, 2010
[...] Prática: melhore a qualidade do código para evitar uma enchente de bugspor Guilherme Silveira, em 14/10 [...]
ASSINE NOSSO RSS
Celso Martins
15. out, 2010
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
Guilherme Silveira
16. out, 2010
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!