FACULDADE DE TECNOLOGIA DO NORDESTE

APRESENTAO DA METODOLOGIA XP EXTREME PROGRAMMING

Para:

Prof. Amaury Brasil

Equipe: Antnio Claudio David Alcntara Walter Pereira Wesley Alencar

Fortaleza CE 2012

SUMRIO 1. INTRODUO ............................................................................................. 7 2. DESENVOLVIMENTO DE SOFTWARE ...................................................... 9 2.1 2.2 Desenvolvimento tradicional ................................................................. 9 Desenvolvimento gil .......................................................................... 10

3. METODOLOGIA XP - EXTREME PROGRAMMING ............................... 12 3.1 3.2 Histria da XP ..................................................................................... 12 Valores da XP ..................................................................................... 12

3.2.1 Feedback .......................................................................................... 12 3.2.2 Comunicao .................................................................................... 13 3.2.3 Simplicidade ..................................................................................... 13 3.2.4 Coragem ........................................................................................... 13 3.3 Equipe XP ........................................................................................... 14 Gerente de projeto ........................................................................ 14 Coach ........................................................................................... 14 Analista de teste ........................................................................... 14 Redator tcnico............................................................................. 14 Desenvolvedor .............................................................................. 15

3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4

Praticas da XP .................................................................................... 15 Envolvimento do Cliente ............................................................... 15 Small Release Pequenas Verses ............................................ 15 Integrao Contnua ..................................................................... 16 Refactoring ................................................................................... 16 Cdigo coletivo ............................................................................. 16 Design simples ............................................................................. 16 Metfora ....................................................................................... 17 Padres de desenvolvimento ....................................................... 17

3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8

3.4.9 3.4.10 3.4.11 3.4.12 3.4.13

Stand up meeting.......................................................................... 17 Ritmo sustentvel ...................................................................... 17 Jogo do Planejamento ............................................................... 17 Programao em Par ................................................................ 20 Desenvolvimento guiado por testes TDD ............................... 20

4. DOCUMENTAO DO PROJETO ............................................................ 21 4.1 4.2 4.3 Documentando Cdigo .................................................................... 21 Documentando Requisitos ............................................................... 21 Documentando Design..................................................................... 21

5. O CONTRATO DE ESCOPO NA XP....................................................... 23 6. QUANDO NO USAR XP.......................................................................... 24 7. CONCLUSO ............................................................................................ 25 8. REFERNCIAS ......................................................................................... 26

LISTA DE FIGURAS

Figura 1 - Modelo em cascata do desenvolvimento tradicional. ......................... 9 Figura 2 - Modelo em espiral do desenvolvimento gil (por Barry Boehm). ..... 10

RESUMO A Programao Extrema ou Extreme Programming (XP), uma forma inovadora de desenvolvimento gil de sistema, onde faz uso de uma metodologia leve, flexvel, eficiente, de baixo risco, previsvel, cientifica e distinguvel de qualquer outro mtodo, ou seja, uma metodologia nica. Atualmente essa metodologia tem atrado bastante ateno no s pela sua eficincia em produzir de forma rpida software com qualidade, mas tambm por fazer isso contraposto as regras da engenharia de software tradicional no desenvolvimento de sistemas. Na prtica da XP, as atividades de programao possuem uma grande comunicao oral, testes automatizados, programao em pares, cultura de contar estrias e propiedade coletiva de codigo, onde todos tem acesso igual ao codigo em qualquer momento do projeto. A Extreme Programming surgiu em resposta s necessidades de pequenas equipes que tinham constantemente grandes problemas com mudanas de requisitos o que consequentemente causava atraso nos prazos e estourava os oramentos.

Palavras-chave: Extreme Programming. Desenvolvimento gil. Prtica da XP. Desenvolvimento Tradicional.

ABSTRACT Extreme Programming or Extreme Programming (XP) is an innovative agile development system, which makes use of a methodology lightweight, flexible, efficient, low-risk, predictable, scientific and distinguishable from any other method, that is, a single methodology. Currently this method has attracted much attention not only for its efficiency in producing quality software quickly, but by doing so opposed the "rules" of traditional software engineering in systems development. In the practice of XP, programming activities have a great oral communication, automated testing, pair programming, culture of storytelling is owned conference code, where everyone has equal access to the code at any time of the project. The Extreme Programming has emerged in response to the needs of small teams that had big problems with constantly changing requirements which consequently caused delay in deadlines and budgets bursting.

