Nosso amigo Luiz “farol” Sanches atualmente está concluindo seus estudos sobre agilidade no C.E.S.A.R. em Recife. Na reta final de seu curso pegou uma tarefa interessante: relacionar quais os motivos pelos quais eXtreme Programming pode não funcionar. O assunto acabou gerando uma discussão interessante na lista que tentaremos sintetizar e compartilhar aqui.
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?
