O colega Robson Pelegrini reportou na lista [scrum-brasil] uma situação que é comum, principalmente em equipes que estão iniciando no desenvolvimento ágil de software e que (com a devida autorização) transcrevo abaixo:

Pessoal,

Gostaria de saber como vocês tratam a questão dos bugs que surgem dentro do SPRINT, por exemplo:

• Criam um item no SPRINT BACKLOG, “correção de bugs”
• Bugs é responsabilidade do time concertar, não podendo esse impactar na entrega do SPRINT

Acredito que a partir da 1ª entrega feito ao PO, temos o que podemos chamar de “legado”, e então começam a surgir bugs e mudanças de requisitos e funcionalidades que geralmente afetam o planejamento feito para o próximo SPRINT.

– Isso costuma ocorrer com vocês ? Como vocês lidam com essas situações ?

Necessário pontuar algumas coisas num cenário como este.  Vamos a elas.

O QUE VEM A SER UM “BUG” DE SOFTWARE?

Como seres humanos, todos estamos sujeitos a erros.  Assim, mais ainda quando estamos lidando com um produto em desenvolvimento, ou seja, que está sendo construindo.  Muitos projetos de software mantém dois ramos do produto –um estável e um em desenvolvimento– justamente para diferir a quantidade de bugs em potencial que podem estar contidos no produto.

Se por um lado tudo isso é verdade, por outro, quando tratamos de desenvolvimento ágil de software, deve-se partir da premissa de que a cada iteração no ciclo de desenvolvimento um item de valor deve ser entregue ao cliente.  São os releases curtos.

Isto posto, cabe nos perguntarmos: afinal o que é um “bug” de software?

Continuar lendo →