Manifesto ágil: os 4 valores e os 12 princípios explicados

O manifesto ágil é um texto curto, com quatro frases de valores e doze princípios, e talvez por isso seja tão citado e tão pouco lido. Muita gente conhece a versão resumida ("ágil não documenta, ágil não planeja") e nunca viu a frase que equilibra tudo, logo abaixo dos valores. O resultado são equipes que usam o manifesto para justificar exatamente o que ele não diz.

O documento se chama Manifesto para Desenvolvimento Ágil de Software e foi escrito por profissionais de software, para software. Mesmo assim, a maior parte do que ele propõe vale para qualquer trabalho em que o resultado não pode ser previsto por inteiro no início: lançar um produto, redesenhar um processo, criar um programa de treinamento.

Abaixo estão os quatro valores e os doze princípios, um por um, com o que significam na prática e as leituras erradas mais comuns.

De onde veio o manifesto

Em fevereiro de 2001, dezessete pessoas se reuniram numa estação de esqui em Snowbird, no estado americano de Utah. Elas representavam abordagens diferentes, então chamadas de métodos leves, que tinham surgido como reação a processos de desenvolvimento pesados e centrados em documentos: Extreme Programming, Scrum, DSDM, Crystal, Feature-Driven Development, entre outros.

Os signatários foram Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas. Não concordavam em tudo, mas encontraram valores comuns, e a palavra "ágil" foi a escolhida para nomeá-los. Pouco depois, parte do grupo fundou a Agile Alliance.

O texto completo, com tradução oficial para o português, está em agilemanifesto.org. Para ver como o manifesto se encaixa no conjunto dos métodos ágeis, comece pelo guia completo de métodos ágeis e Scrum.

Os 4 valores do manifesto ágil

A versão oficial em português diz que, por meio do trabalho, os autores passaram a valorizar:

E fecham com a frase que costuma ser esquecida: mesmo havendo valor nos itens à direita, valorizam mais os itens à esquerda. Os valores são escolhas para quando há conflito, não uma lista de coisas a abolir.

Indivíduos e interações mais que processos e ferramentas

Quando o processo atrapalha a conversa necessária, a conversa vence. Na prática: se duas pessoas resolvem em dez minutos de conversa o que levaria três dias de chamado entre áreas, converse. Leitura errada: "processo não importa". Processos e ferramentas continuam úteis, desde que sirvam às pessoas, e não o contrário.

Software em funcionamento mais que documentação abrangente

A melhor prova de progresso é algo que funciona e pode ser testado por quem vai usar. Na prática: mostrar uma tela funcionando ao usuário diz mais do que um documento de especificação de cinquenta páginas. Leitura errada: "não precisamos documentar". Documentação que ajuda a usar, manter ou auditar o produto continua necessária; o que perde prioridade é o documento produzido só para cumprir etapa.

Colaboração com o cliente mais que negociação de contratos

Cliente e equipe trabalham do mesmo lado, ajustando o caminho juntos. Na prática: em vez de discutir se um pedido está ou não no contrato, discute-se qual item vale mais e o que pode sair para dar espaço. Leitura errada: "não precisamos de contrato". O contrato existe e protege as partes; ele só não deve ser o único canal da relação.

Responder a mudanças mais que seguir um plano

Quando o mundo muda, o plano muda. Na prática: se a Sprint Review mostra que os usuários precisam de outra coisa, o backlog é reordenado. Leitura errada: "não planejamos". Os métodos ágeis planejam o tempo todo, em horizontes curtos; o que evitam é tratar o plano inicial como verdade.

Os 12 princípios explicados

Os princípios detalham como os valores aparecem no trabalho. Abaixo, cada um em paráfrase, seguido do que significa na prática.

