Futurologia ou algo esta cheirando mal quando falamos em Agile?

Fazem quase 10 anos que o movimento 'agile' apareceu, isso foi por volta de 2000. O que começou de uma maneira discreta hoje toma conta do mercado. Se fizermos uma consulta no site indeeed, sobre metodologias agíeis o resultado é o seguinte(pesquisa feita em 22/02/2009):



















Pesquisa por ofertas de emprego no site indeed (22/02/2009)

Como podem ver é esmagadora a diferença do Scrum para os outros métodos. Muitos atribuem isso ao fato de Scrum ter um conjunto de certificações. Não tenho dúvidas de que esse é um dos principais fator de popularização do movimento através do famoso *pega-gerente*! Mas o que parecia ser muito bom para evangelizar sobre agile agora se torna contra os próprios. Pessoas estão culpando o Scrum pelo fracasso de projetos ditos 'agile'. Já vi vários agilistas falarem mais de certificações e da certificação de Scrum master mas o detalhe é que muitos deles tem essa certificação, quando não um botão grande no blog para mostrar isso!



Veio a tona nos últimos meses através de diversas discussões originas pelo post original do James Shore(The Decline And Fall of Agile). Em seu post James Shore expõe esse fato o qual não era novidade, tais problemas o grande Ivar Jacobson já tinha dito neste post.

No seu post Jacobson coloca bem o papel do Scrum, onde ele é util e onde não se aplica muito bem! Mas voltando ao post do James Shore, ele tem um bom ponto. Mas ainda é uma-previsão-ala-mãe-Dínah! Com certeza toda essa conversa em cima disso tem um motivo, o motivo é que algumas coisas estão saindo diferente do jeito que eles imaginavam.

Hoje em dia todos adoram dizer *não existe bala de prata* pena que pouco leram o livro. É inegável que diversos consultores vendem agile e Scrum como sendo as novas balas de prata. Mas esse assunto é realmente difícil de se discutir por que quando apontamos os pontos fracos das metodologias ditas 'agile' escutamos uma resposta de teor religioso.

Falando de Scrum, que é um bom método, mas não pode ser usado sozinho, e eu não estou falando de aplicar técnicas de programação (XP) com o Scrum. O Scrum serve para mostrar os problemas da empresa e isso é bom, mas certos problemas estão no fundo e para resolver esses problemas precisamos de outros níveis de planejamento. Dependendo como você usar Scrum pode gerar um overhead tremendo e com pouco resultado efetivo, a falta de planejamento a curto e médio prazo é um grande problema. Assim como se você tiver planos de médio e longo prazo fica muito mais fácil atingir os objetivos da empresa alinhado a um planejamento estratégico! Se você tem planos de médio/longo prazo não pode usar somente uma técnica de estimativa, você vai precisar de mais, muito mais!

Por pura ignorância alguns agilistas dizem cosias do tipo Scrum/Xp não são processos, questionando ainda metodos consagrados como o RUP. Esses questionamentos em cima do RUP são quanto ao 'peso' do processo e ao grande volume de artefatos e práticas! Mas que surpresa os metodos ageis que sempre reclamaram ser ligth agora dizem que precisam de mais coisas, que precisam do bolo todo, que precisam de pelo menos 3 ou 4 metodos ageis para fazer algo, bom isso já é bem maior do que era antes, já são bem mais práticas e mais peso de processo.

Processo não significa gerar documentos no word, assim como artefatos não se limitam ao meio digital meus amigos! A grande besteira é que o RUP sempre teve muito artefatos mas a maioria deles opcional, o que os agilistas fizeram? O caminho inverso tiraram TUDO e agora estão coloncando aos poucos mais coisa, no final eu não me espantaria se tivesse o tamanho do RUP.

Ok, 'agile' é sobre cultura, midsets, bla-bla, bla e mais bla. Existe o maniesto agil com seus principeios e valores, mas isso não é e nem nunca foi o suficiente, por que agile é tudo o que você quizer, se estiver fazando certo não importa o que use você esta fazendo agil mas se você falahar é por que você fez fraile ou por que as pessoas são ruins! Ahh conta outro a culpa nunca é do método, acho que os caras aprenderam com o erro dos outros em alguns aspectos mas está difícil para eles aprender com o erros deles!

Mas no inicio quando os agilitas fizeram questão de culpar os processos e ferramentas dizendo não o nosso método é melhor, bem mais leve, bem mais rápido e divertido, esqueceram que as mesmas pessoas que falharam nos ditos métodos tradicionais agora estão falhando com agile! Será que o problema estava no RUP ou em quem usa-va ele?

Quando muitos agilistas advogam que você precisa de 2 ou 3 métodos ageis para fazer algo e lhe avisam que você não deveria estar usando apenas um método como scrum ou xp sozinho, de facto cheguei a ler um agilista falando nos comentáriso do James Shore que Scrum não falohu por que não é um método de desenvolvimento de software, por que o Scrum não especifica práticas de desenvolvimento, e esse é outro GRANDE problema dos agilistas, não ver a coisa como um todo e depois ficar crinado bengalas para proteger a fragilidade de alguns metodos como a falta de requisitos no xp com os testes unitários e o refactoring e o on-site constumer. A falta de percepção das coisas como um todo esta ai no mercado, sendo que a coisa virou para algo do tipo, qual o seu preferido metodo agil hoje?

Tudo faz parte do desenvolvimento/produção todas as disciplinas são importantes, algumas deles as quais os agilistas não se atravem a falar como requisitos, mas eles estão sentindo os problemas e sendo assim vou dar uma de mãe dínah e vou dizer que esse será o ano dos Agile Requiriments! Essa falta de percepção tem um nome se chama risco! Requisitos diminuem os riscos de um projeto afunilando as coisas no cone de insertezas!

Os metodos ageis estão ai e não são de todo o mal existem práticas interessantes e que trazem bons resultados mas existem muitos problemas e agora eles começam a aparecer em escala, não podemos dizer que o 'agile' vai perder a briga a qual ele já ganhou, mas quanto maior a altura maior a queda!


Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java