Gestão ágil x tradicional: diferenças na prática do projeto
A diferença entre projeto ágil e tradicional costuma ser resumida como "um tem documentação e o outro não", e essa é justamente a parte menos importante. Há projetos ágeis bem documentados e projetos tradicionais com documentos que ninguém abre. O que separa as duas abordagens é outra coisa: quando as decisões sobre o que será entregue são tomadas e como o projeto reage quando a realidade muda.
No modelo tradicional, decide-se cedo. O escopo é definido, detalhado e aprovado no início, e o resto do projeto consiste em cumprir o plano e controlar os desvios. No modelo ágil, decide-se aos poucos. O time entrega partes utilizáveis em ciclos curtos, observa o resultado e define o próximo passo com o que aprendeu.
Nenhuma das duas é melhor em geral. Cada uma é melhor para um tipo de problema, e muitos projetos precisam das duas. Abaixo estão as diferenças lado a lado, como elas aparecem no dia a dia, um mesmo projeto conduzido nos dois modelos e critérios para escolher.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é o modelo tradicional de gestão de projetos
O modelo tradicional, também chamado de preditivo ou cascata, organiza o projeto em fases sequenciais: iniciação, planejamento, execução, monitoramento e encerramento. O planejamento produz uma linha de base de escopo, cronograma e custo, aprovada pelo patrocinador. A partir daí, o sucesso é medido pela aderência a essa linha de base, e qualquer mudança passa por um processo formal de controle.
Esse modelo funciona bem quando o resultado pode ser especificado com segurança antes de começar e quando mudar depois sai caro: uma obra, a instalação de equipamentos, uma mudança de sede, um projeto regulado com entregas definidas em lei.
Uma confusão comum é associar o PMBOK apenas a esse modelo. As edições recentes do guia do Project Management Institute (PMI) tratam de abordagens preditivas, adaptativas e híbridas. O artigo sobre como escolher entre PMBOK e Scrum explica por que a comparação direta entre os dois é imprecisa.
O que é gestão ágil de projetos
A gestão ágil, ou adaptativa, parte do princípio de que, em problemas complexos, não dá para saber tudo no início. O projeto avança em ciclos curtos (no Scrum, as Sprints), e cada ciclo entrega algo utilizável que é avaliado por quem vai usar. O escopo é detalhado à medida que o time aprende, e o plano é revisto a cada ciclo.
As bases dessa forma de trabalhar, detalhadas no guia completo de métodos ágeis e Scrum, estão no Manifesto Ágil, de 2001, que valoriza responder a mudanças mais do que seguir um plano, sem negar o valor do plano. O artigo sobre o Manifesto Ágil e seus 12 princípios explica cada um deles com exemplos.
Projeto ágil e tradicional: as diferenças lado a lado
| Aspecto | Tradicional (preditivo) | Ágil (adaptativo) |
|---|---|---|
| Quando o escopo é definido | No início, de forma detalhada | Aos poucos, com detalhe só para o curto prazo |
| O que é fixo | Escopo, com prazo e custo estimados a partir dele | Em geral prazo e custo (capacidade do time); o escopo varia |
| Planejamento | Concentrado no início, com linha de base | Contínuo, em vários níveis (produto, ciclo, dia) |
| Mudanças | Tratadas por controle formal de mudanças | Esperadas e incorporadas no backlog a cada ciclo |
| Entregas | Concentradas no fim ou em grandes marcos | Frequentes, a cada ciclo de poucas semanas |
| Medida de progresso | Percentual concluído e desvio da linha de base | Incrementos utilizáveis e resultados alcançados |
| Participação do cliente | Forte no início (requisitos) e no fim (aceite) | Contínua, nas revisões de cada ciclo |
| Riscos | Identificados e planejados no início, monitorados | Reduzidos ao entregar cedo o que é mais incerto |
| Qualidade | Verificada em fases de teste e aceite | Embutida em cada entrega pela definição de pronto |
| Papéis | Gerente de projetos coordena e responde pelo plano | Responsabilidades divididas (no Scrum: Product Owner, Scrum Master, Developers) |
| Documentação | Extensa e formal, base para aprovações | Suficiente para o trabalho; o produto funcionando é a principal evidência |
| Contratos | Escopo fechado, preço fechado | Tendem a contratar capacidade ou resultados, com escopo flexível |
Escopo, prazo e custo: o triângulo invertido
A diferença mais prática está no que fica fixo. No modelo tradicional, o escopo é definido primeiro, e prazo e custo são estimados a partir dele. Se o escopo cresce, prazo e custo crescem junto, ou o projeto entra em conflito.
No modelo ágil, a lógica costuma se inverter: o prazo (uma série de Sprints) e o custo (o time) ficam fixos, e o escopo é o que varia. A pergunta deixa de ser "quanto tempo para fazer tudo isso?" e passa a ser "o que de mais valioso conseguimos entregar com este time até esta data?". Por isso o backlog é ordenado: se o tempo acabar, o que fica de fora é o que valia menos.
Essa inversão explica boa parte do desconforto de patrocinadores acostumados ao tradicional. Eles perguntam "vai ficar pronto tudo até dezembro?", e a resposta honesta do time ágil é "o mais importante, sim; o resto depende do que aprendermos".
Como cada abordagem lida com mudanças e riscos
No tradicional, uma mudança é um desvio a ser avaliado: impacto em prazo, custo e qualidade, aprovação do comitê, nova linha de base. Isso protege o projeto de mudanças impulsivas, mas torna caro mudar quando a mudança é necessária.
No ágil, a mudança entra no Product Backlog e disputa posição com os outros itens. Ela não interrompe o ciclo em andamento (a Meta da Sprint é protegida), mas pode entrar no próximo. O custo de mudar é baixo enquanto a mudança se refere ao que ainda não foi feito.
Com os riscos, a diferença é de estratégia. O tradicional identifica e planeja respostas no início. O ágil também faz isso, mas tem um recurso a mais: entregar primeiro o que é mais incerto. Se a integração com o sistema legado é o maior risco, ela entra na primeira Sprint, e o time descobre cedo se o projeto é viável.
Mesmo projeto nas duas abordagens: exemplo ilustrativo
O exemplo é ilustrativo. Uma transportadora quer um sistema para os motoristas registrarem entregas pelo celular, substituindo os comprovantes em papel.
Conduzido de forma tradicional: a equipe passa dois meses levantando requisitos com operação, financeiro e jurídico. O documento de requisitos é aprovado, o cronograma prevê oito meses de desenvolvimento e um mês de testes. No mês nove, os motoristas recebem o aplicativo e descobrem que a captura da assinatura não funciona com luvas, que a conexão cai nas rodovias e que o fluxo tem telas demais. Corrigir exige uma nova fase.
Conduzido de forma ágil: em quatro semanas, um grupo de dez motoristas recebe uma versão mínima: registrar a entrega com foto do comprovante, funcionando sem internet. Na revisão, aparecem os problemas da luva e da conexão. As Sprints seguintes tratam disso antes de acrescentar assinatura digital e integração com o faturamento. No mês seis, o aplicativo já está em uso por toda a frota, com menos funcionalidades do que o documento original previa e com mais uso real.
O exemplo favorece o ágil porque o problema era incerto: ninguém sabia como os motoristas usariam o aplicativo na rua. Se o projeto fosse a troca da frota de caminhões, com especificação técnica clara e entrega única, o modelo tradicional faria mais sentido.
Mitos sobre gestão ágil e tradicional
- "Ágil não planeja." O ágil planeja mais vezes, em horizontes mais curtos. O que ele evita é detalhar no início o que ainda não se sabe.
- "Tradicional não aceita mudança." Aceita, por meio do controle formal. O ponto é o custo e o tempo desse processo.
- "Ágil é mais rápido." Ágil entrega valor mais cedo, o que é diferente de terminar tudo mais rápido.
- "Tradicional é coisa do passado." Projetos com escopo estável e alto custo de mudança continuam se beneficiando do planejamento preditivo.
- "É preciso escolher um dos dois." A abordagem híbrida combina os dois no mesmo projeto, cada um na parte em que rende mais.
Como escolher entre ágil, tradicional ou híbrido
Cinco perguntas ajudam a decidir:
- O resultado pode ser especificado com segurança antes de começar? Se sim, o preditivo é candidato forte.
- Dá para entregar partes utilizáveis antes do fim? Se não (uma ponte pela metade não serve), o ágil perde força na execução.
- O cliente ou o usuário está disponível para avaliar entregas com frequência? Sem isso, o ciclo ágil não fecha.
- Quanto custa mudar depois de feito? Custo alto favorece decidir cedo; custo baixo favorece aprender fazendo.
- O contrato ou a regulação exigem escopo fechado? Se sim, considere um modelo híbrido, com escopo fechado no nível de resultados e flexível no detalhe.
Para um diagnóstico do seu caso, o seletor de abordagem da Projeto Diário faz perguntas sobre o projeto e indica se ele pede abordagem preditiva, adaptativa ou híbrida. Se a decisão for migrar uma equipe acostumada ao tradicional, o artigo sobre como migrar de projetos tradicionais para o ágil mostra o caminho, e a comparação específica entre quadro de fluxo e cascata está em Kanban ou cascata.
Antes do próximo projeto
Pegue o projeto que vai começar e responda às cinco perguntas acima com o patrocinador, antes de escolher ferramentas ou montar cronograma. Se as respostas se dividirem, separe o projeto em partes e escolha a abordagem de cada uma. Depois, rode o seletor de abordagem para confirmar a leitura e levar um resultado objetivo para a conversa de aprovação.
