Ser ágil é ser rápido?

em Metodologias Ágeis.

Oras, se você estiver se referindo ao significado do adjetivo ágil, contido no dicionário e que se refere a algo “que se movimenta com excesso de facilidade; que se move de maneira rápida; veloz”, pode até ser que sim. Agora, se você estiver se referindo ao ágil dentro do contexto de software, então com certeza não!

Ainda lembro quando estava estagiando na SAP da Hungria, primeiro lugar em que realmente tive experiência com desenvolvimento de software, e, em minha entrevista, o gerente falou que eles eram ágeis.

Eu já havia feito um minicurso de Scrum em um evento da universidade e para mim até então, saber Scrum era ser ágil. Logo, sem hesitar, falei para eles que achava legal o fato de utilizarem a metodologia e estava me gabando por saber o que significava ágil (mal sabia eu, que se eles não utilizassem Scrum mesmo, talvez eu nem tivesse conseguido a vaga :D).

Outra coisa que eu havia colocado em minha cabeça é que ser ágil é realmente ser mais rápido. Pode até que isso realmente aconteça em algumas situações, mas essa não é a regra do mindset, de maneira alguma.

E você não precisa ler aqueles livros de páginas sobre as mais diferentes abordagens que dão para o ágil por aí. Basta ler o manifesto ágil. Sim, simples assim. Tem até o link aqui para ficar ainda mais fácil.

Agora, faça o seguinte: abra a busca de texto do seu navegador na página do manifesto e procure pelas palavras “rápido” e “veloz”. Achou? Pois é!
Para iniciar no ágil, essa é a primeira coisa que você tem que colocar em sua cabeça: desenvolvimento de software ágil não é necessariamente desenvolvimento de software rápido. Não! Uma das melhores definições para o ágil que eu já vi é a seguinte:

 

“The point of Agile is reducing the cost of change and uncertainty.”.

 

Não é uma maravilha? Esse sim é o ponto do ágil: reduzir os custos das mudanças e incertezas. O que o seu cliente quer hoje, amanhã pode não querer mais e não é porque ele é indeciso (pode até ser, vai :D), mas porque o mercado muda e os objetivos também. E toda essa mudança e incerteza não são colocados na conta dos processos antigos que existiam e ainda existem por aí.

 

Mas então por que o ágil consegue responder às mudanças e outras metodologias não?

Ué, por entregar software mais rápido! Êpaaaa! Como assim, Pablo? Você acabou de dizer que não tem nada a ver com rapidez!

Então, são unidades do software final que gerem algum valor para que o cliente entenda se está tudo bem; se a ideia é essa mesmo, se é esse o valor que ele estava esperando. E isso sim é mais rápido.

O que eu estou querendo mostrar é que não adianta pensar que um projeto que você demoraria um ano para entregar utilizando waterfall, agora você vai entregar com dois meses utilizando ágil. O que vai acontecer é que, mesmo que você demore o mesmo ano (o que provavelmente será menos), o valor que você vai gerar para o seu cliente será certeiro.

O software entregue será o que ele realmente estava precisando, ao invés de chegar no final do ano de desenvolvimento com waterfall – e descobrir que seu cliente queria uma moto vermelha mas você acabou entregando um barco azul.

Tenha na cabeça que ágil não é uma metodologia milagrosa. As incertezas sempre estarão lá e o seu cliente sempre vai mudar, isso é algo natural. O que o ágil faz é permitir que você responda às mudanças sem ter que esperar muito tempo. E como já dizia Benjamin Franklin “Tempo é dinheiro”!

Você também pode gostar