Um laboratório agile a céu aberto

Se você apresentar o agile a um desenvolvedor experiente hipotético que ainda não o conhece, é bem possível que a reação seja: “tá, mas você só tá dando um nome ao que a gente já faz.”

É uma reação natural, afinal de contas agile é exatamente isso desde o início. O próprio manifesto foi escrito por desenvolvedores experientes para botar um nome naquilo que eles já estavam fazendo. As abordagens incrementais onde o software funcionando é a principal ferramenta de comunicação com o cliente tinham surgido independentemente várias vezes. Esse tipo de abordagem é o que os desenvolvedores adotam naturalmente se forem deixados em paz.

Isso é ótima notícia para quem já é experiente: para estar por dentro dessa buzzword basta continuar trabalhando normalmente. Mas e para quem está começando e quer aprender? E para quem sempre foi forçado a trabalhar com um modelo cascata e quer aprender? Seria ótimo se existisse algum tipo de fazenda de formigas onde você pudesse soltar um monte de devs, não impor restrições e ver como eles naturalmente se organizam. Onde você pudesse ver os devs agile trabalhando e aprender com eles.

Boa notícia para quem quer aprender: isso existe! E o nome é comunidade open source.

O open source de hoje já tem muito mais suporte corporativo do que o de dez ou quinze anos atrás. E junto com o suporte vem a interferência. Mas felizmente os projetos de hobby não são tão difíceis de encontrar. Até mesmo os projetos com suporte corporativo são bastante espelhados nos projetos de hobby. Ninguém quer contribuir com um projeto burocrático, então ou eles imitam os hobbistas ou simplesmente não recebem contribuições.

Um projeto de hobby é um exemplo perfeito de deixar os desenvolvedores em paz para se organizarem naturalmente: como estão fazendo algo porque querem, e não porque tem alguém pedindo ou pagando, o modo como vão se coordenar vai ser escolhido para beneficiar eles próprios. A partir deste modo de pensar emergem práticas atualmente identificadas com o agile. As práticas são interessantes, mas o mais importante é estar inserido nesta mentalidade. Porque é a partir dela que as práticas podem ser avaliadas criticamente e é a partir dela que novas práticas surgem.

Um dos valores do manifesto agile mais claramente adotado pelos projetos open source é o “software em funcionamento mais que documentação abrangente”, traduzido diretamente no “talk is cheap, show me the code” do Torvalds. Ninguém vê um projeto open source que passa meses “levantando requisitos” e escrevendo documentação antes de escrever ao menos uma prova de conceito ou um protótipo do sistema final. Há sempre uma versão que roda do sistema. Depois que os projetos começam, cada um dos commits modifica um pouco o código, mas sempre se mantém o sistema rodando. Não se quebra o build em projetos open source. Não se quebra o build em projetos agile.

Temos na comunidade open source um laboratório de agile a céu aberto com as portas escancaradas. Todo esse processo pode ser observado e esmiuçado por quem quer aprender. Basta fuçar as pull requests, bugzillas e gits da vida. A fazenda de formigas está aí. Basta ter a curiosidade de olhar.

(A propósito… Eu usei o tempo todo agile com ‘A’ minúsculo porque o Agile com ‘A’ maiúsculo é um termo extremamente sobrecarregado hoje em dia. Não estou falando de práticas específicas, de reuniões de pé, de TDD, nem de quadros com post-its. Estou falando do mentalidade ilustrada pelo manifesto. É triste isso de termos que deixar de usar a palavra que escolhemos para nomear este mentalidade, mas infelizmente é o estado em que nossa indústria chegou.)