Key-words: Extreme Programming. Agile Development. Practice of XP. Traditional development.

1. INTRODUO Na busca constante por resultados satisfatrios e favorveis economia, as empresas tm sido obrigadas a procurar melhorias e estarem sempre dinamizando o processo produtivo. Para encontrar essa melhoria, necessrio um grande investimento no desenvolvimento de solues informatizadas que garantam agilidade ao processo de produo e consequentemente gere um bom retorno financeiro empresa. No entanto, mesmo com um alto investimento, o processo de desenvolvimento de software adotado por muitas empresas est sujeito a riscos do mundo real, como atraso no cronograma, mudanas de requisitos, ausncia de um membro importante na equipe, altas taxas de defeitos e sistema obsoleto aps a entrega, entre outras eventualidades que qualquer (mau) desenvolvimento de projeto est sujeito. Diante da importncia do processo e dos inmeros problemas, os mtodos para desenvolvimento de software deixaram de ser somente de importncia dos desenvolvedores, e passaram a ser de interesse da rea acadmica. Com a influncia acadmica, surgiu o mtodo tradicional de desenvolvimento de software, que tem como caracterstica ser voltado para a documentao, ou seja, os requisitos precisam ser completos e fixos para que cada etapa seja documentada, aprovada e assinada, e s aps isso autorizado o inicio da prxima etapa. Esse mtodo at funciona em alguns desenvolvimentos que tenham longos prazos para entrega, mas esse no o caso de empresas dinmicas que precisam sempre de tudo pronto pra ontem. O modelo tradicional deixa a evoluo muito engessada e deixa a metodologia muito pesada e no flexvel, o prximo trabalho s inicia se o anterior estiver pronto, isso deixa a equipe pressionada e acaba fazendo com que eles trabalhem demais, produzam pouco e fiquem exaustos, sem falar que o grupo responsvel pela etapa seguinte do projeto ficar totalmente ocioso aguardando a concluso da etapa anterior. Outro grande risco que o modelo tradicional est susceptvel de ouvir do cliente, na entrega do projeto pronto, no nada disso que eu queria,

pois nesse modelo o cliente no faz parte da equipe e no acompanha diariamente as evolues do projeto. E foi em resposta a esse cenrio, que surgiu a Extreme Programming, uma metodologia gil de desenvolvimento de software, que tem como prs o rpido desenvolvimento, a entrega imediata e continua de software funcionando, a possibilidade de modificaes sempre que aparea, a sintonia com o cliente para atend-lo melhor, a equipe sempre est motivada e no pressionada, alm de possuir comunicao face-a-face. E com esse modelo simples, gil e uma eficaz prtica de programao usada na soluo de problemas, que as equipes XP vm fazendo sucesso em seus projetos e tm atraindo cada vez mais interesse das reas acadmicas e industrial. Aps conhecer um pouco do contexto da necessidade de evoluo do desenvolvimento de software, este trabalho apresentar um breve resumo sobre a relao do desenvolvimento de software tradicional e gil, em seguida ser abordado como foco principal deste trabalho, a Extreme Programming e seus valores e prticas, sero abordados ainda, o contrato de escopo na XP e fatores relevantes que implicam em quando no usar XP.

2. DESENVOLVIMENTO DE SOFTWARE Na computao, o desenvolvimento de software o ato de elaborar e implementar um sistema computacional, isto , transformar a necessidade de um utilizador ou de um mercado em um produto de software (BIRRELL, 1985). Tendo em vista que para elaborar e implementar um desenvolvimento de software, no basta apenas traduzir a ideia/necessidade do cliente em linguagem de maquina, mas sim basear-se em uma metodologia. Este captulo apresentar um breve resumo sobre dois modelos de desenvolvimento de software, o modelo tradicional e o modelo gil. 2.1 Desenvolvimento tradicional O modelo tradicional foi idealizado por Royce em 1970 e nesta mesma dcada ficou muito conhecido, sendo at hoje o modelo de desenvolvimento mais conhecido na engenharia de software. Com o tempo, o modelo tradicional passou a ser relacionado a qualquer metodologia que de alguma forma adotasse o desenvolvimento em cascata, ou seja, um desenvolvimento onde o software fosse construdo seguindo uma sequencia de etapas, sendo que cada etapa, com exceo da primeira, depende da concluso da etapa anterior para ser iniciada.

