Trabalho de Fundamentos da Engenharia de Software eXtreme Programming Daniel Fabio Domingues Posner 099233844 Rafael Elias de Lima Escalfoni 100134931

Trabalho de Fundamentos da Engenharia de Software

eXtreme Programming

Daniel Fabio Domingues Posner 099233844Rafael Elias de Lima Escalfoni 100134931Rafael de S. Tenório Cavalcanti 104120277

U n i v e r s i d a d e F e d e r a l d o R i o d e J a n e i r o

eXtreme Programming

Criada em 1996 por Kent Beck e Ward Cunningham no desenvolvimento de um sistema de recursos humanos chamado “C3” para a montadora de automóveis Chrysler.

Metodologia ágil, voltada para equipes de pequeno e m₫dio porte de desenvolvimento de software, que precisam lidar com problemas que estejam em mudan₤as constantes, principalmente causados pela dificuldade do levantamento de requisitos iniciais.

Introdu₤₧o

eXtreme Programming

Nos modelos tradicionais o custo de mudan₤as ₫ alto.(tem que fazer ajustes na fase inicial do projeto)

A eXtreme Programming já trabalha pensando que mudan₤as ir₧o ocorrer, o que diminui o custo para uma altera₤₧o.

Introdu₤₧o

eXtreme Programming

Recomendada para equipes de 2 à 12 membros, devido a necessidade de comunica₤₧o e simplicidade. Para implementar em grandes empresas, basta fazer uma divis₧o em várias equipes.

A eXtreme Programming ₫ baseada em quatro valores: Comunica₤₧o, Simplicidade, Feedback e Coragem, que s₧o responsáveis pela melhoria do custo de uma altera₤₧o de requisitos durante o ciclo de vida do projeto.

Introdu₤₧o

eXtreme Programming

A eXtreme Programming se baseia em uma s₫ria de práticas, que podem ser utilizadas individualmente, mas que obt₫m melhores resultados quando utilizadas em conjunto.

Muitas práticas da eXtreme Programming s₧o apenas de bom senso e as pessaos já as utilizam mesmo sem saber. O nome “eXtreme Programming” vem da aplica₤₧o dessas praticas a níveis extremos.

Introdu₤₧o

eXtreme Programming

Se ₫ bom fazer revis₧o de código, ent₧o o código será sempre revisado (Pair Programming).

Se ₫ bom fazer testes, todos v₧o testar o código o tempo todo (Unit Testing), at₫ mesmo o cliente (Functional Testing).

Se fazer projetos ₫ bom, ent₧o será parte do dia-a-dia de todos (Refactoring).

Se ₫ bom o projeto ser simples, o sistema será sempre na forma mais simples que suporte as necessidades requisitadas (The Simpliest Thing That Could Possibly Work).

Introdu₤₧o

eXtreme ProgrammingValores

Baseada em 4 valores: Comunica₤₧o, Simplicidade, Feedback e Coragem.

Comunica₤₧o: Principal valor da XP, grande parte das práticas est₧o baseadas nela. Se n₧o for eficiente pode causar atrasos e problemas no projeto. Uma equipe deve ter meios de se comunicar de maneira rápida e eficiente com o cliente, com o gerente do projeto e com outros desenvolvedores envolvidos.


Simplicidade: É muito difícil n₧o olhar para frente, para os requisitos que precisam ser implementados amanh₧, na próxima semana e no próximo m₨s. Mas ficar compulsivamente pensando no futuro ₫ um dos problemas da curva do custo exponencial das mudan₤as. A XP aposta que ₫ melhor fazer algo simples e de desenvolvimento rápido hoje, e ter que gastar um pouco mais no futuro para remodelar um processo, do que implementar um grande projeto, que acabe tendo muitas funcionalidades que acabem nunca sendo necessárias.


Feedback: O cliente deve receber o sistema o quanto antes, a fim de poder dar um feedback rápido, guiando assim o desenvolvedor do software. Quanto mais cedo o cliente colocar o sistema em produ₤₧o, mais rápido podem ser feitos ajustes para que o mesmo fique de acordo com o que o cliente realmente quer.