1. Satisfazer o cliente com entregas cedo e contínuas de algo valioso. O cliente não espera o fim do projeto para receber valor. Se a primeira entrega útil está prevista para daqui a um ano, o projeto não está seguindo este princípio.
2. Aceitar mudanças nos requisitos, mesmo tarde. Mudança é vista como oportunidade de vantagem para o cliente. Isso exige que mudar seja barato, o que depende de entregas pequenas e qualidade técnica.
3. Entregar com frequência, de poucas semanas a poucos meses, preferindo o intervalo menor. Ciclos curtos reduzem o risco e aceleram o aprendizado. O limite de um mês para a Sprint no Scrum segue a mesma lógica.
4. Pessoas de negócio e desenvolvedores trabalham juntas diariamente. Requisitos não são entregues por escrito e esquecidos. Quem conhece o negócio está disponível durante todo o projeto.
5. Construir projetos em torno de pessoas motivadas, com ambiente, apoio e confiança. O papel da gestão é criar condições para o trabalho, não controlar cada tarefa.
6. Conversa face a face é o meio mais eficiente de transmitir informação. Escrito em 2001, o princípio costuma ser lido hoje como conversa direta e síncrona, o que inclui a videochamada para times distribuídos. O ponto é evitar que a comunicação dependa de documentos e intermediários.
7. Software funcionando é a principal medida de progresso. Percentual de documentação concluída não mede avanço; entrega utilizável mede.
8. Ritmo sustentável, que patrocinadores, desenvolvedores e usuários possam manter indefinidamente. Horas extras constantes são sinal de problema de planejamento, não de dedicação. Times exaustos erram mais e aprendem menos.
9. Atenção contínua à excelência técnica e ao bom design. Qualidade não é fase final; é o que permite mudar rápido sem quebrar o que já funciona.
10. Simplicidade: maximizar a quantidade de trabalho não realizado. Não construir o que ninguém vai usar é a forma mais barata de economizar. Cada funcionalidade a menos é uma a menos para manter.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizáveis. Quem faz o trabalho decide como fazê-lo. O Guia do Scrum 2020 leva a ideia adiante ao falar em times autogerenciáveis.
12. Em intervalos regulares, a equipe reflete sobre como ser mais eficaz e ajusta seu comportamento. É a origem das retrospectivas. Melhorar o próprio modo de trabalhar faz parte do trabalho.

Como ler o manifesto fora do software

Para aplicar em outras áreas, basta traduzir os termos de software para o seu contexto:

A lógica é a mesma: entregar algo que alguém usa, observar e ajustar. Os métodos que colocam essa lógica em prática em diferentes contextos estão no artigo sobre tipos de metodologias ágeis.

Leituras erradas mais comuns

• "Ágil é não ter documentação." O manifesto diz que há valor nela. Documente o que tem uso.
• "Ágil é não ter prazo." Os princípios falam em entregas frequentes com intervalos definidos. Prazos curtos e fixos são parte da disciplina ágil.
• "Ágil é fazer o que o cliente pedir a qualquer hora." Aceitar mudanças não significa interromper o trabalho em andamento a cada pedido. Os métodos ágeis criam momentos para incorporar mudanças sem perder o foco.
• "Ágil é uma metodologia." O manifesto não descreve papéis, eventos nem artefatos. Ele declara valores que métodos como Scrum, Kanban e XP aplicam de formas diferentes.
• "Ágil é coisa de TI." Nasceu no software, mas os valores tratam de incerteza, colaboração e aprendizado, que existem em qualquer área.

Manifesto ágil, Scrum e outros métodos

O manifesto é a camada de valores. Os métodos são a camada de prática. O Scrum, por exemplo, transforma o princípio 3 em Sprints de até um mês, o princípio 12 em Sprint Retrospective e o princípio 4 na colaboração constante entre Product Owner e Developers. Dois dos signatários, Ken Schwaber e Jeff Sutherland, são os autores do Guia do Scrum. A descrição completa do framework está no artigo sobre o que é Scrum.

O Extreme Programming, de Kent Beck, é o método que mais traduziu o princípio 9 em práticas concretas, como programação em par, testes automatizados e integração contínua, descritas no artigo sobre o que é XP.

Use o manifesto como diagnóstico

Os quatro valores rendem uma boa conversa de retrospectiva ou de início de projeto. Pergunte ao time e às partes interessadas:

1. Que processo ou ferramenta está atrapalhando uma conversa que deveria acontecer?
2. Quando foi a última vez que alguém de fora do time usou algo que entregamos?
3. Estamos discutindo mais o contrato ou o valor do que estamos entregando?
4. O que mudou no último mês e o nosso plano ainda não reflete?

Se as respostas incomodarem, você encontrou o ponto em que o projeto está menos ágil do que parece. Para comparar com a lógica preditiva e decidir onde cada uma se aplica, veja as diferenças entre gestão ágil e tradicional.

O próximo passo

Leia o manifesto original, que leva poucos minutos, e escolha um único princípio que o seu projeto mais desrespeita hoje. Leve-o para a próxima reunião do time com uma proposta de mudança concreta para o próximo ciclo. Se quiser ver como os valores viram prática num framework completo, o curso Agile Scrum Foundation da Projeto Diário ensina papéis, eventos, artefatos e práticas ágeis em vídeo, no seu ritmo, e prepara para o exame ASF.