Boa noite a todos!
O exemplo da sandália de garrafa pet utilizado na aula é muito interessante para projetar um problema recorrente que ocorre em projetos ágeis em software. O feedback dado pelo cliente provoca mudanças de prioridade e de fluxo que buscam atender momentaneamente aquela "nova demanda". Entretanto, por estamos "mergulhados" em uma sprint, muitas vezes não observamos o cenário completo (muito menos o cliente consegue ver isso), e terminamos por criar uma solução que logo adiante precisa ser desfeita. Na prática, observo muito retrabalho em projetos que vão absorvendo os feedbacks indiscriminadamente. Nesse sentido, lanço 2 questionamentos:
1) O feedback não deveria ser controlado? Não teríamos que, de alguma forma, "educar" o cliente mostrando para ele que esse feedback traz consequencias? E como fazer isso?
2) Desse modo, não seria muito importante um ajuste adequado do documento de visão inicial (e do backlog inicial), observando o produto como um todo em um nível de detalhamento suficiente, que nos dê condições de analisar impactos de feedbacks futuros?
Esses questionamentos surgem pois, na prática, observando os projetos ágeis, é nítido o volume de retrabalho causado pelos feedbacks absorvidos nas sprints. Muitas vezes, há a necessidade de verdadeiras reengenharias para tratar o impacto de uma mudança futura. Um exemplo aproveitando o caso da construção da casa utilizado na aula: imagina que quando fomos fazer a garagem, descobrimos que o cliente pediu a janela do quarto que fica voltada para a garagem, obrigando ele a perder a vista e a boa ventilação. Desse modo, temos que fechar a janela ao fazer a garagem. Mas aí o quarto ficou sem janela. E eu descubro que ele não tem parede livre para ter uma janela. Isso me obriga a quebrar a cozinha para reduzir o tamanho de modo a liberar um vão para por uma janela (ao menos um basculante).
Obrigado!