Coragem: É preciso coragem para mudar a maneira pela qual se desenvolve sistemas. Colocar um sistema em produ₤₧o assim que ele tenha valor para o cliente, fazer apenas o que se precisa para o momento e adiar o processo de análise n₧o ₫ nada facil.

eXtreme Programming

A XP ₫ baseada em um conjunto de 12 práticas fundamentais, que podem ser aplicadas individualmente, mas que funcionam melhor em conjunto.

Práticas

1. The Customer is Always Available 7. Simple Design2. Planning Game 8. Refactoring3. Collective Code Ownership 9. Pair Programming4. Acceptance Tests 10. Small Releases5. Test First Design 11.Coding Standards6. Continuous Integration 12. 40 Hour Week

eXtreme Programming

1. The Customer is Always Available: O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma itera₤₧o e definir prioridades.

Na XP todas as decisões sobre o rumo do projeto devem ser tomadas pelo cliente. Ele deve priorizar as tarefas, ser responsável pelos testes de aceita₤₧o e orientar os desenvolvedores durante o processo de programa₤₧o.

Esse prática encontra alguma resist₨ncia por que as empresas acham muito caro destinar um funcionário para ficar acompanhando o processo. Como solu₤₧o ou pode-se nomear um membro da equipe para representar ou cliente, ou se fazer reuniões semanais.

Práticas

eXtreme Programming

2. Planning Game: Os jogadores do jogo do planejamento s₧o o cliente e os t₫cnicos. O objetivo: colocar em produ₤₧o as funcionalidades de maior valor possível durante o decorrer do jogo.

No planning game o software ₫ efetivamente planejado pela equipe de desenvolvimento e pela equipe do cliente. Nesta atividade, cada equipe tem o seu papel bem claro e definido: a equipe do cliente ₫ responsável por definir escopo e prioridades e a equipe de desenvolvimento por fornecer estimativas.

Práticas

eXtreme ProgrammingPráticas

2. Planning Game (continua₤₧o)Muitas vezes ₫ difícil manter as equipes focadas

exclusivamente no seu papel. Por isto, cabe ao coach da equipe de desenvolvimento ficar alertando sobre possíveis desvios, evitando que os desenvolvedores escolham as tarefas e que o cliente fa₤a estimativas de prazo de entrega.

Para a realiza₤₧o do Planning Game, o cliente já deve ter as User Stories definidas e baseado em conhecimentos anteriores os desenvolvedores devem fornecer estimativas para o desenvolvimento para cada Story.


2. Planning Game (continua₤₧o)Se n₧o for possível estimar uma Story, quer

dizer que ela esta muito complexa e deve ser dividida em Stories menores, por outro lado, se esta for muito pequena, deve ser agregada a outras. Normalmente ela ₫ adequada quando pode ser desenvolvida em dois ou tr₨s dias.A rela₤₧o entre as funcionalidades entregues e as solicitadas pelo cliente a cada itera₤₧o ₫ chamada de Velocity.


2. Planning Game (continua₤₧o)De posse das User Stories e das estimativas feitas

pela quipe de desenvolvimento, os clientes devem definir o escopo da próxima itera₤₧o, selecionando aquelas que ele deseja que sejam implementadas.

Nas reuniões do Planning Game tamb₫m s₧o repassadas para o cliente as informa₤ões sobre o andamento da release atual e informa₤ões sobre eventuais atrasos.


3. Collective Code Ownership: A equipe como um todo ₫ responsável por cada arquivo de código. N₧o ₫ preciso pedir autoriza₤₧o para alterar qualquer arquivo.

O código deve ser de propriedade de todos e todos devem ter permiss₧o para alterar o que for necessário para que seu trabalho possa ser desenvolvido.

Todos s₧o donos e responsáveis por todo o código. Para garantir o mínimo de problemas com esta t₫cnica, existem os testes automatizados e a Continuous Integration, que garante que as altera₤ões feitas v₧o ser anexadas rapidamente ao código principal, diminuindo muito a chance de duas duplas estarem trabalhando no mesmo código.


4. Acceptance Tests: Os testes de aceita₤₧o s₧o a melhor maneira pela qual o cliente pode fornecer feedback sobre o sistema. S₧o eles que indicam para os desenvolvedores quando a story que eles est₧o desenvolvendo está pronta ou n₧o.

