Métodos ágeis: o que são, frameworks e como aplicar

O Manifesto Ágil tem quatro valores que quase todo mundo já viu, e uma frase final que quase ninguém cita. Depois de listar os quatro pares, o documento fecha assim: “ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Essa frase é a diferença entre adotar métodos ágeis e usá-los como desculpa. Ela diz que documentação, contrato, processo e plano continuam valendo. Sem ela, “somos ágeis” virou justificativa para não escrever nada, não combinar escopo e não ter plano.

O que são métodos ágeis

Métodos ágeis são abordagens de trabalho que entregam valor em ciclos curtos, com retorno frequente de quem usa o resultado, e que tratam mudança de requisito como informação nova em vez de falha de planejamento.

A origem tem data e lugar: em fevereiro de 2001, dezessete profissionais de desenvolvimento de software se reuniram em Snowbird, no estado americano de Utah, e escreveram o Manifesto Ágil, com quatro valores e doze princípios.

Repare que a coluna da direita existe. O Manifesto não é uma lista de coisas ruins, é uma ordem de prioridade quando as duas entram em conflito.

Ágil não é metodologia: a confusão que atrapalha

Uma imprecisão de vocabulário causa boa parte dos problemas de adoção. “Metodologia ágil”, no singular, sugere um manual com passos. Não existe esse manual.

A confusão fica caríssima quando a empresa importa as práticas sem os valores. Copiar a reunião diária é fácil; distribuir autoridade de decisão é o que dá trabalho. É essa a parte que faz diferença, e ela depende de um ambiente em que discordar seja possível, condição tratada em cultura de inovação.

Os principais frameworks

Scrum é o mais adotado e o mais mal aplicado. Ele organiza o trabalho em ciclos de duração fixa, com três papéis, uma lista priorizada e cerimônias específicas. Detalhamos o funcionamento, com exemplos práticos, em Scrum: o que é e como aplicar no seu projeto.

Kanban costuma ser subestimado porque parece simples: um quadro com colunas. O que faz ele funcionar não é o quadro, é o limite de trabalho em andamento. Sem esse limite, o quadro só torna visível o excesso de coisas começadas e nenhuma terminada.

XP é o framework que a maioria ignora, e é o que resolve o problema mais comum de time técnico: código difícil de mudar. Práticas como desenvolvimento guiado por testes, programação em par e integração contínua são o que permite entregar em ciclo curto sem acumular dívida. Sem elas, o ciclo curto só acelera a produção de problema.

Scrum ou Kanban: como escolher

É a dúvida prática mais frequente, e a resposta depende do formato da demanda, não da preferência do time.

Time de sustentação, suporte e operação normalmente vai melhor com Kanban. Time de produto, com Scrum. E boa parte dos times reais opera um híbrido, o que é legítimo desde que os limites sejam explícitos.

Ágil ou cascata: quando cada um serve

Ágil não é sempre a resposta, e dizer o contrário é o que faz gestor experiente desconfiar do assunto.

Métodos ágeis servem quando o requisito é descoberto durante o trabalho. Se você não sabe exatamente o que precisa ser construído, planejar doze meses em detalhe é planejar em cima de suposição, e é a razão pela qual escopo fechado no início costuma estourar. O raciocínio de dimensionar pelo aprendizado está em como definir o escopo do primeiro produto digital e em MVP não é site barato.

Planejamento sequencial serve quando o requisito é conhecido, estável e a ordem de execução é imposta por algo físico ou regulatório. Obra civil, certificação e integração com prazo legal têm etapa que não se antecipa por vontade. Nesses casos, iterar sobre o que já está determinado só adiciona cerimônia.

O erro caro não é escolher um dos dois. É usar o vocabulário de um com a estrutura de decisão do outro: contrato de escopo fechado, prazo fixo e preço fechado, executado em ciclos chamados de sprint. Isso não é ágil, é cascata em ciclos. Vale ver as etapas reais de um projeto em desenvolvimento de software e a faixa de investimento em quanto custa desenvolver um produto digital.

Por que a adoção falha: o ágil de fachada

Cinco sinais de que a empresa adotou as cerimônias e não os valores.

1. A reunião diária é relatório para o gestor. Cada um informa o que fez, ninguém pede ajuda, e a reunião existe para controle e não para desbloquear trabalho.
2. Sprint virou prazo. O ciclo deixou de ser uma janela de trabalho protegida e passou a ser uma data de entrega negociada com o cliente, com escopo cheio e sem folga.
3. Velocidade virou meta. Quando o número de pontos entregues é cobrado como produtividade, o time infla estimativa. A medida deixa de medir.
4. Retrospectiva sem consequência. Os mesmos problemas aparecem em todas as retrospectivas porque nenhuma ação sai com dono e prazo. Quando o padrão se repete, o método dos 5 porquês é o caminho mais curto até a causa.
5. Autonomia só no nome. O time decide como fazer, mas o que fazer, quando entregar e com quem falar continua vindo de cima. Sem autoridade sobre priorização, a agilidade para na porta do time.

Os cinco têm a mesma raiz: a empresa mudou o processo e não mudou onde as decisões são tomadas. É o mesmo padrão de transformação digital que troca ferramenta e mantém o modelo mental.

Como começar sem virar teatro

1. Comece por um time e um problema real. Adoção simultânea em toda a empresa produz vocabulário novo e comportamento antigo.
2. Encurte o ciclo antes de mudar o nome de qualquer coisa. Se hoje a entrega leva três meses, leve para três semanas. A prática vem depois da frequência.
3. Limite o trabalho em andamento. É a intervenção mais barata e a de maior efeito imediato, e não precisa de framework nenhum para começar.
4. Ponha quem usa o resultado na revisão. Ciclo curto sem retorno de usuário é só entrega fracionada. A lição de testar cedo e várias vezes está na Marshmallow Challenge, e a de ir a campo antes de decidir, no projeto de design thinking na Bayer.
5. Mova uma decisão de nível. Escolha uma decisão que hoje sobe para aprovação e deixe o time tomá-la. Sem isso, os quatro passos anteriores são cosméticos.

Vale o registro do porquê estratégico: a capacidade de entregar e corrigir rápido é o que permite atacar uma frente que o concorrente estabelecido não consegue testar sem arriscar o negócio principal, mecanismo descrito em inovação disruptiva. Estrutura que cresce sem somar custo proporcional é o que caracteriza as organizações exponenciais. E a disposição de proteger tempo para experimento que pode falhar depende de não tratar recurso como bolo fixo, tema de mentalidade de escassez.

Conversamos sobre esse assunto com a ACIC, a Associação Comercial e Industrial de Campinas, no vídeo abaixo, com foco em como negócios tradicionais podem aplicar métodos ágeis para destravar crescimento.

Se a conclusão for que o gargalo está na estrutura de decisão, e não no método do time, os critérios para trazer olhar externo estão em o que é consultoria de tecnologia e quando contratar.

Perguntas frequentes