Seja inteligente: evite artigos cascateiros

Um colega me indicou um artigo anti-movimento ágil (Seja inteligente e não use Agile). Eu não me considero um "agilista", mas já estudei o tema a sério e procuro aplicar os princípios ágeis sempre que possível, com bons resultados até o momento.

Acontece que o artigo é tão equivocado que decidi analisá-lo parágrafo a parágrafo para desfazer possíveis mal entendidos perpetrados. O texto entre aspas pertence ao autor do artigo com meus comentários logo em seguida.

"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."

Logo no 1o. parágrafo o autor afirma o óbvio ("você pode fazer um projeto e ter sucesso sem usar agile") como forma de desconstruir as metodologias ágeis. Bem, não me lembro de ter lido que o kernel do Linux, por exemplo, tenha seguido alguma metodologia ágil de desenvolvimento de software e, mesmo assim, é um projeto de sucesso. Ora, é óbvio que projetos ad-hoc podem ter sucesso. Assim como projetos XP, projetos Scrum, projetos RUP, etc.

Agora, a possibilidade de um projeto ad-hoc falhar é muito maior que em projetos que seguem alguma metodologia. Alguma metodologia de desenvolvimento (XP, Crystal, RUP, etc) é melhor que nenhuma metodologia. Em outros termos, não é porque existem pessoas que conseguem atravessar o canal da Mancha a nado que qualquer um vai conseguir repetir o feito com sucesso, entende?

"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?"

Este é outro parágrafo problemático: a começar pelo português macarrônico (... muitos colocam como os métodos ágeis sendo... ), mas vamos nos ater aos conceitos depuráveis.

Bem, Fred Books escreveu um artigo entitulado "No Silver Bullet: Essence and Accidents of Software Engineering" onde afirma que não existe solução única (metodologia, ferramenta, etc) para resolver os problemas de desenvolvimento de software. Agilista ou não, é estupidez achar que existe um "tamanho único" em termos de metodologia de software. Portanto, as perguntas do autor já foram respondidas muitos anos atrás, antes mesmo do movimento ágil.

Outro ponto problemático é quando o autor diz que "muitos projetos acabaram sendo feitos em cascata, mas isso não são os métodos tradicionais... ".

Como não? Depois de uma afirmação leviana dessas eu peguei minhas edições dos livros do Sommerville e Pressman na minha estante e os abri para verificar se me ensinaram errado na universidade. Lá consta que o modelo em cascata (waterfall model) é um exemplo de metodologia clássica de desenvolvimento de software. Respirei aliviado quando vi que estava certo.

O autor instiga o leitor a mostrar-lhe exemplos de projetos atuais ("...nos últimos 5 anos...") que usem cascata e daí concluí que isso não existe. Ora, esta é uma falácia básica de argumento. É o mesmo que dizer: Cangurus não existem porque eu nunca vi um canguru ao vivo. Ridículo, não ?

"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."

Afirmar que ninguém usa método em cascata porque quer é desinformação, no mínimo. Que erros "básicos" são esses que fazem uma pessoa "cair" em um modelo em cascata? Que habilidades são essas que nos fazem "cair" no modelo em cascata?

"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."

Prestem atenção ao texto em negrito. Acontece que os métodos ágeis como o XP são iterativos e incrementais, portanto, o autor afirma uma coisa na primeira sentença e se contradiz na segunda sentença !!!

Outra coisa, os métodos ágeis não são uma alternativa aos métodos em cascata, per si, mas sim uma alternativa aos métodos burocráticos, inchados e cheios de artefatos que não agregam valor ao desenvolvimento de software. O autor nem mesmo conhece os preceitos básicos do movimento ágil, trata-se, portanto, de uma argumentação equivocada contra o movimento ágil.

"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."

O parágrafo acima é tão problemático que vou ter que fatiá-lo. Vejamos,

"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. "

As idéias são recicladas continuamente em informática. Esta é a regra e não há mal nenhum. As idéias centrais do XP já eram utilizadas aqui e ali em vários projetos durante vários anos. XP não é 100% original, assim como o RUP não é.

"E digo mais, o RUP já era iterativo incremental e já resolvia o problema que os ditos métodos ágeis resolvem."

Finalmente o autor falou algo verdadeiro. Só que na ânsia de "desancar" o movimento ágil ele se esqueceu de ver que o XP também é iterativo e incremental.

"... Mas isso eles não gostam muito de falar, por sinal alguns só falam em UP, por que acreditam que essa letra R é profana."

De onde o autor tirou uma besteira dessas?

O "R" de RUP vem de Rational, que é um produto, e marca registrada, da IBM. As pessoas usam Unified Process (UP) para evitar potenciais problemas com copyright. Além disso, o UP é usado para descrever o processo genérico do qual o RUP é um refinamento.

"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 autor coloca os carros na frente dos bois aí (isto está cansando...).

Não é que o movimento ágil ache que tudo de bom que existia antes de 1995 era ágil. Não é isso. O que acontece é que o movimento ágil pegou tudo de bom que existia antes e inseriu nas metodologias (isso é pecado?). E tudo de bom que aparecer nos próximos 100 anos pode e deve ser incorporado em métodologias ágeis ou em métodologias "pesadas" como o (R)UP. Isto se chama evolução.

"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."