Figura 1 - Modelo em cascata do desenvolvimento tradicional.

10

2.2 Desenvolvimento gil O desenvolvimento gil uma metodologia criada por grandes profissionais da rea de engenharia de software, na sua maioria consultores de projetos desenvolvidos utilizando o modelo tradicional. Com uma grande experincia na bagagem e motivados a minimizar os riscos associados ao desenvolvimento de software, como atraso nos prazos e oramentos estourados por conta da dificuldade em mudar requisitos, uma vez que o projeto obrigatoriamente todo planejado e documentado antes de iniciar qualquer implementao, Kent Beck e outros dezesseis profissionais reuniramse em 2001 para criar um novo conceito em desenvolvimento de software, o que foi chamado de Manifesto gil, hoje conhecido como desenvolvimento gil. O manifesto para desenvolvimento gil de software passava ento a priorizar um conjunto de princpios diferentes do modelo tradicional. So eles: Indivduos e interao e no mais processos e ferramentas; Software funcionando e no mais documentao abrangente; Colaborao do cliente e no mais negociao de contratos; Resposta a modificaes e no mais seguir um plano. No desenvolvimento gil os projetos passam a ser construdo em modelo de espiral e no mais em modelo de cascata.

Figura 2 - Modelo em espiral do desenvolvimento gil (por Barry Boehm).

11

Nesse processo cada ciclo, tambm chamado de iterao, corresponde a um setor do espiral, sendo que cada ciclo deve ser curto e ter tamanho e tempo fixo. Alm disso, antes de cada ciclo realizado uma retrospectiva dos processos anteriores, isso para manter o foco e permitir que haja uma evoluo continua com base no que j foi realizado at o momento. Segundo Teles (2004), as iteraes sempre acrescentam valor ao projeto na forma de novas funcionalidades implementadas, testadas e aprovadas. O que proporciona ao cliente: acompanhar a pratica e as evolues do projeto; ver antecipadamente os benefcios do sistema e dar feedback diretamente ao desenvolvedores sobre as funcionalidades implementadas.

12

3. METODOLOGIA XP - EXTREME PROGRAMMING 3.1 Histria da XP De acordo com Castro (2007), embora a Extreme Programming tenha marco de criao no ano de 1996, ela passou por um processo de evoluo, liderado por Kent Beck e Ward Cunningham, de mais de dez anos para possuir bons princpios e boas praticas de desenvolvimento de software, e se tornar o modelo mais conhecido dentre os que se utilizam dos princpios do Manifesto gil. O primeiro relato da aplicao dos princpios e praticas da XP de forma integra em um projeto, aconteceu em 1996, quando Kent Beck, foi chamado para desenvolver um grande sistema de folha de pagamento, o C3, para mais de 86 mil funcionrios. Na Extreme Programming o foco da equipe de desenvolvimento est concentrado nas atividades que geram resultados rpidos e na forma de software intensamente testado e alinhado s necessidades dos usurios, como tambm em simplificar e organizar trabalhos levando em conta as tcnicas da XP e eliminar as atividades redundantes. Alm de reduz o risco dos projetos desenvolvendo software de forma iterativa e reavaliando permanentemente as prioridades dos usurios [TELES, 2004]. 3.2 Valores da XP Para que um projeto seja identificado como extreme programming, ele deve inicialmente possuir os quatro valores fundamentais que sustentam as boas prticas de desenvolvimento de sistema, feedback, comunicao, simplicidade e coragem. Esses valores so as diretrizes da XP, so eles que definem as atitudes da equipe e as principais prioridades da metodologia. 3.2.1 Feedback O feedback importante para qualquer processo de

desenvolvimento, principalmente na XP, onde sempre se est tentando eliminar tudo o que se pode, e para isso preciso de retorno para ter certeza se est no caminho certo. O diferencial da XP est no

13

