Português

Manifesto Agile: Os 4 Valores e os 12 Princípios Explicados

Visão geral dos 4 valores e 12 princípios do Manifesto Agile

O Manifesto Agile é um dos documentos mais lidos da história do software, e tem apenas 68 palavras. Dezessete profissionais o escreveram em fevereiro de 2001 em uma estação de esqui em Snowbird, Utah, frustrados com anos de processos pesados que geravam softwares entregues com atraso e que ninguém queria.

Mas a influência do documento foi muito além do software. Hoje, equipes de marketing rodam Sprints. Departamentos de RH realizam retrospectivas. Equipes de operações usam boards Kanban. Os quatro valores e os doze princípios do Manifesto Agile são a base de tudo isso.

Este guia detalha exatamente o que esses valores e princípios dizem, o que significam na prática e como você pode aplicá-los em qualquer equipe.

O que é o Manifesto Agile?

O Manifesto Agile é um documento fundador escrito em fevereiro de 2001 por 17 profissionais de software na estação de esqui de Snowbird, Utah. Ele define quatro valores centrais e doze princípios que priorizam pessoas, resultados concretos e adaptabilidade em detrimento de processos rígidos e planejamento excessivo antecipado.

Os 17 signatários incluíam algumas das figuras mais influentes da engenharia de software: Kent Beck (criador do Extreme Programming), Jeff Sutherland e Ken Schwaber (cocriadores do Scrum), Martin Fowler, Jim Highsmith, Alistair Cockburn e outros onze. A frustração era compartilhada: processos pesados e orientados a planos produziam softwares entregues com atraso, acima do orçamento e já desatualizados no dia do lançamento.

O documento é publicado em agilemanifesto.org e nunca foi revisado. Permanece exatamente como foi escrito em 2001.

Dados relevantes

  • O Manifesto Agile foi publicado em fevereiro de 2001 em agilemanifesto.org, assinado por 17 profissionais de software. Seus quatro valores totalizam 68 palavras, inalteradas desde a publicação.
  • O 18th Annual State of Agile Report (Digital.ai, 2024) constatou que 71% das organizações adotam abordagens ágeis, ante 37% em 2011.
  • Uma análise do Standish Group CHAOS Report verificou que projetos ágeis têm taxas de sucesso significativamente maiores do que os de Waterfall: 42% de sucesso contra 13% para Waterfall ao controlar o tamanho do projeto (edição de 2020).

Compreender o Manifesto também é contexto essencial para a metodologia Agile como um todo, uma vez que todos os principais frameworks (Scrum, Kanban, XP) têm sua origem neste documento.

Os 4 Valores do Manifesto Agile

Os quatro valores do Manifesto Agile

O Manifesto declara com clareza: "Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Por meio desse trabalho, passamos a valorizar..."

Em seguida, lista quatro pares de valores. Cada um é escrito como "X em vez de Y." A clareza que se segue é igualmente importante: "Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda."

Essa nuance importa. O Manifesto não diz que contratos não têm valor. Diz que a colaboração com o cliente importa mais. Não diz que documentação é inútil. Diz que software funcionando tem prioridade.

Valor O que prioriza O que não rejeita
Indivíduos e interações acima de processos e ferramentas Comunicação direta, julgamento humano, relacionamentos entre equipes Processos e ferramentas (são importantes, mas não o ponto central)
Software funcionando acima de documentação abrangente Entregar algo funcional com o qual os usuários possam interagir Documentação (ainda deve ser escrita, apenas não pode substituir a entrega)
Colaboração com o cliente acima de negociação de contratos Diálogo contínuo com quem usa o produto Contratos (são necessários, mas não são a bússola principal)
Responder a mudanças acima de seguir um plano Ajustar-se com base no aprendizado ao longo da entrega Planos (comece com um, apenas não o trate como dogma)

Valor 1: Indivíduos e interações acima de processos e ferramentas

Uma reunião de standup em que as pessoas genuinamente apontam impedimentos vale mais do que uma ferramenta de acompanhamento de projetos impecavelmente mantida que ninguém lê. Este valor é um lembrete de que processo é meio, não fim.

Na prática: se sua equipe gasta mais tempo atualizando o sistema do que conversando sobre o trabalho em si, algo está invertido.

Valor 2: Software funcionando acima de documentação abrangente

Este é o valor mais mal interpretado. Equipes às vezes o leem como "não escreva documentação." Não é isso que ele diz. Ele afirma que um produto funcionando nas mãos do usuário gera mais aprendizado do que um documento de especificação. Um protótipo entregue na segunda semana diz mais do que um documento de requisitos de 40 páginas escrito no primeiro mês.

