Ágil ou Waterfall (Sequencial) – qual é melhor?

Como um praticante ágil, instrutor, coach e consultor, você poderia esperar que eu dissesse: "Ágil é a única maneira de ter sucesso—me pague muito dinheiro e eu vou te mostrar o porquê!"

Mas aqui está a verdade (alerta de spoiler): só posso responder essa pergunta com "depende". Isso pode soar vago, mas frequentemente é a resposta mais honesta e valiosa.

No fim das contas, apenas você pode decidir o que é melhor para seu projeto e organização, baseado nos direcionadores e restrições que você entende melhor do que eu. Espero que este artigo ajude você a descobrir isso por conta própria.

Vamos começar observando as ideias centrais por trás de cada abordagem.

O gerenciamento de projetos em cascata segue uma abordagem sequencial e preditiva. O escopo geralmente é fixo, e a solução frequentemente é totalmente especificada antes do desenvolvimento. A entrega pode acontecer como um único 'big bang' ou em fases, onde cada fase entrega uma parte significativa da solução geral.

Um método cascata típico envolve estas etapas:

1. Análise: Identificar, documentar, concordar e aprovar os requisitos e quaisquer padrões de qualidade. Em TI, isso inclui requisitos não-funcionais.
2. Design: Criar e aprovar um design detalhado que atenda aos requisitos acordados e critérios de qualidade.
3. Construção: Construir a solução de acordo com o design, garantindo que atenda a todos os requisitos especificados e padrões de qualidade.
4. Teste: Testar minuciosamente a solução para confirmar que atende aos requisitos acordados, design e outros critérios de qualidade.
5. Implementação: Colocar a solução em uso para entregar seu valor de negócio pretendido.

Cada etapa deve ser planejada e provisionada com recursos, com todas as atividades claramente identificadas, estimadas e atribuídas. Em muitos casos, as atividades serão divididas em tarefas detalhadas e capturadas na forma de um gráfico de GANTT. Para um projeto em fases, análise e design de alto nível devem acontecer primeiro para estabelecer o contexto e escopo para cada fase.

A abordagem waterfall requer um estilo preditivo de gerenciamento de projetos no qual cada etapa produz documentação que descreve o que a próxima etapa precisa fazer.

Todo o trabalho de cada etapa é planejado com base na expectativa (que é uma previsão) de que o resultado corresponderá ao que foi acordado. A documentação devidamente aprovada é a principal forma de comunicar a intenção do projeto a todos os envolvidos ou afetados.

O controle do projeto depende de demonstrar que o trabalho entregue corresponde à documentação da etapa anterior, bem como seguir o plano aprovado para a etapa atual. Quaisquer mudanças devem passar por um processo formal no qual a documentação é revisada e aprovada. Idealmente, a documentação é revisada regularmente para garantir que ainda atenda às necessidades empresariais em evolução.

Mudanças podem ser identificadas a partir do trabalho nas etapas posteriores do processo waterfall. Por exemplo, com problemas sendo descobertos durante a etapa de Teste que identificam uma incompatibilidade entre os requisitos especificados e a necessidade empresarial atual. É necessária uma análise dessa incompatibilidade, com quaisquer mudanças acordadas sendo propagadas pela cascata waterfall para serem testadas novamente.

A percepção de sucesso na metodologia cascata tende, portanto, a estar relacionada a quão bem a previsão corresponde à necessidade real e quão próximos os resultados se alinham com a previsão em termos de orçamento, cronogramas e qualidade.

O processo em cascata pode parecer simples à primeira vista, mas frequentemente acaba sendo mais complexo do que o esperado. Ele depende muito de documentação, usa aprovações hierárquicas e segue um planejamento centralizado. Como exige documentação e planejamento detalhados desde o início, o processo pode se tornar complicado, com muitas partes relacionadas que precisam ser conectadas para que o processo alcance o resultado desejado.

Vantagens:

• Estrutura Direta: A abordagem passo a passo é fácil para gerentes de projeto entenderem e explicarem às partes interessadas.
• Planejamento Previsível: A análise e design abrangentes no início apoiam um planejamento e orçamento claros e precisos.
• Acompanhamento Simples: O progresso pode ser monitorado através da documentação (mostrando como os marcos são atingidos) e verificado em relação ao plano (para confirmar que as tarefas estão sendo concluídas no prazo e dentro do orçamento).

