Metodologias geis Extreme Programming e Scrum para o Desenvolvimento de Software

Michel dos Santos Soares1

1

Universidade Presidente Antnio Carlos, BR 482 Km 3, Gigante, Conselheiro Lafaiete, MG, Brasil michelssoares@yahoo.com.br

Resumo - Este artigo apresenta algumas vantagens das metodologias geis para desenvolver software em relao s metodologias tradicionais. Em particular so apresentadas as principais caractersticas e as prticas das metodologias geis Extreme Programming e Scrum. Tambm so feitas comparaes com as metodologias tradicionais, procurando enfatizar que as metodologias geis so baseadas em pessoas e no em processos e planejamentos. Finalmente so apresentadas as principais vantagens e desvantagens da Extreme Programming e da Scrum. Tambm so apresentados alguns resultados empricos do uso de metodologias geis. Palavras-chave: Engenharia de Software, Metodologias geis, Extreme Programming, Scrum Abstract This paper shows some advantages of agile methodologies for software development comparing with traditional ones. In particular Extreme Programming and Scrum are presented with its characteristics and practices. Also are done comparisons with traditional methodologies, emphasizing that agile methodologies are based on people instead of process and planning. Finally the principal advantages and disadvantages of the use of Extreme Programming and Scrum are presented. Also some empirical results of the use of agile methodologies are presented. Key-words: Software Engineering, Agile Methodologies, Extreme Programming, Scrum

Introduo As metodologias geis para desenvolvimento de software so uma resposta s chamadas metodologias pesadas ou tradicionais. Mesmo com a evoluo dos computadores, das tcnicas e ferramentas nos ltimos anos, a produo de software confivel, correto e entregue dentro dos prazos e custos estipulados ainda muito difcil. Dados de 1995 [1], usando como base 8380 projetos, mostram que apenas 16,2% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades especificadas. Aproximadamente 31% dos projetos foram cancelados antes de estarem completos e 52,7% foram entregues, porm com prazos maiores, custos maiores ou com menos funcionalidades do que especificado no incio do projeto. Dentre os projetos que no foram finalizados de acordo com os prazos e custos especificados, a mdia de atrasos foi de 222%, e a mdia de custo foi de 189% a mais do que o previsto. Considerando todos os projetos que foram entregues alm do prazo e com custo maior, na mdia, apenas 61% das funcionalidades originais foram includas. Mesmo os projetos cuja entrega feita respeitando os limites de prazo e custo possuem qualidade suspeita, uma vez que provavelmente foram feitos com muita presso sobre os

desenvolvedores, o que pode quadruplicar o nmero de erros de software, segundo a mesma pesquisa. As principais razes destas falhas estavam relacionadas com o processo em Cascata. A recomendao final foi que o desenvolvimento de software deveria ser baseado em modelos incrementais, o que poderia evitar muitas das falhas reportadas. Processos orientados a documentao para o desenvolvimento de software, como o modelo em Cascata, so de certa forma fatores limitadores aos desenvolvedores. Alm disso, muitas organizaes no possuem recursos ou inclinao para processos pesados de produo de software. Por esta razo, muitas organizaes, particularmente as pequenas, acabam por no usar nenhum processo, o que pode levar a efeitos desastrosos em termos de qualidade de software. Torna-se necessrio, ento, utilizar metodologias geis, que no so orientadas documentao nem tampouco se preocupam apenas com a codificao. A maioria das metodologias geis nada possuem de novo [2]. O que as diferencia das metodologias tradicionais so o enfoque e os valores. A idia das metodologias geis o enfoque nas pessoas e no em processos ou algoritmos. Alm disso, existe a preocupao de gastar menos tempo com documentao e mais com a implementao. Uma caracterstica das

