Introduo

Um processo de software consiste de um conjunto de atividades realizadas para a sua construo e manuteno. Ao longo dos ltimos anos, a crescente demanda por software de qualidade, aliada presso em relao aos prazos de entrega fizeram com que a eficincia de muitas tcnicas e processos tradicionalmente utilizados passasse a ser questionada. A constante necessidade de se obter resultados favorveis na economia mundial tem obrigado a indstria a reunir esforos para dinamizar o seu processo produtivo. Para isso, muito capital tem sido empregado no desenvolvimento de solues informatizadas que deem agilidade a seu processo de produo e, consequentemente, gerem um saldo positivo dentro do mercado. Porm, o processo de produo de desenvolvimento de software normalmente envolve riscos, como o atraso no cronograma, mudanas nos requisitos, sada de um importante membro da equipe de desenvolvimento, alta taxa de defeitos, sistemas tornando-se obsoletos, projetos cancelados, devido ocorrncia desses fatores de risco, dentre outros. Diante deste cenrio, os mtodos utilizados para o desenvolvimento de software vm ganhando importncia e gerando interesse tanto na comunidade de desenvolvedores quanto na rea acadmica. O Extreme Programming um modelo de desenvolvimento de software, criado em 1996, por Kent Bech, no Departamento de Computao da montadora de carros Daimler Crysler, ele possui muitas diferenas em relao a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos dinmicos. O XP um conjunto bem definido de regras, que vem ganhando um grande nmero de adeptos e por oferecer condies para que os desenvolvedores respondam com eficincia a mudanas no projeto, mesmo nos estgios finais do ciclo de vida do processo, devido a quatro lemas adotados por seus seguidores, que correspondem a quatro dimenses a partir das quais os projetos podem ser melhorados.

Descrio dos modelos, caractersticas e funcionalidades.

Conceitos: Extreme Programming (XP) um processo de desenvolvimento de software que adota os valores de comunicao, simplicidade, feedback e coragem [28,29]. Estes quatro valores servem como critrios que norteiam as pessoas envolvidas no desenvolvimento de software e sero detalhados a seguir.

Comunicao: XP foca em construir um entendimento pessoa-a-pessoa do problema, com o uso mnimo de documentao formal e com o uso mximo de interao cara -a-cara entre as pessoas envolvidas no projeto. As prticas de XP como programao em pares, testes e comunicao com o cliente tm o objetivo de estimular a comunicao entre gerentes, programadores e clientes. Simplicidade: XP sugere que cada membro da equipe adote a soluo mais fcil que possa funcionar. O objetivo fazer aquilo que mais simples hoje e criar um ambiente em que o custo de mudanas no futuro seja baixo. O objetivo dessa abordagem adotada por XP evitar a construo antecipada de funcionalidades, como feita em muitas metodologias tradicionais, que acabam muitas vezes nem sendo usadas.

Feedback: Os programadores obtm feedback sobre a lgica dos programas escrevendo e executando casos de teste. Os clientes obtm feedback atravs dos testes funcionais criados para todas as estrias (casos de uso simplificados). O feedback importante, pois possibilita que as pessoas aprendam cada vez mais sobre o sistema e assim corrijam os erros e melhorem o sistema. Coragem: Ela necessria para que realmente se aplique XP como deve ser aplicado. Exemplos de atitude que exigem coragem so: alterar cdigo j escrito e que est funcionando; jogar cdigo fora e reescrever tudo de novo; e permitir cdigo compartilhado por todos. Estes exemplos de atitudes podem ser necessrios para trazer melhorias ao projeto e no devem ser evitadas simplesmente devido ao medo de tent-las.
Temores no Processo de Desenvolvimento de Software Desenvolvedores Clientes Fazer mais do que sabem fazer No obter o que pediram Fazer coisas que no tm sentido Pedir a Coisa errada Ficarem defasados tecnicamente Pagar demais por muito pouco Receberem responsabilidades sem autoridade Jamais ver um plano relevante No receber instrues claras do que deve ser feito No saber o que est acontecendo Resolver problemas complicados sem ajuda e Fixarem-se em suas decises iniciais e no reagir a mudanas tempo. nos negcios. Fonte: (TELES, 2005, p. 68)

