Costumo dizer que agile não é questão de ferramental ou conhecimento específico, mas uma questão pura e simples de atitude pessoal. Com isso não quero dizer que a interpretação do que é metodologia ágil (ou mesmo do que é agile) esteja equivocada. Pelo contrário, hoje me parece que cada vez mais as pessoas entendem melhor essa questão. O que acho de verdade é que, antes de ser possível ter quaisquer práticas ágies “rodando suave” em uma organização (não necessariamente uma empresa – um grupo de amigos querendo desenvolver software que funciona decentemente é uma organização) é preciso que cada indivíduo seja, por formação e convicção pessoal, uma pessoa agile.
Qual o parâmetro para avaliar que alguém tem essa atitude a que me refiro? Um desenvolvedor senior a teria? Mas o que define essa “senioridade”? A atitude de que falo pouco tem a ver com experiência profissional. E também não tem muito a ver com o conhecimento tecnico. Não é o tempo que alguém passa fazendo algo que define como essa pessoa irá saber executar essas tarefas. No rails summit 2009 o Obie Fernandez falou muito bem sobre esse assunto. O que define o quanto alguém pode ficar bom em algo é, além da prática em si, a forma como é realizada essa prática. Também há uma entrevista do @akitaonrails onde ele fala sobre o assunto de forma bastante direta:
… quem fez 10 anos a mesma coisa não é um sênior, é um júnior de 10 anos.
O que é necessário não é a experiência, mas o que foi possível o desenvolvedor extrair dela.
Nada, a não ser a personalidade, garante que alguém irá tomar “atitudes ágeis” no dia-a-dia. Ser um profissional excepcional tecnicamente não importa se a pessoa não tem a habilidade de se auto-gerenciar. Uma equipe ágil é um conjunto onde todos trabalham para atingir um objetivo que foi traçado por todos, de certa forma pode-se dizer que ninguém é alguma coisa, todo mundo está alguma coisa. E esse tipo de raciocínio também pode ser um grande bloqueio para alguns, principalmente se isso implica em abrir mão de pequenos reconhecimentos (do tipo, EU fiz esse código e por isso ele funciona). Por outro lado há pessoas que gostam de se considerar não responsáveis por parte do projeto. Sabe aquele bom e velho: “cara, tem que fazer essa jossa! Como você é o [coloque cargo formal de ti aqui] da empresa, é sua responsabilidade. Não sei nem como mas tem que ser feito!”? Pela minha experiência, pessoas que tem esse tipo de atitude normalmente também são bastante ciumentas em relação ao próprio trabalho. Essas pessoas muitas vezes podem ser geniais, mas não servem para integrar um time ágil.
Essa atitude agile é sobre querer (mais uma vez, convicção pessoal) entregar software com a maior qualidade possível. É sobre querer compreender o que realmente precisa ser feito, e não fazer o que está escrito em um documento como uma forma de poder culpar outros caso algo não saia como previsto posteriormente. Também é sobre compreender que organização não tem nada a ver com hierarquias rígidas onde, classicamente, uma ordem pula de um local alto no organograma e desce se propagando ao melhor estilo telefone sem fio (ganhando alguns significados e perdendo outros conforme a capacidade compreensão do próximo nó na cadeia). Novamente, é sobre entregar qualidade e sobre tentar os meios mais eficientes para que isso possa ocorrer, não importando se usar esses meios estrapola os limites do teclado e do mouse.
Um desenvolvedor ágil não vai esperar que alguém lhe diga o que ele precisa fazer, ele sabe encontrar qual a próxima tarefa necessária e importante para ser desenvolvida. Ele também não vai sentar na cadeira, se fechar no escopo para a resolução dessa tarefa, e “code like hell” até poder dar um refresh no browser e ver o resulatdo aparentemente acontecer. Ele vai estudar a tarefa para encontrar uma forma de executá-la da maneira mais clara e rápida possível, sem se desviar do objetivo final de entregar o software com alta qualidade.
Esse desenvolvedor de atitude agile não espera que a sua organização (novamente não obrigatoriamente uma empresa) estabeleça formalmente metodologias ágeis de desenvolvimento para que ele siga. Ele não se importa nem se seus superiores sabem o que é isso. Ele usa técnicas ágies (como testes, refatoração, integração contínua…) para garantir que seu trabalho atinja a qualidade que ele sabe ser necessária, e não porque alguém disse que esse é o único jeito de fazer algo. Ele prefere, por experiência e formação, fazer as coisas da melhor forma. E não da forma “suficiente para agradar”. É aquele desenvolvedor que vai procurar (e quase sempre conseguir) entregar qualidade independente do ambiente em que está inserido. É claro que ambientes ruins vão afastar esses caras, mas ele vão entregar qualidade enquanto suportarem estar por ali.
Você provavelmente já trabalhou em alguma empresa que tem aquele desenvolvedor antigo de casa, que está lá desde que a empresa saiu do papel. O conhecimento tecnico dele é inegável, bem como o conhecimento sobre os detalhes dos frameworks criados pela empresa para atender as necessidades dos desenvolvedores que foram contratados desde então. O mais provável é que esse senior tenha escrito (provavelmente sozinho), grande parte desses frameworks. Para contratar alguém a opinião desse senior é indispensável, afinal ele conhece bem o ferramental tecnico utilizado e é capaz de julgar quais habilidades tecnicas o sujeito tem que ter para conseguir corresponder como programador! Claro, esse programador não precisa ser alguém realmente interessado em aprender e evoluir – precisa de um conhecimento tecnico especifico e bem estabelecido e ser obediente para não quebrar as regras e práticas estabelecidas por esse senior, que aliás é alguém com muito ciúme do próprio código. Afinal nesse código de framework e nesses produtos core da empresa estão também a reputação dele, esse código é aprova cabal do quanto ele é bom e senior.
Imagine que essa mesma empresa agora resolva que vai adotar [insira agora uma metdologia ágil de desenvolvimento que lhe agrade] para desenvolver seu novo produto. É claro que essa empresa jovem e bem informada já ouviu falar que agile, para dar realmente certo, não pode ser feito por qualquer equipe, precisa de bons profissionais envolvidos. Então ela escolhe 4 ou 5 daqueles profissionais mais seniores descritos acima e monta a super equipe agile que irá tocar o próximo produto. A empresa conseguiu que o cliente aloque um especialista de domínio para ficar a disposição desses 4 jedis enquanto eles desenvolvem. Comprou chocolates, quadros brancos, enfim… Só que… Não está dando certo. Por algum motivo os jedis estão mais preocupados em impressionar uns aos outros com seus conhecimentos tecnicos do que com sua capacidade de compreender o domínio para o qual precisam escrever uma aplicação. Muitas vezes, quando um problema é vislumbrado, ao invés de discutirem em conjunto, cada um deles vai silenciosamente para sua mesa tentando codar o mais rápido possível uma solução que resolva o problema da forma que ele acha melhor. Ele não vai expor em público as ideias dele sobre o assunto porque isso é jogar pérola aos porcos, ninguém é capaz de enteder seus motivos. E o especialista de domínio? Só o que pode fazer é aguardar, confortavelmente instalado, que alguém lhe pergunte o que ele precisa. Os jedis sabem que estão quebrando uma regrinha ou outra da metodologia, mas eles são jedis oras! Podem fazer tudo dar certo através do próprio esforço.
Se esse time não se desviou da utilização da metodologia ágil adotada no início, logo ficará claro que eles têm problemas, afinal esse é um dos principais papéis dessas metodologias: mostrar os problemas rapidamente. Ótimo! Hora de acalmar os egos e botar a engrenagem para funcionar… mas provavelmente o que vai acontecer é que um muro das lamentações será instalado de um lado e o paredão de fuzilamento do outro. Há pessoas o suficiente para culparem, inclusive o especialista de domínio que não consegue pedir o que precisa de forma direta (também, ninguém perguntou… ;]). E aí é óbvio que a maior culpa é da metodologia ágil que não funciona em ambientes reais, certo?
Portanto, agile é muito menos relativo a adoção formal de uma metodologia e muito mais a atitude dos membros envolvidos em um projeto. Se as pessoas forem “agile”, as práticas ágies vão emergir naturalmente e a escolha de uma metodologia vai ajudar todos a conversarem na mesma língua. Mas é impossível tornar as pessoas “ágeis” apenas impondo e evangelizando um metodologia entre elas.