Valor 3: Colaboração com o cliente acima de negociação de contratos

Contratos definem o que foi acordado no início. Clientes descobrem o que realmente precisam depois de ver as primeiras iterações. Colaboração regular, demos e ciclos de Feedback permitem que o produto evolua em direção ao que o cliente de fato quer, não apenas ao que foi escrito no briefing original.

Valor 4: Responder a mudanças acima de seguir um plano

Mercados mudam. Concorrentes lançam produtos. O Feedback dos usuários surpreende. Um plano escrito antes do início do trabalho reflete suposições, não a realidade. Equipes ágeis atualizam o plano conforme aprendem. O planejamento do Sprint é onde este valor se operacionaliza: as equipes planejam um Sprint de cada vez, não seis meses de uma só vez.

Os 12 Princípios do Agile

Os 12 princípios do Agile

Os doze princípios expandem cada valor em orientações práticas. Foram escritos junto com os quatro valores e publicados como página complementar em agilemanifesto.org/principles.html.

# Princípio Significado em linguagem simples
1 Satisfazer o cliente por meio da entrega contínua e antecipada de software com valor. Entregue algo útil cedo. Não espere até que tudo esteja perfeito.
2 Aceitar mudanças de requisitos, mesmo no final do desenvolvimento. Mudança tardia não é falha. É informação. Construa processos que consigam absorvê-la.
3 Entregar software funcionando com frequência, de algumas semanas a alguns meses, com preferência pelos intervalos mais curtos. Ciclos curtos superam ciclos longos. Quanto mais frequentemente você entrega, mais rápido aprende.
4 Pessoas de negócio e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto. Quem entende o domínio e quem constrói o produto não devem operar em silos.
5 Construir projetos em torno de indivíduos motivados. Dar a eles o ambiente e o suporte necessários e confiar que farão o trabalho. Autonomia e confiança geram resultados melhores do que vigilância e microgerenciamento.
6 O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa face a face. Conversa direta supera cadeias de documentação. (Videochamadas contam.)
7 Software funcionando é a medida primária de progresso. Pontos de Velocity, tickets fechados e funcionalidades iniciadas são aproximações. A única medida real é algo que funcione.
8 Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Horas extras intensas não são estratégia. Equipes que correm a todo vapor por meses esgotam-se e produzem trabalho com falhas.
9 Atenção contínua à excelência técnica e ao bom design aumenta a agilidade. Código ruim deixa você mais lento com o tempo. Cortar atalhos para ir mais rápido agora torna você mais lento depois.
10 Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial. Faça menos. A melhor funcionalidade é aquela que você não precisa construir. A melhor etapa de processo é aquela que pode ser eliminada.
11 As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizadas. Mandatos de cima para baixo produzem conformidade. Equipes auto-organizadas produzem propriedade e criatividade.
12 Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ajusta seu comportamento de acordo. Retrospectivas de Sprint não são opcionais. A melhoria contínua está integrada ao ritmo do trabalho.

Três princípios são mais relevantes para equipes que não trabalham com software: o Princípio 2 (aceitar mudanças tardias), o Princípio 10 (maximizar o trabalho não realizado) e o Princípio 12 (retrospectivas regulares). Eles se aplicam igualmente a campanhas de marketing, processos de RH e fluxos de operações.

Por que o Manifesto Agile ainda importa

O Manifesto foi escrito em resposta a um problema específico: projetos de software que falhavam porque tentavam prever e especificar tudo com antecedência. Esse problema não desapareceu. Se algo, piorou.

Eis por que a relevância do Manifesto cresceu:

O trabalho é mais complexo. Os problemas que as equipes enfrentam em 2026 (integração de IA, trabalho distribuído, lançamentos em múltiplos mercados) são mais difíceis de especificar com antecedência do que os projetos de software corporativo de 2001. A entrega iterativa e os ciclos rápidos de aprendizado são ainda mais importantes.

Os ciclos de Feedback são mais rápidos e baratos. Em 2001, entregar algo significava lançamentos físicos ou implantações noturnas. Hoje, uma equipe pode lançar uma funcionalidade para 10% dos usuários em minutos e medir os resultados em horas. A aposta do Manifesto no Feedback rápido é ainda mais recompensada.

O Agile foi além do software. Equipes de marketing, RH, finanças e operações rodam Sprints. Os 12 princípios são independentes de domínio. O Princípio 8 (ritmo sustentável) se aplica a qualquer equipe. O Princípio 10 (maximizar o trabalho não realizado) se aplica a qualquer processo. O Princípio 12 (retrospectivas regulares) se aplica a qualquer grupo que busca melhorar.

