REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g .

b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

Tecnologias de Desenvolvimento gil de Software: XP e Scrum

Karolina Mendona Figueiredo (Sistemas de Informao UniFOA) karolina.m.figueiredo@hotmail.com Ldia Silva Costa (Sistemas de Informao UniFOA) lidiacosta_si@hotmail.com Thiago Rodrigues Folly (Sistemas de Informao UniFOA) thiago.folly@hotmail.com Professor Dr. Carlos Eduardo Costa Vieira (Sistemas de Informao UniFOA) cadu.vieira@gmail.com Resumo Este artigo apresenta um estudo das duas metodologias geis de desenvolvimento de softtware mais usadas atualmente, XP (Program Extrem) e Scrum. Inicialmente, apresentado o surgimento da metodologias geis atravs do Manifesto gil e em seguida, ser feita uma apresentao das caractersticas das metodologias geis XP e Scrum. Esse estudo visa demonstrar como estas duas tecnologias podem ser utilizadas juntas a fim de melhorar o desenvolvimento gil para obter um software hbrida. Palavras-Chave: Metodologias geis; XP; Scrum; Estudo; Hbrido. 1. Introduo Para que o desenvolvimento de um software seja de qualidade, so necessrios um conjunto de fatores como pessoas capacitadas, estrutura e, principalmente, o mtodo de desenvolvimento usado. Os mtodos so condies predefinidas que tm como finalidade orientar a construo de um determinado produto, definindo como ser o seu desenvolvimento. Na computao, o uso de mtodos para a construo de software largamente utilizado h anos, pois auxiliam na obteno dos requisitos bsicos e procuram sempre garantir a mxima confiabilidade do sistema. Disciplinas como Engenharia e Requisitos de Software estudam diversos tipos de mtodos, com o objetivo de melhorar o processo de desenvolvimento. Processo pode ser definido como um conjunto de atividades interrelacionadas que visam um objetivo especfico. Na Engenharia de Software, os processos so utilizados com o intuito de orientar a construo de softwares para garantir um resultado final com a maior qualidade possvel. Processos geis de desenvolvimento tem como caracterstica uma abordagem iterativa e incremental dos princpios da Engenharia de Software. Os processos de software so adotados desde a crise do software dos anos 70, onde a indstria do software sofreu um colapso pela falta de padres que levavam a freqentes falhas de desenvolvimento. Embora existam diversos modelos de processos e caractersticas bsicas comuns entre eles como especificao de software, projeto, implementao, validao

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

e evoluo de software, no h um processo ideal, sendo que a escolha de um processo depender das caractersticas do sistema a ser construdo. Um processo de software tambm pode ser denomindado de ciclo de vida, pois, descreve a vida do sistema, desde as suas fases inicias at a finalizao do produto. Esta descrio envolve desde a anlise e definio dos requisitos e o projeto do sistema, passando pela programao e testes at a entrega do sistema e posterior manuteno. As metodologias tradicionais so tambm chamadas de pesadas ou orientadas a documentao. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em mainframes e terminais burros. Na poca, o custo de fazer alteraes e correes era muito alto, uma vez que o acesso aos computadores era limitado e no existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de cdigo. Por isso, o software era todo planejado e documentado antes de ser implementado. A principal metodologia tradicional e muito utilizada at hoje o modelo Clssico. O termo Metodologias geis tornou-se popular em 2001 quando 17 especialistas em processos de desenvolvimento de software representando os mtodos Scrum, Programao Extrema entre outros, estabeleceram princpios comuns compartilhados por todos esses mtodos. Foi ento criada a Aliana gil e o estabelecimento do Manifesto gil. Os conceitos chave do Manifesto gil so (CASTRO,I..;MOREIRA,2010): Indivduos e interaes ao invs de processos e ferramentas; Software executvel ao invs de documentao; Colaborao do cliente ao invs de negociao de contratos; Respostas rpidas a mudanas ao invs de seguir planos.

O Manifesto gil no rejeita os processos, ferramentas, documentao, negociao de contratos ou o planejamento, mas simplesmente mostra que eles tm importncia secundria quando comparados com os indivduos e interaes, com o software estar em funcionamento, com a colaborao do cliente e as respostas rpidas a mudanas e alteraes. Esses conceitos aproximam-se melhor com a forma que pequenas e mdias organizaes trabalham e respondem a mudanas. Entre as metodologias geis existentes, a mais conhecida a Extreme Programming. Decidiu-se estudar sobre o assunto porque cada vez mais os mtodos geis tm despertado o interesse da comunidade de Engenharia de Software como uma alternativa para o processo de desenvolvimento de softwares de uma maneira mais rpida, eficiente e que atenda as reais necessidades dos clientes. Existem no mercado vrios mtodos disponveis que utilizam a abordagem gil e que, por seguirem os princpios geis, apresentam uma srie de atividades semelhantes no seu processo de desenvolvimento. O artigo apresentar a interao entre os processos propostos pelos mtodos geis XP e Scrum.

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

2. Desenvolvimento geis de Software O desenvolvimento gel de software uma abordagem de desenvolvimento caracterizada pela capacidade de absorver mudanas, sejam elas nas foras de mercado, nos requisitos do sistema, na tecnologia de implentao ou nas equipes de projeto. Metodologia XP (Programao Extrema)
A XP uma metodologia gil, tem como objetivo o desenvolvimento rpido do software, a garantia da satisfao do cliente alm de favorecer o cumprimento das estimativas. A modelagem e a documentao so aspectos importantes da XP, bem como de qualquer outra metodologia de desenvolvimento de software. Entretanto, a XP o aconselha explicitamente a minimizar o trabalho investido nestas atividades a apenas o necessrio. Essa metodologia foi elaborada pelo engenheiro de software Kent Beck, um dos 17 signatrios originais do Manifesto gil em 2001. O seguidores da metodologia XP so conduzidos por quatro valores fundamentais: comunicao, simplicidade, feedback e coragem. A comunicao, tem como objetivo manter o melhor relacionamento possvel entre os desenvolvedores e seus respectivos clientes, priorizando as conversas pessoais. A forma como as pessoas se comunicam, se tornou um fator chave na XP, pois, usa-se o mximo possvel a comunicao pessoal evitando o uso de telefones e o envio de mensagens por correiro eletrnico. encorajada tambm a comunicao entre desenvolvedores e gerente do projeto. A simplicidade visa permitir a criao de cdigos simples, evitando que estes possuam funes consideradas desnecessrias, procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro e implementar o software com o menor nmero possvel de mtodos e classes. A prtica do feedback significa que o programador ter constantes informaes do cdigo e do cliente. A informao do cdigo fornecida pelos constantes testes, que podem indicar erros tanto individuais quanto do software integrado. Quanto as informaes do cliente, significa que o programador ter que entregar freqentemente uma parte do software em funcionamento para que o cliente possa avaliar e sugerir novas caractersticas e informaes aos desenvolvedores. Eventuais erros e no conformidades so rapidamente identificados e corrigidos nas prximas verses. Isso tudo ocorre, para que o produto final esteja de acordo com as especificaes reais do cliente. E finalmente, necessrio coragem para conseguir implantar os trs valores anteriores e principalmente obter feedback constante do cliente, afinal no so todas as pessoas que conseguem se comunicar bem e possuem facilidade e relacionamento. A XP baseia-se nas seguintes prticas a seguir:

Ambiente Informativo: o ambiente de desenvolvimento deve refletir o projeto. Qualquer membro do projeto, deve ser capaz de identificar rapidamente e de forma clara o andamento do mesmo. Cartes com histrias devem ser anexados em murais,

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