Os testes devem ser escritos pela equipe do cliente, fornecendo material para que os desenvolvedores do sistema possam avaliar o progresso da implementa₤₧o, e ter certeza de que o que est₧o desenvolvendo está correto.


4. Acceptance Tests: (continua₤₧o)Os testes devem ser escritos antes que inicie o

desenvolvimento da Story, e devem ser automatizados para diminuir o tempo gasto com eles.

Os testes sendo definidos pelo cliente, fazem com que o produto final fique mais de acordo com o que o cliente realmente precisa, uma vez que cada tarefa só vai será concluída depois de passar pelos testes que o próprio cliente definiu. Colocando a cria₤₧o de testes como uma tarefa do cliente o obriga a participar de forma realmente efetiva do desenvolvimento do sistema e cria uma "cumplicidade" maior entre equipe de desenvolvimento e equipe do cliente.


5. Test First Design: Define que qualquer m₫todo de cada objeto que possa falhar deve ter um teste automatizado que garanta o seu funcionamento.

Após os programadores receberem a Story a ser implementada, eles passam a escrever os testes unitários para ela.

Os testes automatizados s₧o fundamentais para a XP, uma vez que d₧o suporte a outras t₫cnicas da metodologia, como o Refactoring e o Collective Code Ownership

eXtreme Programming

6. Continuous Integration: A t₫cnica de Continuous Integration diz que o código desenvolvido por cada par de desenvolvedores deve ser integrado ao código base constantemente.

Geralmente os problemas de integra₤₧o ocorrem por haver muita diferen₤a entre os códigos desenvolvidos, pois muito trabalho foi feito por cada membro da equipe entre cada integra₤₧o

Com a integra₤₧o contínua, e os unit tests, estes problemas se reduzem bastante, pois cada vez que algum código ₫ integrado, todos os unit tests devem ser rodados, e se algum deles falhar, ₫ porque o código rec₫m integrado foi o responsável por inserir este erro no sistema.

Práticas


7. Simple Design: Deve-se projetar apenas "a coisa mais simples que possa funcionar".

Esta ent₧o ₫ a aposta da XP, que n₧o deve ser desenvolvido nada que n₧o seja necessário para a itera₤₧o na qual se está trabalhando agora, "resistindo à tenta₤₧o" de fazer uma rotina "mais completa". Este princípio ₫ conhecido na XP pela sigla YANGNI (you are not gonna need it), que diz que normalmente se acaba n₧o precisando de todas as funcionalidades e flexibilidade que se coloca em um código que poderia ser implementado de forma simples.


8. Refactoring: Deve-se reescrever o código, melhorando e simplificando o mesmo, sempre que for possível.

Indícios de que um código precisa de refactoring s₧o: código duplicado, m₫todos de classes muito longos, m₫todos cujos nomes n₧o indicam claramente o que fazem e excesso de comentário no código.

Com o refactoring se consegue Simple Design e os Testes automatizados d₧o seguran₤a ao processo, assim vemos como as práticas do XP se complementam.


9. Pair Programming: Todo o código deve ser produzido por duas pessoas utilizando o mesmo computador. Enquanto um dos parceiros se preocupa com detalhes da implementa₤₧o, ficando responsável pela digita₤₧o do código, o outro deve tentar ter uma vis₧o mais ampla da rotina, revisando o código.

Duas pessoas conseguem pensar em um número maior de testes automatizados, existe uma troca de experi₨ncias fazendo um nivelamento da equipe e garante que todos os membros da equipe já tenham trabalhado em todos os módulos dos sistema.


10. Small Releases: Com pequenas releases ₫ possível existir um feedback constante do cliente, conseguindo dados para o Planning Game. Assim ₫ possível ajustar o desenvolvimento às necessidades que v₧o surgindo no decorrer do processo.

Geralmente trabalha-se com releases mais curtas, já que quanto menor o tempo entre cada vers₧o, mais facil fica corrigir eventuais problemas.


11. Coding Standards: Para que todos possam ter acesso a qualquer parte do código e que as pessoas possam trabalhar em pares, ₫ importante que os desenvolvedores sigam um padr₧o de desenvolvimento. O ideal ₫ que, com o passar do tempo, algu₫m que olhe o código n₧o saiba dizer por quem o mesmo foi escrito. Assim fica mais fácil conseguir um código simples, e muito mais ágil o processo no caso da necessidade de um Refactoring

eXtreme Programming

12. 40 Hour Week: Trabalhar por longos períodos ₫ contraproducente. Um programador cansado coloca mais erros no código e o tempo ganho em uma noite de hora extra muitas vezes ₫ perdido no dia seguinte, procurando por um bug dentro de uma rotina. O número 40 ₫ apenas uma sugest₧o, cada pessoa tem sua própria capacidade de trabalho, este tempo poderia ser de 35 ou 45 hora.

Práticas

eXtreme ProgrammingVariáveis

Na Extreme Programming, s₧o consideradas quatro variáveis que est₧o presentes no desenvolvimento de um projeto: custo, tempo, qualidade e escopo.

Se o cliente decide, por exemplo, em ter um projeto com o menor custo, no menor prazo e com a qualidade máxima, a quarta variável, neste caso escopo, deve ser definida de acordo pela equipe de desenvolvimento, ficando neste exemplo bastante prejudicada.


Custo: poucos recursos para um projeto podem trazer s₫rios prejuízos para as demais variáveis, pois com um or₤amento muito apertado normalmente n₧o se consegue contar com a equipe que se gostaria, e isto pode trazer problemas para a efetiva resolu₤₧o do problema do cliente. Tempo: um prazo maior para a entrega final do sistema aumenta a qualidade e o escopo do mesmo, dentro de um limite. Por outro lado, caso o prazo seja muito pequeno, prejudica-se o escopo da aplica₤₧o.


Qualidade: Pode-se ter ganhos pequenos (dias ou semanas) se sacrificando a qualidade em alguns pontos do projeto, como por exemplo definindo-se um número menor de unit tests para uma classe. Contudo, mas este ganho tende a desaparecer na medida em que a baixa qualidade pode causar problemas que tomar₧o tempo para serem corrigidos.

Escopo: um escopo menor pode melhorar a qualidade, pois se tem menos tarefas para serem desenvolvidas, e tamb₫m reduz o prazo e o custo.


As variáveis custo e tempo normalmente s₧o decis₧o do cliente, pois ₫ dele a decis₧o sobre quando precisa do sistema implementado e qual o valor que está disposto a pagar por isto. A variável qualidade n₧o deve ser sacrificada. Portanto, normalmente a variável sobre a qual a equipe de desenvolvimento acaba tendo o controle ₫ sobre o escopo.

eXtreme ProgrammingM₫tricas

O Release Plan ₫ o plano de desenvolvimento gerado a partir das sessões de planning game. Neste plano est₧o definidas quais as stories far₧o parte de cada itera₤₧o dentro da release, qual o desenvolvedor responsável por cada story e a estimativa de prazo.

Um termo importante dentro do planejamento de projetos XP ₫ velocity. A velocity ₫ a rela₤₧o entre funcionalidades entregues e as funcionalidades planejadas por cada desenvolvedor e deve ser medida a cada itera₤₧o.


Toda metodologia de desenvolvimento deve fornecer ao seu gerente condi₤ões para avaliar o andamento do projeto, atrav₫s de medi₤ões de qualidade (tanto do produto quanto do processo de desenvolvimento) e prazos. Estas medi₤ões s₧o conhecidas no desenvolvimento de sistemas como m₫tricas. As m₫tricas mais importantes na XP s₧o:

Velocity: Número de funcionalidades entregues comparado ao número de funcionalidades prometidas.

40 Hour Week: Quantidade de horas trabalhadas por semana por desenvolvedor.


Test Coverage of the Code: Quantidade de Unit Tests por classe, tamb₫m ₫ uma m₫trica de qualidade interna de trabalho, pois serve para medir o qu₧o testado está um sistema.

Acceptance Test Coverage: Quantidade de testes de aceita₤₧o do projeto como um todo.

Acceptance Test Pass: Percentual de testes de aceita₤₧o aprovados para cada itera₤₧o enviada, em rela₤₧o ao total de testes de aceita₤₧o da mesma.

