Metodologias Ágeis

As Metodologias Ágeis, de alguns anos para cá, estão cada vez mais difundidas dentro das empresas e é praticamente impossível atualmente você não encontrar em alguma empresa de software.

Mas existem algumas visões equivocadas quanto a estas práticas e sei, muito ácido o assunto.

Mesmo assim, irei deixar minha humilde opinião sobre o assunto de coisas que tenho vivenciado ao longo destes anos na área e que assuntam um pouco.

Se você é Scrum Master ou Gestor de Desenvolvimento ou até mesmo CTO, acalme este coraçãozinho ai e tenta entender o todo antes de julgar.

Metodologias ágeis vs Manifesto ágil original

O termo metodologias ágeis não é novo nem aqui e muito menos em canto algum e começou a ser difundido no final da década de 90 e inicio dos anos 2000.

O lendário Kent Beck (pai do Extreme Programing) já estava provando de sua tese em equipes utilizando TDD, e diversas outras iniciativas na época estavam já sendo difundidas.

Mas não havia um senso comum ou ainda era tudo muito novo. Me recordo de ter visto uma entrevista do próprio Uncle Bob dizendo que precisavam juntar estes conceitos e criar um senso comum.

E foi feito! No ano de 2001, mais precisamente em Fevereiro/2001 entusiastas se reuniram para criar o Manifesto Ágil, as famosas escrituras sagradas do Ágil.

Entre os ilustres representantes estavam Kent Beck, Martin Fowler, Robert C. Martin (Uncle Bob) e outros que estão no link do manifesto acima.

Os principios que impulsionaram o manifesto, ficam bem claro:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Olhando para os valores e refletindo, parece que algo no meio do caminho se perdeu.

Onde será que nos perdemos ou encontramos alguns monstros criados pelo mercado?

Quando você olha para o manifesto e começa a refletir sobre alguns itens, chega a dar aquela repulsa em alguns itens olhando a realidade de algumas empresas passadas ou até mesmo a atual.

Até mesmo o próprio Scrum em seu framework perde um pouco da essencia do que é o manifesto ágil, podendo até citar diversos, mas vou focar em um apenas.

Quando ele diz “responder a mudanças mais que seguir um plano” você já deve ter se perguntado para quê a tal reunião de planning no meio de uma sprint.

Sem contar com a perca de tempo que tais reuniões nos trazem, pergunto: sempre acontece o que foi planejado?

É sempre “lindo e maravilhoso” como foi descrito as atividades na hora da planning ou você ao abrir o código teve que fazer o velho malabarismo para dar conta da atividade em questão?

Bom, não precisa me responder, apenas refita. Eu vou te dar um parecer do que realmente sempre ocorre comigo.

Geralmente mudam os itens em 40% pra mais do que estava ali na planning, ficando a minha responsabilidade correr atrás e dar conta da atividade.

Ai você deve estar se falando, “ah mas, na firma onde trabalho funciona”, parabéns e atenção te digo, porque você pode estar ou se enganando ou não chegou ao ponto de questionar o que está sendo feito.

Estamos fazendo Ágil, é o que as consultorias vendem, mas..

Consultorias de software trazem sempre este termo “vendemos a solução ágil” ou “estamos implantando o ágil na empresa XPTO”.

E pelo que parece muitos CTO’s gostam e muito desta propaganda, mas na real o termo ágil não é mágico.

Parece que o termo irá resolver os problemas do cliente, mas na realidade a imaturidade da galera que tem tocado estes processos deixa muito a desejar.

O Scrum, Kanban ou até mesmo o Lean, você implementando não quer dizer que a construção do teu software será mais rápido.

Este é outro absurdo que geralmente ouvimos inclusive de profissionais da área e até mesmo nossos queridos Scrum Master.

Não, isto não significa que terá software pela metade do tempo, esquece esta história.

Concluindo

Bom, se você chegou até aqui, provavelmente com muita raiva (desculpe), mas obrigado mesmo assim.

A minha ideia aqui com este artigo não é confrontar ninguém e muito menos mudar a sua opinião, mas meu relato é necessário.

Necessário para dar uma visão de outra parte do processo que talvez, possa somar para construir algo melhor nos projetos.

Valeu!