utilizao de flip chart visando aprimorar a comunicao da equipe acarretando em ganho de tempo. Build de Dez Minutos : assegurar que seja possvel executar os bulids (parte do software que contm recursos que vo integrar o produto final) e todos os testes automatizados do projeto em at dez minutos. Builds rpidos e automatizados ajudam a reduzir o estresse da equipe em momentos de dificuldade. Ciclo Semanal: uma vez por semana os desenvolvedores devem se reunir com o cliente para priorizar as funcionalidades que possam ser implementadas e testadas por completo nesta semana. Nesse perodo, denominado iterao, o cliente pode avaliar e utilizar o que foi produzido. Atravs destes resultados, um nova reunio realizada, e so estabelecidas novas prioridades de acordo com o que o cliente acabou de aprender com o software e com aquilo que j imaginava ser necessrio produzir ao longo do restante do projeto. Ciclo Trimestral: o planejamento geral de um projeto XP divido em trimestres. A cada incio de um trimestre a equipe se rene com o para estabelecer o tema ou os temas que sero implementados ao longo dos prximos trs meses. Nesta fase, a equipe tambm reflete sobre o andamento do projeto no trimestre anterior, identifica os problemas e aes para solucion-los no trimestre que se inicia. Desenvolvimento Orientado a Testes: os programadores desenvolvem o software criando primeiramente os testes. A XP tem como objetivo, a validao do software durante todo o processo de desenvolvimento. Os testes so executados automaticamente, durante todo tempo. Design Incremental: o objetivo criar a soluo mais simples possvel que seja suficiente para implementar as funcionalidades de cada iterao. Qualquer caracterstica que possa ser implementada para dar apoio a funcionalidades futuras, s sero codificadas de fato no futuro caso haja certeza da necessidade. Equipe Integral: as equipes XP devem ser formadas por desenvolvedores, mas tambm por clientes e quaisquer outras pessoas que devam ser ouvidas ao longo do desenvolvimento. Um projeto bem sucedido precisa levar em conta a opinio de diversas partes, bem como incorporar diferentes pontos de vista. Folga: equipes XP devem estabelecer um nvel de folga em seus planejamentos. projetos XP so construdos com base em comunicao aberta e honesta. Para que ela exista a equipe deve criar um relacionamento de confiana entre todos os envolvidos no projeto. Folgas ajudam a equipe a acomodar eventuais imprevistos, de modo que possa cumprir com suas promessas apesar deles. Histrias: as histrias normalmente so escritas pelo prprio cliente em pequenos cartes de papel. Os cartes no tm a inteno de armazenar todas as informaes sobre uma histria. Desenvolvedores em um equipe XP utilizam a conversa presencial com o cliente para aprender o mximo possvel sobre os detalhes de cada histria. Dessa forma, o

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

registro da histria feito no carto acaba servindo basicamente como um lembrete do dilogo. Integrao Contnua: prtica de interagir e construir o software vrias vezes por dia, mantendo os programadores em sintonia, alm de possibilitar acesso rpido. Esta prtica pode ser facilitada com o uso de apenas uma mquina de integrao , que dever ter livre acesso a todos os membros da equipe. Programao em Par: o desenvolvimento do cdigo feito em dupla, ou seja, dois programadores utilizam um nico computador. Um programador vai desenvolvendo o cdigo, enquanto o outro programador analisa o cdigo procurando identificar erros sintticos e semnticos, pensando estrategicamente como poder melhorar o cdigo que est sendo implementado. Sentar-se Junto: os integrantes da equipe procuram sentar juntos em uma sala aberta, na qual todos possam trabalhar em conjunto e se comunicar de forma mais rpida e eficaz possvel. Os desenvolvedores normalmente, precisam de privacidade, o que difcil de ser conseguido em um espao de trabalho aberto e compartilhado com outras pessoas. possvel atender essa necessidade com pequenos cubculos prximos rea comum da equipe, ou limitando as horas de trabalho de modo que os desenvolvedores possam resolver problemas particulares fora do ambiente de desenvolvimento.

Trabalho Energizado: a metodologia XP, segue a filosofia de que o mais importante no trabalhar mais e sim trabalhar de forma mais inteligente, em um perodo de tempo semanal que as pessoas sejam capazes de sustentar sem ficarem esgotadas e sem prejudicarem o trabalho com o dficit de ateno decorrente da fadiga. Existe uma distino importante entre movimento e progresso. Uma equipe que se movimenta muito, que trabalha muitas horas, que "d um gs" pelo projeto, mas produz vrias coisas erradas no est progredindo. Est apenas consumindo energia. O importante no se movimentar muito, se mover na direo certa, de forma inteligente e sustentvel. Prticas Corolrias: Prticas Corolrias Anlise da Raiz do Problema: significa que a equipe XP deve atacar as causas dos problemas, pois Corrigir os sintomas s vezes ajuda a tapar um buraco, mas como as causas reais no so tratadas, a tendncia que o problema retorne. A anlise da raiz de um problema ajuda a corrigir e prevenir essas ocorrncias. Base de Cdigo Unificada: deve haver apenas uma base de cdigo. Mltiplas linhas de codificao so uma enorme fonte de desperdcios em desenvolvimento de software. Cdigo Coletivo: o cdigo-fonte do software pertence a todos os membros da equipe. Isso significa, que qualquer membro da equipe pode acrescentar valor ao cdigo,

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

