Seja Inteligente e não use Agile

Você não precisa ser agile, você pode fazer um projeto e ter sucesso sem usar agile. Mais softwares foram feitos sem agile ou qualquer metodologia, leia-se AD-HOC, do que com métodos agéis. Neste posto gostaria de esclarecer o diversos enganos que os ditos "agilistas" erram quando falamos de processos tradicionais e desenvolvimento de software.

Em outro post depois falar dos pontos positivos, ou seja, do que é bom mesmo. Mas neste post vou focar neste equívocos que o pessoal comente ou omitem de propósito. Vou falar de algumas falácias também...

Hoje em dia muitos colocam como os métodos ágeis sendo a única solução que funciona para o desenvolvimento de software, será que isso é verdade, será que não existem outras opções? Será que esta é a única solução e será que isso funciona sempre e não tem defeitos.

Primeiro Passo: Escolhendo as palavras mágicas

Palavras Mágicas

Não posso negar o marketing dos caras é bom. Qual metodologia você gostaria de usar, para facilitar a sua escolha vou lhe dar uma lista de opções:

• Metodologia Ruim
• Metodologia Cara
• Metodologia Lenta e Pesada
• Metodologia RUP
• Metodologia Ruim, Cara, Lenta, Pesada e Falha
• Metodologia XYZ
• Metodologia Agile

Bom pode paracer besteira, mas já é intuitivo, este nome vai te chamar muito mais atenção. Todos vão querer usar a metodologia bom ou invés da metodologia ruim. Outro ponto que os caras gostam de pegar e na cascata, nem o cara que inventou isso usava cascata, certamente que muitos projetos acabaram sendo feitos em cascatas mas isso não são os métodos tradicionais... se você acham que é me resposta o seguinte:

• Me diga 3 sites de cases de projetos em cascatas nos últimos 5 anos
• Me passa 4 vídeos de pessoas falando a favor deste método
• Me mostre 5 livros falando que cascata é o núcleo dos métodos tradicionais
• Me fale de 7 projetos que tenham escolhido usar isso de consciência limpa, ou seja, de livre escolha e por escolha de facto.

Não existe. Isso não existe, na prática os projetos que acabaram sendo executados em cascata, tirando os projetos do DOD(Departamento de Defesa dos Estados Unidos) não usaram este método por que quiseram, acabaram caindo nisso por erros básicos de processes, ou pela falta da habilidade de trabalhar com processo.

Segundo Passo: Batendo em morto

Matando e Batendo em Cachorro Morto

Outra coisa que o pessoal faz é bater em morto, ficam martelando e martelando esta questão da cascata e pelo amor de Deus, métodos ágeis não são a solução para a cascata a solução é desenvolver de forma iterativa incremental, e isso ja exite a muito tempo e foi criando muito antes do agile.

Então o pessoal pega a uma solução que já existia e já solucionada e vende isso como uma solução nova para um problema velho, mas que na verdade é a única solução, pelo menos é o que os caras dizem. Pura mentira! E digo mais o RUP ja era iterativo incremental e ja resolvia o problema que os ditos métodos ágeis resolvem mas isso eles não gostam muito de falar, por sinal alguns só falam em UP, por que acreditam que esta letra R é profana.

Terceiro Passo: O Pattern do Saco de Gato

Saco de Gatos

Mais uma técnica utilizada pelos agilistas, antes de prosseguir faço a vocês a seguinte pergunta:

• Defina métodos ágeis, me de um escopo

O manifesto ágil é tão abrangente tanto quanto especifico e claro como uma bula de remédio tarja preta, ou seja, deslocamento total da realidade. Os caras tem a incrível habilidade de dizer que tudo que era bom que existiam antes de 1995 já era Agile e tudo de bom que vai existir nos próximos 100 anos vai ser agile também.

O pensamento é mais ou menos assim, se é bom e funciona é agile, se é ruim não é agile, pelo amor de Deus, os caras não tem nem a humildade de assumir que projetos ágeis falham por defeitos do próprio processo que ao mesmo tempo é definido e indefinido.

Então eles utilizam o pattern do saco de gatos, ou seja, tudo que presta eles colocam em um saco de gato chamado "Agile" e o que não presta eles colocam em outro saco de gato chamado "Metodologia Tradicional", bom no tradicional dos caras eles colocam coisas como PmBoK, RUP, OOAD e CMMI.