tempo de execuso desse processo, uma vez que possui contato incessante com o cliente esse retorno quase que imediato. 3.2.2 Comunicao a chave para um desenvolvimento rpido e com a satisfao do cliente. A comunicao na XP realiza com foco na simplicidade, em vez de extensos documentos escritos, utilizada uma comunicao face-a-face, sempre que possivel. Esse valor enfatiza a comunicao contnua entre o cliente e os membros da equipe de desenvolvimento, uma vez que na XP o cliente est presente ao processo de evoluo. Com o cliente presente o desenvolvimento progride com maior propriedade, pois ele decide o que vai ser construdo e em que ordem. 3.2.3 Simplicidade Significa que o software desenvolvido usando a forma mais simples possivel de design e construo, o que permitir eliminar, tanto quanto possvel, os elementos desnecessrios na construo de software e facilitar modificaes futuras. Esse valor segue a regra que diz "voc no vai precisar", se no vai precisar no momento entao no deve ser usada, uma funcionalidade s deve ser adicionada quando realmente for necessria, e no em antecipao de necessidade. 3.2.4 Coragem Fazer a coisa certa, mesmo quando no a coisa mais popular a fazer. Por ser um processo inovador que contraria diversas premissas do modelo tradicional, preciso ter coragem para implantar comunicao e feedback entre os desenvolvedores e cliente, e mostrar que esse o caminho mais simples possivel para progredir. preciso ter coragem ainda para enfrentar uma serie de inovaes no processo de desenvolvimento como: desenvolver software de forma incremental; permitir que o cliente defina prioridades; fazer desenvolvedores trabalharem em par; abrir mo de documentao

14

que serve como defesa; modelar e documentar apenas quando for extremamente necessrio. 3.3 Equipe XP Em uma equipe XP de fundamental importncia que os papeis do que cada um ir fazer esteja claro e bem defino no inicio do projeto. Abaixo ser listado os papeis mais importantes de uma equipe XP. 3.3.1 Gerente de projeto uma pessoa que conhece e acredita nos valores e prticas da XP, pois quando necessrio ir cobrar isto da sua equipe. o responsvel pelos assuntos administrativos, pelo envolvimento do cliente com as atividades do projeto, por filtrar assuntos no relevantes ao desenvolvimento do sistema e por possveis implementaes em iteraes futuras. 3.3.2 Coach ideal que esta seja a pessoal com o maior grau de conhecimento no processo de desenvolvimento, nos valores e prticas da XP, pois lidar com questes tcnicas do projeto. O coach tem como responsabilidade verificar e sinalizar, em caso de erro, se todos da equipe compreendem e esto usando os processos XP. 3.3.3 Analista de teste Tem como responsabilidade: testar e garantir a qualidade do sistema; ajudar o cliente a escrever testes de aceitao e assegurar que o sistema os aceite. Na escolha do analista de teste deve ser levado em considerao que seja uma pessoa com viso de fora do projeto e no algum que tenha uma viso somente da codificao. 3.3.4 Redator tcnico responsvel por manter a documentao do sistema atualizada e no envolver os desenvolvedores neste processo. O redator deve ainda possuir uma boa sintonia com a equipe e o cliente,

15

uma vez que a documentao ser feita embasada no cdigo e regras de negocio atendidas pelo sistema. 3.3.5 Desenvolvedor O desenvolvedor responsvel por analisar, projetar e codificar o sistema. Esse papel tambm permitir que em algum momento do projeto, o desenvolvedor exera outras atividades como analista, projetista e programador, isso porque na XP no existe diferena entre essas atividades. Com pratica da XP de programao em par, os nveis distintos de desenvolvedores acabam se tonando uniforme. 3.4 Praticas da XP So as atividades seguidas pela equipe XP durante o processo de desenvolvimento de um sistema. Ao utilizar essas praticas deve ser levado em considerao que a utilizao isolada de uma delas no trar o resultado satisfatrio esperado, pois essas prticas fazer parte de um todo, onde as prticas fracas so compensadas pelas fortes. Abaixo ser descrito um breve resumo sobre cada pratica da XP. 3.4.1 Envolvimento do Cliente No modelo XP, a presena do cliente essencial no dia-a-dia do projeto, pois ele a pessoal mais apta a sanar duvidas dos desenvolvedores, como por exemplo, na compreenso de uma estria, onde logo em seguida ele poder validar essa estria e passar o feedback necessrio sobre as funcionalidades dessa estria possibilitando aos desenvolvedores criar ciclos rpidos e precisos. 3.4.2 Small Release Pequenas Verses a elaborao de pequenas verses funcionais do sistema e liberao ao cliente. Essa prtica sugere que o investimento no projeto seja feita de forma gradual, medida que cada pequena verso funcional do sistema for liberada o cliente poder testar o que est comprando.

