Princípios ágeis: o Manifesto, seus valores e o que eles mudam

Em fevereiro de 2001, dezessete profissionais que vinham experimentando, cada um por conta própria, métodos leves de desenvolvimento se reuniram e chegaram a um acordo sobre uma única página de texto. Essa página — o Manifesto para Desenvolvimento Ágil de Software — tem quatro declarações de valores e doze princípios de apoio, e nada mais. Ela não cita papéis, reuniões, artefatos nem certificações. Tudo o que hoje se chama de ágil, dos quadros de Scrum aos eventos de planejamento trimestral e a toda a indústria de escalonamento, foi construído depois em cima dessa página, e boa parte disso a contradiz.

É por causa dessa distância que este guia começa pelo próprio texto. Se você entende o que os valores afirmam de fato e contra qual problema os autores estavam reagindo, consegue avaliar qualquer prática que coloquem na sua frente — inclusive as que a sua organização já usa — pelos seus méritos, e não pelo fato de ela ter o rótulo de ágil. Este artigo fica no nível dos valores e princípios; o guia do framework Scrum cobre a implementação concreta mais usada, e o de fundamentos de gerenciamento de projetos cobre a tradição preditiva com a qual o manifesto discutia.

Por que o manifesto foi escrito

O modelo dominante nos anos 1990 vinha de disciplinas de engenharia em que o formato do produto era conhecido antes do início da construção. Você levantava os requisitos, escrevia uma especificação, projetava o sistema, construía, testava e entregava — cada fase concluída e aprovada antes de a próxima começar. A abordagem costuma ser chamada de waterfall, ou cascata, por causa de um artigo de 1970 que apresentava o diagrama sequencial como um modelo falho, usado como contraexemplo, e depois propunha iterar; o mercado adotou o diagrama e ignorou a ressalva.

Fases sequenciais funcionam quando três condições são atendidas: os requisitos podem mesmo ser conhecidos com antecedência, não mudam durante a construção e o custo de descobrir um erro no fim é suportável. Software quase nunca atende a nenhuma delas. Usuários não conseguem descrever o que querem até verem alguma coisa; o mercado muda durante um desenvolvimento de dezoito meses; e os defeitos que mais importam — um fluxo de trabalho mal entendido, uma tela inutilizável, um teto de desempenho na arquitetura — só aparecem quando alguém tenta usar o produto. Um projeto que descobre seu mal-entendido central durante o teste de aceitação já gastou o orçamento.

Os métodos leves do fim dos anos 1990 foram reações independentes a esse padrão. Eles diferiam nos detalhes, mas compartilhavam uma aposta: se você não consegue saber a resposta de antemão, encurte o ciclo entre fazer e aprender até que errar fique barato.

Os quatro valores

Cada valor é escrito como uma comparação, e todos terminam com o mesmo esclarecimento: embora haja valor nos itens à direita, os autores valorizam mais os itens à esquerda. Essa formulação importa. Nenhum dos quatro é uma ordem para abandonar o item da direita.

Indivíduos e interações mais que processos e ferramentas. Um processo definido deixa pessoas boas um pouco mais consistentes; ele não transforma um time fraco em um time bom. Quando algo dá errado, a primeira pergunta na maioria das organizações é qual etapa do processo foi pulada. A pergunta do manifesto é qual conversa não aconteceu. Na prática, isso significa colocar no mesmo lugar, ou conectar direito, as pessoas que precisam conversar, manter times pequenos e estáveis e tratar uma ferramenta como algo que registra uma decisão, não como algo que a toma.

Software em funcionamento mais que documentação abrangente. A única medida honesta de progresso é um sistema rodando e fazendo algo que um usuário reconhece. Uma especificação noventa por cento completa não diz nada sobre quanto do produto existe. Este é o valor mais distorcido, e o FAQ abaixo trata dessa distorção; a disciplina que ele exige é que todo documento tenha um leitor identificado e um motivo para existir.

Colaboração com o cliente mais que negociação de contratos. Contratos de escopo e preço fechados criam uma relação de confronto em que cada descoberta vira um pedido de mudança e uma briga. A alternativa é fixar o orçamento e o prazo e deixar o escopo flexível, com o cliente presente continuamente para decidir o que cabe dentro. Isso exige um cliente disposto a se envolver toda semana, e não só nos marcos, o que costuma ser a parte mais difícil de viabilizar numa adoção ágil.

Responder a mudanças mais que seguir um plano. Um plano é uma previsão feita no momento de maior ignorância. Tratar qualquer desvio como fracasso cria uma pressão forte para esconder más notícias. Tratar o plano como algo a ser revisado conforme as evidências chegam torna barato dar más notícias, e essa é a única forma de elas chegarem cedo o bastante para que alguém possa agir.

Os doze princípios na prática

Os princípios são mais concretos que os valores, e é neles que está a maior parte do conteúdo prático. Em vez de listá-los como slogans, veja o que cada um pede que um time realmente faça de outro jeito.

Três deles merecem uma pausa, porque costumam ser ignorados. O princípio nove liga a agilidade à qualidade de engenharia: uma base de código sem testes não consegue absorver requisitos que mudam, então um time que adota iterações sem adotar test-driven development, integração contínua e refactoring vai ficar mais lento a cada iteração até parar. O princípio oito descarta o ciclo de sprint seguido de colapso que muitos times confundem com alto desempenho. E o princípio doze é o motor: sem uma retrospectiva que mude alguma coisa, os outros onze são regras estáticas, e não um sistema que melhora.

Controle empírico de processos

Por baixo de tudo isso está uma ideia emprestada da engenharia de processos. Um processo definido é aquele que você consegue especificar por completo com antecedência e depois executar: com as mesmas entradas, ele produz as mesmas saídas, então planejá-lo uma vez é racional. Um processo empírico é aquele em que variáveis demais são desconhecidas, então você o controla por inspeção e adaptação frequentes — faz um pouco, olha o resultado, ajusta.

O empirismo precisa de três coisas para funcionar: transparência, para que todos vejam o mesmo estado real do trabalho; inspeção, com frequência curta o bastante para que um desvio de rota saia barato; e adaptação, ou seja, a autoridade e a disposição para mudar de rumo com base no que foi visto. Tire qualquer uma delas e o ciclo se quebra. Um time que inspeciona toda semana, mas não tem autoridade para mudar nada, está fazendo uma reunião de status, não conduzindo um processo empírico.

Iterativo e incremental são as duas técnicas que tornam a inspeção possível, e não são sinônimos. Incremental significa construir o produto em fatias que acrescentam, cada uma, uma função utilizável — um fluxo de login, depois uma busca, depois um checkout. Iterativo significa revisitar e melhorar o que já existe conforme você aprende. Uma entrega de verdade precisa das duas coisas: fatiar fino o suficiente para lançar e já contar com voltar e retrabalhar as primeiras fatias assim que os usuários colocarem a mão nelas. Um time que só trabalha de forma incremental acumula um produto cheio de primeiros rascunhos.

Leituras equivocadas comuns

• “Ágil significa sem documentação.” A declaração de valor compara a documentação com software em funcionamento; ela não a elimina. Produtos regulados, APIs públicas e sistemas que sobrevivem ao próprio time precisam de material escrito duradouro.
• “Ágil significa sem estimativas nem datas.” Decisões de negócio exigem previsões. O ágil muda a forma como as previsões são feitas e a frequência com que são revisadas — veja estimativa e planejamento —, não o fato de elas existirem.
• “Ágil significa sem arquitetura.” Design emergente não é ausência de design. Significa adiar decisões até o último momento responsável e manter sob revisão deliberada as que são caras de reverter.
• “Fazemos sprints de duas semanas, então somos ágeis.” A duração da iteração é a coisa mais fácil de copiar e a que menos significa. Um time que planeja duas semanas de tarefas atribuídas, reporta status todo dia e faz release duas vezes por ano mudou o calendário e nada mais.
• “Auto-organização significa sem gestão.” Os times decidem como fazer o trabalho. Alguém continua definindo a direção, financiando o esforço, contratando e resolvendo os problemas que estão fora do alcance do time.

Onde o ágil não se encaixa

Ser honesto sobre os limites é o que separa um profissional de um evangelista.

Abordagens adaptativas partem do princípio de que dá para mudar de ideia tarde sem pagar caro por isso. Onde não é — engenharia civil, um lote de produção de hardware, o lançamento de um satélite, uma migração com uma única virada irreversível —, uma análise inicial aprofundada é a escolha racional, e modelos híbridos que planejam de forma preditiva as partes imutáveis enquanto conduzem o software de forma adaptativa dentro delas funcionam melhor do que fingir que tudo é flexível.

Elas também partem do princípio de que há um cliente disposto a se envolver. Quando o comprador assina um contrato de escopo fechado e some por seis meses, ou quando uma regra de licitação pública exige a especificação completa antes da escolha do fornecedor, o valor da colaboração fica sem espaço. E elas partem do princípio de que o time é pequeno o bastante para conversar. Coordenar muitos times exige estrutura adicional, que é o que os frameworks de escalonamento tentam oferecer, e é por isso que eles são tão controversos.

Por fim, o ágil no nível do time não consegue consertar um pipeline de entrega que leva três meses para colocar uma mudança em produção. É justamente essa restrição que as práticas de DevOps se propõem a remover, e sem elas um time pode ser perfeitamente ágil até o ponto em que o trabalho dele fica parado numa fila.

Principais pontos

• O manifesto é uma página com quatro valores e doze princípios; todo framework, papel e cerimônia que as pessoas associam ao ágil foi acrescentado depois e é opcional.
• Cada valor é uma comparação que reconhece explicitamente que o item da direita ainda tem valor — nenhum deles abole documentação, contratos ou planos.
• O controle empírico de processos — transparência, inspeção e adaptação em um ciclo curto — é o mecanismo; a entrega iterativa e incremental é o que cria algo para inspecionar.
• Excelência técnica não é enfeite opcional: sem testes, automação e refactoring, a capacidade de acolher mudanças desaparece em poucos meses.
• A abordagem se encaixa em trabalho intelectual com requisitos incertos e decisões reversíveis, e se encaixa mal quando uma mudança tardia é de fato catastrófica ou o cliente não pode participar.
• Copiar o calendário — sprints, dailies, um quadro — sem mudar quem decide, com que frequência se faz release e com que honestidade se reporta é a adoção fracassada mais comum.