metodologias geis que elas so adaptativas ao invs de serem preditivas. Com isso, elas se adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invs de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento. Apesar do uso crescente das metodologias geis, ainda falta uma base maior de projetos para verificar suas vantagens. Mesmo assim, os resultados iniciais em termos de qualidade, confiana, datas de entrega e custo so promissores. Para ser realmente considerada gil a metodologia deve aceitar a mudana ao invs de tentar prever o futuro. O problema no a mudana em si, mesmo porque ela ocorrer de qualquer forma. O problema como receber, avaliar e responder s mudanas. Enquanto as metodologias geis variam em termos de prticas e nfases, elas compartilham algumas caractersticas, como desenvolvimento iterativo e incremental, comunicao e reduo de produtos intermedirios, como documentao extensiva. Desta forma existem maiores possibilidades de atender aos requisitos do cliente, que muitas vezes so mutveis. Dentre as vrias metodologias geis existentes, as mais conhecidas so a Extreme Programming [3] e a Scrum [4]. Metodologia Um exemplo de uma metodologia tradicional ou pesada o modelo em Cascata [5], que composto basicamente por atividades seqenciais de levantamento de requisitos, anlise, projeto, implementao, teste, implantao e manuteno. Este modelo derivado de outras engenharias tradicionais (Civil, Eltrica, Naval,...) e foi o primeiro a ser usado pela Engenharia de Software, na dcada de 70. O termo Engenharia de Software surgiu em uma conferncia no final da dcada de 60 [6]. A proposta inicial era a sistematizao do desenvolvimento de software, que deveria ser tratado com engenharia e no como arte. Desta forma, a idia foi propor a utilizao de mtodos, ferramentas e tcnicas para a produo de software confivel, correto e entregue respeitando os prazos e custos definidos. Apesar de toda evoluo desde que o termo foi criado, o nmero de fracassos em projetos de software ainda alto. O modelo em Cascata dominou a forma de desenvolvimento de software at o incio da dcada de 90, apesar das advertncias dos pesquisadores da rea e dos desenvolvedores,

que identificaram os problemas gerados ao se adotar esta viso seqencial de tarefas. Por exemplo, Fred Brooks em seu famoso artigo No Silver Bullet: Essence and Accidents of Software Engineering, descreve que a idia de especificar totalmente um software antes do incio de sua implementao impossvel [7]. Outro pesquisador, Tom Gilb, desencoraja o uso do modelo em Cascata para grandes softwares, estimulando o desenvolvimento incremental como um modelo que apresenta menores riscos e maiores possibilidades de sucesso [8]. As metodologias pesadas devem ser aplicadas apenas em situaes em que os requisitos do software so estveis e requisitos futuros so previsveis. Estas situaes so difceis de serem atingidas, uma vez que os requisitos para o desenvolvimento de um software so mutveis. Dentre os fatores responsveis por alteraes nos requisitos esto a dinmica das organizaes, as alteraes nas leis e as mudanas pedidas pelos stakeholders, que geralmente tm dificuldades em definir o escopo do futuro software.

Figura 1 - custo de mudana no projeto no modelo em cascata O grfico da Figura 1 apresenta o custo de alterar requisitos de software em vrias fases do desenvolvimento ao se usar o modelo em Cascata. Pelo grfico fica claro que o custo de alteraes no modelo em Cascata cresce de forma exponencial de acordo com as fases do projeto. Desta forma, estima-se que caso alguma alterao tenha como custo 1x quando feita na fase de requisitos, ela ter um custo de 60x a 100x quando feita na fase de implantao [5]. Portanto, alteraes nos requisitos no modelo em Cascata no so desejveis.

Extreme Programming A Extreme Programming (XP) uma metodologia gil para equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente [3]. Dentre as principais diferenas da XP em relao s outras metodologias esto: Figura 2 custo de mudanas no projeto com metodologias geis Como alteraes em requisitos so comuns, a curva ideal deveria ser a da Figura 2, em que o custo no cresce muito mesmo quando alteraes so feitas em fases avanadas do desenvolvimento. O grfico da Figura 2 apresenta o custo de mudanas nas metodologias geis. Na verdade, as metodologias geis incentivam a mudana nos requisitos, pois desta forma possvel realmente entregar ao cliente o produto que ele precisa. O termo metodologias geis tornou-se popular em 2001 quando dezessete especialistas em processos de desenvolvimento de software representando os mtodos Extreme Programming (XP), Scrum, DSDM, Crystal e outros, estabeleceram princpios comuns compartilhados por todos esses mtodos. O resultado foi a criao da Aliana gil e o estabelecimento do Manifesto gil (Agile Manifesto) [9]. Os conceitos chave do Manifesto gil so: Indivduos e interaes ao invs processos e ferramentas. Software executvel ao invs documentao. Colaborao do cliente ao invs negociao de contratos. Respostas rpidas a mudanas invs de seguir planos. de de de ao Feedback constante Abordagem incremental A comunicao entre as pessoas encorajada.