mesmo que ele prprio no tenha desenvolvido, poder faz-lo, desde que faa a bateria de testes necessria. Uma vantagem da propriedade coletiva, que se algum membro da equipe, por algum motivo necessitar deixar o projeto antes do fim, a equipe consegue continuar o projeto com poucas dificuldades. Cdigo e Testes: Mantenha apenas cdigo e testes como artefatos permanentes. Gere outros documentos que se faam necessrios a partir do cdigo e dos testes. Os clientes pagam pelo que o sistema faz hoje e o que a equipe pode fazer com que o sistema faa futuramente. Quaisquer artefatos que contribuam para essas duas fontes de valor so valiosos. O resto desperdcio. Continuidade da Equipe: Preserve equipes eficazes. O valor de software criado no apenas pelo que as pessoas sabem e fazem, mas tambm por seus relacionamentos e pelo que as pessoas so capazes de conquistar juntas. Contrato de Escopo Negocivel: caso o cliente perceba a necessidade de fazer ajustes no escopo para que o software leve em conta seu aprendizado ao longo do projeto, ou mudanas nas circunstncias, ele pode. Em projetos XP, o escopo revisado freqentemente para garantir que equipe dedique seus esforos ao que mais prioritrio em cada etapa do projeto. Envolvimento do Cliente Real: XP estabelece uma diviso de responsabilidade: desenvolvedores tomam decises tcnicas, enquanto o pessoal de negcio toma as decises de negcio. Sendo assim, projetos XP normalmente contam com a participao ativa de uma ou mais pessoas do negcio, que definem e priorizam as funcionalidades que devem ser implementadas. Equipes que Encolhem: medida que uma equipe aumenta a sua capacidade de produo, deve-se manter a carga de trabalho constante, mas gradualmente reduza o tamanho da equipe. Isso libera as pessoas para formarem outras equipes. Quando a equipe tem muito poucas pessoas, misture-a com outra equipe que tambm seja muito pequena. Implantao Diria: uma prtica corolria porque tem inmeros pr-requisitos. A taxa de defeitos tem que ser da ordem de apenas um punhado por ano. O processo de build tem que ser bem automatizado. As ferramentas de deploy precisam ser automatizadas, incluindo a capacidade de colocar em produo de forma incremental e voltar atrs (rollback) em caso de falhas. Sobretudo, a confiana entre a equipe e os clientes precisa estar altamente desenvolvida. Implantao Incremental: quando estiver substituindo um sistema legado, gradualmente substitua partes dele desde o incio do projeto. De vez em quando grandes implantaes funcionam, mas a implantao incremental acarreta em mais segurana. Pagar Por Uso: as prticas atuais requerem que o cliente pague por cada release do software. Pay-per-release coloca em oposio os interesses do cliente e os do fornecedor. O fornecedor motivado de forma egosta a lanar muitos releases, cada

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

um contendo o mnimo possvel de funcionalidades necessrias para fazer os clientes quererem pagar por eles. O cliente deseja menos releases (devido a dor do upgrade), cada um contendo muitas funcionalidades. A tenso entre esses dois conjuntos de interesses reduz comunicao e feedback. Os membros de um projeto em XP tm papis que devem ser desempenhados. A equipe composta no apenas por programadores, mas tambm por profissionais responsveis pelos testes, o gerente de projeto que ir cuidar dos recursos necessrios. importante lembrar que dentro de uma equipe XP, no existem pessoas com aes mais importantes que as outras, no existindo hierarquia. Cada membro contribui no projeto da melhor maneira possvel. A seguir temos os papis desempenhados em um projeto XP: Analista de Testes; Gerente de Projeto; Programador (Desenvolvedor); Rastreador; Redator Tcnico; Treinador.

