Vivemos num mundo onde a metodologia Agile é ubíqua. Desde gigantes tecnológicos famosos a pequenas startups, toda a gente a utiliza para criar os seus produtos. À medida que aprende sobre Agile, pode ter-se deparado com o termo "metodologia em cascata".
A maioria dos gestores de projetos que utiliza Agile considera a metodologia em cascata ultrapassada e sem qualquer utilidade em 2023. Mas será isso realmente verdade?
Enquanto gestor sénior de produto, tenho bastante experiência tanto com Agile como com a metodologia em cascata. Em defesa da metodologia em cascata, vamos analisá-la em detalhe: o que é, como funciona e quando é apropriado utilizá-la.
Em que consiste a metodologia de gestão de projetos em cascata?
A metodologia em cascata representa o conceito de gerir projetos de desenvolvimento dividindo-os em fases distintas e tratando cada uma delas sequencialmente.
Embora dividir grandes volumes de trabalho em partes mais pequenas seja um conceito que os seres humanos utilizam desde a origem dos tempos, o “nascimento” formal da metodologia em cascata aconteceu muito mais tarde — em 1970, quando o Dr. Winston W. Royce, um proeminente cientista informático da época, a descreveu no seu livro “Gerir o Desenvolvimento de Grandes Sistemas de Software”.
Desde então, tornou-se a principal forma de as empresas de software gerirem os seus projetos, até o mundo começar a inclinar-se para o Agile no início dos anos 2000.
Como é o ciclo de vida do desenvolvimento de software (SDLC) com o método em cascata
Ao contrário da estrutura iterativa e incremental do Agile, o SDLC da metodologia em cascata tem um início e um fim distintos. Divide todo o processo de criação de software em cinco fases ou marcos diferentes, e o trabalho numa fase não começa até a fase anterior estar concluída. Visualmente, tem o seguinte aspeto:
O trabalho flui de uma fase para outra, até chegar ao fim, altura em que o projeto é considerado “concluído” — o que o torna visualmente semelhante a uma cascata (daí o termo).
Vejamos agora cada fase desta abordagem linear e compreendamos em que consiste.
Fase n.º 1: Recolha de requisitos
Tudo começa com a recolha dos requisitos do projeto junto de todas as partes interessadas. Durante a fase de requisitos, os gestores de projetos criarão um documento abrangente e altamente detalhado que cobre todos os aspetos do projeto, desde os requisitos funcionais até ao orçamento e ao plano de riscos.
Have an account? Log In
Fase n.º 2: Conceção da solução
Com base nos requisitos recolhidos na fase anterior, a equipa do projeto começará a formular e a conceber a solução. O termo “conceção” refere-se aqui à estrutura técnica do produto (conceção do sistema), à conceção visual e de interação do produto (conceção de UI/UX) e à conceção física (se se tratar de um produto físico).
Fase n.º 3: Implementação
É nesta fase que ocorre a programação propriamente dita. Os membros da sua equipa de desenvolvimento começarão a construir o produto com base nos entregáveis que criou durante a fase de conceção.
Ao contrário do Agile, em que pode alterar constantemente o âmbito e a conceção do projeto, a metodologia em cascata pressupõe que seguirá o documento de conceção e não “fará evoluir” o produto durante a fase de implementação.
Fase n.º 4: Testes
Assim que a equipa de engenharia de software tiver terminado de construir o produto, podemos avançar para a fase seguinte do nosso plano de projeto — os testes. A sua equipa começará a verificar se existem erros, falhas de segurança ou problemas de experiência do utilizador no produto.
Durante a fase de testes, verificará também se a funcionalidade e a conceção do produto final correspondem aos documentos de requisitos do projeto que criou durante as duas primeiras fases.
Fase n.º 5: Implementação e suporte pós-lançamento
Partindo do princípio de que a sua equipa encontrou e corrigiu todos os problemas significativos do produto, está na altura de fazer o lançamento e entregar a solução aos seus clientes e utilizadores finais.
Os seus programadores passarão agora à fase de manutenção, recolhendo constantemente feedback dos clientes, fazendo as correções necessárias e lançando novas correções e atualizações do produto.
É tudo: o seu projeto está concluído e pode avançar para o próximo!
Então, deve utilizar o método em cascata?
Se pensa, enquanto gestor de projetos com uma mentalidade Agile (pelo menos, presumo que sim), que esta metodologia está fora de moda e que nunca deveria considerar utilizá-la, então discordo (respeitosamente) de si e defendo que a abordagem em cascata é, na verdade, a melhor escolha para determinados tipos de projetos.
Deixe-me apresentar-lhe alguns exemplos para provar o meu ponto de vista.
Casos de estudo: o método em cascata em ação
Tal como acontece com qualquer conceito complexo, alguns exemplos concretos podem ser úteis para compreender como a metodologia funciona na vida real. Por isso, apresento aqui alguns exemplos baseados em projetos reais (nos quais posso ou não ter trabalhado pessoalmente) para ajudar a perceber claramente como a abordagem em cascata funciona na prática.
Caso n.º 1: uma plataforma de desalfandegamento para o Governo do Egito
Imagine que faz parte de uma empresa que ganhou o contrato para modernizar os sistemas de comércio internacional e de desalfandegamento de um país relativamente grande, como o Egito.
O que o Governo egípcio pretende é um sistema de autoridade portuária que gere os manifestos de todos os navios (um documento aduaneiro que contém informações sobre toda a carga e todos os passageiros a bordo desse navio) que entram nos vários portos do Egito.
Além disso, pretende que este sistema se integre diretamente com outro produto que querem que desenvolva, o qual tratará de todas as declarações aduaneiras (também conhecidas como DAU ou documentos administrativos únicos) no país. O formulário é bastante complexo para ser preenchido por pessoas comuns, por isso querem que o automatize para elas.
O Egito tem um sistema complexo de tributação e de direitos aduaneiros que altera as taxas com base no tipo de bens que importa, na sua quantidade e noutros fatores. Como os cidadãos comuns não fazem ideia de quais são essas taxas, o Governo egípcio quer que a sua aplicação calcule automaticamente tudo para os cidadãos com base no que declararam e lhes permita pagar online utilizando os seus cartões de crédito.
Parece uma tarefa enorme, não é? Pois bem, ao finalizar os detalhes da implementação, a sua chefia (e talvez até o Governo egípcio) irá procurá-lo, enquanto gestor de projeto, e perguntar-lhe como pretende organizar a implementação deste projeto.
Por que motivo e como deve utilizar o método em cascata neste cenário:
Tudo o que desenvolver para um governo nacional terá, muito provavelmente, por base uma lei ou uma decisão ratificada pelo parlamento. Estas decisões incluirão tudo, desde os termos gerais do projeto (por exemplo, o seu custo e prazo) até aos mais ínfimos detalhes sobre o funcionamento de tudo.
Parece e soa a um documento de requisitos da primeira fase do método em cascata, certo? Na verdade, é mesmo isso, e significa também que não pode realmente alterar os detalhes da implementação, da conceção e dos requisitos no decurso do projeto, como acontece no desenvolvimento de software Ágil.
Já liderei um produto deste tipo. Um dia, percebemos que podíamos melhorar significativamente a experiência do utilizador fazendo alguns pequenos ajustes na lógica de negócio. Partilhámos imediatamente a nossa ideia com o representante da autoridade aduaneira que trabalhava connosco.
Pois bem, ele disse que não. Poderia pensar que rejeitar uma proposta destas foi uma má ideia, mas ele tinha uma boa razão para não o poder fazer.
Os nossos pequenos ajustes implicariam uma alteração na fórmula que o governo utilizava para calcular os impostos de um determinado produto. A fórmula estava definida na lei, pelo que alterá-la significaria reunir todo o parlamento nacional e submetê-la a votação.
More Articles
Caso n.º 2: o sistema de controlo de voo do helicóptero Ingenuity
Ingenuity é o nome que a NASA deu ao helicóptero de alta tecnologia que construiu e enviou para Marte em 2021. Eis o aspeto do pequeno aparelho.
Agora imagine que era um dos afortunados gestores de projeto responsáveis pelo desenvolvimento do software para esta incrível peça de tecnologia. Mais concretamente, a sua equipa tinha de escrever o código que controlaria o voo do helicóptero.
Criar um sistema de controlo de voo para uma aeronave (especialmente um helicóptero) é muito difícil. Terá de considerar todas as leis da física que interagem com a sua aeronave durante o voo e calcular a velocidade de rotação necessária das pás, o ângulo das pás e um milhão de outras coisas.
Mas a sua tarefa é ainda mais complexa. O seu helicóptero terá de voar acima da superfície de outro planeta, com uma atmosfera 100 vezes menos densa do que a que temos na Terra.
Por que motivo e como deve utilizar o método em cascata neste cenário:
Na minha opinião, o desenvolvimento em cascata é a sua única opção neste caso. Ao contrário da gestão de projetos Ágil, na qual se constrói algo pequeno (o seu MVP), se implementa, se utiliza na vida real, se recolhem comentários e se melhora gradualmente a solução com base nesses comentários, os riscos são demasiado elevados num projeto deste tipo.
Pode realmente arriscar-se a criar um MVP cheio de erros do Ingenuity e fazê-lo voar 140 milhões de milhas até Marte? Não há simplesmente maneira de alguém concordar com isso.
Por isso, terá de construir a versão final e, em seguida, testar rigorosamente todos os seus sistemas antes de ter a confiança necessária para o colocar num foguetão com destino ao planeta vermelho.
O modelo em cascata está vivo e recomenda-se!
Na verdade, é muito mais popular do que seria de esperar, com metade de todos os projetos a nível mundial a utilizar ainda esta metodologia de desenvolvimento.
Embora o advento das metodologias ágeis tenha tornado o mundo um lugar melhor para muitos gestores de projetos, ao permitir-lhes lançar produtos muito mais cedo e desenvolvê-los com base no feedback dos seus utilizadores, o modelo em cascata continua a ser uma metodologia de grande valor que pode utilizar em projetos com flexibilidade limitada e baixa tolerância a erros.
Espero que tenha gostado da nossa análise da metodologia em cascata. Se também quiser ler um pouco mais sobre metodologias ágeis, eis o que posso sugerir:
- O nosso guia sobre gestão ágil de produtos.
- A compilação das melhores práticas para a gestão ágil de portefólios.
- A nossa lista selecionada das melhores ferramentas de gestão ágil de produtos.
Estes são apenas três dos muitos guias e artigos que temos sobre gestão de produtos e de projetos. Para saber mais, subscreva o nosso boletim informativo.