Decore o mantra do Manifesto Ágil, até que ele esteja tatuado de tal forma em sua mente que você passe a vivê-lo de forma integral.
Em fevereiro de 2001, 17 pessoas que já trabalhavam com Extreme Programming, Scrum, ou outros dos chamados Métodos Leves (Lightweight Methods) de desenvolvimento de software, reuniram-se em um hotel nas montanhas nevadas do estado norte-americano de Utah para trocar ideias sobre o que estavam fazendo.
O único inglês da turma, Martin Fowler, foi quem sugeriu o termo “agile” (ágil) para descrever aquilo que estavam, afinal, discutindo, ainda que estivesse preocupado com o fato de que os americanos poderiam ter dificuldade em pronunciar tal termo. Depois de muitas conversas, esquiadas, comida e diversão, Martin apresentou a redação do Manifesto Ágil, assinado por todos os presentes e por muito mais pessoas a partir de então.
De tempos em tempos, é bom a gente dar uma parada e revisar as razões pelas quais a gente faz certas coisas. Caso contrário, repete-se a história do sentinela do banco do jardim. Não conhece?
<alívio cômico> Há muito tempo, no jardim central de um prédio do exército de um país tropical, havia um banco de cimento onde os oficiais costumavam relaxar em seus intervalos, fumando um charuto. Com o passar dos anos, a ação do tempo e o cocô dos pássaros fizeram com que o banco ficasse manchado, escurecido, feio. O general ordenou que o banco fosse pintado e que um soldado raso ficasse de sentinela, afastando os pássaros e impedindo que as pessoas sentassem na tinta fresca. Antes da tinta secar, morreu o general, sem que uma contraordem fosse dada. Reza a lenda que até hoje soldados revezam-se como sentinelas do banco, dia e noite. A grande maioria deles não sabe a razão dessa ordem. </alívio cômico>
Quando os microcomputadores começaram a se popularizar, entre o final dos anos 1980 e o começo dos anos 1990, o desenvolvimento de sistemas, que até então estava restrito aos “iniciados”, passou a permear uma terra desconhecida, em que jovens aventureiros nas linguagens de programação como Basic, Clipper e outras passaram a criar soluções para pequenos escritórios, na maioria das vezes resolvendo seus próprios problemas. Os escritórios cresciam, as máquinas eram conectadas em rede e instaurava-se o caos. Ao contrário da geração anterior, que desenvolvia programas para imensos e caríssimos computadores e, por isso, era obrigada a seguir toda uma metodologia que implicava na boa documentação para os usuários e, especialmente, para outros desenvolvedores, os mais novos estavam mais preocupados em criar rapidamente sistemas que fossem tão intuitivos para os usuários, que prescindiriam de documentação, e novas funcionalidades sempre tinham prioridade sobre a documentação para outros (que outros?) que poderiam vir a manter o sistema.
Rapidamente – ainda bem! – notou-se a importância de aproveitar a velocidade dos novos desenvolvimentos, colocando-se alguma ordem no caos e, ao mesmo tempo, abandonar métodos antigos que já começavam a ficar ultrapassados pelas novas possibilidades geradas por novas máquinas, novas linguagens de programação e novos ambientes de desenvolvimento.
O que chamamos hoje de métodos ágeis tem origem nos ensaios de Fred Brooks Jr., em sua obra seminal O mítico homem-mês, que tive a honra de traduzir para o português. No ensaio que dá título ao livro é enunciada a “lei de Brooks” que, em resumo, diz que adicionar pessoas a um projeto atrasado apenas irá atrasá-lo mais ainda. Em sua análise sobre a razão disso, Fred aponta sobrecargas causadas por comunicação e gestão e sugere pequenos times para projetos bem definidos e contidos. O livro de Brooks foi originalmente publicado em 1975.
Foi Jeff Sutherland, porém, que no início dos anos 1990 começou a formatar o Scrum, que serviu como influência para o Extreme Programming de Kent Beck. Hoje as duas metodologias estão bem casadas – o Extreme Programming para a engenharia da solução e o Scrum para a evolução e gestão empírica de seus processos. Como o óbvio deve ser sempre lembrado, não custa repetir o que reza o Manifesto Ágil.
• Indivíduos e suas interações são mais importantes que processos e ferramentas.
• Software em funcionamento é mais importante que documentação abrangente.
• Colaboração com o cliente é mais importante que negociação de contratos.
• Responder a mudanças é mais importante que seguir um plano.
Se essas quatro pequenas frases forem sempre recitadas, como um mantra, a cada vez que um programador se sentar à frente de seu computador e, em especial, no início de cada reunião de desenvolvimento, já teremos uma imensa melhora na qualidade de qualquer produto a ser entregue a um cliente.
Defendo, porém, como você constatará na leitura deste livro, que o Scrum e os métodos ágeis não servem apenas para o desenvolvimento de software, mas também para muitas outras coisas. Assim, tomo a liberdade de mudar um pouco o que diz o manifesto ágil original, encaixando-o mais ao propósito deste livro.
• Indivíduos e suas interações são mais importantes que processos e ferramentas.
• Entregas funcionais são mais importantes que documentação abrangente.
• Colaboração com o cliente é mais importante que negociação de contratos.
• Responder a mudanças é mais importante que seguir um plano.
O agilista Ilan Goldstein, autor do livro Scrum shortcuts without cutting the corners, propõe mais um item ao Manifesto Ágil:
• Atitude é mais importante que aptidão.
Ao longo de seu trabalho com métodos ágeis, você pode querer acrescentar mais itens ao seu manifesto pessoal, ou ao manifesto de sua equipe. Essa é uma atividade bastante motivadora. A seguir, dois exemplos vindos de outros autores.
• A sabedoria de muitos é mais importante que o brilhantismo de um (Roman Pichler).
• O furo é mais importante que a furadeira (Theodore Levitt).
Mike Cohn, autor de uma das mais utilizadas apresentações sobre o Scrum, reflete, em um artigo para o portal InfoQ, sobre o que gostaria de ver na evolução dos métodos ágeis:
Eu gostaria que todos os nomes desaparecessem. Chega de Scrum, XP, KanBan, Lean, DSM, Crystal. Deveríamos ficar apenas com o nome “ágil”. Já vimos isso acontecer há duas décadas com objetos. Nós tínhamos vários enfoques e métodos de Rumbaugh, Booch, Meyer, Jacobson e outros. As diferenças foram colocadas de lado e hoje falamos meramente de objetos e de UML. Também gostaria que chegássemos a um ponto em que não precisássemos mais falar de “desenvolvimento ágil de software”, mas apenas “desenvolvimento de software” – e é óbvio que ele é ágil. Ninguém mais me pergunta se o código em Ruby que estou escrevendo é orientado a objetos. É claro que é! Espero que algum dia ninguém mais me pergunte se usei a metodologia ágil em um projeto. É claro que usei!
Leia esse post do Artur Margonari para um arrazoado interessante sobre o Manifesto Ágil. Não deixe de ler os comentários e aproveita para seguir o Artur no LinkedIn. Ele é uma das grandes fontes atuais de inspiração para agilistas de todas as idades.