Relative Bug Density: Quantidade de erros encontrados pelo usuário para cada classe multiplicado pelo tempo que cada um levou para ser corrigido.


Estas m₫tricas s₧o possíveis gra₤as ao caráter dinâmico da XP, onde o cliente pode fornecer feedback sobre o desenvolvimento durante o mesmo, e n₧o apenas após ter o produto final em suas m₧os. Por este aspecto, e tamb₫m por suas características de ser fortemente baseado em testes, tanto unitários quanto de aceita₤₧o, que a ger₨ncia de projetos em XP difere tanto da ger₨ncia tradicional.

eXtreme ProgrammingCasos bem sucedidos

Algumas empresas que utilizam eXtreme Programming:

BrasilEmpresa Cidade SiteObjective Solutions São Paulo, SP e Curitiba, PR www.objective.com.brImprove It Rio de Janeiro, RJ www.improveit.com.brBrasilTelecom Brasília, DF www.brasiltelecom.com.brEmbrapa InformáticaAgropecuária

Campinas, SP www.cnptia.embrapa.br

Qualiti Recife, PE www.qualiti.com.brSecretaria da Fazenda doEstado de São Paulo

São Paulo, SP www.fazenda.sp.gov.br

CETIP Rio de Janeiro, RJ www.cetip.com.brA&L Software Campinas, SP www.alsoftware.com.brArgonavis São Paulo, SP www.argonavis.com.brSoftSite Tecnologia Fortaleza, Ceará www.softsite.com.br


Estados UnidosEmpresa Cidade SiteIndustrial Logic, Inc. Berkeley, CA www.industriallogic.comThoughtWorks, Inc. Chicago www.thoughtworks.comRoleModel Software, Inc. Holly Springs, NC www.rolemodelsoft.comMonster Consulting, Inc. Bountiful, Utah www.monsterconsulting.comObject Mentor, Inc. Vernon Hills, IL www.objectmentor.comTrilogy Austin, Texas www.trilogy.comSymantec, Inc. Beaverton, OR www.symantec.comMotorola, Inc. Arlington Heights, IL www.motorola.comCC Pace Systems Fairfax, VA www.www.ccpace.comKuvera Enterprise Solutions, Inc. Boulder, CO www.kuvera.comEscrow.com Santa Ana, CA www.escrow.comThinkspark Dallas, Texas www.thinkspark.comIONA Technologies Waltham, MA www.iona.comVerio, Inc. Orem, UT www.verio.netNet Objectives, Inc. Issaquah, WA www.netobjectives.come-automate Corporation American Fork, UT www.e-automate.comTRW, Inc. Aurora, Colorado www.trw.comSabre Southlake, Texas www.sabre.comQuest Software Irvine, CA www.quest.comFidelity Investiments Cincinnati, OH www.fidelity.comJera Design San Francisco, CA www.jera.comLearningPatterns.com, Inc. New York, NY www.learningpatterns.comTrivera Technologies Medford Lakes, NJ www.triveratech.comTwin Bridge Consulting Skokie, IL www.twinbridgeconsulting.comPoppendieck.LLC Eden Prairie, MN www.poppendieck.comBoldTech Systems Denver, CO www.boldtech.comBespoke Technologies Denver, CO www.bespoketechnologies.comVirtuas Englewood, CO www.virtuas.com


América LatinaEmpresa Cidade País SiteRMyA Buenos Aires Argentina www.rmya.com.arPrimal Forces Buenos Aires Argentina www.132.com.arWalicxe Montevideo Uruguai www.walicxe.com

InglaterraEmpresa Cidade SiteSecure Trading Bangor www.securetrading.comWorkshare Technology Londres www.workshare.comConnextra Londres www.connextra.comThoughtWorks Ltd. Londres www.uk.thoughtworks.comLogicaCMG Londres www.logicacmg.comeXoftware Londres www.exoftware.com

AlemanhaEmpresa Cidade SiteOFFIS Oldenburg www.offis.deSiemens AG Munique www.siemens.deDaimlerChrysler AG Stuttgart www.daimlerchrysler.de/Daedalos Consulting Witten www.daedalos.deCórtex Brainware Pullach im Isartal www.cortex-brainware.deAgile Software & Consulting GmbH Hahnstätten www.agile-gmbh.defumiX IT Consulting GmbH Heidelberg www.fumix.de


