17 líderes de software se reuniram e mudaram para sempre o desenvolvimento de software.
4Valores
12Princípios
17Signatários
2001Publicado
JT
Professor
José Themoteo
Gestão Ágil de Projetos de Software
Snowbird, Utah — Fevereiro 2001
Manifesto Ágil
17 líderes de software se reuniram e mudaram para sempre o desenvolvimento de software. Explore os valores, princípios e as pessoas por trás dessa revolução.
4Valores
12Princípios
17Signatários
2001Publicado
Os 4 valores centrais
O Manifesto define quatro valores. O lado esquerdo é mais valorizado — mas o lado direito ainda tem valor. Clique para expandir.
Indivíduos e interaçõesmais que
processos e ferramentas
Pessoas motivadas e a comunicação direta entre elas superam qualquer ferramenta sofisticada. Times auto-organizados entregam mais valor quando confiam uns nos outros.
Software funcionandomais que
documentação abrangente
A principal medida de progresso é software que funciona nas mãos do cliente. Documentação tem valor, mas não substitui a entrega real de valor.
Colaboração com o clientemais que
negociação de contratos
Envolver o cliente continuamente ao longo do desenvolvimento gera produtos mais alinhados às necessidades reais do que contratos rígidos negociados no início.
Responder a mudançasmais que
seguir um plano
Times ágeis abraçam a mudança como vantagem competitiva. Adaptar-se a novos requisitos, mesmo tarde no desenvolvimento, é preferível a seguir um plano desatualizado.
"Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda." — Manifesto Ágil
Exemplos práticos
Valor 1 de 4
Indivíduos e interações
mais que processos e ferramentas
Cenário do dia a dia
Bug crítico em produção às 18h
›
Sem o valor
O dev abre um ticket no Jira, preenche 8 campos, aguarda triagem, agenda reunião para o dia seguinte. O bug fica ativo por 14 horas.
Com o valor
Ana manda mensagem direta para Pedro: "vi o bug, consigo corrigir em 20 min, você pode revisar agora?" Bug resolvido em 40 minutos. Ticket aberto depois como registro.
A ferramenta não desaparece — ela é o registro. Mas a resolução veio da conversa direta. O processo serviu às pessoas, não as controlou.
Integração de novo membro
Novo desenvolvedor integrado ao time
›
Sem o valor
Novo dev recebe PDF de 60 páginas. Segue os passos sozinho por duas semanas. Produz seu primeiro PR no dia 15.
Com o valor
Novo dev senta ao lado de uma dev sênior no primeiro dia. Em 3 horas fez pair programming e enviou o primeiro commit para produção.
Interação direta transfere contexto que nenhum documento captura completamente. A mentoria acelerou meses de aprendizado.
1 / 4
Valor 2 de 4
Software funcionando
mais que documentação abrangente
Cenário de entrega
Sistema de pagamentos para e-commerce
›
Sem o valor
Após 6 meses, o time entrega um documento de 200 páginas. O cliente ainda não viu nada rodando.
Com o valor
Após 2 semanas, o cliente faz um pagamento real com cartão. Nas seguintes: boleto, parcelamento, reembolso. Cada entrega é utilizável.
Software funcionando revela problemas que documentação não revela. O cliente percebe na segunda semana que precisava de Pix — impossível de antecipar num doc escrito 6 meses antes.
Decisão de negócio
Demo para investidores no prazo
›
Sem o valor
Time tenta terminar todas as 47 features antes de mostrar algo. Demo adiada três vezes. Investidores perdem confiança.
Com o valor
Com 4 features funcionando perfeitamente, o time faz a demo. Investidores usam o produto ao vivo e redefinem as prioridades seguintes.
Documentação descreve intenções. Software funcionando prova capacidade. Para um investidor, a diferença entre os dois vale milhões.
2 / 4
Valor 3 de 4
Colaboração com o cliente
mais que negociação de contratos
Cenário clássico
App de gestão de estoque para varejo
›
Sem o valor
Contrato com 120 requisitos congelados. Cliente só vê o sistema 8 meses depois. A empresa foi adquirida no meio do projeto e as necessidades mudaram.
Com o valor
O gerente participa da review a cada duas semanas e sugere: "preciso ver o histórico por fornecedor, não por produto". O time ajusta na sprint seguinte.
O contrato protege juridicamente, mas não produz software útil sozinho. A colaboração contínua garante que o software ainda vai resolver o problema certo.
Mudança de escopo
Feature pronta que o cliente não queria
›
Sem o valor
Time passa 3 semanas construindo relatórios em PDF. Na entrega: "nosso time usa Excel, PDF nunca vai funcionar". 3 semanas desperdiçadas.
Com o valor
Antes de começar, o PO conversa: "como você vai usar isso?" Resposta: "exportar pro Excel". Time constrói integração direta. 3 dias, uso imediato.
O contrato dizia "módulo de relatórios". Só a colaboração revelou o que "relatórios" significava na prática para aquele cliente.
3 / 4
Valor 4 de 4
Responder a mudanças
mais que seguir um plano
Cenário de mercado
Startup lançando app de finanças pessoais
›
Sem o valor
Plano: 12 meses, lançamento em dezembro. Em junho o Nubank lança feature idêntica. O time segue o plano. Em dezembro, o produto nasce obsoleto.
Com o valor
Em junho, o time pivota em 2 semanas para autônomos e MEIs. Lançamento em setembro com posicionamento claro e nicho ignorado pelos bancos.
O plano de janeiro foi essencial para começar. Mas abandoná-lo em junho foi o que determinou o sucesso. O plano era uma hipótese, não uma obrigação.
Contexto técnico
Arquitetura que precisa mudar no meio do projeto
›
Sem o valor
Plano previa banco relacional. Na sprint 6 o time percebe que o volume exige outra abordagem. Gerente: "está no plano, vamos seguir". Sistema entra lento e caro.
Com o valor
O time apresenta a evidência na retrospectiva. Em consenso, migram o núcleo. Duas semanas de retrabalho evitam 2 anos de débito técnico crescente.
Seguir um plano técnico desatualizado é dívida técnica com juros. Responder à evidência real — mesmo quando dói — separa produtos sustentáveis dos que somem em dois anos.
4 / 4
Os 12 princípios
Os princípios guiam como equipes ágeis trabalham na prática. Eles derivam dos 4 valores e detalham comportamentos concretos.
Os 17 signatários
Em fevereiro de 2001, 17 profissionais se reuniram em Snowbird, Utah. Clique em um autor para saber mais.
Linha do tempo
Anos 1970–90
A era do modelo cascata
O desenvolvimento de software seguia modelos sequenciais rígidos. Requisitos eram congelados no início, projetos demoravam anos e frequentemente entregavam software desatualizado ou irrelevante.
Anos 1990
Métodos leves emergem
Surgem alternativas: Scrum (Schwaber & Sutherland, 1995), XP – Extreme Programming (Kent Beck, 1996), Crystal (Alistair Cockburn), DSDM e Feature Driven Development. Cada um rejeita o planejamento excessivo em favor de iterações curtas.
Fevereiro 2001
A reunião de Snowbird
17 líderes de diferentes metodologias se reúnem no Ski Bird Lodge, em Snowbird, Utah. Em três dias de discussão, convergem em valores e princípios comuns, produzindo o Manifesto para o Desenvolvimento Ágil de Software.
Março 2001
Publicação do Manifesto
O documento é publicado em agilemanifesto.org. A palavra "Ágil" é adotada como termo guarda-chuva para todos os métodos leves, batendo "Adaptativo", "Flexível" e outros termos considerados.
2001–2010
Adoção em escala
Scrum e XP se tornam dominantes. A Agile Alliance é fundada. Surgem certificações, conferências e uma comunidade global de praticantes. O Scrum Guide é publicado em 2010.
2010–hoje
Ágil além do software
Os princípios ágeis se expandem para marketing, RH, finanças e gestão em geral. Surgem frameworks de escala como SAFe, LeSS e Nexus. O Manifesto completa mais de duas décadas como referência fundacional do setor.