16

3.4.3 Integrao Contnua Como o nome j diz, a realizao da integrao de novas funcionalidades, ao sistema, em curtos espaos de tempo, se possvel, podem ser realizados at diversas vezes ao dia. Isso diminui a possibilidade de conflitos e erros no cdigo fonte, alm de permitir que toda a equipe tenha conhecimento do cdigo recm desenvolvido. 3.4.4 Refactoring a melhoria e padronizao de cdigos, esta pratica tende a alterar todo cdigo duplicado, ilegvel, mal codificado, lento e sem padronizao dentro do projeto, desde que essa alterao no comprometa as funcionalidades atuais do sistema. 3.4.5 Cdigo coletivo Lendo sobre esta prtica, possvel usar o termo ningum de ningum para descrev-la, uma vez que na XP no existe uma pessoa responsvel por uma parte do cdigo, todos os desenvolvedores tem acesso e total liberdade para alter-lo, se o cdigo no estiver claro, sem aviso prvio. Essa pratica contribui para uma maior reviso do cdigo. 3.4.6 Design simples Como j dito nos princpios da XP, simplicidade est atrelada ao processo de desenvolvimento. importante que o projeto seja desenvolvido da forma mais simples, com cdigos simples, que atenda as necessidades e possveis alteraes do cliente. O termo programar com cdigos simples facilmente interpretado de forma errnea por parte de alguns desenvolvedores, por achar que a mesma coisa que cdigo fcil. Cdigo simples aquele desenvolvido para uma determinada funcionalidade, sem se preocupar, em um primeiro momento, com os sistemas em que ser linkado.

17

3.4.7 Metfora Tem o objetivo facilitar a comunicao dentro do projeto, atravs de comparaes e analogias com um determinado assunto em questo, desta forma possvel ter uma compreenso mais rpida e de melhor memorizao. Essa pratica traduz as palavras do cliente para uma melhor compreenso dentro do projeto. 3.4.8 Padres de desenvolvimento Para uma boa compreenso do desenvolvimento entre a equipe, a XP orienta que seja utilizado, desde o inicio do projeto, um dos padres da linguagem de desenvolvimento. Isso permitir uma forma mais clara de comunicao seja ela verbal ou codificada. 3.4.9 Stand up meeting Stand up meeting ou Reunio em p, essas reunies so realizadas dessa forma para que no se perca o foco no assunto abordado e para evitar que as reunies se alonguem. 3.4.10 Ritmo sustentvel Para garantir que a equipe esteja sempre concentrada e menos propicia falhas, a XP abomina a pratica de trabalhos exaustivos, que desrespeite os limites fsicos de cada integrante da equipe. O ritmo de trabalho recomendado pela XP uma carga horaria de 8 horas dirias e 40 horas semanais. 3.4.11 Jogo do Planejamento o momento usado para reunir desenvolvedores e cliente para priorizar funcionalidades e assegurar que a equipe esteja trabalhando naquilo que gere o mximo de valor para o cliente. Esse planejamento pode acontecer vrias vezes durante o projeto. Abaixo relaciono alguns pontos importantes abordados no Jogo do Planejamento. So eles:

18

Dividindo Responsabilidades So de responsabilidade do cliente as decises de negocio, enquanto dos desenvolvedores so de decises tcnicas. Contudo essas responsabilidades geram direitos para ambas as parte: Direitos do Cliente Receber um plano geral do que ir ser feito e quanto custar; acompanhar o progresso do projeto atravs de um sistema executvel; mudar de ideia, substituir funcionalidades e alterar prioridades; entre outros. Direitos do Desenvolvedor Saber quais so as necessidades e prioridades; pedir e receber ajuda da equipe e o cliente; gerar e atualizar estimativas; escolher as responsabilidades, ao invs delas serem impostas. Escrevendo estrias No modelo XP, usada a pratica de escrever estrias em cartes, e a partir delas fazer o levantamento das funcionalidades do sistema. As estrias so escritas de forma vontade e com as prprias palavras do cliente. Sabendo que cada estria tem um custo de desenvolvimento, o cliente ser bem claro em cada nova insero de funcionalidade. Tarefas O surgimento de tarefas dentro das estrias acontece a partir do momento em que uma estria demora dias ou at semanas para ser desenvolvida, neste caso, a estria dividida em partes menores chamada tarefa.

