Parece que a “Agilidade” em projetos veio para ficar. Muito se fala sobre transformação ágil e agilidade nos negócios, inclusive prescrevendo a morte do Modelo Cascata. Mas será que essa é a solução para todo e qualquer tipo de projeto?
Como vimos em um post anterior, o Modelo Cynefin explica muito bem em que tipos de projetos podemos usar os Modelos Tradicionais. E tais modelos normalmente seguem esta sequência de desenvolvimento:
Obviamente, dependendo do modelo tradicional, uma ou outra fase tem seu nome modificado, ou ainda fases são acrescentadas ou eliminadas. Mas forma geral, o que todos têm em comum é que uma fase só se inicia após o término da fase anterior.
Esses modelos são também chamados de Cascata ou Waterfall, porque a fase seguinte sempre estará depois da anterior, e nunca vai voltar para trás como as águas de uma cachoeira. Esses modelos são altamente prescritivos, ou seja, tem foco em planos detalhados definidos no princípio do projeto, como custo, escopo e um cronograma bem detalhado. Mudanças são geralmente indesejadas.
O modelo cascata é utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos. Uma forma de utilizar o modelo cascata é quando precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente. Por exemplo, quando temos um sistema já pronto e precisamos fazer uma adaptação porque alguma lei governamental foi alterada ou criada.
Também podemos utilizar o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis.
As Fases de um projeto
O modelo cascata tem sido usado há séculos na construção civil e sempre com resultados muito satisfatórios. Na construção da sua casa dos sonhos você poderia fazer assim:
- Fase Análise e definição de requisitos: é uma lista com o que você quer que essa casa tenha. Então essa casa poderia ter 3 suítes com banheiras de hidromassagem, uma cozinha americana e uma sala com portas de correr que se abrem para o espaço da piscina e churrasqueira. (Sonhar, realmente não custa nada).
- Fase Projeto: aqui são elaboradas as famosas plantas, com todas as medidas e indicações necessárias para que a construção seja feita sem que ao seu final ela desabe ou se pareça com um hospital.
- Fase Implementação: esta é a fase da construção. É mais do que esperado que esta fase te dê uma dor de cabeça danada, já que você terá que lidar com os pedreiros; e porque estes normalmente acabam construindo paredes tortas e fora do lugar. Mas se o projeto for bem acompanhado por um arquiteto ou mestre de obras, é possível que esta fase termine sem muitos traumas.
- Fase de Testes: aqui já temos praticamente a casa pronta. O que vamos fazer é ver se a água do chuveiro está escorrendo em direção do ralo ou para dentro do quarto. Se ao acionar o interruptor a luz vai acender. Se a porta está encaixando no batente etc. Caso pequenas falhas estejam acontecendo, suas correções são realizadas antes de darmos a casa como pronta e entregue.
- Fase Manutenção: este é o dia a dia de morar em uma casa, vai ter que cortar a grama, lavar os quintais, desentupir calhas e ralos etc.
Embora tenham evoluído ao longo dos tempos com novas máquinas e equipamentos, projetos de construção civil existem há eras na história da humanidade e, em linhas gerais, sua forma de execução se manteve a mesma: uma longa fase de definições e especificações no início que tem como saída um plano, seguida de sua fase de execução, validação e entrega.
A história do Modelo Cascata no desenvolvimento de software
Até aqui já vimos que o modelo cascata realmente é bem sucedido quando temos um escopo bem definido. Mas, por que ele foi adotado no desenvolvimento de software?
No início do desenvolvimento de software não existiam técnicas, recursos e práticas capazes de fomentar a construção de sistemas com características adequadas para acompanhar a evolução e popularização dos computadores.
Assim, o modelo usado até então em projetos, foi adaptado para o mundo intangível do software. Esses modelos são denominados prescritivos, porque se baseiam na capacidade de prescrever um conjunto de elementos e atividades de um processo. Tudo é definido do início ao fim. Ou seja, as fases são prescritas exatamente da mesma forma que construímos uma casa.
Não devemos demonizar esse modelo, já que ele foi concebido para trazer ordem ao caos que existia na área de desenvolvimento de software até então. Dessa forma, o modelo cascata realmente proporcionou uma grande contribuição, pois forneceu um roteiro razoavelmente eficaz para as equipes que desenvolviam software.
No entanto, com o aumento da complexidade dos sistemas, esse modelo mostrou que o trabalho de engenharia de software não é muito adequado quando o escopo é muito volátil. E foi por isso que novas formas de desenvolvimento foram criadas.
Os grandes problemas
Os principais problemas encontrados no modelo cascata quando aplicados no desenvolvimento de software são:
- Os projetos de software reais construídos e evoluídos na indústria de software raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse modelo em forma sequencial possa conter iterações, onde poderíamos passar diversas vezes pelas mesmas atividades, ele o faz indiretamente. Como resultado tem-se que mudanças podem provocar bastante confusão na medida em que a equipe de projeto prossegue.
- É muito raro e difícil que o cliente saiba estabelecer explicitamente todas as suas necessidades logo no início do projeto. O modelo cascata é fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que existem no início dos projetos.
- O cliente precisa ter muita paciência, o que raramente acontece. Uma versão operacional (pronta para ser executada no cliente) não estará disponível até estarmos próximo ao final do projeto. Se tivermos um erro grave nas etapas iniciais, como uma especificação mal compreendida e mal construída, podemos ter um resultado desastroso.