O Manifesto gil no rejeita os processos e ferramentas, a documentao, a negociao de contratos ou o planejamento, mas simplesmente mostra que eles tm importncia secundria quando comparado com os indivduos e interaes, com o software estar executvel, com a colaborao do cliente e as respostas rpidas a mudanas e alteraes. Esses conceitos aproximam-se melhor com a forma que pequenas companhias de Tecnologia da Informao trabalham e respondem a mudanas. Entre as metodologias geis a mais conhecida a Extreme Programming.

O primeiro projeto a usar XP foi o C3, da Chrysler. Aps anos de fracasso utilizando metodologias tradicionais, com o uso da XP o projeto ficou pronto em pouco mais de um ano [10]. A maioria das regras da XP causa polmica primeira vista e muitas no fazem sentido se aplicadas isoladamente. a sinergia de seu conjunto que sustenta o sucesso de XP, encabeando uma verdadeira revoluo no desenvolvimento de software. A XP enfatiza o desenvolvimento rpido do projeto e visa garantir a satisfao do cliente, alm de favorecer o cumprimento das estimativas. As regras, prticas e valores da XP proporcionam um agradvel ambiente de desenvolvimento de software para os seus seguidores, que so conduzidos por quatro valores: comunicao, simplicidade, feedback e coragem [3]. A finalidade do princpio de comunicao manter o melhor relacionamento possvel entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicao. A comunicao entre os desenvolvedores e o gerente do projeto tambm encorajada. A simplicidade visa permitir a criao de cdigo simples que no deve possuir funes desnecessrias. Por cdigo simples entende-se implementar o software com o menor nmero possvel de classes e mtodos. Outra idia importante da simplicidade procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. A aposta da XP que melhor fazer algo simples hoje e pagar um pouco mais amanh para fazer modificaes necessrias do que implementar algo complicado hoje que talvez no venha a ser usado, sempre considerando que requisitos so mutveis. A prtica do feedback constante significa que o programador ter informaes constantes do cdigo e do cliente. A informao do cdigo dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Em relao ao cliente, o feedback constante significa que ele ter freqentemente

uma parte do software totalmente funcional para avaliar. O cliente ento constantemente sugere novas caractersticas e informaes aos desenvolvedores. Eventuais erros e no conformidades so rapidamente identificados e corrigidos nas prximas verses. Desta forma, a tendncia que o produto final esteja de acordo com as expectativas reais do cliente. necessrio coragem para implantar os trs valores anteriores. Por exemplo, no so todas as pessoas que possuem facilidade de comunicao e tm bom relacionamento. A coragem tambm d suporte simplicidade, pois assim que a oportunidade de simplificar o software percebida, a equipe pode experimentar. Alm disso, preciso coragem para obter feedback constante do cliente. A XP baseia-se nas 12 prticas [3] a seguir: Planejamento: consiste em decidir o que necessrio ser feito e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, no em requisitos futuros. Alm disso, a XP procura evitar os problemas de relacionamento entre a rea de negcios (clientes) e a rea de desenvolvimento. As duas reas devem cooperar para o sucesso do projeto, e cada uma deve focar em partes especficas do projeto. Desta forma, enquanto a rea de negcios deve decidir sobre o escopo, a composio das verses e as datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma detalhado para que o software seja entregue nas datas especificadas. Entregas freqentes: visa construo de um software simples, e conforme os requisitos surgem, h a atualizao do software. Cada verso entregue deve ter o menor tamanho possvel, contendo os requisitos de maior valor para o negcio. Idealmente devem ser entregues verses a cada ms, ou no mximo a cada dois meses, aumentando a possibilidade de feedback rpido do cliente. Isto evita surpresas caso o software seja entregue aps muito tempo, melhora as avaliaes e o feedback do cliente, aumentando a probabilidade do software final estar de acordo com os requisitos do cliente. Metfora: so as descries de um software sem a utilizao de termos tcnicos, com o intuito de guiar o desenvolvimento do software. Projeto simples: o programa desenvolvido pelo mtodo XP deve ser o mais simples