19

Estimando as estrias Serve para dizer o tamanho do esforo ou tempo necessrio para implementao de cada estria. Essas estimativas normalmente so feitas por pontos ou por fraes de pontos, tendo como base 8 horas de trabalho dirio. Por exemplo, quando uma estria levasse 8 horas para ser concluda ela receberia 1 ponto de estimativa, se levasse 6 horas, ela receberia ponto de estimativa, ou se levasse 2 horas ela receberia de estimativa. Estimando a Equipe Processo realizado em equipe, onde se avalia as estrias e identificar os aspectos importantes para avaliar as estimativas de desenvolvimento. Esse processo deve contar com a participao do cliente, pois ele pode tirar duvidas e tornar o processo mais gil. Planejando os Releases Neste momento os releases so divididos, de forma que cada um implemente um conjunto de funcionalidades, com valores bem definidos para o cliente. Planejando as Iteraes A realizao deste processo se resume em atribuio de pequenas partes de tempo dedicado a implementao de um conjunto de estrias, esse tempo normalmente tem durao de duas semanas. Aps a definio do tempo, importante que esse se mantenha at o fim do projeto, para facilitar o planejamento futuro. Encerrando uma Iterao

20

Este momento tem como objetivo validar os resultados da iterao e descobrir eventuais erros, atravs de testes feitos pelo cliente. Encerrando um Release O encerramento do release s acontece aps a ltima iterao ser finalizada, e aps este momento o sistema disponibilizado para que os usurios possam acessar. 3.4.12 Programao em Par Baseia-se em um cdigo implementado por duas pessoas trabalhando juntas em um nico computador. A melhor forma de programa de par simplesmente sentar-se lado a lado, em frente do monitor, de modo que os programadores se concentrem no cdigo que est sendo escrito. A habilidade de programar em par algo que leva tempo para aprender. Pois as pessoas tero que aprender a trabalhar de um modo cooperativo, que inclui dar e receber de ambos os parceiros, independentemente da situao da empresa. A tcnica de programao em pares aumenta a qualidade do software uma vez que enquanto um programador codifica o outro programador revisa o cdigo digitado a procura de pequenos erros que poderiam demorar vrias horas para serem localizados. Outro grande benefcio da programao em par a troca de experincia e ideias entre os desenvolvedores, o que uniformiza o nvel dos desenvolvedores da equipe. 3.4.13 Desenvolvimento guiado por testes TDD No modelo XP, para cada cdigo implementado deve existir um teste automatizado, ou seja, primeiramente criado um cdigo e depois criado um cdigo para testar se ele funciona. atravs do teste automatizado que qualquer programador poder alterar, sem medo, uma parte de um cdigo que no tenha sido implementada por

21

ele, j que o teste automatizado dir se houve alterao no comportamento do software. A prtica do TDD conta com dois tipos de testes, so eles: Teste de unidade: responsvel por verificar se os resultados gerados por cada classe esto corretos. Teste de aceitao: verifica se a iterao entre as classes que implementa um funcionalidade atende as necessidades de forma correta.

4. DOCUMENTAO DO PROJETO No uma prtica primordial no modelo XP, a Extreme Programming foi projetada para realizar comunicao face-a-face e no por documentao escrita. O modelo XP defende a ideia de menos burocracia e mais conversa eficaz no encontro com a equipe. 4.1 Documentando Cdigo Como no h uma pratica definida de documentao, a XP utiliza, quando solicitado documento de cdigo, o ciclo de desenvolvimento que comea com design simples, programao em par, testes de unidade extensiva e evoluo de cdigo com a refatorao. Essa documentao suficiente dentro da equipe, mas fora dela seria necessrio escrever uma documentao. 4.2 Documentando Requisitos A documentao de requisitos mais definitiva do que documental, pois eles so documentados na forma de testes automatizados que verificam os resultados da utilizao do software. 4.3 Documentando Design Em virtude da utilizao de um modelo de desenvolvimento em espiral, j explicado acima, pelo fato dos programadores estarem sempre juntos, o modelo julga como desnecessria a construo desse

