Manifesto Ágil - 10 anos

Por Cesar Brod

Data de Publicação: 28 de Fevereiro de 2011

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" para descrever aquilo que estavam, afinal, discutindo, mesmo preocupado com o fato de que os americanos tinham 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.

O portal InfoQ está publicando uma série de matérias e entrevistas que ilustram muito bem o momento que levou à publicação do Manifesto Ágil e quais foram as evoluções a partir dele. Isto é muito bacana pois, 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> 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 fez 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. 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 desta 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, onde jovens aventureiros nas linguagens conhecidas 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 a 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 também manter o sistema.

Rapidamente - ainda bem! - notou-se a importância de aproveitar a velocidade dos novos desenvolvimentos, colocando 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, linguagens de programação e 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 para a razão disto, 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 de seus processos. Como o óbvio deve ser sempre lembrado, não custa repetir o que reza o Manifesto Ágil:

• Indivíduos e 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 estas quatro pequenas frases forem sempre recitadas, como um mantra, a cada vez que um programador senta-se à 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.

Mike Cohn, autor de uma das mais utilizadas apresentações sobre o Scrum, reflete, em seu artigo para o 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 "agile" (ágil). Já vimos isto 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!

Este artigo é dedicado aos amigos da Jera Software Ágil e a todos aqueles que melhoram a vida de seus clientes desenvolvendo com métodos ágeis.