Agile não é para todos
Agile não é para todos. Waterfall também não. Nem RUP, nem qualquer método, técnica ou filosofia.
Assim como nem todos são bons jogadores de futebol ou bons em matemática, nem todos serão bons ou se adaptarão ao desenvolvimento ágil de software.
Note o destaque em negrito na frase acima, pois estou aqui falando de práticas ágeis para o desenvolvimento de software, uma coisa que o Scrum não é (o Scrum é apenas um framework gerencial “ágil”, podendo ser aplicado à projetos de software ou de outros mercados). Extreme Programming já vai além, sendo, essa sim, uma metodologia de desenvolvimento ágil de software (que, por usa vez, usa muitos conceitos gerenciais do Scrum no que diz respeito à comunicação intra e extra-equipe).
Cada metodologia possui um conjunto de princípios básicos, algumas possuem práticas e, outras, formatos bem específicos de documentos a serem seguidos fielmente. Algumas possuem tudo isso junto.
De acordo com o perfil psicológico, social e profissional, é comum que pessoas envolvidas em desenvolvimento de software (gerentes, desenvolvedores, designers, testadores etc) possuam suas preferências quanto à metodologias e práticas. Alguns se dão muito bem apenas com waterfall, outros apenas com agile, uns poucos com ambas e muitas outras. E isso é extremamente normal. As metodologias ágeis são vistas como a salvação do mundo do desenvolvimento de software, principalmente num mercado dinâmico como a internet. Mas, não se engane, nem todos os profissionais conseguem trabalhar num ambiente realmente ágil. Eles são piores do que os que conseguem? Não. São apenas pessoas diferentes.
Ambientes “ágeis” exigem um conjunto de habilidades bem diferentes em relação a outros tipos de ambientes. Geralmente, exigem também muito sacrifício pessoal em detrimento do próprio ego, sendo essa uma das principais barreiras para que se consiga implementar uma cultura de desenvolvimento ágil de software.
Alguns profissionais (desenvolvedores e outros) não estão acostumados e não querem praticar coisas como feedback rápido, desenvolvimento orientado por testes, daily meetings e as outras práticas que as acompanham. Desenvolvimento ágil de software não é apenas escrever centenas de post-its e colá-los num quadro branco ou numa parede. É estar disposto a mudar muitos hábitos e fazer alguns sacrifícios, aceitar algumas “imposições” das metodologias, trabalhar em equipe e para a equipe.
Se a pessoa não se encaixa nesse tipo de mentalidade, tudo bem. Não significa nada em termos de qualidade profissional, mas uma empresa que deseja trabalhar com métodos ágeis definitivamente não é o lugar certo para ela, já que ambos os lados sairão perdendo.
3 Comentários