2.1 Ciclo de Vida da Metodologia XP Um projeto que utiliza a metodologia gil de desenvolvimento XP, possui algumas fases durante o seu ciclo de vida. Essas fases so compostas por vrias tarefas que sero executadas durante o processo de desenvolvimento de software. As fases da XP so: explorao, planejamento inicial, iteraes do release, produo, manuteno e morte. Explorao: fase anterior construo do sistema. Nela, so realizadas investigaes de possveis solues e verifica-se a viabilidade de tais solues. Os programadores elaboram possveis arquiteturas e tentam visualizar como o sistema funcionar considerando o ambiente tecnolgico (hardware, rede, software, performance, trfego) onde o sistema ser implantado. Com isso, os programadores e os clientes vo ganhando confiana, e quando eles possurem estrias suficientes, j podero comear a construir o primeiro release do sistema. Planejamento Inicial: fase utilizada para que os clientes determinem uma data para lanamento do primeiro release. O planejamento funciona da seguinte maneira: Os programadores, juntamente com o cliente, definem as estrias (casos de uso simplificados) a serem implementadas e as descrevem em cartes. Os programadores atribuem uma certa dificuldade para cada estria e, baseados na sua velocidade de implementao, dizem quantas estrias podem implementar em uma iterao. Depois, os clientes escolhem as estrias de maior valor para serem implementadas na iterao isso chamado planejamento de iterao. O processo ento se repete at terminar as iteraes do release. O tempo para cada iterao deve ser de uma a trs semanas e para cada release de dois a quatro meses.

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

Iteraes do release: so escritos os casos de teste funcionais e de unidade. Os programadores vo seguindo mais ou menos o seguinte fluxo de atividades na seguinte ordem: escrita dos casos de testes; projeto e refatoramento; codificao; realizao dos testes; e integrao. medida que esse fluxo vai sendo seguido, o sistema vai sendo construdo segundo os princpios, valores e prticas apresentados anteriormente. Depois de terminado o primeiro release, j se ter uma idia melhor das tecnologias e do domnio do problema de modo que as iteraes podero ser mais curtas nos releases subseqentes e j podem fazer estimativas mais confiveis com o que se aprendeu das iteraes passadas. Depois do final do primeiro release, considera-se o incio da fase de produo onde cada release subseqente do sistema, depois de construdo, colocado para rodar em um ambiente que simula o ambiente de produo para ver seu comportamento em termos de desempenho. Podese fazer testes de aceitao adicionais para simular o funcionamento real do sistema no ambiente alvo. Manuteno: pode ser considerada como uma caracterstica inerente a um projeto XP. Em XP voc est simultaneamente produzindo novas funcionalidades, mantendo o sistema existente rodando, incorporando novas pessoas na equipe e melhorando o cdigo. Mecanismos como: refatoramento, introduo de novas tecnologias, e introduo de novas idias de arquitetura podem ser utilizados em um projeto XP. importante ressaltar que a manuteno dada em um sistema que j est em produo deve ser feita com muita cautela, pois uma alterao errada pode paralisar o funcionamento do sistema resultando em prejuzos para o cliente, como o atraso na entrega do software. Morte: corresponde ao trmino de um projeto XP. Existem duas razes para se chegar ao final de um projeto, uma boa e a outra ruim. A boa razo quando o cliente j est satisfeito com o sistema existente e no enxerga nenhuma funcionalidade que possa vir a ser implementada no futuro. A m razo para a morte em XP seria a do projeto ter se tornado economicamente invivel, devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros. 3. Metodologia Scrum Scrum uma metodologia gel de gerenciamento de projeto, focada no trabalho em equipe, com equipes auto-gerenciadas e participao ativa do cliente. O nome Scrum vem do jogo rugby, esporte semelhante ao futebol, com bola oval e jogado tambm com as mos. No rugby, o scrum utilizado para reposio da bola, aps faltas ou penalidades. Oito jogadores de cada time posicionam se frente frente, formando um circulo. Um jogador da equipe que no cometeu a infrao lana a bola no espao entre os jogadores alinhados que tentam, com os ps, ganhar a bola para isso, o grupo deve trabalhar em conjunto, como se fosse uma unidade. A utilizao da palavra Scrum associada ao desenvolvimento de produtos foi feita primeira vez por Takeuchi e Nonaka, no livro The New Product Development Game, onde os autores defendem a idia de que no desenvolvimento toda a equipe deve trabalhar como unidade para atingir um objetivo comum, como no Scrum do rugby.

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

