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 ágeis. Neste artigo gostaria de esclarecer os diversos enganos
que os ditos “agilistas” erram quando falamos de processos tradicionais
e desenvolvimento de software.

Em
outro artigo vou falar dos pontos positivos, ou seja, do que é bom
mesmo. Mas aqui vou focar nestes equívocos que as pessoas comentem
– 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

Não
posso negar que 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 parecer besteira, mas já é intuitivo: este nome vai te chamar
muito mais atenção. Todos vão querer usar a metodologia boa ao invés da
metodologia ruim. Outro ponto que os caras gostam de pegar é na
cascata, nem o cara que inventou isso usava cascata, certamente que
muitos projetos acabaram sendo feitos em cascata, mas isso não são os
métodos tradicionais… se você acha que é, me responda o seguinte:

• Me diga 3 sites de cases de projetos em cascata nos últimos 5 anos
• Me mostre 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 fato.

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 porque quiseram;
acabaram caindo nisso por erros básicos de processos, 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
essa questão da cascata. Por favor, métodos ágeis não são a
solução para a cascata. A solução é desenvolver de forma iterativa
incremental, e isso já existe há muito tempo, foi criado muito antes do
agile.

Então o
pessoal pega 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 já era iterativo incremental e já 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 essa 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 proposição:

• Defina métodos ágeis. Me dê um escopo.

O
manifesto ágil é tão abrangente quanto especifico e claro como
uma bula de remédio tarja preta, ou seja, deslocamento total da
realidade. Os caras têm a incrível habilidade de dizer que tudo que era
bom que existia 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. As pessoas não têm 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 eles colocam coisas como PmBoK, RUP, OOAD e CMMI.

Falando
de CMMI, como os caras têm aversão a isso! Tal aversão pode ser
comparada aos maiores fervores religiosos do nosso mundo. Ter
documentação não é ruim, ter um pilha com 50 mil folhas de documentação
e papel e diagramas não é ruim, desde que isso tenha valor.

É nesse
ponto do valor que eles 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. 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, e  julgam que você não sabe o que está 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 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 que se não funcionou era porque 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 têm disciplina, a metodologia 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 de 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 têm nada a ver
com agile, por mais que os agilistas queiram fazer este rebranding.

Mas
é fato: é 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, são poucos os que
sabem fazer o mix dos métodos tradicionais com os métodos ágeis.

Sexto passo: o pensamento errado

Pensando certo?

Você
não deve pensar “puxa, não vou usar métodos tradicionais porque 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 cada
organização, cada projeto e 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. Estimar não é ruim, não é errado;
gerenciar 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 metodologia ágil.

No final das contas você tem que ter
agilidade/produtividade, senã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, tem a ver com processo, com balanço de disciplina e
formalismo.

Ah, e os casos de uso e as 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 ao cliente, e muitas 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 benefícios. E pense bem, nem
todo o projeto 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 existem outras opções. Não é inteligente se apegar a dogmas. Em uma
caixa de ferramenta não existem só as familias de chaves…

Abraços e até a próxima.