O Manifesto Ágil em 4 valores e 12 princípios: o guia definitivo
Entenda de uma vez o coração da agilidade. Os 4 valores e 12 princípios traduzidos para o dia a dia de quem entrega software.
Em fevereiro de 2001, 17 profissionais de software se reuniram em Utah para escrever um documento de 68 palavras que mudaria a indústria. O Manifesto Ágil não criou Scrum, Kanban nem XP. Criou um critério para julgar todos eles.
Mais de duas décadas depois, ele continua sendo lido errado. Empresas dizem 'somos ágeis' porque rodam daily, mas continuam decidindo escopo em planilha congelada de seis meses. Este post resgata o que realmente está escrito ali e como traduzir para a rotina do time.
Os 4 valores: o que vale mais quando você tem que escolher
O manifesto não diz que processos não importam. Diz que indivíduos e interações importam MAIS. Os 4 valores são tradeoffs, não absolutos.
- Indivíduos e interações mais que processos e ferramentas.
- Software em funcionamento mais que documentação abrangente.
- Colaboração com o cliente mais que negociação de contratos.
- Responder a mudanças mais que seguir um plano.
Os 12 princípios: como o manifesto vira prática
Os princípios traduzem os valores em comportamento observável. Vamos agrupar para facilitar.
Sobre entrega: satisfaça o cliente com entregas contínuas e frequentes; mude requisitos mesmo tarde no projeto; entregue software funcionando em semanas, não meses; software funcionando é a principal métrica de progresso.
Sobre pessoas: pessoas de negócio e desenvolvedores trabalham juntos diariamente; construa projetos em torno de indivíduos motivados; conversa cara a cara é a forma mais eficiente; processos ágeis promovem ritmo sustentável.
Sobre técnica e melhoria: excelência técnica e bom design aumentam agilidade; simplicidade (maximizar trabalho não feito) é essencial; as melhores arquiteturas emergem de times auto-organizados; em intervalos regulares, o time reflete e ajusta.
O teste de 30 segundos: seu time é ágil de verdade?
Esqueça se vocês rodam daily ou se chamam o gerente de Scrum Master. Faça as perguntas que importam: quando o cliente muda de ideia no meio do sprint, o que acontece? Existe alguma decisão de produto que precisa de aprovação de 3 níveis hierárquicos? Vocês entregam software em produção a cada quantos dias?
Se a resposta a essas três perguntas te deixa desconfortável, agilidade no seu time é ritual, não cultura. A boa notícia: dá para mudar. A má: começar pelo nome da reunião não funciona.