Desenvolvimento Ágil ou desenvolvimento Waterfall?

Desenvolvimento Ágil ou desenvolvimento Waterfall? É uma
velha questão. Os fatos nos
dizem que o paradigma Waterfall dominava totalmente o mundo e que, pouco a
pouco, foi substituído pelo paradigma Ágil em muitas empresas. Mas seguem
existindo outras, especialmente grandes corporações, que permanecem
prisioneiras do velho paradigma.

Por que quero falar sobre isso agora? Porque acabo de ler o livro: “Why Agile is Falling at Large Companies”, de Geri Schneider Winters. Meu primeiro pensamento: “outro livro que tenta
provar que as mudanças não são
possíveis”. Com todo o cuidado e respeito, pensei: ler aqueles que
pensam como eu pode ser agradável, embora provavelmente inútil; mas ler aqueles
que pensam de forma diferente é sempre útil.

A leitura foi gratificante: o livro explora profunda e
seriamente a questão,  em vez de enfatizar a impossibilidade (como eu suponha
ao ler o título) de que é possível aplicarmos o paradigma Ágil de forma
responsável, sólida, considerando todos os elementos necessários para
o sucesso. Mas eu não vou falar mais sobre isso aqui. Sinceramente, recomendo a
leitura do livro!

Paradigma Waterfall
O paradigma Waterfall implica uma análise monolítica, muito profunda
e detalhada do problema a ser resolvido e a resolução total do mesmo ao nível
de projeto, para só em seguida passar à implementação. Será que funciona?
Enfatiza a previsibilidade (custo em tempo e dinheiro) e acredita que tudo correrá bem se o projeto inicial se ajustar à realidade, não conter erros significativos e a própria realidade não mudar muito durante a implementação.

Este paradigma foi pensado para outras circunstâncias, em
que o tamanho dos sistemas e, acima de tudo, a velocidade de mudança eram muito
menores do que hoje.

No início dos anos 80 começamos a ser procurados para a
implementação de grandes sistemas corporativos e imediatamente enfrentamos grandes
dificuldades, superadas com esforço, cada vez mais convencidos de que
o paradigma que estávamos usando não era adequado.

No meu caso, em 1984 apareceu uma grande empresa brasileira
que precisava de um sistema corporativo baseado em um único grande banco de
dados central em torno do qual tudo precisava ser construído. Após a primeira
análise se percebeu que se trataria de um banco de dados de pelo menos 500
entidades e ficou claro que enfrentar esse desafio com o tradicional paradigma Waterfall
nos levaria ao fracasso. Também ficou claro que nós não tínhamos um paradigma
alternativo, de modo que começamos a investigar, procurando novas soluções.

Paradigma Ágil
Mais cedo ou mais tarde, muitas pessoas tiveram problemas
semelhantes. E nos fizemos, provavelmente, as mesmas perguntas. Com a metodologia Waterfall
priorizamos a previsibilidade de custos, mas o que ocorre com a qualidade do
produto? Como os sistemas obtidos atendem às necessidades reais? Como mantê-los válidos e atualizados através do tempo? É razoável
pensar que os custos (dinheiro e tempo) serão menores se usarmos metodologias Ágeis? Ou, na prática, tendem
a ser muito maiores?!

O paradigma Ágil tende a ser um desenvolvimento incremental.
Como o caracterizamos? Por uma permanente interação, envolvimento dos usuários,
prototipagem. 

E quais os problemas encontramos no Paradigma
Ágil? À medida que se avança, são encontradas situações que não estavam
previstas. Quando devemos modificar ou adicionar processos para tratar os
mesmos dados, isto é feito com facilidade. Mas tudo é muito diferente quando as
mudanças estruturais são necessárias no banco de dados: o nível de
independência entre os dados e os programas dos DBMS é
rudimentar e, portanto, quando há mudanças significativas nas estruturas dos
dados, você precisa executar um conjunto de operações complexas, tais como, por
exemplo, determinar quais os programas permanecerão corretos e quais deverão
ser modificados, o que acarreta custos significativos considerando as varáveis tempo, dinheiro e risco
de erros.

Fatalmente devemos cair neste problema? Não há nenhuma maneira de resolvê-lo automaticamente?

Se olharmos para trás, vamos ver que muitas tentativas foram feitas.  Por exemplo, no final dos
anos 70, ANSI-SPARC emitiu uma recomendação destinada a independência viável
entre dados e programas. Houve então o lançamento de um DBMS (SUPRA) que
obedecia razoavelmente a essa recomendação. Mais tarde, a Microsoft incluiu um mecanismo (Datasets/Dataviews) no Framework.net com o mesmo objetivo.
Por diferentes razões, estas iniciativas não prosperaram.

Em 1985, concluímos que a melhor maneira de resolver o problema era aumentar o nível
de abstração e passar a trabalhar com o conhecimento puro.

Com o passar do tempo,  conseguimos uma boa gestão automática
do conhecimento dos sistemas de negócio que nos permitiram, como subprodutos, a
automação de:

– Projeto, geração, manutenção e reorganização do banco de
dados.

– Geração de projeto e manutenção de programas.

Resumo
O paradigma Waterfall é obsoleto, mas continua existindo
porque quase todos os sistemas legados utilizam.

Não é razoável enfrentar o desenvolvimento de novos sistemas com o paradigma
Waterfall.

O paradigma Ágil oferece vantagens claras para novas
aplicações.

Permitir uma boa independência
entre os dados e os programas, de modo a viabilizar um verdadeiro
desenvolvimento incremental, ajuda muito.

 


(*)  Breogán Gonda é engenheiro de
Computação, pesquisador, professor, consultor e presidente da GeneXus S.A