As metodologias ágeis enfrentam muitas resistências no mercado. Muitas vezes a resistência está em nós mesmos!

Com certeza essa metodologia é um quebra de paradigma. E para entender bem um novo paradigma as vezes é preciso que esvaziemos alguns conceitos de nossa cabeça para poder absorver outros. Muitas empresas ainda apresentarão resistências à esses frameworks de processos ágeis por causa de alguns pontos. Vou citar alguns:

• Puro desconhecimento. Não conhece metodologia ágil e os benefícios que trás.
• Preconceito. Alguém falou que não funciona e por isso passa a acreditar.
• Acha que funciona para outras empresas mas que é impossível aplicar no próprio ambiente de trabalho.
• Interpretações erroneas e extremistas dos conceitos ágeis.

Podemos adotar uma metodologia ágil repentinamente aplicando todas as práticas ou adotar vagarosamente começando com uma ou duas técnicas e progredindo aos poucos. Podemos trabalhar com agilidade tanto em empresas pequenas como em grandes. Nas empresas grandes existe a governança e questões culturais, mas não devemos encarar isso como barreiras e sim analisar como a agilidade pode ser aplicada sem causar atritos desnecessários.

Para falar sobre interpretação errônea é clássico o exemplo de Pair Programming. Muita gente imagina que essa técnica pode atrapalhar mas desconhece o fato que o código está sendo revisado a todo tempo. Qualquer boa prática ágil pode não funcionar se não aplicada corretamente, é por isso que temos papéis importantes para impedir esses desvios como por exemplo o coach do Extreme Programming e o Scrum Master.

Quem olha o lado extremista é aquele que diz que o agilista não faz documentação, porém nenhuma metodologia diz isso. O que fala o Manifesto Ágil é que pessoas e interações são mais importantes que processos e ferramentas. Como disse o Felipe Rodrigues, “A documentação boa é aquela que é estritamente necessária. O resto é resto.”

Muitas perguntas passam por nossa cabeça quando a gente depara com novos paradigmas, é normal! Porém uma opinião tem que ser formada quando se conhece bem os opostos.

Como estimar prazos em uma metodologia ágil? Como fica o contrato? Como garantir implementar funcionalidades dentro do escopo?

Um dos grandes ganhos da metodologia ágil com certeza é estimativa de prazos. O Scrum tem várias técnicas para estimar um prazo conciso. Mas como estimar? O Scrum tem o Planning Poker.

E se a estimativa falhar? É mais difícil isso acontecer pois os sprints (iterações) devem ser curtos, mas se acontecer o Scrum tem o Sprint Retrospective, Sprint Review.

Como aprender com os erros? Sprint Backlog atualizado. Como manter o time auto-motivado? Daily Scrum. Como fazer códigos melhores? Pair Programming.

Alguém já pensou nos problemas que a gente enfrenta. Sempre ouvimos a frase “Não reinventar a roda”.

Devemos ter testers? Sim, mas se o time trabalhar com TDD do Extreme Programming pode ser que não precise.

Podemos ter analistas de negócios? Sim, desde que não seja um intermediário.

Esse post causou uma boa polêmica e levantou vários pontos que o mercado utiliza para não adotar agilidade (Vejam os comentários aqui).

Sobre o Autor: