O Manifesto gil

Facilitar mudanas mais efetivo do que tentar preveni-las. Aprender a confiar nas suas habilidades para responder a eventos imprevisveis mais importante do que confiar nas suas habilidades de planejamento contra desastres. Ns ltimos 12-18 meses, vrias publicaes Software Development, IEEE Software, Cutter IT Journal, Software Testing, Quality Engineering e mesmo The Economist, publicaram artigos nos quais Martin Fowler chamou de a Nova Metodologia (www.martinfowler.com/articles/newMethodology.html), refletindo o crescente interesse nestes novos enfoques no desenvolvimento de software (Extreme Programming, Crystal Methodologies, SCRUM, Adaptive Software Development, Feature-Driven Development, Dynamic Systems Development Methodology entre outros). Adicionalmente a essas metodologias batizadas, vrias organizaes desenvolveram suas prprias abordagens lights para desenvolverem software. Formao da Aliana gil De 11 a 13 de Fevereiro de 2001, na The Lodge da estao de esqui Snowbird nas montanhas Wasatch em Utah, EUA, 17 pessoas se encontraram para conversar, esquiar, relaxar e tentar achar um denominador comum. O que surgiu foi a Aliana do Desenvolvimento gil de Software. Como seria difcil outra reunio com estes anarquistas organizacionais, o que resultou desta reunio foi o simblico Manifesto do Desenvolvimento gil de Software assinado por todos participantes. Embora o Manifesto apresente algo de especfico, muitos membros da Aliana tratam os temas com mais profundidade. Ao final de dois dias de reunio, o mentor da Extreme Programming Bob Martin brincou que ele estava quase fazendo uma declarao melosa. Pois, tingido com humor, o sentimento de Bob foi compartilhado pelo grupo todos ns gostamos de trabalhar com pessoas com as quais compartilhamos objetivos e valores baseados no mtuo respeito e confiana, que promovem a colaborao, cujo foco est nos modelos das organizaes e que produzem tipos de comunidades de profissionais nas quais gostaramos de trabalhar. O movimento da metodologia gil no anti-metodologia; de fato, muitos de ns queremos restaurar a credibilidade desta palavra. Tambm queremos restaurar um equilbrio. Ns abraamos a modelagem mas no meramente arquivar alguns diagramas num empoeirado repositrio corporativo. Ns abraamos a documentao mas no o gasto de resmas de papel em nunca mantidos e raramente utilizados tomos. Ns planejamos mas reconhecemos os limites do planejamento em ambientes turbulentos. Aqueles que se distinguem como proponentes de XP, SCRUM ou qualquer outra metodologia gil como hackers ignoram ambos a metodologia e a definio original do termo (um hacker foi originalmente definido como um programador que gosta de resolver problemas complexos de programao, ao invs daquele que pratica desenvolvimento ad hoc ou destruio).

1/9

Anteriormente, Alistair Cockburn identificou o desagrado geral da palavra light: Eu no me importo que as metodologias sejam chamadas de leve em peso, mas eu no tenho certeza que quero ser referido como um peso-leve participando de uma reunio de metodologistas de pouco peso. Isso se parece com um monte de magrelos e fracos de idia tentando se lembrar que dia hoje. Ento nossa primeira tarefa foi encontrar um adjetivo com o qual poderamos conviver. Agora nossos processos so geis, mesmo que algum de ns esteja um pouco capenga. O resultado desta reunio (e a frentica interao seguida online) foi o Manifesto gil. Enquanto o propsito e os princpios do Manifesto foram desenvolvidos pelo grupo todo, ns (Jim e Martin, ambos autores do Manifesto) adicionamos, para este artigo, nossas interpretaes e explicaes. O Manifesto gil: Propsito Ns estamos descobrindo maneiras melhores de se desenvolver software, desenvolvendo e ajudando outras pessoas a desenvolver. Ns valorizamos: Indivduos e interaes ao invs de processos e ferramentas Software operante ao invs de documentaes completas Colaborao do cliente ao invs de negociaes contratuais Responder mudanas ao invs de seguir um planejamento Esta declarao tem um nmero fascinante de aspectos, no apenas aqueles que as 17 pessoas estavam tentando concordar. Primeiro a palavra descobrindo. Embora este grupo fosse composto por experientes e reconhecidos gurus desenvolvedores, a palavra descobrindo foi escolhida para assegurar (ou assustar) a audincia que os membros da Aliana no tm todas as respostas e no adotam a teoria da bala de prata. Segundo, a palavra desenvolvendo indica que os membros de fato praticam estes mtodos nos seus trabalhos. Ken Schwaber (um proponente do SCRUM) falou dos seus dias de vendedor de ferramentas para automatizar metodologias pesadas. Impressionado com a capacidade de resposta da empresa de Ken, Jeff Sutherland o perguntou quais das metodologias pesadas ele utilizava no seu desenvolvimento interno. Eu ainda lembro da expresso do Jeff, recorda Ken, quando eu disse Nenhuma, se utilizssemos alguma delas, estaramos fora do mercado! Terceiro, este grupo para ajudar e no para ditar. Os membros da Aliana querem ajudar outras pessoas atravs dos mtodos geis e ampliar seus prprios conhecimentos aprendendo com o quais tentam ajudar. As declaraes dos valores tm um formato: em cada uma, o primeiro segmento indica a preferncia, enquanto o ltimo descreve um item que, embora importante, de prioridade menor. Esta distino est no corao da agilidade, mas simplesmente pedir s pessoas para listarem o que valorizado no revela as diferenas essenciais. Roy Singham, chefe do Martin na ThoughtWorks, colocou bem quando disse que a periferia dos casos, as escolhas difceis, que o interessa. De fato, ns valorizados o planejamento, documentao completa, processos e ferramentas. Isso fcil de falar. O difcil perguntar o que voc valoriza mais ?

2/9

A Aliana reconhece a importncia dos processos e ferramentas, reconhecendo adicionalmente que a interao entre indivduos capacitados tem ainda maior importncia. Da mesma forma, documentao completa no necessariamente ruim, mas o foco primrio deve permanecer no produto final a entrega de software operante. Entretanto, toda equipe de projeto precisa determinar por si s qual documentao absolutamente essencial. Negociao contratual, sendo o acordo para um projeto interno ou um contrato legal, no uma prtica ruim, apenas insuficiente. Contratos e acordos podem apresentar condies de fronteira nas quais as partes podem trabalhar, mas somente atravs de contnua colaborao que a equipe consegue entender e entregar o que o cliente deseja. Ningum discute que seguir um planejamento uma boa idia certo ? Bem, sim e no. No mundo turbulento dos negcios e tecnologia, seguir escrupulosamente um plano pode ter conseqncias desastrosas, mesmo se o plano for executado fielmente. Portanto, um plano cuidadosamente elaborado, pode se tornar perigoso se ele impedir mudanas. Ns examinamos vrios projetos de sucesso e apenas alguns, se que teve algum, entregaram o que foi planejado inicialmente, ainda que eles tiveram sucesso devido equipe de desenvolvimento que respondia sempre e sempre s mudanas externas. O Manifesto gil: Princpios Nossa prioridade mais alta satisfazer o cliente atravs de entregas contnuas e antecipadas de software vlido. Numa recente workshop, um gerente de desenvolvimento de software questionou a abordagem das funcionalidades e estrias no planejamento de ciclos iterativos. Mas os documentos de especificao de requisitos e arquitetura no so importantes ? ele perguntou. Sim. Respondeu Jim. Eles so importantes, mas ns devemos entender que o cliente no se importa com documentos, diagramas UML ou integrao com o legado. Clientes se importam se voc est ou no entregando software operante para ele a cada ciclo de implantao alguns pedaos da funcionalidade dos negcios que provam para ele que o aplicativo em evoluo serve s suas necessidades. Implementar o princpio valor para o cliente uma das atividades mais fceis de dizer do que de fazer. O gerenciamento tradicional de projeto assume que cumprir um plano igual ao sucesso do projeto que igual a demonstrar valor ao cliente. A volatilidade associada aos projetos de hoje em dia exige que o valor do cliente seja re-avaliado freqentemente, e ir de encontro ao plano do projeto original pode no ter muito impacto no sucesso do projeto. Mudanas nos requisitos so bem-vindas, mesmo as que chegam tarde no desenvolvimento. Processos geis asseguram a mudana como uma vantagem competitiva do cliente. O crescimento da imprevisibilidade do futuro um dos aspectos mais desafiadores da nova economia. Turbulncias nos negcios e na tecnologia causam mudanas, que

3/9

podem ser vistas tanto quanto ameaas a serem evitadas ou como oportunidades a serem abraadas. Ao invs de resistir s mudanas, o enfoque gil se vira para acomod-las da maneira mais fcil e eficiente possvel, enquanto mantendo cincia de suas conseqncias. Embora a maioria das pessoas concorde que feedback importante, elas geralmente ignoram o fato que o resultado do aceite de um feedback uma mudana. Metodologias geis asseguram este resultado pois seus proponentes entendem que facilitar mudanas mais efetivo do que tentar evit-las. Entregar software produtivo freqentemente, de algumas semanas a alguns meses, de preferncia os tempos mais curtos. Por muitos anos, os gurus dos processos vm dizendo para todo mundo utilizar um estilo incremental e iterativo de desenvolvimento de software, atravs de mltiplas entregas com funcionalidades crescentes. Enquanto esta prtica vem crescendo em uso, ela ainda no predominante, entretanto, essencial em projetos geis. Alm do que, ns trabalhamos duro para reduzir o tempo dos ciclos de entrega. Lembrar que entrega no o mesmo que release1. O pessoal do comercial pode ter razes vlidas para no colocar cdigo em produo a cada par de semanas. Temos vistos projetos que no chegam at uma release por mais de anos. Mas isso no os isentam de um rpido ciclo interno de entregas que permite que todos avaliem e aprendam com o produto em crescimento. Pessoal de negcio e desenvolvedores trabalham juntos diariamente durante o projeto. Muitos caras querem comprar software da mesma maneira que compram carros. Eles tm uma lista de caractersticas em mente, negociam o preo e pagam por aquilo que pediram. Este modelo simples de compra chamativo, mas para a maioria dos projetos de software, no funciona. Assim, desenvolvedores geis respondem com uma mudana radical no nosso conceito do processo de requisitos. De incio, ns no esperamos um conjunto detalhado de requisitos para ser assinado no incio do projeto; ao invs, ns temos uma viso de alto nvel dos requisitos que sujeita a freqentes mudanas. Claramente, isso no suficiente para projetar nem codificar, ento a lacuna preenchida com interaes freqentes entre o pessoal de negcio e os desenvolvedores. A freqncia deste contato geralmente surpreende as pessoas. Ns colocamos dirio a princpio para enfatizar que o contnuo comprometimento do cliente seja parte, e de fato divida a responsabilidade, do projeto de software. Criar projetos em torno de indivduos motivados, proporcionar o ambiente e suporte que eles necessitam e confiar que eles faro o servio. Implante todas as ferramentas, tecnologias e processos que voc quiser, at o nosso processo gil, mas no final, so as pessoas que fazem a diferenas entre sucesso e falha. Ns percebemos, entretanto, que quanto mais duro a gente trabalhava em idias de processos, o melhor que podamos esperar era um efeito de segunda ordem no projeto. Ento importante maximizar o fator humano de primeira ordem.

4/9

Para muitas pessoas, confiana a coisa mais difcil de se passar. Decises devem ser tomadas pelas pessoas que mais conhecem a situao. Isto significa que os gerentes devem confiar suas equipes as decises das coisas que eles so pagos para conhecer. O mtodo mais eficiente e efetivo para transmitir informaes entre e para a equipe de desenvolvimento converso cara a cara. Inevitavelmente, quando discutimos metodologias geis, surge o tpico da documentao. Nossos oponentes muitas vezes aparecem furiosos, zombando da nossa falta de documentao. Isso suficiente para nos fazer gritar, o caso no documentao entendimento! Sim, documentos fsicos tm peso e substncia, mas a medida real do sucesso abstrata. Ser que as pessoas envolvidas ganham o entendimento que precisam ? Muitos de ns somos escritores, mas independente de nossos prmios e vendas de livros, ns sabemos que escrever difcil e um meio ineficiente de comunicao. Ns o utilizamos pois temos que, porm muitas equipes de projeto podem e devem utilizar uma tcnica mais direta de comunicao. Conhecimento tcito no pode ser transferido extraindo-o da cabea das pessoas para o papel, escreveu Nancy Dixon em Common Knowledge (Hardvard Business School Press, 2000). Conhecimento tcito pode ser transferido movendo ao redor as pessoas que o detm. A razo que o conhecimento tcito no somente fatos mas relacionamentos entre fatos isto , a maneira que pessoas podem combinar certos fatos para lidarem com uma situao especfica. Ento a distino entre gil e metodologias centradas em documentos no documentao extensiva versus sem documentao; mas sim um conceito distinto que mistura a documentao e conversao requerida para obter o entendimento. Software produtivo a medida primria do progresso. Freqentemente, ns vemos equipes de projetos que no percebem que esto em perigo at um pouco antes da entrega. Eles fizeram os requisitos no prazo, o projeto no prazo e talvez at os cdigos no prazo, mas os testes e a integrao levaram muito mais tempo do que eles imaginaram. Ns somos a favor primariamente do desenvolvimento iterativo pois ele fornece marcos2 que no podem ser burlados, os quais transmitem uma medida precisa do progresso e profundo entendimento dos riscos envolvidos num dado projeto. Como Chet Hendrickson, co-autor de Extreme Programming Installed (Addison-Wesley, 2000), lembra, Se um projeto vai falhar, eu prefiro saber depois de um ms do que depois de 15. Software produtivo a medida do progresso porque no h outra forma de se capturar as sutilezas dos requisitos: Documentos e diagramas so muito abstratos para permitir que o usurio saiam cantando os pneus, disse Dave Thomas, co-autor do The Pragmatic Programmer (Addison-Wesley, 1999). Processos geis promovem um desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. Nossa indstria caracterizada por longas noites e finais de semana, durante os quais as pessoas tentam desfazer os erros dos planejamentos irresponsveis. Ironicamente, estas longas horas na verdade no levam a grande produtividade. Martin e Kent Beck sempre

5/9

se lembram de empresas que gastam o dia inteiro removendo os erros feitos na noite anterior. Agilidade depende de pessoas que esto alertas e criativas, e conseguem manter esta ateno e criatividade durante todo o projeto de desenvolvimento de software. Desenvolvimento sustentvel significa encontrar um ritmo de trabalho (40 ou tantas horas por semana) que a equipe consiga sustentar durante todo tempo e permanecer saudvel. Ateno contnua excelncia tcnica e boa soluo3 melhoram a agilidade. Muitas pessoas quando olham para o desenvolvimento gil vem traos do esforo rpido e sujo RAD (Rapid Application Development) da ltima dcada. Mas, enquanto o desenvolvimento gil similar ao RAD em termos de velocidade de flexibilidade, h uma grande diferena quando surge a clareza tcnica. Abordagens geis enfatizam a qualidade da soluo porque soluo de qualidade essencial para manter a agilidade. Um dos aspectos capciosos, no entanto, o fato de que os processos geis assumem e encorajam a alterao dos requisitos enquanto o cdigo vai sendo escrito. Tal qual o projeto no pode puramente ser uma atividade antecipada a ser completada antes da construo. Ao invs, o ato de projetar uma atividade contnua que realizada durante todo o ciclo do projeto. Cada e toda iterao tero o trabalho de projetar. A diferena que os processos geis enfatizam os diferentes estilos de projeto. FDD [Feature-Driven Development] tem um passo explcito no incio de cada iterao no qual a soluo executada, usualmente graficamente com UML. XP deposita grande nfase na re-fabricao para permitir que o projeto evolua na medida que o desenvolvimento prossegue. Mas todos estes processos pedem emprestados uns para os outros: FDD usa a re-fabricao quando os desenvolvedores re-visitam decises anteriores de projeto, e XP encoraja pequenas sesses de projeto antes da codificao. Em todos os casos, a soluo continuamente melhorada durante o projeto. Simplicidade a arte de maximizar a quantidade de trabalho no feita essencial. Qualquer tarefa de desenvolvimento de software pode ser abordada por uma variedade de mtodos. No projeto gil, particularmente importante utilizar abordagens simples, pois elas so mais fceis de mudar. mais fcil acrescentar alguma coisa num processo muito simples do que tirar alguma coisa de um processo muito complicado. Por isso, h um grande gosto pelo minimalismo em todos os mtodos geis. Inclua somente aquilo que todos precisam ao invs daquilo que algum precisa, para facilitar a incluso de alguma coisa quando uma equipe especfica precisar. Simples, de princpios e propsitos claros criam comportamentos complexos e inteligentes, disse Dee Hock, ex-CEO da Visa International. Regras complexas e regulamentos criam comportamentos simples e estpidos. Nenhuma metodologia pode atender a toda complexidade dos modernos projetos de software. Dar s pessoas um conjunto simples de regas e encoraj-las na criatividade produzir um resultado muito melhor do que impor regras e regulamentos complexos.

6/9

As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas. Ao contrrio do que voc tem ouvido, forma no quer dizer funo. Forma quer dizer falha. A forma de fazer as coisas est sempre sujeita mudana em resposta s imperfeies reais ou percebidas, elas deixam de funcionar devidamente, escreveu Henry Petroski, professor de engenharia civil e autor do The Evolution of Useful Things (Vintage Books, 1994). Stuart Brand escreve que a idia forma quer dizer funo vem enganando arquitetos na crena que eles podem prever como os prdios sero de fato utilizados. As vises de Petroski so similares a um dos dois pontos deste princpio que os melhores projetos (arquiteturas e requisitos) emergem do desenvolvimento iterativo e uso ao invs de planos antecipados. O segundo ponto do princpio que propriedades emergentes (emergncia, propriedade chave dos sistemas complexos, aproximadamente traduzida por inovao e criatividade em organizaes humanas) so melhores quando geradas a partir de equipes auto-organizadas com alta interatividade e poucas regras de processo. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva e ento sintoniza e ajusta seu comportamento de forma apropriada. Mtodos geis no so alguma coisa que voc pega e segue religiosamente. Voc pode comear com um daqueles processos [citados acima], mas ns todos reconhecemos que no podemos aparecer com o processo certo para toda situao. Assim, qualquer equipe gil deve refinar e refletir durante o caminho, constantemente melhorando suas prticas para as situaes locais. Jim tem trabalhado com consultorias para desenvolver a Adaptive Software Development combinao da metodologia Extreme Programming. A primeira equipe que a utilizou, a modificou de imediato. Martin tem trabalhado com um grande nmero de equipes na ThoughtWorks para customizar4 as prticas da Extreme Programming s vrias situaes dos projetos. Confiar nas pessoas, acreditar nas capacidades individuais e na interao do grupo so chaves para o sucesso que se estendem em equipes confiveis que monitoram e melhoram seus prprios processos de desenvolvimento. Rumo ao Futuro gil As respostas ao Manifesto gil tm sido gratificantes. Muitos e-mails expressam sentimentos tais como, Meu gerente de produto colocou o Manifesto na sua parede. Muitos dos colegas do Martin na ThoughtWorks deram uma passada para dizer o quanto eles compartilhavam dos valores. Uma questo levantada de imediato foi se a Aliana ou no a precursora da, conforme disse um participante, Metodologia Peso-Leve Unificada [Unified Lightweight Methodology]. Absolutamente no! Enquanto o grupo acredita que um conjunto de propsitos e princpios comuns beneficiar os usurios de metodologias geis, ns somos igualmente convictos que a variedade e diversidade de prticas so necessrias. Quando isso vai para as metodologias, cada projeto distinto e cada equipe de projeto distinta no h uma soluo tamanho nico.

7/9

E o futuro ? Podemos confiantemente dizer que no sabemos. Agilidade est mais para confiana na habilidade das pessoas de responderem a eventos imprevisveis do que na confiana da habilidade delas de previso. Ns tambm sabemos que o relacionamento pessoal formado em nossa colaborao, de longe, importa mas do que o documento que produzimos. Uma coisa clara: estamos apenas comeando.
O Manifesto para o Desenvolvimento gil de Software Dezessete anarquistas concordam: Ns estamos descobrindo maneiras melhores de se desenvolver software, desenvolvendo e ajudando outras pessoas a desenvolver. Ns valorizamos: Indivduos e interaes ao invs de processos e ferramentas Software operante ao invs de documentaes completas Colaborao do cliente ao invs de negociaes contratuais Responder mudanas ao invs de seguir um planejamento Isto , enquanto ns valorizamos os itens da direita, ns valorizamos mais os itens da esquerda. Ns seguimos os seguintes princpios: Nossa prioridade mais alta satisfazer o cliente atravs de entregas contnuas e antecipadas de software vlido. Mudanas nos requisitos so bem-vindas, mesmo as que chegam tarde no desenvolvimento. Processos geis asseguram a mudana como uma vantagem competitiva do cliente. Entregar software produtivo freqentemente, de algumas semanas a alguns meses, de preferncia os tempos mais curtos. Pessoal de negcio e desenvolvedores trabalham juntos diariamente durante o projeto. Criar projetos em torno de indivduos motivados, proporcionar o ambiente e suporte que eles necessitam e confiar que eles faro o servio. O mtodo mais eficiente e efetivo para transmitir informaes entre e para a equipe de desenvolvimento converso cara a cara. Software produtivo a medida primria do progresso. Processos geis promovem um desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. Ateno contnua excelncia tcnica e boa soluo melhoram a agilidade. Simplicidade a arte de maximizar a quantidade de trabalho no feita essencial. As melhores arquiteturas, requisitos e projetos emergem de equipes autoorganizadas. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva e ento sintoniza e ajusta seu comportamento de forma apropriada.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas www.agilealliance.org Agosto de 2001

8/9

Notas da Traduo: 1 2 3 4 deliver foi traduzido com entrega porm optou-se por deixar release no original no original milestones project foi traduzido como projeto no sentido de atividade em andamento e design, embora tambm projeto, foi traduzido como soluo no original tailor

Joo Rotta Neto joaorotta@hotmail.com Junho de 2002

9/9