Se é por ter experiência em projetos ágeis, já trabalho a quase 3 anos em projetos orientados a XP. Daí posso falar por vivência própria e não por leituras curiosas de artigo.
O Kenobi citou muito bem quando falou sobre refactorings. Isso pra mim é um dos grandes engodos do XP. Você sai acreditando que pode produzir produtos rapidamente e que possíveis distorções possam ser corrigidas com o tempo. Se vc está falando que o teu usuário pediu um ou dois campos a mais ou mesmo uma nova funcionalidade, pode até funcionar. Mas por favor não erre no seu design, as consequências são amargas. Você pode chegar no meio do caminho e perceber que a solução imaginada na primeira iteração, quando o meu foco da lanterna era muito fechado, não foi robusto suficiente para suportar as novas iterações e as funcionalidades decorrentes. Por exemplo, um problema que deveria ser solucionado por uma simples agregação, pros pares das primeiras iterações foi resolvido por herança. Vamos então dar uma de Dr. Frankstein (ou seria Dr. Pitangui) e criar o nosso monstro através de refactorings (famoso bisturi e agulha).
É claro que tudo isso tem a ver também com a experiência dos “programadores”. Mas sem ter uma visão do “todo”, como eu poderia crucificar os pares das primeiras iteração por terem adotado uma solução que não foi a melhor. Ainda mais por confiarem plenamente no “bisturi”.
Infelizmente a realidade pode ser mais amarga e a “emenda sair pior que o soneto”.
Volto a dizer: acho que podemos ter desenvolvimentos ágeis sem abrir mão de um boa definição de escopo e um bom design. Existem qualidades que podem ser mescladas e podemos colher frutos de um processo misto e que alcance um ponto de equilíbrio.