Alm dos valores apresentados anteriormente XP define um conjunto de princpios que devem ser seguidos por equipes que forem usar XP em projetos. Os princpios serviro para ajudar na escolha de alternativas de soluo de problemas durante o curso do projeto. Devese preferir uma alternativa que atenda aos princpios de uma forma mais completa do que outra que seja incompleta, ou seja, que esteja mais longe da filosofia de XP. Os princpios fundamentais so: feedback rpido, assumir simplicidade, mudana incremental, abraando mudanas e trabalho de qualidade. Feedback rpido: A ideia de XP que os participantes de um projeto como clientes, programadores e gerentes devem estar sempre se comunicando para facilitar o aprendizado coletivo sobre o projeto que est sendo desenvolvido e de alertar rapidamente sobre dvidas, riscos e problemas para facilitar eventuais aes de contingncia. Assumir simplicidade: Todo problema deve ser tratado para ser resolvido da forma mais simples possvel. XP afirma que se deve fazer um bom trabalho (testes, refactoring, comunicao) para resolver hoje os problemas de hoje e confiar na sua habilidade de adicionar complexidade no futuro quando for necessrio. Mudana incremental: Quando muitas mudanas so realizadas todas de uma vez, no se obtm um bom resultado. Em vez disso, esse princpio de XP diz que as mudanas devem ser incrementais e feitas aos poucos. Os programadores tm a liberdade para estar sempre fazendo alteraes de melhoria no cdigo e as mudanas de requisitos so incorporadas de forma incremental. Abraando mudanas (Embracing Change): XP procura facilitar o ato de incluir alteraes atravs do uso de vrios princpios e prticas. A idia de XP a de que mudanas

devem ser sempre bem vindas independentemente do estgio de evoluo do projeto. Isso muito benfico em projetos cujos requisitos so bastantes volteis devido aos clientes no saberem o que querem. Trabalho de qualidade: Em XP, qualidade no um critrio opcional, mas sim obrigatrio. Embora a definio de qualidade possa variar de pessoa para pessoa, XP trata qualidade no sentido de se ter um sistema que atenda aos requisitos do cliente, que rode 100% dos casos de teste e que agregue o maior valor possvel para o negcio do cliente.

Prticas Conceito:Para aplicar os valores e princpios durante o desenvolvimento de software, o XP

prope uma srie de prticas. H uma confiana muito grande na sinergia entre elas, os pontos fracos de cada uma so superados pelos pontos fortes de outras. Jogo de Planeamento (Planning Game): O desenvolvimento feito em iteraes semanais. No incio da semana, desenvolvedores e cliente renem-se para priorizar as funcionalidades. Essa reunio recebe o nome de Jogo do Planeamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente essencial neste processo e, assim, ele fica sabendo o que est acontecendo e o que vai acontecer no projeto. Como o escopo reavaliado semanalmente, o projeto regido por um contrato de escopo negocivel, que difere significativamente das formas tradicionais de contratao de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem colocadas em produo. Pequenas Verses (Small Releases): A liberao de pequenas verses funcionais do projeto auxilia muito no processo de aceitao por parte do cliente, que j pode testar uma parte do sistema que est comprando. As verses chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. Metfora (Metaphor): Procurar facilitar a comunicao com o cliente, entendendo a realidade dele. O conceito de rpido para um cliente de um sistema jurdico diferente para um programador experiente em controlar comunicao em sistemas de tempo real, como controle de trfego areo. preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto. Projeto Simples (Simple Design): Simplicidade um princpio do XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira verso apenas o usurio "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, voc vai fazer o cdigo exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticao e restries de acesso. Um erro comum ao adotar essa prtica a confuso por parte dos programadores de cdigo simples e cdigo fcil. Nem sempre o cdigo mais fcil de ser desenvolvido levar a soluo mais simples por parte de projeto. Esse entendimento fundamental para o bom andamento do XP. Cdigo fcil deve ser identificado e substitudo por cdigo simples. Time Coeso (Whole Team): A equipe de desenvolvimento formada pelo cliente e pela equipe de desenvolvimento.

