Métodos ágeis e Scrum: guia completo para gerenciar projetos
Você recebeu um projeto em que o cliente ainda não sabe exatamente o que quer, as prioridades mudam a cada reunião e o cronograma feito no início já não serve na terceira semana. É nesse cenário que a metodologia ágil faz diferença: em vez de tentar prever tudo no começo, a equipe entrega em ciclos curtos, mostra o resultado e decide o próximo passo com base no que aprendeu.
O problema é que "ágil" virou um rótulo para muita coisa. Tem empresa que chama de ágil qualquer quadro de tarefas na parede, e tem equipe que roda reunião diária sem nunca entregar nada utilizável. Para usar bem, você precisa separar três camadas: os valores e princípios (o Manifesto Ágil), os métodos que os colocam em prática (Scrum, Kanban, XP e outros) e a decisão sobre qual abordagem serve para cada projeto.
Quem domina as três consegue explicar ao patrocinador por que um projeto vai rodar em Sprints e outro vai seguir um cronograma tradicional, em vez de aplicar o mesmo método a tudo.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é metodologia ágil
Metodologia ágil é um jeito de gerenciar projetos e produtos em que o trabalho é planejado e entregue em incrementos pequenos, com inspeção frequente do resultado e adaptação do plano. O foco sai de "cumprir o plano original" e vai para "entregar valor e aprender o mais cedo possível".
Três ideias sustentam qualquer método ágil:
- Entrega incremental: em vez de um grande resultado no fim, o projeto produz partes utilizáveis ao longo do caminho. Num sistema, cada ciclo libera funcionalidades que alguém já consegue usar.
- Ciclos curtos de feedback: o cliente ou usuário vê o resultado parcial com frequência e influencia o que vem a seguir.
- Equipe com autonomia: quem faz o trabalho decide como fazê-lo, e o gerente ou líder remove obstáculos em vez de distribuir tarefas minuto a minuto.
Um detalhe de vocabulário: em rigor, "ágil" é um conjunto de valores, não uma metodologia única. Scrum se define como framework, Kanban como estratégia para otimizar o fluxo de valor e XP como um conjunto de práticas de engenharia. No dia a dia, porém, "metodologia ágil" é o nome que o mercado usa para tudo isso, e é nesse sentido amplo que ele aparece aqui.
Na linguagem do Project Management Institute (PMI), o ágil corresponde à abordagem adaptativa, em oposição à preditiva (escopo, prazo e custo definidos no início, mudanças controladas formalmente). O Guia PMBOK reconhece as duas e também a combinação delas, a abordagem híbrida. Nenhuma é melhor em absoluto: cada uma serve a um tipo de projeto.
O Manifesto Ágil: os 4 valores e os 12 princípios
O termo ganhou força em fevereiro de 2001, quando 17 profissionais de desenvolvimento de software se reuniram em Snowbird, no estado americano de Utah. Entre eles estavam representantes de Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development e Pragmatic Programming. O encontro produziu o Manifesto para Desenvolvimento Ágil de Software, que tem versão oficial em português no site agilemanifesto.org.
Os quatro valores
O manifesto compara quatro pares de coisas e diz qual delas recebe mais peso:
| Valorizamos mais | Do que |
|---|---|
| Indivíduos e interações | Processos e ferramentas |
| Software em funcionamento | Documentação abrangente |
| Colaboração com o cliente | Negociação de contratos |
| Responder a mudanças | Seguir um plano |
A frase que fecha o manifesto costuma ser esquecida e é a mais importante: os itens da direita têm valor, mas os da esquerda valem mais. O manifesto não manda abolir documentação, contrato ou plano. Ele diz o que prevalece quando há conflito. Uma equipe que não documenta nada e chama isso de ágil leu metade do texto.
Os 12 princípios, agrupados por tema
Os princípios detalham os valores. Para aplicar, vale agrupá-los em quatro temas:
- Valor para o cliente: a prioridade é satisfazer o cliente com entregas cedo e contínuas; mudanças de requisito são bem-vindas, mesmo tarde; entregas frequentes, de poucas semanas a poucos meses, com preferência pelo intervalo menor.
- Colaboração: pessoas de negócio e desenvolvedores trabalham juntas todos os dias; projetos se constroem em torno de pessoas motivadas, com ambiente e confiança; a conversa face a face é o meio mais eficiente de passar informação.
- Medida e ritmo: software funcionando é a principal medida de progresso; o ritmo deve ser sustentável por tempo indeterminado, sem maratonas de hora extra.
- Qualidade e melhoria: atenção contínua à excelência técnica e ao bom design; simplicidade, entendida como a arte de maximizar a quantidade de trabalho que não precisa ser feito; equipes auto-organizadas produzem as melhores arquiteturas e requisitos; em intervalos regulares, a equipe reflete e ajusta seu comportamento.
Fora do software, troque "software funcionando" por "entrega utilizável": uma campanha no ar, um módulo de treinamento aplicado, um processo redesenhado e rodando.
Como funciona a metodologia ágil na prática
Os métodos variam, mas o ciclo de fundo é parecido em todos:
- Lista priorizada do que precisa ser feito. No Scrum se chama Product Backlog. É uma lista viva, ordenada por valor, e só os itens do topo precisam estar detalhados.
- Ciclo curto de trabalho. A equipe puxa os itens do topo e trabalha neles por um período fixo (no Scrum, a Sprint, de no máximo um mês) ou em fluxo contínuo (no Kanban).
- Entrega de algo utilizável. Cada ciclo termina com um resultado que pode ser inspecionado de verdade, não com um relatório de percentual concluído.
- Revisão com quem vai usar. Cliente, usuários e patrocinador veem o resultado e dizem o que mudou nas prioridades.
- Ajuste do plano e do processo. A lista é reordenada e a equipe discute o que melhorar no próprio jeito de trabalhar.
Exemplo: implantação de um sistema de agendamento numa prefeitura. No modelo preditivo, a equipe levantaria todos os requisitos de todas as secretarias, desenharia o sistema inteiro e faria a implantação no fim. No modelo ágil, a primeira entrega poderia ser o agendamento de um único serviço (emissão de uma certidão, por exemplo) numa unidade piloto, em poucas semanas. Os atendentes usam, apontam problemas, e as entregas seguintes ampliam serviços e unidades com base no uso real. O risco de construir algo que ninguém usa cai muito. Vale lembrar que, em órgão público, o contrato e a licitação continuam exigindo escopo e marcos definidos; é aí que entra o híbrido, tratado mais abaixo.
Os principais métodos ágeis: Scrum, Kanban, XP e outros
Scrum
O Scrum é o método ágil mais conhecido. O Guia do Scrum, escrito por Ken Schwaber e Jeff Sutherland (versão atual de novembro de 2020), o define como um framework leve para gerar valor por meio de soluções adaptativas para problemas complexos. A estrutura é enxuta:
- Três responsabilidades: Product Owner (maximiza o valor do produto e ordena o backlog), Scrum Master (responsável pela eficácia do time e pelo uso correto do Scrum) e Developers (quem constrói o incremento). Juntos formam o Scrum Team, normalmente com 10 pessoas ou menos.
- Cinco eventos: a Sprint, que contém Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
- Três artefatos: Product Backlog, Sprint Backlog e Incremento, cada um com um compromisso (Meta do Produto, Meta da Sprint e Definição de Pronto).
O Scrum funciona melhor quando há um produto claro, uma equipe dedicada e um responsável pelas prioridades com autoridade de fato. A versão 2020 trouxe mudanças relevantes, como a Meta do Produto e o fim da separação entre "time de desenvolvimento" e Scrum Team; o artigo sobre o que mudou no Scrum Guide 2020 detalha cada uma. O funcionamento de cada papel, evento e artefato, com um exemplo de Sprint, está no artigo sobre o que é Scrum, nesta mesma categoria.
Kanban
O Kanban nasceu no Sistema Toyota de Produção e foi adaptado ao trabalho do conhecimento. O Kanban Guide (publicado em kanbanguides.org) o define como uma estratégia para otimizar o fluxo de valor em um processo, com três práticas: tornar o fluxo de trabalho visível, gerenciar ativamente os itens em andamento (controlando o trabalho em progresso, o WIP) e melhorar o fluxo continuamente.
Diferente do Scrum, o Kanban não exige iterações de duração fixa nem papéis novos. Você começa pelo processo que já existe, desenha as etapas num quadro, limita quantos itens podem ficar em cada etapa e mede o fluxo. O guia lista quatro medidas: WIP, vazão (throughput), idade do item de trabalho e tempo de ciclo. Por isso o Kanban se encaixa bem em trabalho que chega de forma contínua e imprevisível, como suporte, manutenção, demandas jurídicas ou um setor de compras. Para entender o método com calma, leia o que é Kanban e como funciona.
XP (Extreme Programming)
O XP, desenvolvido por Kent Beck na segunda metade dos anos 1990 e descrito no livro Extreme Programming Explained (1999), é o mais técnico dos três. Seus valores são comunicação, simplicidade, feedback, coragem e respeito. As práticas atacam a qualidade do código: programação em par, desenvolvimento guiado por testes (o teste é escrito antes do código), integração contínua, refatoração constante, entregas pequenas e frequentes e ritmo sustentável.
Raramente uma empresa "adota XP" como método de gestão. O mais comum é a equipe usar Scrum ou Kanban para organizar o trabalho e práticas de XP para garantir que o que é entregue a cada ciclo funciona e pode ser alterado sem quebrar. Sem essas práticas, Sprints curtas viram uma fábrica de dívida técnica.
Outros nomes que você vai encontrar
- Lean: a filosofia de eliminar desperdício e otimizar o fluxo, base do Kanban e muito usada em operações e serviços.
- Scrumban: uma combinação de Scrum e Kanban, comum em equipes que fazem projeto e sustentação ao mesmo tempo.
- DSDM, Crystal e FDD: métodos que já estavam na mesa em 2001 e hoje aparecem menos no mercado brasileiro.
- Frameworks de escala, como SAFe e LeSS: coordenam vários times ágeis trabalhando no mesmo produto ou portfólio. Só fazem sentido depois que os times individuais já funcionam bem.
Scrum, Kanban e XP: qual a diferença
A tabela resume o que muda entre os três na rotina da equipe:
| Critério | Scrum | Kanban | XP |
|---|---|---|---|
| Ritmo | Sprints de duração fixa, até um mês | Fluxo contínuo, com cadências de reunião definidas pela equipe | Iterações curtas e entregas pequenas |
| Papéis | Product Owner, Scrum Master e Developers | Nenhum papel obrigatório | Cliente próximo da equipe e desenvolvedores |
| Mudança de prioridade | Entra no backlog e vale para a próxima Sprint, sem pôr em risco a Meta da Sprint atual | A qualquer momento, desde que respeite o limite de WIP | Replanejamento a cada iteração |
| Foco principal | Entregar um incremento de valor por Sprint | Fluidez e previsibilidade do fluxo | Qualidade técnica do software |
| Métrica típica | Progresso rumo à Meta da Sprint e à Meta do Produto | Tempo de ciclo, vazão e idade dos itens | Testes passando e integração frequente |
| Melhor uso | Desenvolvimento de produto com equipe dedicada | Demanda contínua e variável | Software com exigência alta de qualidade |
Os três não competem entre si. Uma combinação comum: Scrum para organizar o produto, quadro Kanban para visualizar o Sprint Backlog e práticas de XP no código. Para uma comparação mais detalhada, com exemplos de escolha, veja o artigo Kanban, Scrum e XP: comparação e como escolher.
Ágil, tradicional ou híbrido: como escolher a abordagem
A pergunta certa não é "qual método está na moda", e sim "quanto deste projeto eu consigo prever com segurança?". Use os critérios abaixo:
| Situação do projeto | Tende a pedir |
|---|---|
| Escopo conhecido, requisitos estáveis, pouca margem para mudar depois de executado (obra civil, instalação de equipamentos, mudança de sede) | Preditiva |
| Resultado incerto, cliente descobre o que quer ao ver protótipos, valor depende de testar com usuários (aplicativo, novo produto digital, portal de serviços) | Ágil |
| Demanda contínua e imprevisível, sem "fim de projeto" claro (sustentação de sistemas, atendimento interno, marketing de conteúdo) | Kanban |
| Contrato, orçamento ou licitação com escopo fechado, mas partes do trabalho com muita incerteza (implantação de ERP, projeto em órgão público, lançamento de produto com data fixa) | Híbrida |
Alguns exemplos de como isso fica na prática:
- Obra de uma loja nova: fundação, estrutura e instalações seguem um cronograma preditivo com caminho crítico. A comunicação visual e a montagem do mix de produtos podem rodar em ciclos curtos, testando opções com o time comercial.
- Implantação de ERP: fases, marcos e orçamento planejados de forma preditiva (o contrato exige). Parametrização, relatórios e integrações em Sprints, com usuários-chave validando cada entrega.
- Evento corporativo: data imutável, fornecedores com prazos rígidos. O planejamento logístico é preditivo; a programação de conteúdo e a campanha de inscrição se beneficiam de um quadro Kanban com revisões semanais.
O artigo sobre metodologias híbridas de gestão de projetos aprofunda como combinar as duas lógicas sem criar burocracia dupla. Se quiser um diagnóstico do seu caso, o seletor de abordagem da Projeto Diário faz 12 perguntas sobre o projeto e indica se ele pede abordagem preditiva, adaptativa ou híbrida.
Como adotar métodos ágeis no seu projeto: passo a passo
Se a análise apontou para ágil ou híbrido, siga uma sequência que reduz o risco de a mudança ficar só no nome:
- Escolha um piloto com escopo controlado. Um projeto novo, de três a seis meses, com uma equipe pequena e um cliente interno disposto a participar. Evite começar pelo projeto mais crítico da empresa.
- Defina quem decide as prioridades. Uma pessoa, com autoridade real, que vai ordenar a lista de trabalho e estar disponível para a equipe. Sem isso, nenhum método ágil funciona.
- Monte a lista inicial de entregas. Escreva os itens do ponto de vista de quem vai usar, ordene por valor e detalhe só o que será feito nas próximas semanas.
- Escolha o método pelo tipo de trabalho. Entregas de produto com equipe dedicada: Scrum. Demandas contínuas: Kanban. Na dúvida, comece pelo Kanban, que parte do processo atual e muda menos coisa de uma vez.
- Combine o que significa "pronto". Uma lista curta de critérios que toda entrega precisa cumprir (testado, revisado, documentado no manual do usuário, aprovado pela área). É o que impede o "90% pronto" eterno.
- Rode de três a quatro ciclos antes de julgar. As primeiras Sprints ou semanas de fluxo são de aprendizado. Meça o que foi entregue e use a retrospectiva para ajustar.
- Alinhe a gestão. Diretoria e PMO precisam aceitar relatórios baseados em entregas e não em percentual de tarefas. O artigo sobre metodologias ágeis fora de TI traz exemplos para áreas como RH, marketing e operações.
Erros que fazem a adoção ágil fracassar
- Trocar o nome sem trocar o jeito de decidir. Reunião diária, quadro e post-its não tornam a equipe ágil se o gerente continua definindo cada tarefa e o escopo continua congelado.
- Product Owner sem tempo ou sem autoridade. Quando quem prioriza é um comitê, ou alguém que aparece uma vez por mês, a equipe trabalha no que acha importante e o cliente não reconhece o resultado.
- Entregas que não podem ser usadas. Uma Sprint que termina com "telas desenhadas" ou "70% do módulo" não gera feedback real. Cada ciclo precisa terminar com algo que alguém consegue inspecionar de verdade.
- Ignorar a qualidade técnica. Entregar rápido sem testes e sem revisão acumula retrabalho, e em poucos meses a velocidade cai. É por isso que práticas de XP continuam relevantes.
- Usar o ágil para fugir do planejamento. O Manifesto não elimina planos, só os torna revisáveis. Projetos ágeis planejam o tempo todo, em horizontes mais curtos.
- Escalar antes de funcionar. Implantar um framework de escala com dezenas de times quando nenhum time isolado entrega com consistência só multiplica o problema.
Para começar ainda hoje, faça o exercício com o projeto que você tem em mãos: liste as cinco entregas mais valiosas, pergunte quem tem autoridade para ordená-las e veja se a primeira pode chegar às mãos de um usuário em até quatro semanas. Se a resposta for sim, você já tem um piloto ágil. Para dominar o Scrum com profundidade (papéis, eventos, artefatos e as práticas que o complementam), o curso Agile Scrum Foundation da Projeto Diário cobre o framework do início ao fim e prepara para o exame de certificação ASF.