possvel e satisfazer os requisitos atuais, sem a preocupao de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem. Esta forma de raciocnio se ope ao implemente para hoje e projete para amanh. Testes: a XP focaliza a validao do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando primeiramente os testes. Refatorao: focaliza o aperfeioamento do projeto do software e est presente em todo o desenvolvimento. A refatorao deve ser feita apenas quando necessrio, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que possvel simplificar o mdulo atual sem perder nenhuma funcionalidade. Programao em pares: a implementao do cdigo feita em dupla, ou seja, dois desenvolvedores trabalham em um nico computador. O desenvolvedor que est com o controle do teclado e do mouse implementa o cdigo, enquanto o outro observa continuamente o trabalho que est sendo feito, procurando identificar erros sintticos e semnticos e pensando estrategicamente em como melhorar o cdigo que est sendo implementado. Esses papis podem e devem ser alterados continuamente. Uma grande vantagem da programao em dupla a possibilidade dos desenvolvedores estarem continuamente aprendendo um com o outro. Propriedade coletiva: o cdigo do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um cdigo, mesmo que ele prprio no o tenha desenvolvido, pode faz-lo, desde que faa a bateria de testes necessria. Isto possvel porque na XP todos so responsveis pelo software inteiro. Uma grande vantagem desta prtica que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto com poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que no seja de forma detalhada. Integrao contnua: interagir e construir o sistema de software vrias vezes por dia, mantendo os programadores em sintonia, alm de possibilitar processos rpidos. Integrar apenas um conjunto de modificaes de cada vez uma prtica que funciona bem porque fica bvio quem

deve fazer as correes quando os testes falham: a ltima equipe que integrou cdigo novo ao software. Esta prtica facilitada com o uso de apenas uma mquina de integrao, que deve ter livre acesso a todos os membros da equipe. 40 horas de trabalho semanal: a XP assume que no se deve fazer horas extras constantemente. Caso seja necessrio trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema srio no projeto que deve ser resolvido no com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prtica procura ratificar o foco nas pessoas e no em processos e planejamentos. Caso seja necessrio, os planos devem ser alterados, ao invs de sobrecarregar as pessoas. Cliente presente: fundamental a participao do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponvel para sanar todas as dvidas de requisitos, evitando atrasos e at mesmo construes erradas. Uma idia interessante manter o cliente como parte integrante da equipe de desenvolvimento. Cdigo padro: padronizao na arquitetura do cdigo, para que este possa ser compartilhado entre todos os programadores.

requisitos pouco estveis ou desconhecidos e iteraes curtas para promover visibilidade para o desenvolvimento. No entanto, as dimenses em Scrum diferem de XP. A Scrum divide o desenvolvimento em iteraes (sprints) de trinta dias. Equipes pequenas, de at dez pessoas, so formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (os requisitos, em outras palavras) definidas no incio de cada sprint. A equipe responsvel pelo desenvolvimento desta funcionalidade. Na Scrum existem reunies de acompanhamento dirias. Nessas reunies, que so preferencialmente de curta durao (aproximadamente quinze minutos), so discutidos pontos como o que foi feito desde a ltima reunio e o que precisa ser feito at a prxima. As dificuldades encontradas e os fatores de impedimento (bottlenecks) so identificados e resolvidos. O ciclo de vida da Scrum baseado em trs fases principais, divididas em sub-fases: 1. Pr-planejamento (Pre-game phase): os requisitos so descritos em um documento chamado backlog. Posteriormente eles so priorizados e so feitas estimativas de esforo para o desenvolvimento de cada requisito. O planejamento inclui tambm, entre outras atividades, a definio da equipe de desenvolvimento, as ferramentas a serem usadas, os possveis riscos do projeto e as necessidades de treinamento. Finalmente proposta uma arquitetura de desenvolvimento. Eventuais alteraes nos requisitos descritos no backlog so identificadas, assim como seus possveis riscos. 2. Desenvolvimento (game phase): as muitas variveis tcnicas e do ambiente identificadas previamente so observadas e controladas durante o desenvolvimento. Ao invs de considerar essas variveis apenas no incio do projeto, como no caso das metodologias tradicionais, na Scrum o controle feito continuamente, o que aumenta a flexibilidade para acompanhar as mudanas. Nesta fase o software desenvolvido em ciclos (sprints) em que novas funcionalidades so adicionadas. Cada um desses ciclos desenvolvido de forma tradicional, ou seja, primeiramente faz-se a anlise, em seguida o projeto, implementao e testes. Cada um desses ciclos planejado para durar de uma semana a um ms. 3. Ps-planejamento (post-game phase): aps a fase de desenvolvimento so