Desvantagens:

• Gerenciamento de Mudanças Complexo: Lidar com mudanças necessárias pode ser trabalhoso, às vezes levando as equipes a contornar o processo completamente e resultando em perda de controle.
• Detecção Tardia de Problemas: O desenvolvimento em grandes incrementos com testes focados principalmente no final do processo pode revelar problemas tarde demais, causando atrasos inesperados e estouros de orçamento.
• Foco Reduzido no Valor de Negócio: A extensa análise e documentação iniciais não oferecem valor direto ao negócio; existem apenas para orientar o processo.

Embora ainda tenha um elemento de processo distinto para estruturar o desenvolvimento, uma abordagem ágil para gerenciamento de projetos foca mais nas pessoas do que no processo. O trabalho inicial é intencionalmente leve, moldando apenas a solução e o plano de alto nível enquanto deixa os detalhes mais refinados para o último momento responsável antes do desenvolvimento. Tipicamente, o desenvolvimento prossegue recurso por recurso dentro de "Sprints" de duração fixa.

Os participantes do projeto – incluindo, de forma importante, pessoas do mundo dos negócios dentro das equipes de desenvolvimento – colaboram durante todo o projeto. Eles constroem incrementos menores do que no modelo waterfall tradicional, usando um processo iterativo.

Cada iteração inclui análise, design, construção, teste e, idealmente, implantação, em ciclos que podem durar apenas algumas horas ou se estender por vários dias ou semanas (ao invés das semanas ou meses frequentemente vistos no waterfall). O objetivo é implantar partes da solução assim que elas puderem entregar valor.

O desenvolvimento depende da colaboração detalhada de indivíduos conhecedores e qualificados, capacitados pela organização para desenvolver uma solução que atenda à necessidade do negócio.

Esses indivíduos definem os detalhes da necessidade antes de planejar o trabalho de desenvolvimento necessário. Eles então executam esse plano, ajustando-o continuamente para manter o foco na entrega do máximo valor. Para uma verdadeira agilidade, as equipes frequentemente seguem valores como aqueles encontrados no Scrum, que é atualmente a abordagem de entrega ágil mais amplamente adotada.

A abordagem iterativa é altamente tolerante a mudanças porque adia o planejamento detalhado até o último momento responsável, usando dados em tempo real e ciclos de planejamento curtos. Em vez de ser totalmente prevista desde o início, a solução emerge gradualmente para atender necessidades que foram delineadas (mas não meticulosamente definidas) no início do projeto.

Ao priorizar requisitos de alto nível antecipadamente e lidar primeiro com os mais importantes, permite que equipes ágeis mantenham controle rigoroso sobre prazos e orçamentos. O desenvolvimento simplesmente termina de forma controlada uma vez que os limites de tempo ou orçamento são atingidos, com apenas os itens menos valiosos sendo excluídos da entrega final.

Como os ciclos de desenvolvimento são curtos (geralmente cerca de duas semanas) e fixos, faz sentido medir o sucesso através da entrega incremental de valor em um ritmo previsível.

A abordagem iterativa e incremental, com ciclos de tempo curtos conduzidos por equipes autônomas e auto-organizadas, frequentemente parece caótica. Mas quando composta por pessoas competentes, colaborativas e disciplinadas, ela é altamente eficiente e eficaz. Dito isso, o risco de usar uma abordagem ágil com indivíduos que não são competentes, colaborativos e disciplinados muito provavelmente levará ao fracasso. Isso torna a supervisão (mas não o gerenciamento) essencial até que as equipes tenham demonstrado sua capacidade coletiva de entregar.

Vantagens:

• Desenvolvimento Iterativo: Ciclos de desenvolvimento rápidos com oportunidade para colaboração e feedback contínuo reduz o risco de construir uma solução que não atenda às necessidades reais.
• Entrega Incremental de Valor: Entregar valor tangível em intervalos curtos melhora o controle geral ao tornar o progresso mais fácil de acompanhar e a ação corretiva mais fácil de identificar.
• Adaptabilidade: Deixar os detalhes para o último momento responsável permite que as soluções surjam para atender às necessidades atuais ao invés das previstas.

Desvantagens:

• Pode parecer desestruturada: Especialmente para aqueles acostumados a controles baseados em processos. Não é adequada para gerentes e líderes com alta necessidade de controle.
• Alta competência e colaboração de todos os envolvidos: Líderes precisam de confiança para confiar e competência para empoderar suas equipes colaborativas.
• Potencial para caos e fracasso: Equipes que carecem de competência e profissionalismo demonstrados podem falhar sem supervisão adequada.

Nota: as desvantagens descritas acima se aplicam a equipes ou organizações que são novas na forma ágil de trabalhar, onde há competência genuína com agilidade é difícil identificar desvantagens universais, embora algumas específicas do contexto possam surgir.

As principais diferenças entre uma abordagem ágil e uma abordagem cascata podem ser resumidas em 5 dimensões:

1. Desenvolvimento da Solução – Emergente vs. Especificada:

• Ágil: A solução emerge ao longo do tempo para atender às necessidades de negócio em mudança. Os detalhes evoluem mais próximo do desenvolvimento, mantendo a solução flexível.
• Cascata: A solução é definida antecipadamente para atender a uma necessidade esperada. É necessário um controle cuidadoso de mudanças para manter o alinhamento com as necessidades em transformação.

2. Participantes do Projeto – Colaborativo e Multifuncional vs. Segmentado & Especializado:

• Ágil: Os membros da equipe trabalham juntos com papéis amplos, fazendo o que for necessário para alcançar seu objetivo compartilhado. O objetivo é evitar comunicação via documentação e minimizar transferências onde for possível.
• Cascata: Embora algum grau de colaboração seja frequentemente observado, muitas vezes é focado em atividades específicas e especializadas (como levantamento de requisitos). Os participantes do projeto tendem a adotar a abordagem segmentada da Engenharia Industrial que dominou o pensamento do século 20, tipicamente com comunicação e controle gerenciados via documentação.

3. Gestão – Auto-organizável vs. Gerenciada:

• Ágil: As equipes se organizam e se gerenciam, decidindo como completar tarefas e ajustando processos conforme aprendem.
• Cascata: As equipes tipicamente recebem direcionamento de gerentes, que decidem o que deve ser feito, por quem e quando. O nível de detalhamento nessas instruções pode variar baseado no projeto ou estilo do gerente, no entanto.

4. Mudança – Abraçada vs. Resistida:

• Ágil: Como as equipes trabalham em direção a objetivos amplos sem definir cada detalhe antecipadamente, elas recebem bem as mudanças conforme novas necessidades ou insights emergem.
• Cascata: O gerenciamento de mudanças é burocrático e custoso porque requer análise minuciosa, documentação e aprovação. Como resultado, frequentemente atua como uma barreira para mudanças necessárias.

5. Controle baseado em: Disciplina Profissional vs. Conformidade de Processo

• Ágil: Depende fortemente da competência, disciplina e auto-organização da equipe. Os membros da equipe fazem compromissos uns com os outros e assumem coletivamente a propriedade das tarefas e soluções.
• Cascata: Usa planejamento detalhado e instruções claras. O papel de cada um é definido antecipadamente, e o gerente de projeto coordena as atividades. O sucesso depende de seguir o plano e processos conforme projetados.

Como mencionei anteriormente, depende...

No mundo complexo de hoje, executar um projeto totalmente ágil ou totalmente waterfall é improvável. Mais frequentemente, as equipes descobrem que alguma agilidade pode agregar valor a um projeto principalmente waterfall, enquanto alguns elementos waterfall fazem sentido em um projeto que é de outra forma ágil. Essa mistura é frequentemente chamada de abordagem híbrida, situando-se na área cinzenta entre os dois extremos.

Então, a verdadeira pergunta de um gerente de projeto não é "Qual método puro devo escolher?", mas sim "Onde no espectro meu projeto deve se situar?" Métodos ágeis prosperam em ambientes com alta volatilidade, incerteza, complexidade e ambiguidade (VUCA). Por outro lado, abordagens em cascata normalmente funcionam melhor onde as coisas são mais estáveis, certas, simples e claras.

O framework Cynefin pode ajudá-lo a identificar onde seu projeto pode se encaixar neste espectro.

Cynefin, pronunciado kuh-nev-in, é uma palavra galesa que significa os múltiplos fatores interligados em nosso ambiente e nossa experiência que nos influenciam (como pensamos, interpretamos e agimos) de maneiras que nunca conseguiremos compreender completamente.