Falando de CMMI, como os caras tem aversão a isso, tal aversão pode ser comparada aos maiores afervores religiosos do nosso mundo. Ter documentação não é ruim, tem um pilha com 50000 folhas de documentação e papel e diagramas não é ruim, desde que isso tenha valor.

Neste ponto do valor que os caras ja se perdem de novo, o objetivo não é colocar coisas em papel de bolo e guardanapos e sim utilizar menos formalismo em coisas com menos valor, agora isso é muito diferente de documentos x rabiscos.

Quarto Passo: A Arrogância Agile (AA)

Gato se achando muito mais do que é...

Este é outro ponto a se pensar, os caras acham que conhecem PmBoK ou CMMI, mas na prática não conhecem, nunca utilizaram da maneira correta, logo eles julgam que você não sabe o que esta fazendo e não vai conseguir fazer o projeto funcionar.

Também acham que você não sabe nada de agile, eu por exemplo uso agile, uso Scrum, XP, FDD e também uso Lean\Kanban que por sinal não tem nada a ver com agile: Agile != Lean. Mas os caras tem as seguintes visões, pensam que:

• Você não sabe
• Você leu mas não praticou, vai praticar
• Vou praticou mas errou, ScrumBut e outras trovas...
• Vou usou de forma errada, ou seja, não era agile

A mentalidade chega a ser ao ponto de, se não funcionou era por que não era agile. Em determinados cenários agile não funciona, com equipes muito verdes, com requisitos muito complexos e equipes que não tem a disciplina não funciona.

Quinto Passo: Atacar a concorrência

Ops...

CMMI não funciona, ou demora muito, ou é complicado. Em alguns cenários usar agile pode ser como usar veneno, ou seja, só vai matar o projeto mais cedo. Não se esqueçam que o projeto que deu a vida ao XP foi um projeto fracassado.

CMMI nada mais é do que uma grande régua, ou seja, ele serve para medir o seu processo, ele vai ao nível do "O que" e não do "Como" mas não deixa de ser uma boa maneira de evoluir a sua empresa e qualidade.

Eu particularmente venho utilizando CMMI em conjunto com algumas práticas dos métodos ágeis, diversas práticas da engenharia como integração contínua, reuniões de pé, retrospectivas, big visible charts, etc... e conceitos e práticas de lean e kaban, que de novo, não tem nada a ver com agile, por mais que os agilistas queiram fazer este rebranding.

Mas é facto, difícil ver agilistas sensatos com os pés no chão que sabem quando usar e quando não usar práticas ágeis e digo mais, poucos os que sabem fazer o mix dos métodos tradicionais com os métodos ágeis.

Sexto Passo: O pensamento Errado

Pesando Certo?

Você não deve pensar, puxa, não vou usar métodos tradicionais por que isso pesa, vou ser ágil, isso é uma besteira sem tamanho. Na prática processo é != de concreto. A cada projeto você vai customizar o processo para as necessidades do projeto e eu faço isso com CMMI. Em todo o projeto você vai ter que balancear formalismo e disciplina.

Determinados projetos precisam de mais formalismo e outros não, isso vai muito de organização a organização, projeto a projeto e necessidade a necessidade, logo não assuma a premissa de que você precisa sair só usando papel velho para anotar e trabalhar com projeto.

O pensamento certo é ser pragmático e não dogmático, muitos só sabem ver o mundo com a lente cor de rosa do agile e isso é um dogma, o mesmo que vemos nas religiões. Pessoal estimar não ruim, isso não é errado, gerênciar riscos é um boa prática, ter um gerente não significa ter um capataz, gestão é comunicação e liderança e isso se faz mesmo na sendo ágil.

No final das contas você tem que ter agilidade/produtividade se não o projeto não vinga, você tem que produzir, mas isso não tem nada a ver com utilizar ou não utilizar métodos ágeis mas tem a ver com processo, com balanço de disciplina e formalismo.

Ahh e os casos de uso e a ferramentas cases também não são vilões, você não precisa colocar tudo em post-it esse não é um objetivo o objetivo é atender o cliente e muita vezes este atender não é feito com software mas sim com processo. Você pode usar isso e não é para apoiar e para agregar e para lhe dar beneficio e pense bem nem todo o projeto vai ser de equipes colocadas, ou seja, equipes que estão no mesmo espaço físico.

Sempre precisamos ponderar se a solução que os ditos métodos ágeis estão dando é uma solução única ou se não existe outras opções, não é inteligente se apegar a dogmas, em uma caixa de ferramenta não existem só as familias de ferramentas de chave.

Abraços e até a próxima.