Scrum Outra metodologia gil que apresenta uma comunidade grande de usurios a Scrum [4]. Seu objetivo fornecer um processo conveniente para projeto e desenvolvimento orientado a objeto. A Scrum apresenta uma abordagem emprica que aplica algumas idias da teoria de controle de processos industriais para o desenvolvimento de softwares, reintroduzindo as idias de flexibilidade, adaptabilidade e produtividade. O foco da metodologia encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexvel e em um ambiente em constante mudana. A idia principal da Scrum que o desenvolvimento de softwares envolve muitas variveis tcnicas e do ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisvel e complexo, requerendo flexibilidade para acompanhar as mudanas. O resultado do processo deve ser um software que realmente til para o cliente [11]. A metodologia baseada em princpios semelhantes aos da XP: equipes pequenas,

feitas reunies para analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase so feitas as etapas de integrao, testes finais e documentao. Ferramentas de apoio Por serem metodologias relativamente novas, existem poucas ferramentas disponveis que suportem o processo gil de desenvolvimento. Dentre as existentes, a maioria suporta apenas a Extreme Programming e ainda esto em fase de pesquisa e desenvolvimento. A mais conhecida a XPlanner [12], que uma ferramenta de cdigo livre usada para auxiliar o planejamento da Extreme Programming. O desenvolvimento desta ferramenta ainda est em progresso, mas j existe uma verso estvel para o gerenciamento de estrias do usurio, gerenciamento de tarefas, verificao de progresso do projeto e gerenciamento das mtricas individuais e da equipe. Atualmente existe suporte para vrios idiomas, dentre eles o francs, o espanhol, o chins, o italiano, o alemo e o portugus. Dentre as funcionalidades futuras da ferramenta esto a integrao com outras metodologias geis, em especial a Scrum. Resultados As metodologias geis ainda esto em sua infncia, mas j apresentam resultados efetivos. Por exemplo, um artigo [13] comparando mtodos geis com as metodologias tradicionais pesadas mostrou que os projetos usando os mtodos geis obtiveram melhores resultados em termos de cumprimento de prazos, de custos e padres de qualidade. Alm disso, o mesmo estudo mostra que o tamanho dos projetos e das equipes que utilizam as metodologias geis tm crescido. Apesar de serem propostas idealmente para serem utilizadas por equipes pequenas e mdias (at 12 desenvolvedores), aproximadamente 15% dos projetos que usam metodologias geis esto sendo desenvolvidos por equipes de 21 a 50 pessoas, e 10% dos projetos so desenvolvidos por equipes com mais de 50 pessoas, considerando um universo de 200 empresas usado no estudo. Em relao qualidade do software, de acordo com [14] e [15] o uso correto da XP pode levar a organizao a atingir os nveis CMM [16] 2 e 3, apesar do CMM ser orientado a metodologias tradicionais e ter como foco o qu fazer, enquanto a XP enfoca o como fazer. Juntos estes mtodos formam um framework para estruturar o desenvolvimento de software de uma organizao. Na Boeing a XP foi usada antes de serem implementadas as idias de CMM. Verificou-se que no foram necessrias muitas

