Achamos um bug, o que fazer?

green_bug
Esse é mais um daqueles posts que eu vou só defender uma idéia. Não tenho a menor intenção de proclamar, como sempre, o que é certo ou errado. Deixo para vocês decidirem, depois de estudar um pouco o assunto, não só através dessa postarem, mas através de outras fontes também.

A história começa com a implantação de uma metodologia ágil, seja ela qual for. Todo o ciclo de desenvolvimento ágil se baseia na entrega de valor, através da entrega contínua e adiantada de software funcionando a nossos amados clientes. Tudo na mais alta qualidade, como todo profissional deve fazer. Acontece que nem sempre tudo ocorre como queremos. Como somos seres humanos, passíveis de erros, esses refletem no nosso trabalho e por conseguinte, em nosso código-fonte.

Mas como fazer? Aliás, quando fazer? Devemos contar o esforço desse nosso retrabalho como parte da nossa velocidade, ou como não estamos entregando valor algum novo ao cliente, não poderíamos contabiliza-los?

Em uma das empresas com as quais trabalhei, a consultoria que lá prestou o serviço antes de mim, instruiu o time de desenvolvimento a não contar os bugs. Afinal, em princípio esse trabalho não representa uma entrega de valor ao cliente, certo? Se pensarmos bem, os bugs em geral são trabalhos que, como não foram bem feitos no passado, voltaram para atrapalhar o presente e portanto são responsabilidade do time de desenvolvimento. Confesso que por muito tempo eu concordei com essa visão monocromática da coisa. Mas um dia me mostraram a luz e hoje vou partilhar com vocês.

Quando estive estudando a fundo os métodos ágeis, em especial o Scrum, descobri que eles são mais do que métodos para gestionar projetos ou equipes. Eles são modelos para gestão do conhecimento. Eles fomentam a colaboração entre os membros do time, entre os times e principalmente entre time e cliente. Todos partem do princípio que ninguém sabe o todo de um projeto e ao assumir isso, constroem o conhecimento dando um passo de cada vez. Lindo não? Um passo de cada vez, assim como é difícil planejar anos a frente por que muita coisa pode acontecer em nossas vidas, nós como seres únicos, imagine muitos de nós interagindo e criando pensando num objetivo comum, o projeto em questão. Cada pessoa que se soma ao time é um acréscimo infinito de complexidade. São novas idéias, novas habilidades, mas também novos egos, novas dificuldades. Em um cenário dessa complexidade, imaginar que se possa planejar mais do que algumas poucas semanas é um sonho muito distante. Por isso planejamos de maneira iterativa e incremental.

Esclarecida a parte do planejamento, vamos falar um pouco sobre as métricas que regem o nosso trabalho. Sim, somos ágeis e usamos métricas. Porque? Simples, vivemos no mundo real, das corporações, no qual os gestores precisam de métricas para avaliar se estamos indo bem ou mal em determinado projeto. Mas quais métricas são justas para o time e a gestão? Quais métricas fazem sentido? A coisa toda em cima dos bugs é que diretamente eles não agregam valor ao produto. Afinal não adicionam nada de novo e é algo que em algum momento alguém deixou de fazer certo, portanto devemos fazer certo agora, algo como pagar pelo débito que existe no projeto. Mas nem sempre é assim. Muitas vezes, muitas vezes mesmo, as empresas de software tem baixa retenção de funcionários/colaboradores e isso obviamente envolve os desenvolvedores. Assim a equipe que hoje mantém um produto pode quase nem ter mais alguém que faça parte da equipe original. Portanto puni-los fazendo com que suas métricas sejam desmotivantes não é o caminho.

Mas então, o que fazer com os bugs?

Simples, corrija-os. Mas e as estimativas? E os esforços? Respondo perguntando: a correção de um bug demanda esforço? Vai gastar tempo dos seus desenvolvedores? Poxa meu filho, se isso não vai se resolver magicamente, se as pessoas terão que gastar seu tempo e trabalho para resolver aquilo então isso merece uma estimativa de esforço. Não caia na armadilha de confundir métrica de esforço com valor de negócio. Realmente um bug não acrescenta valor nenhum ao negócio, ao produto e isso é fato, mas certamente vai demandar esforço do seu time.

Portanto, ao encontrar um bug, coloque-o no topo do seu backlog e lembre-se, ele vai te custar tempo, portanto deve ter a sua medida, em story points, homens-hora, pontos de função, o que seja. Embora realmente não isso não vai aumentar em nada o valor do seu produto.

Posted on: 11 de julho de 2014, by :

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *