O modelo Waterfall é útil para projetos que têm objetivos claros e imutáveis do início ao fim, mas há pelo menos 7 razões para não ser usado no desenvolvimento de software. Sobretudo, se o seu time de desenvolvimento tiver a responsabilidade de priorizar clientes ou usuários finais, provavelmente o framework em cascata não vai funcionar e será necessário optar pelo Método Ágil.
O Waterfall divide as atividades de um projeto em fases sequenciais lineares: cada conjunto de tarefas depende das entregas que vieram da etapa anterior. O progresso normalmente flui de cima para baixo, como uma cachoeira – por isso o nome “cascata” ou “waterfall” –, através das fases de concepção, iniciação, análise, design, codificação, teste, implementação e manutenção.
Isso quer dizer que o Waterfall depende de equipes que seguem uma sequência de etapas e nunca avançam até que a fase anterior seja concluída. A metodologia, em sua forma tradicional, praticamente não deixa espaço para mudanças ou revisões inesperadas.
Esse modelo cria um ambiente físico rígido, onde as alterações de design se tornam proibitivamente mais caras à medida que o projeto avança.
Como um time de Waterfall lida com um problema?
Imagine que Tom é o gerente de TI de uma empresa de desenvolvimento de software em Waterfall. Ele e outros líderes do departamento estão preocupados porque o DAU (número de usuários ativos diários) de seu aplicativo online está em declínio. Eles então estabelecem uma meta: aumentar essa métrica em 15% em 3 meses.
Depois de debater ideias e discutir alternativas, ele e os outros gerentes decidem renovar o site do aplicativo com a mais recente combinação JavaScript + Elixir + Phoenix. Tom é o encarregado de conduzir todo esse esforço.
Agora, ele precisa encontrar um arquiteto e um designer de software disponível no departamento para começar a traçar as especificações, wireframes e desenhos desta nova versão do produto.
Depois que as especificações e a etapa de design estiverem completamente concluídas, elas serão enviadas para os desenvolvedores de front-end, a alguns desenvolvedores de back-end e talvez a um DBA (Database Administrator), para revisar a camada de persistência. Quando tudo estiver concluído, eles vão encaminhar o produto para alguns especialistas em Quality Assurance (QAs) testarem.
Mas quanto tempo todo esse processo levará? Provavelmente, muito mais do que a empresa pode pagar por um produto de baixo desempenho.
Além disso, há uma pergunta importante que Tom e seus colegas não fizeram: a reformulação do aplicativo resolveria o problema com a baixa adesão de usuários? Não necessariamente. “Ao correr, certifique-se de estar correndo na direção certa.”
A prática padrão do time de uma empresa de desenvolvimento software em cascata é mais ou menos assim:
- As decisões são tomadas no topo e fornecidas às equipes de desenvolvimento para implementação;
- Os gerentes atribuem as tarefas a desenvolvedores;
Além disso, o projeto de Tom e seus colegas envolveria muitas interfaces e dependências fora do desenvolvimento básico do produto, o que significa que o time tende a ser composto de “equipes dentro de equipes”.
Isso pode ser uma grande desvantagem, pois no Waterfall as pessoas prestam mais atenção em como as coisas devem acontecer no momento certo, em vez de observar se as coisas estão realmente se encaixando no todo.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte de que precisam e confie neles para fazer o trabalho.
5º Princípio do Manifesto Ágil
Embora o planejamento seja importante, é fundamental que os desenvolvedores e especialistas em qualidade entendam como o produto vai ser recebido e utilizado pelo cliente ou o usuário final. Todas as pessoas envolvidas no projeto também devem ter a oportunidade de dizer imediatamente que há/podem haver falhas em uma etapa específica do projeto sem ter que esperar pelo estágio de teste.
Como um time Ágil lida com um problema?
Agora, imagine que a empresa de desenvolvimento tenha um time Ágil: como Tom vai interagir com a sua equipe? Bem, ele não dirá para o time reformular o site do aplicativo. Em vez disso, dará o problema para a equipe resolver, ou seja, o desafio de aumentar o DAU em 15%. É o time que vai descobrir qual é a melhor solução.
As equipes ágeis recebem problemas a serem resolvidos, não soluções a serem implementadas. Gerentes ágeis não dizem aos desenvolvedores o que fazer. As equipes são multifuncionais e autogerenciadas, com total autonomia para decidir como resolver o problema. Os membros do time são especialistas e têm todas as habilidades necessárias para entregar uma solução completa, porque todos são donos de todas as tarefas, e não pessoas individuais que são donas de tarefas individuais.
Segurança para falhar = inovação
Ciclos de iteração curtos + Falha = Falha com raio de explosão curto
Falha = Aprendizagem
Ninguém precisa ficar atribuindo tarefas ou lembrando o time de fazer uma tarefa A ou B; os gestores confiam que os membros da equipe vão fazer o seu trabalho (afinal, eles são adultos). Como a solução foi ideia de todos do time, eles se apropriaram da solução e ficam motivados para fazer o trabalho com qualidade. A equipe se sente fortalecida.
7 Razões para não usar o modelo Waterfall no desenvolvimento
1 – Rigidez. Fazer alterações no modelo em cascata é difícil e muito caro. O teste é feito nas últimas fases do ciclo de vida do software, o que significa que provavelmente será tarde para fazer modificações se algo inesperado acontecer ou se o cliente não gostar do produto. Caso seja preciso mudar os objetivos ou o escopo do trabalho, pode ser impossível fazer o que for necessário para continuar avançando.
2 – Não há como voltar atrás nas etapas. A única maneira de contornar essa desvantagem é encontrar uma maneira de concluir o trabalho na etapa atual em que ocorreram as dificuldades. Se isso não for possível, a equipe terá que reiniciar todo o projeto para acrescentar as novas informações ou corre o risco de invalidar as etapas anteriores, pois elas têm dependências em cascata.
3 – Este método exclui usuários finais e clientes. O modelo em cascata enfoca os processos internos do trabalho, valorizando a eficiência do projeto e da equipe, sem levar em conta os desejos e necessidades do cliente (que talvez até mudem ao longo do processo). Não há espaço para compartilhar ideias ou opiniões porque os esboços passam a fazer parte das etapas de planejamento.
4 – O teste do produto só é feito na conclusão do projeto. No Waterfall, quaisquer problemas ou obstáculos só são vistos na hora do teste. Até lá, há muito espaço para que as dificuldades passem despercebidas por toda a equipe, que fica mais focada em aspectos técnicos e no escopo.
5 – O tempo para entrega dos projetos é longo. Como cada fase requer a conclusão de 100% de todas as tarefas e documentação antes da transição para a próxima etapa, os projetos podem levar muitos meses para serem entregues. Essa desvantagem é a razão pela qual projetos complexos evitam o uso do modelo em cascata. Se ocorrer algo inesperado, como já dito nas outras 4 razões acima, algumas equipes podem ter que voltar ao ponto de partida, criando um déficit de tempo ainda mais significativo.
6 – Não funciona bem para projetos complexos. O modelo em cascata se esforça para gerenciar bem o tamanho e o escopo do projeto. É como um autor olhar para os capítulos de um livro cuja comparação é importante para completar a composição do romance inteiro.
7 – Os custos de tempo e mão de obra são enormes. Se a equipe esperar meses até que o time tenha realmente desenvolvido o produto – ou mesmo um Mínimo Produto Viável (MVP) –, antes de ver se é comercial e tecnicamente operável, e que o usuário ficará satisfeito, o risco todo ficará para o final do processo. Resultado: todo mundo gastou tempo e dinheiro para construir um produto que pode ser inviável.
Por que os projetos de desenvolvimento falham?
- 80% dos orçamentos de times de TI são consumidos corrigindo problemas.
- Aplicativos mal definidos (falta de comunicação entre as áreas de negócios e de TI) contribuem para uma taxa de falha de projeto de 66%, custando às empresas pelo menos US $ 30 bilhões a cada ano.
- 60% a 80% das falhas de projetos de desenvolvimento podem ser atribuídas diretamente à fraca coleta, análise e gerenciamento de requisitos.
- 40% dos problemas de software são encontrados pelos usuários finais.
- 25% a 40% de todos os gastos em projetos de desenvolvimento são desperdiçados com retrabalho.
(Fontes: Project Management Institute – PMI)
Em resumo, um projeto de desenvolvimento de software pode ser realizado como um enorme contêiner sendo carregado nas costas de cada membro do time ou como pequenas peças de um Lego, montado por toda a equipe em conjunto.
Apesar de ser apontado como desatualizado, é claro que o modelo em cascata continua sendo respeitado e ainda é uma escolha relevante hoje devido à sua abordagem de desenvolvimento direta, previsível e simplificada. Pode não ser um método adequado para alguns setores. As limitações do Waterfall tornam-se mais evidentes dependendo do tamanho, tipo e objetivos do projeto.
Se sua empresa tem um time de desenvolvimento com mais de 10 pessoas ou o trabalho for imprevisível, a abordagem Ágil pode trazer melhores resultados, menos custos e tem mais probabilidade de satisfazer o cliente, já que é flexível a mudanças.
Por fim, é importante ter cuidado com o “falso Ágil” ou “mini-Waterfall”. Se o time de desenvolvimento estiver trabalhando com entregas frequentes, mas não contemplar o cliente nem o usuário, ou começarem a surgir miniespecificações de user stories, ou se as falhas e obstáculos forem deixados para o final da sprint, então é hora de erguer a bandeira vermelha. É sinal de que é um processo em cascata iterativo. Parece só uma pequena cachoeira, mas isso é um Waterfall.
Em busca de ciclos mais ágeis de trabalho? A UDS desenvolve aplicações web e mobile com alta performance em ciclos curtos de entrega, prezando por segurança e escalabilidade.
