Tipos de metodologias ágeis: exemplos e quando usar cada uma
Quem pede um exemplo de metodologia ágil quase sempre ouve "Scrum" como resposta. Não está errado, mas é incompleto. Scrum é o framework ágil mais conhecido, só que existe uma família inteira de métodos que nasceram da mesma insatisfação com projetos longos, planos rígidos e entregas que chegam tarde demais, e cada um resolve um problema um pouco diferente.
Escolher o método pelo nome mais famoso leva a erros previsíveis. Um time de suporte com demandas que chegam todo dia sofre com Sprints de duas semanas. Um time de desenvolvimento com muitos defeitos em produção não resolve o problema só com eventos do Scrum, porque o que falta são práticas técnicas. Uma empresa com vinte times no mesmo produto precisa de algo além do que um time sozinho usa.
A seguir estão os principais tipos de metodologias ágeis, com o que cada uma propõe, quando funciona melhor e uma tabela para comparar. Antes, um ponto de partida comum a todas.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que faz uma metodologia ser ágil
O termo "ágil" se consolidou em 2001, com o Manifesto para Desenvolvimento Ágil de Software. Os autores já praticavam métodos diferentes (Scrum, XP, DSDM, Crystal, FDD, entre outros) e se reuniram para registrar o que tinham em comum: quatro valores e doze princípios, explicados em detalhe no artigo sobre o manifesto ágil.
Na prática, um método é ágil quando:
- entrega resultado utilizável em ciclos curtos ou em fluxo contínuo;
- usa o retorno de clientes e usuários para decidir o próximo passo;
- aceita mudança de prioridade como parte normal do trabalho;
- dá ao time autonomia para decidir como trabalhar;
- inspeciona e melhora a própria forma de trabalhar com regularidade.
Todos os métodos abaixo atendem a esses critérios. O que muda é a ênfase.
Os principais tipos de metodologias ágeis
Scrum
Framework criado por Ken Schwaber e Jeff Sutherland e apresentado em 1995. Organiza o trabalho em Sprints de até um mês, com três responsabilidades (Product Owner, Scrum Master e Developers), cinco eventos e três artefatos. É definido pelo Guia do Scrum, um documento curto e gratuito.
Quando usar: produtos com incerteza alta, em que vale entregar algo a cada poucas semanas e ajustar o rumo com quem usa. Quando sofre: demanda que chega de forma imprevisível todos os dias, como suporte e operação. Para entender o framework por inteiro, veja o que é Scrum e como funciona.
Kanban
Pelo Kanban Guide, Kanban é uma estratégia para otimizar o fluxo de valor em um processo. As práticas centrais são definir e visualizar o fluxo de trabalho, gerenciar ativamente os itens em andamento (com limites de trabalho em progresso) e melhorar o fluxo continuamente. Não há Sprints nem papéis obrigatórios. Existe também o Kanban Method, de David J. Anderson, com ênfase em mudança evolutiva na organização.
Quando usar: trabalho contínuo com prioridades que mudam a qualquer momento, como suporte, manutenção, marketing operacional e áreas administrativas. Quando sofre: quando o time precisa de um ritmo de planejamento e revisão com o cliente e não o cria por conta própria.
XP (Extreme Programming)
Método criado por Kent Beck no fim dos anos 1990, com foco em excelência técnica no desenvolvimento de software. As práticas mais conhecidas são programação em par, desenvolvimento guiado por testes, integração contínua, refatoração e entregas pequenas e frequentes. As práticas e valores estão detalhados em o que é XP (Extreme Programming).
Quando usar: times de software com problemas de qualidade, retrabalho e medo de mexer no código. É comum combinar XP com Scrum: o Scrum organiza o trabalho, o XP cuida de como o código é feito. Quando sofre: fora do software, a maior parte das práticas não se aplica.
Lean Software Development
Adaptação dos princípios do sistema Toyota de produção ao desenvolvimento, sistematizada por Mary e Tom Poppendieck em livro de 2003. Os princípios incluem eliminar desperdício, entregar rápido, adiar decisões irreversíveis e otimizar o todo, e não as partes.
Quando usar: como lente para enxergar desperdícios (espera, retrabalho, trabalho parcialmente pronto) em qualquer processo. É menos um método com regras e mais um conjunto de princípios que inspira Kanban e outros.
DSDM
O Dynamic Systems Development Method surgiu no Reino Unido em 1994, criado por um consórcio de empresas, e hoje é mantido pelo Agile Business Consortium. É um dos métodos ágeis mais estruturados: tem fases de projeto, papéis definidos, timeboxes e a priorização MoSCoW (deve ter, deveria ter, poderia ter, não terá desta vez).
Quando usar: organizações que precisam de governança de projeto mais formal, com prazo e custo fixos e escopo variável. Quando sofre: times pequenos que não precisam de tanta estrutura.
Crystal
Família de métodos proposta por Alistair Cockburn, em que o nível de formalidade varia conforme o tamanho do time e a criticidade do sistema. A ênfase está em comunicação, entregas frequentes e reflexão do time sobre a própria forma de trabalhar.
Quando usar: como referência para calibrar quanto processo um time realmente precisa. Aparece menos como método formal do que Scrum e Kanban.
FDD (Feature-Driven Development)
Método orientado a funcionalidades, criado por Jeff De Luca com contribuições de Peter Coad no fim dos anos 1990. Começa com um modelo geral do domínio, monta uma lista de funcionalidades e planeja, projeta e constrói por funcionalidade, em ciclos curtos.
Quando usar: projetos de software maiores, com domínio de negócio complexo e equipes que preferem papéis técnicos bem definidos.
Frameworks de escala
Quando vários times trabalham no mesmo produto, surgem frameworks para coordená-los: SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum, de Craig Larman e Bas Vodde), Nexus (da Scrum.org) e Scrum@Scale (de Jeff Sutherland). Eles não substituem os métodos de time; organizam a integração entre times. O SAFe, um dos mais conhecidos, está explicado em SAFe: o que é o Scaled Agile Framework.
Tabela comparativa dos métodos ágeis
| Método | Ritmo de trabalho | Papéis definidos | Foco principal | Melhor encaixe |
|---|---|---|---|---|
| Scrum | Sprints de até um mês | Sim (PO, SM, Developers) | Entregar valor com inspeção e adaptação frequentes | Produtos com incerteza alta |
| Kanban | Fluxo contínuo | Não obrigatórios | Fluxo, limite de trabalho em progresso, previsibilidade | Demanda contínua e imprevisível |
| XP | Iterações curtas | Alguns (cliente, programadores, coach) | Qualidade técnica do software | Times de desenvolvimento |
| Lean | Não prescreve | Não | Eliminar desperdício | Qualquer processo, como princípio |
| DSDM | Timeboxes dentro de fases | Sim, vários | Governança com escopo variável | Projetos com prazo e custo fixos |
| Crystal | Entregas frequentes | Varia com o tamanho | Comunicação e calibragem do processo | Times que querem processo mínimo |
| FDD | Ciclos curtos por funcionalidade | Sim, técnicos | Construção orientada a funcionalidades | Software grande com domínio complexo |
| Frameworks de escala | Cadência comum entre times | Sim, adicionais | Coordenar muitos times | Vários times no mesmo produto |
Para uma comparação mais funda entre os três mais usados, com critérios de escolha, veja Kanban, Scrum e XP: comparação e como escolher.
Exemplos de metodologia ágil aplicada a projetos comuns
Os cenários abaixo são ilustrativos e mostram como a natureza do trabalho aponta para o método:
- Desenvolvimento de um aplicativo de agendamento para uma rede de clínicas: Scrum, com práticas de XP. Há muita incerteza sobre o que os pacientes vão usar, e entregas a cada duas semanas permitem testar com usuários reais.
- Central de atendimento de TI de uma prefeitura: Kanban. Os chamados chegam todos os dias, com prioridades diferentes. Limitar o trabalho em progresso e medir o tempo de ciclo traz previsibilidade sem forçar ciclos fixos.
- Campanha de lançamento de produto: Scrum ou Kanban, conforme o ritmo. Se há marcos de revisão com a diretoria, Sprints ajudam; se o fluxo de peças é contínuo, Kanban funciona melhor.
- Implantação de ERP com contrato de escopo fechado: abordagem híbrida, com fases preditivas para contrato e infraestrutura e ciclos ágeis para parametrização e testes com usuários.
- Banco com vinte times no mesmo sistema: Scrum ou Kanban nos times e um framework de escala para coordenar dependências e planejamento.
Como escolher a metodologia ágil do seu projeto
- Olhe para a chegada do trabalho. Demanda previsível que pode ser planejada em lotes favorece Scrum; demanda contínua e imprevisível favorece Kanban.
- Identifique o maior problema atual. Falta de foco e de retorno do cliente aponta para Scrum. Gargalos e filas apontam para Kanban. Defeitos e retrabalho técnico apontam para XP.
- Conte os times. Um time não precisa de framework de escala. Vários times no mesmo produto talvez precisem.
- Considere as restrições da organização. Contratos de escopo fechado, auditoria e governança formal podem pedir DSDM ou uma abordagem híbrida.
- Comece pelo mínimo e adapte. Escolha um método, aplique como ele é descrito por algumas iterações e só depois ajuste. Adaptar antes de entender costuma eliminar justamente o que faria diferença.
O que fazer agora
Descreva em três linhas como o trabalho chega ao seu time, qual o maior problema hoje e quantos times dependem uns dos outros. Com essas respostas e a tabela acima, a escolha fica bem mais estreita. Para ver como os métodos ágeis se encaixam com a gestão de projetos tradicional, o guia completo de métodos ágeis e Scrum dá o panorama. E, se o Scrum for o ponto de partida, o curso Agile Scrum Foundation da Projeto Diário ensina o framework e as práticas ágeis mais usadas, com preparação para a certificação.
