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?