CanadáEmpresa Cidade SiteClearStream Consulting Inc. Calgary www.clearstream.comRed Hook Group Red Hook Group Toronto www.redhookgroup.comMayford Technologies Almonte www.mayford.caSaorsa Development Inc. Nova Scotia www.saorsa.comAgile Logic Fullerton www.agilelogic.comSoftware Productivity Center, Inc. Vancouver www.spc.ca

EuropaEmpresa Cidade País SiteLesire Software Engineering Leuven Bélgica www.lesire.comEuropeloan Bank Bruxelas Bélgica www.europeloan.comAlcatel R&I Antuérpia

MarcoussisBélgicaFrança

www.alcatel.bewww.alcatel.fr

Tryx bvba Mechelen Bélgica www.tryx.comTietoEnator Consulting Oslo Noruega www.tietoenator.comBanca IMI S.p.A. Milão Itália www.bancaimi.iteXoftware Dublin Irlanda www.exoftware.comSoftware ImprovementGroup

Holanda Amsterdam

www.software-improvers.com/

Daedalos Zurique Suíça www.daedalos.comMandrillo Consulting Johanneshov Suécia www.mandrillo.seLysholdt Consulting A/S Solrød Strand Dinamarca www.lysholdt-consulting.comISB Barcelona Espanha www.isb.esInvest Valley.com Saint-Priest França www.invest-valley.com

eXtreme ProgrammingProgramas que utilizam

Iterate: ₫ uma ferramenta comercial desenvolvida pela empresa Diamond Sky e foca exclusivamente no controle das user stories e no planning game.http://www.diamond-sky.com/products/iterate

http://www.diamond-sky.com/products/iterate

eXtreme ProgrammingProgramas que utilizam

XpPlanit: ₫ uma ferramenta comercial on-line para gerenciamento de projetos XP, tamb₫m baseada no planejamento de itera₤ões e na medi₤₧o constante da velocity, com a característica de ter um repositório central de projetos que possam ser acessados pelos membros da equipe pela Web.http://www.xpplanit.com/

http://www.xpplanit.com/

Programas que utilizameXtreme Programming

VersionOne: desenvolvido pela empresa VersionOne, ₫ mais uma ferramenta comercial de controle de itera₤ões baseada em user stories, que, a exemplo das anteriores, tamb₫m gera estatísticas sobre a medi₤₧o da velocity da equipe.http://www.versionone.net/

http://www.versionone.net/


Select Scope Manager: ₫ uma ferramenta comercial, bastante completa, que permite o controle de itera₤ões e releases, e tem como diferencial em rela₤₧o às ferramentas anteriores a possibilidade de exportar dados para o MS-project.http://www.selectbs.com/products/scope.htm

http://www.selectbs.com/products/scope.htm


XP Tracker Plugin: O XP Tracker Plugin ₫ um plugin para a interface wik i, utilizada no desenvolvimento de páginas web colaborativas. Na verdade n₧o ₫ uma ferramenta, mas sim uma esp₫cie de linguagem de script para a interface citada acima, que possibilita o controle de stories e a medi₤₧o da velocity.http://twiki.org/cgi-bin/view/Plugins/XpTrackerPlugin

http://twiki.org/cgi-bin/view/Plugins/XpTrackerPlu

eXtreme ProgrammingConclusões

Como rela₤₧o às metodologias tradicionais, consideradas muito pesadas para equipes pequenas, um novo grupo de metodologias surgiu nos últimos anos. Elas s₧o chamadas de metodologias ágeis, entre as quais a XP se enquadra, e propõem uma diminui₤₧o na burocracia do desenvolvimento de software.

Em um encontro em Utah, nos Estados Unidos, em fevereiro de 2001, os principais autores das ent₧o chamadas metodologias leves se encontraram para discutir as semelhan₤as entre suas metodologias, e descobriram que elas t₨m muito em comum. Nesta ocasi₧o foi criado o termo metodologias ágeis, e foi escrito o "manifesto ágil", que descreve as quatro principais diferen₤as entre as metodologias ágeis e as metodologias tradicionais:

eXtreme Programming1) Indivíduos e itera₤ões ao inv₫s de processos e ferramentas.

2) Software em funcionamento ao inv₫s de documenta₤₧o compreensível.

3) Colabora₤₧o do cliente ao inv₫s de negocia₤₧o de contrato.

4) Responder às mudan₤as ao inv₫s de seguir o plano.

Conclusões

ConclusõeseXtreme ProgrammingSendo as duas principais diferen₤as entre as

metodologias ágeis e as tradicionais:

1) Elas s₧o adaptativas, ao inv₫s de previsivas: as metodologias tradicionais tentam planejar uma grande parte do software em muitos detalhes com bastante anteced₨ncia. Por isto elas s₧o resistentes à mudan₤a. Já nas metodologias ágeis, as mudan₤as de requisitos durante o desenvolvimento s₧o bem-vindas. Elas tendem a ajustar o desenvolvimento do software às mudan₤as de requisitos, sendo mais flexíveis neste ponto.

2) Elas s₧o orientadas às pessoas, n₧o aos processos: a meta das metodologias de desenvolvimento ₫ desenvolver um processo que vai funcionar da mesma maneira, independente de quem o esteja utilizando. Metodologias ágeis levam mais em conta a habilidade da equipe de desenvolvimento, e tendem por isto a se ajustar à equipe.

ConclusõeseXtreme ProgrammingAs metodologias ágeis s₧o hoje uma realidade, uma

vez que est₧o ficando cada vez mais populares entre os desenvolvedores. Estas metodologias t₨m em comum um foco maior na comunica₤₧o e na codifica₤₧o, ao inv₫s de focar no processo, como as metodologias tradicionais. Uma destas metodologias ₫ a Extreme Programming, baseada em um conjunto de t₫cnicas e valores rígidos, que devem ser observados durante todo o ciclo de vida do desenvolvimento. A XP, por seu caráter informal, gera pouca documenta₤₧o e prega que qualquer t₫cnica de ger₨ncia de projetos que for empregada deve ser o menos burocrática possível, pois o foco da equipe de desenvolvimento deve se a produ₤₧o do software.


A ger₨ncia de projetos XP, ent₧o, deve ser o mais "leve" possível, n₧o gerando documenta₤₧o desnecessária e n₧o pertinente ao desenvolvimento. Para tanto, as t₫cnicas de ger₨ncia de projetos aplicadas a esta metodologia devem seguir as características da mesma, como o uso de user stories, o planejamento de releases e o acompanhamento das tarefas dos desenvolvedores. Por outro lado, ₫ necessário aos administradores do negócio um acompanhamento da rentabilidade dos projetos, característica que n₧o ₫ pertinente à metodologia, mas que pode ser obtida pelos mesmos lan₤amentos efetuados para o tracking do projeto.


Verificamos tamb₫m que o eXtreme Programming ₫ uma metodologia bastante promissora, que pode ser bastante vantajosa se for bem utilizada. Encontramos uma grande dificuldade em definir vantagens e desvantagens na sua utiliza₤₧o, já que este assunto ₫ muito subjetivo. Algumas consequencias da implementa₤₧o do eXtreme Programming como a diminui₤₧o da documenta₤₧o e a necessidade de mais pessoas nas equipes, podem ser vistas como vantagens para algumas pessoas e como desvantagens para outras, ent₧o tentamos nos manter objetivos, e apenas explicar as consequencias da sua utiliza₤₧o, e deixar o leitor decidir por si próprio se considera cada consquencia uma vantagem ou uma desvantagem.

eXtreme ProgrammingBibliografia

eXtreme Programming Refactored - The case against XP Matt Stephens.

eXtreme Programming for Web ProjectsDoug Wallace. IsobelRagget.

eXtreme Programming Applied - Playing to WinTravis Griggs.

eXtreme Programming ExplainedKent Beck.

Questioning eXtreme ProgrammingPete McBreen.

Extreme ProgrammingVinicius Teles.

Documents

Trabalho de Fundamentos da Engenharia de Software eXtreme Programming Daniel Fabio Domingues Posner 099233844 Rafael Elias de Lima Escalfoni 100134931