alteraes nos processos para que a Boeing fosse certificada com o nvel 5 da CMM [17]. A XP ideal para ser usada em projetos em que os stakeholders no sabem exatamente o que desejam e podem mudar muito de opinio durante o desenvolvimento do projeto. Com feedback constante, possvel adaptar rapidamente eventuais mudanas nos requisitos. Um outro ponto positivo so as entregas constantes de partes operacionais do software. Desta forma, o cliente no precisa esperar muito para ver o software funcionando, como nas metodologias tradicionais. A integrao e o teste contnuos tambm possibilitam a melhora na qualidade do software. No mais necessrio existir uma fase de integrao de mdulos, uma vez que eles so continuamente integrados e eventuais problemas so resolvidos constantemente. A XP apresenta algumas desvantagens e problemas identificados, e tem recebido algumas crticas. Muitos acreditam que a XP a volta ao processo catico de desenvolvimento de software, conhecido tambm como codificaremenda [5]. Este modelo catico existe principalmente em pequenas e mdias organizaes que no podem suportar os altos custos de desenvolvimento ao se usar metodologias tradicionais. A XP possui a tendncia de eliminar vrias boas prticas que existiram durante vrios anos do desenvolvimento de software. Por exemplo, a anlise do problema por meio de diagramas. Obviamente no se deve projetar vrios diagramas, muitos dos quais nunca sero consultados. Mas importante projetar alguns modelos que ajudaro no entendimento do problema. A anlise de requisitos parece ser muito informal, e em alguns casos dificilmente funcionaria assim. A informalidade na captura de requisitos pode no ser bem vista pelos clientes, que podem se sentir inseguros. Outra possibilidade de insegurana a refatorao de cdigo, que pode ser vista pelos clientes como amadorismo e incompetncia. Na XP no existe a preocupao formal em fazer a anlise e o planejamento de riscos. Como riscos acontecem normalmente em projetos de desenvolvimento de software, este um ponto negativo da XP. Deve-se, portanto, procurar implementar uma estratgia de gesto de riscos sem tornar a metodologia muito complexa. De forma geral, as 12 prticas da XP apiam-se mutuamente. Portanto, deve-se procurar aplic-las totalmente, ou a maior parte possvel. Por exemplo, no usar a programao em dupla pode atrapalhar a prtica do cdigo ser de propriedade coletiva. Apesar disso, elas podem ser de certa forma adaptadas realidade das organizaes. A implantao de todas as

prticas pode ser confusa, levando ao abandono prematuro da XP. Segundo Beck [3], as prticas da XP podem ser implantadas uma a uma para que sejam evitadas confuses, desentendimentos e presses, pois a equipe sobre presso tem a tendncia de voltar a aplicar as prticas anteriores. Em relao metodologia Scrum, existem vrios casos de sucesso relatados [18]. Segundo Schwaber e Beedle [4], a Scrum deve ser usada em equipes de at 10 pessoas. Em projetos que precisam de equipes maiores, deve-se dividir as pessoas em equipes de at 10 pessoas. Isto necessrio para melhorar a comunicao entre as pessoas da equipe. Discusso e Concluses As Metodologias geis tm sido bem aceitas pela indstria de software e por pesquisadores da Engenharia de Software. Apesar de no haver ainda uma grande base de comparaes os primeiros resultados tm sido satisfatrios. De certa forma, apesar da XP ser uma metodologia nova e ser considerada por muitos como uma revoluo, ela no apresenta muitos pontos revolucionrios. Na verdade, a XP agrupa uma srie de prticas que tm sido usadas desde o incio da computao eletrnica, como a programao em duplas e a propriedade coletiva do cdigo. possvel fazer uma analogia do futuro das metodologias geis com as metodologias para desenvolvimento de software orientadas a objeto. Da mesma forma que vrias metodologias de desenvolvimento orientadas a objeto surgiram e competiram entre si, surgiram tambm vrias metodologias geis. No caso da orientao a objetos houve um esforo de padronizao que resultou na notao UML [19], que atualmente um padro na indstria de software mundial. Da mesma forma, futuramente possvel que as vrias metodologias geis unam-se, principalmente em torno da XP, por ser a mais aceita. Existe, por exemplo, um movimento para o uso conjunto da XP com a Scrum. A XP seria usada para a fase de desenvolvimento e a Scrum para o planejamento e gerenciamento do projeto. A integrao das duas metodologias seria relativamente simples, uma vez que elas compartilham algumas caractersticas, como a necessidade da presena do cliente, pequenas liberaes e o encorajamento em fazer as mudanas necessrias para atender requisitos reais dos stakeholders. Existe inclusive a proposta da metodologia hbrida XP@Scrum [20]. Apesar de no existirem estudos empricos suficientes, alguns autores recomendam o uso em conjunto da Scrum e da XP para grandes projetos [20].

