Se você trabalha na área de TI, já deve ter vivenciado algum projeto com ágil, ou pelo menos visto alguma iniciativa ágil na sua empresa. Todas as iniciativas, nos mais variados projetos que vi até hoje seguiram as mesmas fases: Negação -> Resistência -> Adaptação/Exploração -> Aceitação/Comprometimento. Das 4 fases, a resistência parece ser a fase mais difícil de se passar, especialmente para os desenvolvedores.
Eu, como testadora, acredito no ágil sim! Sou feliz de fazer parte de uma equipe que também acredita, mas não foi do dia pra noite que o ágil passou a funcionar na nossa equipe. Foram mais de 2 meses até conseguirmos ajeitar o ágil à nossa equipe. Isso pois ele vem para quebrar paradigmas. O pessoal está muito acostumado e apegado ao modelo de projeto cascata, com toda aquela burocracia, que não consegue ver os benefícios do ágil. A primeira impressão parece ser: Ágil é igual a GoHorse, pequenas entregas de valor, danem-se os testadores e documentadores. É aí que começam a vir os problemas de commit, pois mais de um desenvolvedor alterou o mesmo fonte, na mesma linha, e após o merge o sistema simplesmente para; não compila mais.
Gente, sobre o ponto do commit, o caso é uma questão de Gestão de Configuração e em qualquer (absolutamente qualquer) processo de desenvolvimento que se faça (incluindo-se GoHorse) é necessário uma ferramenta de gerenciamento de fonte e um processo de mudança que permita que mais de um desenvolvedor submeta suas implementações.
Além disso, o ágil diz que todos são responsáveis pelo projeto enquanto equipe na mesma sprint. Não existe essa de "danem-se os testadores e documentadores", pois todos são responsáveis se algo falhar. O desenvolvedor não pode só pensar no mundinho de desenvolvimento. Não existe GoHorse no ágil de jeito algum.
Quanto ao tempo, as pequenas entregas da sprint, são entregas de valor e não qualquer coisa. Para isso é feito todo um detalhamento sobre o que, como e a prioridade das entregas (Sprint Planning). As reuniões diárias também estão aí para que todos saibam o que cada membro da equipe está fazendo e o que ele vai fazer.
O fato é que no modelo cascata ninguém sabe ao certo o que o colega ao lado está fazendo, salvo o gerente de projetos que quando está muito ocupado manda um e-mail todo dia pela manhã perguntando em quantos por cento está a entrega. Eu não acredito no funcionamento de um projeto no modelo cascata, com projetos engessados, complexos, e com estimativas e prazos de entrega tão reais quanto gnomos.
Ao meu ver, esse argumento de que "Ágil no desenvolvimento não funciona", é só uma desculpa de pessoas acomodadas que não querem mudança, pois as tiram da zona de conforto.
Até mais, :D