A decisão entre Agile e Waterfall ainda é a escolha estratégica mais comum que as equipes enfrentam ao iniciar uma nova iniciativa, e o Manifesto é a articulação mais clara do que torna o Agile diferente.

Equívocos comuns sobre o Agile

O Manifesto é frequentemente mal interpretado. Estes são os erros mais comuns e o que o documento realmente diz.

Equívoco 1: "Agile significa sem planejamento."

Não significa. O Manifesto diz "responder a mudanças em vez de seguir um plano", não "nunca planeje". Todo Sprint começa com planejamento de Sprint. Todo trimestre começa com definição de metas. A diferença é que os planos ágeis são atualizados à medida que novas informações chegam, em vez de seguidos rigidamente independentemente do que você aprende.

Equívoco 2: "Agile significa sem documentação."

O Manifesto valoriza software funcionando em detrimento de documentação abrangente. "Abrangente" é a palavra-chave. Escreva documentação que seja útil. Não escreva documentação como substituto para entregar algo.

Equívoco 3: "Agile é apenas para equipes de software."

O Manifesto foi escrito por profissionais de software, mas os valores não são específicos de software. O Princípio 1 (entrega antecipada de valor), o Princípio 2 (aceitar mudanças) e o Princípio 12 (retrospectivas regulares) se aplicam a qualquer equipe que realiza trabalho complexo.

Equívoco 4: "Agile significa sem prazos."

Equipes ágeis têm prazos. Revisões de Sprint acontecem em datas fixas. Lançamentos de produtos têm janelas de lançamento. A diferença é que as equipes ágeis negociam o escopo para cumprir o prazo, em vez de negociar o prazo para se adequar ao escopo.

Equívoco 5: "Scrum é Agile."

O Scrum é uma implementação dos valores ágeis. O Kanban também. O Extreme Programming também. Agile é a filosofia; Scrum é uma receita que a segue. Você pode ser ágil sem usar Scrum. Você pode executar cerimônias Scrum sem ser genuinamente ágil (isso se chama "cargo-cult agile" e é mais comum do que a maioria das organizações gostaria de admitir).

Como aplicar o Manifesto Agile na sua equipe

Você não precisa adotar um framework formal para começar a aplicar os valores ágeis. Veja como passar dos princípios do Manifesto para a prática real.

Passo 1: Identifique os "desperdícios" atuais

Observe onde sua equipe gasta tempo em atividades que não produzem valor diretamente. Cadeias longas de aprovação, relatórios de status que ninguém lê, reuniões que poderiam ser uma mensagem. O Princípio 10 (maximizar o trabalho não realizado) começa aqui.

Passo 2: Encurte o ciclo de entrega

Qual é a menor coisa que sua equipe poderia entregar com a qual um usuário real pudesse interagir? Se seu ciclo atual é trimestral, mire no mensal. Se é mensal, mire na quinzena. Gráficos de Burndown podem ajudar a visualizar se o trabalho entregue a cada ciclo está de fato sendo concluído.

Passo 3: Traga o cliente para a conversa mais cedo

O "cliente" pode ser um cliente externo, uma parte interessada interna ou um usuário final. Seja quem for, encontre uma forma de mostrar o trabalho em andamento em vez do trabalho finalizado. Feedback antecipado é barato. Feedback tardio é caro.

Passo 4: Inicie o hábito de retrospectivas

Reserve 30 a 60 minutos ao final de cada ciclo de trabalho para fazer três perguntas: O que foi bem? O que não foi? O que vamos mudar? O Princípio 12 é o retorno composto do Agile. Equipes que realizam retrospectivas consistentemente melhoram mais rápido do que as que não realizam. A versão formal é a retrospectiva de Sprint, mas até um documento compartilhado simples pode ser o ponto de partida.

Passo 5: Experimente com limites de WIP

Escolha uma etapa do seu fluxo de trabalho (Em Andamento, Em Revisão ou semelhante) e limite quantos itens podem permanecer ali de uma vez. Tanto Scrum quanto Kanban concordam em uma coisa: concluir trabalho em andamento supera iniciar trabalho novo. Limites de WIP forçam esse comportamento.

Passo 6: Dê mais autonomia à sua equipe

O Princípio 11 diz que os melhores resultados vêm de equipes auto-organizadas. Isso significa que as pessoas que fazem o trabalho devem ter voz sobre como ele é feito. Comece com algo pequeno: deixe a equipe escolher como conduzir seus standups, ou permita que estimem sua própria capacidade a cada Sprint em vez de ter um gestor definindo metas.