Testes de Aceitao (Customer Tests): So testes construdos pelo cliente em conjunto com analistas e testadores, para aceitar um determinado requisito do sistema. Ritmo Sustentvel (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudvel (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras so permitidas quando trouxerem produtividade para a execuo do projeto. Reunies em p (Stand-up Meeting): Reunies em p para no se perder o foco nos assuntos de modo a efetuar reunies rpidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe. Posse Coletiva (Collective Ownership): O cdigo fonte no tem dono e ningum precisa ter permisso concedida para poder modificar o mesmo. O objetivo com isto fazer a equipe conhecer todas as partes do sistema. Programao em Pares (Pair Programming): a programao em par/dupla num nico computador. Geralmente a dupla criada com algum sendo iniciado na linguagem e a outra pessoa funcionando como um instrutor. Como apenas um computador, o novato que fica frente fazendo a codificao, e o instrutor acompanha ajudando a desenvolver suas habilidades. Dessa forma o programa sempre revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs).Com isto, procura-se sempre a evoluo da equipe, melhorando a qualidade do cdigo fonte gerado. Padres de Codificao (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Dessa forma parecer que todo o cdigo fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitrios (unit tests) e depois crie o cdigo para que os testes funcionem. Esta abordagem complexa no incio, pois vai contra o processo de desenvolvimento de muitos anos. S que os testes unitrios so essenciais para que a qualidade do projeto seja mantida. Refatorao (Refactoring): um processo que permite a melhoria contnua da programao, com o mnimo de introduo de erros e mantendo a compatibilidade com o cdigo j existente. Refactorizar melhora a clareza (leitura) do cdigo, divide o em mdulos mais coesos e de maior reaproveitamento, evitando a duplicao de cdigo-fonte. Integrao Contnua (Continuou Integration): Sempre que realizar uma nova funcionalidade, nunca esperar uma semana para integrar na verso atual do sistema. Isto s aumenta a possibilidade de conflitos e a possibilidade de erros no cdigo fonte. Integrar de forma contnua permite saber o status real da programao.

Vantagens e desvantagens
Vantagens: As praticas do XP so utilizadas pelos integrantes da equipe, para facilitar no desenvolvimento e agregar na qualidade do projeto, com isso, todos no time devem estar cientes, de cada fase do sistema. Um dos benefcios que a mesma oferece tornar o processo mais gil e flexvel. Conforme Astels, as praticas do XP so criadas para funcionarem juntas, e fornecer mais valor do que cada uma poderia fornecer individualmente. Analise previa de tudo o que pode acontecer durante o desenvolvimento do projeto, oferecendo qualidade, datas de entregas e custos promissores. O XP ideal para ser usado em projetos em que o cliente no sabe exatamente o que deseja e pode mudar muito de opinio durante o desenvolvimento do projeto. Com o feedback constante possvel adaptar rapidamente eventuais mudanas de requisitos. Essas alteraes nos requisitos so muitas vezes criticas nas metodologias tradicionais, que no apresentam meios de se adaptar rapidamente as mudanas. Outro ponto positivo das metodologias geis so as entregas constantes de partes operacionais do software. Desta forma, o cliente no precisa esperar muito pra ver o software funcionando, como nas metodologias tradicionais. Desvantagens: frequente acontecer bugs em todos os projetos de desenvolvimento de software e com o XP no diferente . Existem pontos fracos nessa metodologia como: - No existe uma avaliao dos riscos, devendo, portanto, implementar uma analise e estratgias que buscam diminuir erros. - A analise de requisitos informal e com isso pode no ser bem vista pelos clientes, que podero se sentir inseguros quanto ao bom funcionamento do sistema.

Refatorao do cdigo pode ser vista como irresponsabilidade e incompetncia, pois, no existe uma preocupao formal na utilizao do cdigo. - A falta de documentao caracterstica no processo XP, pois o mesmo no da muita nfase a burocracias (documentos, formulrios, processos, controles rgidos, etc.), sendo, portanto importante a elaborao de documentos e diagramas que facilitem no entendimento e na identificao do problema.

Concluso
Extreme Programming uma metodologia que busca reduzir ou mesmo sanar problemas de atrasos no cronograma, retrabalhos no projeto e desperdcios de tempo e dinheiro nos processos de desenvolvimento. Para isso, a XP utiliza-se de uma srie de prticas que auxiliam as equipes de desenvolvimento a trabalhar de maneira mais eficiente. Um dos fatores que tornam a XP eficiente a integrao constante entre cliente e desenvolvedores, isso favorece para que as necessidades do cliente sejam rapidamente compreendidas e em seguida implementadas. A programao em par tambm um diferencial da metodologia XP no requisito treinamento, enquanto que no desenvolvimento tradicional a falta de treinamento influencia diretamente no prazo de um projeto, na metodologia XP um dos integrantes da dupla vai sendo treinado ao longo do desenvolvimento de maneira transparente para o projeto. Por se tratar de uma metodologia relativamente nova que contraria muitos paradigmas do desenvolvimento tradicional, ainda h um preconceito com a metodologia e a dvida sobre a eficcia da sua utilizao. Mas, percebe ao longo deste trabalho que existe grande chance nos prximos anos da metodologia XP vir a ser bastante utilizada. E que, como em qualquer outra metodologia, ela possui pontos fracos, mas se utilizada da forma correta, a combinao dos valores e boas prticas criam as condies necessrias para que uma equipe de desenvolvimento obtenha sucesso em seus projetos.