Ao contrrio de metodologias definidas ( como o RUP), onde o processo de desenvolvimento bem definido e repetvel, o Scrum uma metodologia emprica, na qual defendida a idia de que problemas fundamentalmente empricos no podem ser resolvidos com sucesso utilizanndo uma abordagem tradicional de controle. [1]

3.1 A Rotina do Scrum Os requisitos do projeto so organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade (itens mais importantes no topo). Essa lista deve ser constantemente atualizada e repriorizada. O Scrum trabalha com desenvolvimento incremental, onde cada iterao chamada de sprint. Os sprints so curtos, tendo durao de 30 dias. A equipe separa uma parte do topo do backlog para o sprint, formando o sprint backlog ( lista de tarefas do sprint). A equipe tem autonomia para decidir como as tarefas sero implementadas, mas as tarefas do sprint backlog no podem ser trocadas por outras do product backlog, garantindo que os requisitos mais importantes sejam implementados primeiro e que a equipe mantenha o foco durante o sprint. O sprint possui um objetivo claro e definido, conhecido de toda a equipe. Os papis do Scrum Os principais papis no scrum so: Equipe: o grupo de pessoas que trabalha na construo do produto. Dono do projeto: representa a viso do negcio no projeto. Scrum Master: seria o lder da equipe, se esta no fosse auto-gerenciada. 4. Concluso As metodologias que conhecemos hoje em dia como metodologias geis se baseiam nos mesmos princpios e no manifesto gil. A partir disso que muitas prticas dessas metodologias so parecidas ou at mesmo iguais, s mudando seu nome. Em nosso artigo estudamos especificamente o Scrum e a Programao Extrema (XP). O Scrum, particularmente, um framework focado principalmente em planejamento e gerncia. J o XP mais focado em prticas de desenvolvimento. Mesmo assim, vrias prticas so coincidentes entre Scrum/XP como sprint/desenvolvimento iterativo, e por a vai. A principal diferena que encontramos entre as duas que Scrum no te diz nada sobre prticas de desenvolvimento de software gil, at porque pode usar Scrum no s para fazer sistemas, como tambm para fazer carros, avies ou bolos. Nossa viso que as prticas de XP complementam o Scrum. Certas prticas de desenvolvimento, que observamos ser essencial para o bom andamento de um projeto de

REVISTA CADERNOS UNIFOA CENTRO UNIVERSITRIO UNIFOA c a d e r n o s u n i f o a @ f o a. o r g . b r __________________________________________________________________________________ REVISTA CIENTFICA

DO

software, no fazem parte do escopo do Scrum mas fazem parte do XP, como desenvolvimento guiado por testes, integrao contnua, design incremental, metforas, cdigo coletivo, programao em par e outros. Por isso, que conclumos que essa combinao bastante recomendvel.

Referncias [1] WIKIPDIA SCRUM CASTRO,I.C.A.;MOREIRA,A.M. Metodologias de Desenvolvimento: Um comparativo entre Extreme Programming e Rational Unified Process. Disponvel em: <http://www.frb.br/ciente/BSI/BSI.CASTRO.%20et%20al%20.F2%20.pdf> . Acesso em: 15 set. 2010 CESTARI,Eduardo. Extreme Programming - XP Disponvel em: <http://indecisos.wordpress.com/2006/09/11/extreme-programming-xp/> Acesso: 05 mai. 2010. FAGUNDES, P.B.; DETERS, J.I.; SANTOS, S.S. Comparao entre os processos dos mtodos geis: XP,Scrum, FDD e ASD em relao ao desenvolvimento iterativo incremental. Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 2008. Disponvel em: <http://revista.ctai.senai.br/index. php/edicao01/article/viewDownloadInterstitial/21/18>. Acesso em: 20 ago. 2010. KNIBERG, Henrik. Scrum e XP direto das Trincheiras: como ns fazemos Scrum. InfoQ, 2010. Disponvel em: <http://www.infoq.com/br/minibooks/scrum-xp-fromthe-trenches>. Acesso em: 20 ago. 2010. MELO,T. Princpios e Prticas de Extreme Programming. Disponvel em: <http://www.tiagodemelo.info/palestras/xp.pdf >. Acesso em: 20 nov. 2010.