Exemplos do Manifesto Agile por função e área

Os quatro valores se traduzem de forma diferente dependendo de quem está realizando o trabalho.

Função Valor em ação Exemplo prático
Engenharia Software funcionando em vez de documentação Entregue um protótipo funcional para usuários beta na segunda semana em vez de escrever uma especificação de 30 páginas para um ciclo de revisão de um mês.
Marketing Responder a mudanças em vez de seguir um plano Lance uma campanha em Sprints de duas semanas. Se o primeiro conjunto de anúncios tiver desempenho inferior, ajuste a mensagem antes de gastar todo o orçamento.
Produto Colaboração com o cliente em vez de negociação de contratos Realize entrevistas com usuários quinzenalmente ao longo do desenvolvimento em vez de fazer uma única rodada de levantamento de requisitos no início.
RH / People Ops Indivíduos e interações em vez de processos e ferramentas Use conversas individuais e Feedback direto para identificar problemas de desempenho com antecedência em vez de depender exclusivamente do sistema de avaliação anual.
Operações Responder a mudanças em vez de seguir um plano Mantenha um board de priorização MoSCoW para as demandas recebidas, de forma que problemas urgentes sejam resolvidos sem comprometer o trabalho planejado.
Design Colaboração com o cliente em vez de negociação de contratos Compartilhe wireframes de baixa fidelidade com usuários finais a cada Sprint. Use as reações deles para revisar antes de se comprometer com uma construção completa.

Histórias de usuário são uma das ferramentas mais práticas para fazer a ponte entre as necessidades do cliente e os itens de trabalho da equipe. São o artefato ágil que torna o Valor 3 (colaboração com o cliente) tangível.

Perguntas frequentes

Quem escreveu o Manifesto Agile?

O Manifesto Agile foi escrito por 17 profissionais de software que se reuniram na estação de esqui de Snowbird, Utah, em fevereiro de 2001. O grupo incluiu Kent Beck, Jeff Sutherland, Ken Schwaber, Martin Fowler, Jim Highsmith, Alistair Cockburn, Ward Cunningham e outros nove. Eles assinaram o documento coletivamente como autores, embora o termo "agile" tenha sido proposto durante a própria reunião.

Quando o Manifesto Agile foi publicado?

O Manifesto Agile foi publicado em fevereiro de 2001, especificamente entre 11 e 13 de fevereiro de 2001, durante um retiro de três dias na estação de Snowbird, Utah. O documento foi publicado online em agilemanifesto.org e não foi revisado desde então.

Quais são os 4 valores do Manifesto Agile?

Os quatro valores são: (1) Indivíduos e interações acima de processos e ferramentas, (2) Software funcionando acima de documentação abrangente, (3) Colaboração com o cliente acima de negociação de contratos, e (4) Responder a mudanças acima de seguir um plano. Cada par de valores significa que o lado esquerdo tem prioridade, mas o lado direito ainda tem valor.

Qual é a diferença entre os 4 valores e os 12 princípios?

Os 4 valores são a base filosófica: definem o que as equipes ágeis priorizam. Os 12 princípios são a expansão operacional: explicam como agir com base nesses valores na prática. Por exemplo, o Valor 4 diz "responda a mudanças." O Princípio 2 diz "aceite mudanças de requisitos, mesmo no final do desenvolvimento." O Princípio 3 diz "entregue software funcionando com frequência." Ambos apoiam o mesmo valor, mas em diferentes níveis de especificidade.

O Manifesto Agile ainda é relevante em 2026?

Sim. Os quatro valores foram escritos como reação a processos excessivamente especificados e orientados a planos. Em 2026, essas mesmas dinâmicas aparecem no desenvolvimento assistido por IA, em grandes transformações digitais e em equipes distribuídas. O Manifesto não descreve ferramentas ou tecnologias. Descreve prioridades. E essas prioridades, favorecendo pessoas em vez de processos, resultados funcionando em vez de documentação e aprendizado em vez de previsão, são tão aplicáveis hoje quanto eram em 2001. O 18th Annual State of Agile Report (Digital.ai, 2024) constatou que 71% das organizações agora reportam usar abordagens ágeis.

O Manifesto Agile não é um artefato histórico. É uma lente para tomada de decisão. Sempre que sua equipe enfrenta uma escolha entre finalizar a documentação e entregar o protótipo, entre seguir o plano original e ajustar com base em novos dados, entre um processo e uma conversa, o Manifesto indica qual direção seguir. Essa orientação não tem prazo de validade.