Por que XP não funciona?

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.

Se você não testa, você não é ágil!

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?