De 11 a 13 de fevereiro de 2001, no resort de esqui The Lodge at Snowbird nas montanhas Wasatch de Utah, dezessete pessoas se reuniram para conversar, esquiar, relaxar e tentar encontrar um terreno comum e, claro, para comer. O que surgiu foi o Manifesto Ágil “Desenvolvimento de Software”. Representantes de Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e outros simpatizantes da necessidade de uma alternativa para documentação, processos de desenvolvimento de software pesados convocados.
Agora, uma reunião maior de anarquistas organizacionais seria difícil de encontrar, então o que emergiu dessa reunião foi simbólico – um Manifesto para Desenvolvimento Ágil de Software – assinado por todos os participantes. A única preocupação com o termo ágil veio de Martin Fowler (um britânico para quem não o conhece) que admitiu que a maioria dos americanos não sabia pronunciar a palavra ‘ágil’.
As preocupações iniciais de Alistair Cockburn refletiram os primeiros pensamentos de muitos participantes. “Pessoalmente, eu não esperava que esse grupo específico de agilitas concordasse em algo substantivo.” Mas seus sentimentos pós-reunião também foram compartilhados: “Falando por mim, estou encantado com a redação final [do Manifesto]. Fiquei surpreso que os outros parecessem igualmente encantados com a redação final. Então concordamos em algo substantivo. “
Chamando a nós mesmos de “The Agile Alliance”, este grupo de pensadores independentes sobre desenvolvimento de software, e às vezes concorrentes entre si, concordou com o Manifesto para o Desenvolvimento de Software Ágil.
Mas enquanto o Manifesto fornece algumas ideias específicas, há um tema mais profundo que motiva muitos, mas não todos, com certeza, os membros da aliança. No final da reunião de dois dias, Bob Martin brincou dizendo que estava prestes a fazer uma declaração “mole”. Mas, embora tingidos de humor, poucos discordaram dos sentimentos de Bob, que todos nos sentíamos privilegiados por trabalhar com um grupo de pessoas que mantinham um conjunto de valores compatíveis, um conjunto de valores baseado na confiança e no respeito mútuo e promovendo modelos organizacionais baseados em pessoas, colaboração e construção dos tipos de comunidades organizacionais nas quais gostaríamos de trabalhar. No fundo, acredito que Metodologias Ágeis tratam realmente de coisas “fracassadas”, de entregar bons produtos aos clientes operando em um ambiente que faz mais do que falar sobre “
Por exemplo, eu acho que, em última análise, Extreme Programming cresceu rapidamente em uso e interesse, não por causa da programação em pares ou refatoração, mas porque, tomadas como um todo, as práticas definem uma comunidade de desenvolvedores livre da bagagem das corporações Dilbertesque. Kent Beck conta a história de um trabalho inicial em que estimou um esforço de programação de seis semanas para duas pessoas. Depois que seu gestor transferiu o outro programador no início do projeto, ele completou o projeto em doze semanas e se sentiu péssimo consigo mesmo! O chefe é claro discutiu com Kent sobre o quão lento ele foi durante as segundas seis semanas. Kent, um pouco desanimado porque era um “fracasso” como programador, finalmente percebeu que sua estimativa original de 6 semanas era extremamente precisa para 2 pessoas e que seu “fracasso”
Esse tipo de situação acontece todos os dias marketing, gestão ou clientes externos, clientes internos e, sim, até mesmo desenvolvedores não querem tomar decisões difíceis, então impõem demandas irracionais por meio da imposição de regras corporativas. estruturas de poder. Este não é apenas um problema de desenvolvimento de software, ele ocorre em todas as organizações Dilbertesque.
Para ter sucesso na nova economia, para entrar agressivamente na era do e-business, do e-commerce e da web, as empresas precisam se livrar de suas manifestações de Dilbert de faz-de-obra e políticas misteriosas. Essa liberdade das inanidades da vida corporativa atrai os defensores das Metodologias Ágeis e assusta os begeebers (você não pode usar “ofensa” em um jornal profissional) dos tradicionalistas. Francamente, as abordagens ágeis assustam os burocratas corporativos pelo menos aqueles que estão felizes empurrando o processo pelo processo versus tentando fazer o melhor para o “cliente” e entregar algo oportuno, tangível e “como prometido” porque eles ficam sem lugares para se esconder.
O movimento ágil não é anti-metodologia, na verdade, muitos querem restaurar a credibilidade da palavra metodologia. Restabelecer o equilíbrio. Abraçar a modelagem, mas não para arquivar algum diagrama em um repositório corporativo empoeirado. Aceita a documentação, mas não centenas de páginas de tomos nunca mantidos e raramente usados. planeasse, mas reconhece os limites do planeamento em um ambiente turbulento. Aqueles que classificariam os proponentes do XP ou SCRUM ou qualquer outra Metodologia Ágil como “hackers” ignoram tanto as metodologias quanto a definição original do termo hacker.
A reunião em Snowbird foi incubada em um encontro anterior de proponentes da Programação Extrema e alguns “outsiders”, organizado por Kent Beck no Rogue River Lodge em Oregon na primavera de 2000. Na reunião de Rogue River, os participantes expressaram apoio a uma variedade de metodologias “Light”, mas nada formal ocorreu. Durante o ano de 2000 foram escritos vários artigos que referenciavam a categoria de processos “Light” ou “Lightweight”. Vários desses artigos se referiam a “Metodologias leves, como Extreme Programming, Adaptive Software Development, Crystal e SCRUM”. Nas conversas, ninguém gostou muito do apelido de “Light”, mas pareceu ficar por enquanto.
Em setembro de 2000, Bob Martin, da Object Mentor em Chicago, deu início à próxima reunião com um e-mail; “Gostaria de convocar uma pequena conferência (dois dias) no período de janeiro a fevereiro de 2001 aqui em Chicago. O objectivo desta conferência é reunir todos os líderes de métodos leves em uma sala. Todos vocês estão convidados; e eu estaria interessado em saber quem mais eu deveria abordar.” Bob criou um site Wiki e as discussões se acirraram.
No início, Alistair Cockburn ponderou com uma epístola que identificava o descontentamento geral com a palavra ‘Light’: leve participando de uma reunião de metodologistas leves. De alguma forma, parece um bando de pessoas magras e fracas tentando lembrar que dia é hoje.”
O debate mais acirrado foi sobre a localização! Havia uma séria preocupação com Chicago no inverno frio e nada divertido para fazer; Snowbird, Utah coisas frias, mas divertidas de se fazer, pelo menos para aqueles que esquiam de cabeça para baixo como Martin Fowler tentou no primeiro dia; e Anguilla no Caribe quente e divertido, mas demorado para chegar. No final, Snowbird e esqui venceram; no entanto, algumas pessoas como Ron Jeffries querem um lugar mais quente da próxima vez.
Esperamos que o trabalho conjunto como Agile Alliance ajude outras pessoas em suas profissões a pensar sobre desenvolvimento de software, metodologias e organizações de maneiras novas e mais ágeis. Se sim, cumprimos nossos objectivos.
Jim Highsmith, da Agile Alliance, ©2001 Jim Highsmith
Manifesto para o Desenvolvimento Ágil de Software.
Ao desenvolver e ao ajudar outros a desenvolver software,
temos vindo a descobrir melhores formas de o fazer.
Através deste processo começámos a valorizar:
Indivíduos e interacções mais do que processos e ferramentas
Software funcional mais do que documentação abrangente
Colaboração com o cliente mais do que negociação contratual
Responder à mudança mais do que seguir um plano Ou seja, apesar de reconhecermos valor nos itens à direita,
valorizamos mais os itens à esquerda.