Atualmente o autor est coordenando um projeto de pesquisa em que a XP usada para o desenvolvimento de softwares baseados em Web. Como a Web um ambiente de desenvolvimento dinmico e com mudanas constantes, as metodologias tradicionais orientadas a documentao so menos adequadas que as metodologias geis. Uma idia a ser implantada futuramente neste projeto de pesquisa a integrao da XP com outras metodologias geis, como a Scrum. Neste caso os aspectos de gerenciamento de projetos da Scrum sero integrados com as prticas da XP. O desafio futuro das Metodologias geis encontrar meios de eliminar alguns de seus pontos fracos, como a falta de anlise de riscos, sem torn-las metodologias pesadas. Outro desafio como usar essas metodologias em grandes empresas e equipes, uma vez que normalmente essas metodologias so baseadas em equipes pequenas. Neste caso, pelo menos necessrio resolver os problemas de comunicao internos na equipe, uma vez que comum em grandes empresas os funcionrios estarem separados geograficamente. Apesar do interesse nas metodologias geis, ainda faltam casos de sucesso de seu uso em projetos grandes e crticos. Referncias 1.

Standish Group, CHAOS report, 586 Olde Kings Highway, Dennis, MA 02638, USA, (1995)

2. Cockburn, A. e Highsmith, J. "Agile Software Development: The Business of Innovation", IEEE Computer, Sept., (2001), pp. 120-122 3. Beck, K., Programao Extrema Explicada , Bookman, (1999) 4. Schwaber, K. e Beedle, M. "Agile Software Development with SCRUM", Prentice-Hall, (2002) 5. Pressman, R. Engenharia de Software McGraw-Hill, (2001) 6. Naur, P. e Randell, B. Software Engineering: Report on a Conference sponsored by the NATO science committee. 7-11 October, Garmisch, Germany, (1968) 7. Brooks, F., No Silver Bullet: Essence

and Accidents of Software Engineering Proc. IFIP, IEEE CS Press, 1987, pp. 1069-1076; reprinted in IEEE Computer, Apr, (1987), pp. 10-19
8. Gilb, T., Principles of Engineering Management, Wesley, (1988) Software Addison-

9. Agile Manifesto, http://agilemanifesto.org/, acessado em 25 de Setembro de 2004 10. Highsmith, J. Orr, K. Cockburn, A. "Extreme Programming", E-Business Application Delivery, Feb., (2000), pp. 417 11. Schwaber, K. "Scrum Development Process", OOPSLA'95 Workshop on Business Object Design and Implementation. Springer-Verlag. (1995) 12. XPlanner,http://www.xplanner.org/, acessado em 24 de Setembro de 2004 13. Charette, R. Fair Fight? Agile Versus Heavy Methodologies Cutter Consortium E-project Management Advisory Service, 2, 13, (2001) 14. Paulk, M. C. Extreme Programming from a CMM perspective, IEEE Software, vol. 18, n. 6, (2001), pp 19-26 15. Glazer, H. Dispelling the process myth: having a process does not mean sacrificing agility or creativity, Crosstalk (2001) 16. The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, (1995) 17. Abrhamsson, P., Salo, O., Ronkainen, J., Agile software development methods review and analysis, VTT (2002) 18. Rising, L. e Janof, N.S. "The Scrum software development process for small teams". IEEE Software 17(4): (2002), pp. 26-32 19. Booch, G., Jacobson, I., Rumbaugh, J. UML - Guia do Usurio. Campus, So Paulo, 476p, (2000) 20. XP@Scrum, http://controlchaos.com/about/xp.php acessado em 24 de Setembro de 2004