22

documento. No entanto, em caso extremo que exija o documento, a Equipe XP usa algumas UML em um quadro branco, ou em outro objeto de fcil e simples visualizao da equipe, em seguida pe as mos na massa, constri o documento.

23

5. O CONTRATO DE ESCOPO NA XP De acordo com Beck (2005), no contrato dos projetos XP, so definidos previamente o tempo, custos, qualidade e um escopo que indica o que ser feito, como no desenvolvimento tradicional. A nica diferena que a XP no engessa o escopo em um contrato assinado no inicio do projeto, mas sim negocia as etapas do projeto medida que estas evoluam. Com a assinatura de contratos curtos medida que uma etapa seja encerrada, permite reduzir possveis riscos e dar uma maior liberdade ao cliente em fazer ajustes no escopo e flexibilidade em revisar o escopo medida que o projeto progrida.

24

6. QUANDO NO USAR XP indiscutvel a capacidade da XP em desenvolver software de forma rpida, eficaz, produtiva, disciplinada e sobre tudo humana. No entanto, antes de aplicar a metodologia XP devem ser levados em considerao alguns fatores que possam impossibilitar o uso da metodologia, como por exemplo: equipes grandes; clientes desconfiados e tecnologia que no permita suporte facilitado a mudanas. Outros fatores tambm podem impossibilitar o uso da XP, so eles: Cultural: A equipe j est organizada e trabalhando em um modelo tradicional de desenvolvimento. Isso levar muito tempo at que a equipe consiga adotar as prticas da XP e esquea as tradicionais. Tamanho da Equipe: A XP preza por trabalhar com uma equipe pequena, de no mximo 12 programadores. Com uma equipe de 100 programados no vivel o uso da XP, pois os resultados no sero obtidos com a mesma qualidade. Tecnologia: Tambm no aconselhvel usar XP quando a tecnologia no permite escrever casos de teste, quando o feedback demorado e quando no incorpora facilmente as mudanas. Espao Fsico: Deve permitir organizao da equipe XP de forma que todos fiquem prximos uns aos outros. Cliente: Para aplicao da XP, imprescindvel que o cliente esteja presente e disponvel para esclarecimento de duvidas no desenrolar do projeto.

25

7. CONCLUSO Este trabalho teve como foco principal a apresentao da Extreme Programming, juntamente de seus valores, equipe e boas prticas de programao. Foi abordado ainda, modelos de desenvolvimento de software, tradicional e gil, o desenvolvimento guiado por teste, documentao do projeto, contrato de escopo da XP e alguns fatores que implicam em no utilizar XP. A partir do que foi apresentado, possvel concluir que, a Extreme Programming uma metodologia que busca, de forma inovadora, minimizar e porque no solucionar os problemas de atrasos em cronograma, oramentos estourados, trabalho desnecessrio, alm do desperdcio de tempo e dinheiro investido na aplicao. Embasada em valores e prticas de desenvolvimento, a XP proporciona que sua Equipe trabalhe de forma simples, porm eficiente, concentrada e com uma constante troca de experincia. Foi possvel compreender com este trabalho a importncia do cliente estar sempre por perto, no desenvolvimento do projeto, tirando duvidas e validando funcionalidades, isso permite que o projeto esteja em constante evoluo e sempre atendendo as necessidades do cliente. Enfim, conclumos que mesmo sendo uma metodologia relativamente nova, e possuindo alguns pontos fracos, mas que esses em conjunto com valores e princpios da XP, so supridos pelos pontos fortes, a Extreme Programming tem uma grande chance futuramente de ser a metodologia mais eficaz no desenvolvimento de software gil.

26

8. REFERNCIAS

Birrell, N.D..A Practical Handbook for Software Development. [S.l.]: Cambridge University Press, 1985. ISBN 0521254620 TELES, Vincius Manhes. Extreme Programming: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. 1. ed. So Paulo: Novatec, 2004. 316 p. CASTRO, Vinicius A. Desenvolvimento gil com Programao Extrema. Monografia Curso de Cincia da Computao, Universidade Federal de Sergipe, So Cristvo, Sergipe, 2007. BECK, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change, Second Edition. Addison Wesley Professional, 2005.