Em uma simplificação excessiva reconhecida do Framework Cynefin, o ambiente em que estamos trabalhando – neste caso, nosso ambiente de projeto – pode ser colocado em um espectro caracterizado como claro, complicado, complexo ou caótico.

Em um ambiente de projeto que é:

• Claro, há um caminho óbvio entre problema e solução.
• Complicado, o caminho entre problema e solução pode não ser óbvio, mas uma boa análise revelará um caminho para uma solução apropriada.
• Complexo, não é possível identificar um único caminho, mesmo com análise, porque previsões só podem ser feitas com base em teoria em vez de experiência.
• Caótico, não há base para previsão porque há muitos fatores em mudança ou conflitantes. O único caminho a seguir é através de experimentação.

No exposto acima, o domínio claro se presta ao waterfall puro e o domínio caótico requer agilidade. Os outros dois – os mais comuns na realidade – provavelmente são melhor atendidos por uma abordagem híbrida. Então, pergunte-se: "qual dos itens acima melhor descreve meu ambiente de projeto?" e deixe isso orientar sua seleção de abordagem.

Você também precisa considerar outras restrições conduzidas pelas regras e cultura da sua organização ao decidir sobre a abordagem mais sensata para seu projeto. Tentar fazer uma abordagem waterfall funcionar em uma cultura caracterizada pela agilidade ou uma abordagem ágil funcionar em uma cultura caracterizada por comando e controle causará problemas.

Uma abordagem híbrida pode ter maior probabilidade de "vender" e ter sucesso.

O Manifesto Ágil, aprimorado para ampliar sua aplicabilidade além do software, identifica quatro declarações de valor destinadas a orientar os profissionais em direção a comportamentos ágeis. Qualquer pessoa que pretende trabalhar de forma ágil deve valorizar:

Focando nos itens à esquerda enquanto ainda reconhece valor naqueles à direita.

Embora haja debate sobre se o Manifesto original se aplica totalmente no mundo de hoje – particularmente em um contexto de software – as declarações de valor ainda oferecem orientação útil para a governança de projetos. Faz sentido basear a governança de um projeto ágil nos itens à esquerda, e a governança de um projeto waterfall nos itens à direita.

• Pessoas e trabalho em equipe: Monitorar e possibilitar disciplina profissional e colaboração.
• Entregando valor ao negócio: Focar no valor que suporta as necessidades do negócio, ao invés de simplesmente cumprir requisitos de processo.
• Envolvimento ativo do negócio: Ter representantes do negócio trabalhando em estreita colaboração com a equipe durante todo o projeto.
• Atender necessidades atuais na implementação: Garantir que a solução atenda aos requisitos reais do negócio no lançamento—mesmo que esses requisitos sejam diferentes do plano inicial.

• Seguindo processos predefinidos: Garantindo que todos cumpram as etapas e aprovações estabelecidas.
• Produzindo documentação preditiva: Desenvolvendo especificações claras e verificando se a solução está alinhada com elas.
• Aprovando mudanças adequadamente: Validando todas as alterações na documentação original.
• Aderindo aos planos: Garantindo que os planos permaneçam precisos e responsivos às mudanças aprovadas.

Em uma configuração híbrida, a governança deve encontrar o equilíbrio certo entre elementos ágeis e waterfall. Isso envolve adequar quais partes de cada abordagem fazem mais sentido para o contexto específico do projeto.

A abordagem de entrega de projetos mais eficaz deve ser orientada pelo contexto – tanto a natureza do trabalho quanto o ambiente no qual o projeto irá existir. Desconfie de qualquer pessoa que promova agile puro ou waterfall puro como uma receita universalmente aplicável para o sucesso.

Com uma referência final ao framework Cynefin – descreve um estado de Aporia (significando impasse) ou Confusão e não é um bom lugar para estar. Você muito provavelmente se encontrará, junto com seu projeto, sofrendo aqui se for incapaz ou não estiver disposto a adequar sua abordagem de projeto ao seu contexto e ambiente.

Você precisa pensar por si mesmo, analisar o contexto e agir de acordo. Fazendo isso, você tem a melhor chance de sair da Aporia/Confusão para um dos outros estados onde uma abordagem, muito provavelmente híbrida, otimizará sua oportunidade de sucesso no projeto.