Projetos (ágeis ou não) falham por uma série de fatores, dentre os quais o principal é o fator humano. É claro que se o processo desconsidera o fator humano então ele possui uma falha grave. Agora, afirmar que os processos utilizados em metodologias ágeis são definidos e indefinidos (ao mesmo tempo!) é burrice. Pegue o Scrum, por exemplo, onde temos os Sprints, os encontros diários, etc. As regras estão lá, basta conhecê-las.

"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."

Sim, uma pilha de 50 mil folhas de documentação e papel e diagramas não é ruim, a princípio, pois depende da complexidade do software, mas QUEM vai atualizar isso?

A documentação deve evoluir junto com o software e não ser emoldurada na parede. O que acontece é que estas 50 mil folhas acabam mofando em um canto do escritório enquanto o software já está lá na frente, evoluindo. Mesmo que essas 50 mil folhas tenham algum valor, ele irá se perder com o tempo, pois são necessários recursos humanos para manter tamanha quantidade de documentação alinhada com a evolução e mudança dos requisitos.

O tópico "Quarto passo: a Arrogância Agile (AA)" é o único que salva deste artigo tosco. Não existem muitas meias-verdades nem muitas falácias nesta parte, portanto podemos pulá-la sem dó.

"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."

Ah, entendi. Vamos incutir o medo: não usem isso ou o projeto de vocês vai fracassar também. Divertido, mas fracassa como argumentação. O autor volta ao tema do "one size fits all" que nunca é a solução. Use metodologia ágil onde for viável!

Eu conheço uma tentativa de usar CMMI em uma corporação que foi um fracasso. Por isso eu não devo nem olhar mais para CMMI? É claro que não!

"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."

Dizer que CMMI é uma grande régua é a mesma coisa que dizer que giraffa é um cavalo com pescoço grande. CMMI é um meta-framework de integração de modelos de processos, onde existe muito mais coisas que simplesmente métricas. Dizer que usa CMMI não é a mesma coisa que usar CMMI.

"Você não deve pensar "puxa, não vou usar métodos tradicionais porque isso pesa, vou ser ágil". Isso é uma besteira sem tamanho. "

Concordo. Pessoas inteligentes não fazem isso.

"Na prática, processo é != de concreto. "

Não diga! Nossa, você merece um prêmio por tamanho insight! Quando é que eu iria imaginar que, na prática, a teoria != prática.

"A cada projeto você vai customizar o processo para as necessidades do projeto e eu faço isso com CMMI. "

Você quer dizer CMMI-SW, certo? Ou você usa também CMMI-SE, CMMI-IPPD, e CMMI-SS? Isso eu duvido muito que alguém consiga utilizar 60% de tudo que tem no CMMI-SW, por exemplo.

"Em todo o projeto você vai ter que balancear formalismo e disciplina."

E quanto às disciplinas formais? Elas já são automaticamente balanceadas?

"Determinados projetos precisam de mais formalismo e outros não, isso vai muito de cada organização, cada projeto e necessidade. "

Peraí! Esta eu lembro, é uma afirmação que se encontra em 10 de cada 10 livros de engenharia de software nacionais e internacionais, certo?

"O pensamento certo é ser pragmático, e não dogmático."

Mas esse é um dos princípios do movimento ágil: pragmatismo. Em projetos de software significa eliminar as gorduras do projeto, isto é, atividades e artefatos que não adicionam valor ao projeto. Detalhe: esse "valor" depende de cada projeto, é óbvio.

"Estimar não é ruim, não é errado; "

XP e Scrum fazem estimativas durante o ciclo de vida do projeto.

"gerenciar riscos é um boa prática, ter um gerente não significa ter um capataz. "

XP, Scrum e RUP põem os riscos no centro da discussão. As próprias stories do XP são priorizadas em termos de valor para o cliente e risco de implementação. Quanto ao gerente/capataz, trata-se de um problema cultural que passa até mesmo ao largo de quaisquer metodologias.

"Gestão é comunicação e liderança, e isso se faz mesmo na metodologia ágil."

Concordo.

"No final das contas você tem que ter agilidade/produtividade, senão o projeto não vinga."

Caramba! O cara simplesmente manda desconsiderar tudo que ele escreveu antes!!! Assim papai não aguenta...

"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."

Este parágrafo está quase bom, realmente, a não ser pela parte disciplina x formalismo. De novo não!!!

"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. "

Um dos gurus do movimento ágil, Alistair Cockburn, é defensor ferrenho do uso de casos de uso em metodologias ágeis. Leia, meu filho, leia e aprenda!

"Esse não é um objetivo. O objetivo é atender ao cliente, e muitas vezes este atender não é feito com software, mas sim com processo. "

OK. Mas em metodologias de desenvolvimento de software o objetivo é entregar software de qualidade no prazo e custo acordado. Agora, se o problema for fazer reengenharia de processos, então o software é apenas parte da equação.

"Você pode usar isso e não é para apoiar e para agregar e para lhe dar benefícios."

Alguém sinceramente entendeu esse parágrafo?

"E pense bem, nem todo o projeto será de equipes colocadas, ou seja, equipes que estão no mesmo espaço físico."

Espere um pouco, me dê um minuto que vou pensar um pouco nisso que você escreveu. É muita informação nova para mim ... [ modo irônico = ON ].

"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... "

Ah, uma coisa inteligente no meio de tanta besteira...