XP (Extreme Programming) Desenvolvimento ágil Fundamentos Aplicações Valores
Introdução Não adianta ter bons profissionais, com um bom planejamento e riscos calculados, se não existir comunicação entre eles. De que adianta? O que acabaremos gerando serão: cronograma e custos imprevisíveis. Com a busca dessa idéia, o numero de softwares finalizados no prazo e dentro do orçamento previsto, teve aumento considerável devido ao uso de métodos de des desenv envolv olvime imento nto ág ágil, il, cuj cujoo ob objeti jetivo vo é rapide rapidezz na ent entreg rega, a, aliada aliada a
qualidade do processo e do produto. Hoje há vários métodos de desenvolvimento ágil, entre eles está o XP (Extreme Programming) que será estudado nesse trabalho. Os valores defendidos pela XP como o próprio nome diz deriva-se da idéia de se utilizar boas práticas em extremo, e não apenas comprar algumas idéias e mudanças e aplicar, este pode ser um fator determinante para definir o seu sucesso ou o seu fracasso. Apesar de o XP ser um método de desenvolvimento ágil que auxilia na produção do software e ter inúmeras vantagens, ele também tem algumas desvantagens, que serão apresentadas a seguir.
Desenvolvimento Ágil As metodologias tradicionais (modelos em cascata, iterativo e prototipação) faziam parte de um desenvolvimento de software muito diferente do atual. As modif mo difica icaçõe çõess nec necess essári árias as tinh tinham am um custo custo alt alto, o, dev devido ido às lim limita itaçõe çõess dos comput com putado adores res e fal falta ta de ferram ferrament entas as mo moder dernas nas para para ap apoia oiarr a criaçã criaçãoo do software. Por isso, primeiro o software era planejado e documentado para então ser implementado. O modelo clássico caracterizado como metodologia tradi tradici cion onal al é ut utililiz izad adoo at atéé ho hoje je.. Segu Seguem em algu alguns ns mo motitivo voss pa para ra o pe pequ quen enoo rendimento e sucesso desses modelos: ●
Tempo Tempo ele elevad vadoo ent entre re ca cada da fas fasee do projeto projeto,, não aco acomp mpanh anhand andoo as mudanças de requisitos do projeto;
●
Falta de conhecimento por parte do cliente da sua real necessidade;
●
Forte linearidade no desenvolvimento do projeto.
Nos últimos anos, começaram a aplicar novas metodologias, visando sempre à rapidez no fornecimento do software junto com a qualidade do processo e do produto. Surgem, então, os métodos ágeis, popularizados quando Kent Beck criou o Manifesto Ágil, indicando alguns princípios compartilhados por tais métodos: ●
Foco em indivíduos e interações: melhores do que processos e ferramentas evitando especulações dos desenvolvedores; desenvolvedores;
●
Software funcionando: é mais importante do que documentação detalhada;
●
Colaboração do cliente: ao invés de negociação de contratos;
●
Adaptação a mudanças: é mais viável do que seguir um plano inicial (Ausência de linearidade no desenvolvimento do projeto).
O objetivo do Manifesto Ágil não é desconsiderar processos, ferramentas, documentação, negociação de contratos ou planejamento, mas mostrar o valor secundário que estes possuem diante dos indivíduos e interações, do bom funcionamento do software, da colaboração do cliente e das respostas velozes
às modificações. Esses conceitos estão mais relacionados à forma que as pequenas e médias organizações trabalham, devido a estarem habituadas a mudanças. A mais conhecida dentre as metodologias ágeis é o XP .
3 XP (Extreme Programming) XP é uma metodologia para desenvolvimento de software ágil, com qualidade que atenda as necessidades do cliente, ou a prática e perseguição da mais clara simplicidade, aplicando no desenvolvimento de software. Foi criado no final da década de 90. É uma metodologia ágil voltada a equipes pequenas e médias que produzem software baseados em requisitos vagos e quee mu qu muda dam m co com m rapi rapide dez. z. As princ princip ipai aiss dife difere renç nças as en entre tre o XP e ou outra trass metodologias são feedbacks constantes e uma abordagem incremental. Para isso é necessária uma comunicação entre os indivíduos. Conforme Astels, a necessidade de entregar o software mais rápido fez com que Kent Beck, Wrad Cunningham e Ron Jeffries explorassem os extremos de determinadas práticas de desenvolvimento. O primeiro projeto a usar a metodologia XP, foi o C3 (Chrysler Comprehensive Compensation) da Chrysler, por um lado restrito e por outro lado levado aos limites. Essa prática foi chamada de “acertar os pontei pon teiros ros em dez dez”. ”. O resulta resultado do foi um umaa ino inovaç vação ão no des desenv envolv olvime imento nto de software, chamada XP. A XP é considerada uma disciplina de desenvolvimento de software, porque há certas coisas que você precisa fazer para estar desenvolvendo a XP, se você optar por não fazer testes você não estará sendo Extremo. ●
Ter feedback antecipado, concreto e contínuo pelos ciclos curtos.
●
Por sua abordagem incremental de planejamento, que gera rapidamente um plano geral que vai evoluir com o decorrer do projeto.
●
Habilidade de agendar de forma flexível a implementação das funcionalidades, respondendo às mutáveis necessidades do negócio.
●
Confia Con fiança nça nos tes testes tes aut autom omati atizad zados os escrit escritos os por progra programa mador dores es e clientes para monitorar o progresso do desenvolvimento, para permitir que o sistema evolua e para detectar cedo os erros.
●
Comunicação oral, testes e código fonte para comunicar a estrutura e o objetivo do sistema.
●
Confiança na intensa colaboração de programadores com habilidades comuns.
●
Confiança nas práticas que combinam tanto com os instintos de curto prazo prazo dos progra programa mador dores es qua quanto nto os int intere eresse ssess de lon longo go prazo prazo do projeto.
4 Fundamentos da XP
Há diversos fundamentos que a XP leva ao extremo e que em sua maioria não são val valori orizad zadas as ou me mesmo smo me menci nciona onadas das pel pelas as dem demais ais met metodo odolog logias ias de desenvolvimento. desenvolvimento. Dentre elas podemos citar: ●
Se revisar o código é bom, revisaremos código o tempo inteiro (Programação em pares);
●
Se testar é bom, testes serão escritos antes de programar e todos vão testar o tempo inteiro (teste de unidade), até mesmo os clientes (testes funcionais);
●
Se o proj projet etoo é bo bom, m, ele ele fa fará rá pa part rtee da dass funç funçõe õess diár diária iass de todo todoss (refatoração);
●
Se simplicidade é bom, sempre deixaremos o sistema com o projeto mais simples que suporte a funcionalidade atual (a coisa mais simples que possa funcionar), evoluindo constantemente a fim de adicionar a flexibilidade necessária e eliminar a complexidade desnecessária;
●
Se arquitetura é importante, todos trabalharão para definir e redefinir a arquitetura o tempo inteiro;
●
Se testes de integração são importantes, então vamos integrar e testar várias vezes ao dia;
●
Se iterações curtas são boas, faremos iterações muito, muito pequenas – segundos, minutos e horas, não semanas, meses e anos;
●
Colocar um sistema mínimo em produção rapidamente e desenvolvê-lo na direção que se mostra mais favorável;
●
40 horas semanais de trabalho. Na XP, horas extras não são bemvindas, na sexta feira os integrantes devem terminar o seu turno e terem 2 dias para não pensarem em trabalho, para chegarem na segunda-feira cheio de energias e idéias
●
O client clientee dev devee est estar ar sem sempre pre dis dispon poníve ívell para para respon responder der que questõ stões es e redefinir prioridades de menor escala;
●
Distinguir entre decisões que devem ser tomadas por interesses dos negócios e aquelas que devem ser tomadas pelos envolvidos no projeto;
●
Padrões de codificação. Por vezes as duplas serão trocadas e talvez partes do sistema serão feitos por outras duplas, portanto é necessário a adoção de padrões de codificação com uma restrição, o mais simples possível e que seja aprovada por todo o grupo.
5 Aplicação da XP A XP foi desenvolvida para ser aplicada em projetos em que: ●
Os requisitos mudem com freqüência;
●
Utilizem desenvolvimento orientado a objetos;
●
Trabalhem com times de dois a 10 programadores;
●
Não sejam severamente restringidos pelo ambiente computacional;
●
Boa parte da execução de testes possa ser feita em pouco tempo no dia;
●
E possua desenvolvimento incremental.
A XP assusta ou irrita algumas pessoas que tem o primeiro contato. Mas nenhumas das idéias defendidas pela XP são novas. A maioria delas é tão velha quanto à própria programação, todas as técnicas da XP foram testadas há décadas. As grandes mudanças que a XP traz são: ●
Colocar todas as práticas juntas;
●
Garantir que elas sejam praticadas a fundo;
●
Garantir que as práticas apóiem umas às outras em Extremo.
6 Valores do XP Para guiar o desenvolvimento, o XP baseia-se em cinco valores:
6.1 Comunicação:Tem como objetivo criar e manter o melhor relacionamento possível entre a equipe desenvolvedora e o cliente, recomendando o contato direto (face-a-face) , para evitar qualquer tipo de ou mal entendido entre os desenvolvedores e para que possíveis dúvidas possam ser resolvidas de imediato.
Além de sanar as dúvidas no desenvolvimento, desenvolvimento, o cliente deverá esta disponível para a equipe, ou mesmo presente no ambiente de trabalho da empresa. Isto fará com que o cliente entenda o sistema e enriquecerá os relacionamentos pessoais, criando um elo de parceria e confiança mútua. Algumas equipes não se adaptam bem com isso. Enquanto estiverem com esse problema a metodologia estará comprometida, portanto, a equipe deve entrar em um acordo. É encorajada também a comunicação entre desenvolvedores e gerente do projeto. Este se caracteriza como um dos fatores principais no XP: conversar ao máximo pessoalmente, evitando o uso do telefone e mensagens de e-mail.
6.2 Simplicidade: Visa minimizar o código, descartando as funções consideradas desnecessárias desnecessárias ou não essenciais. Ou seja, deve ser implementado o menor número de classes e métodos. Deve-se também estar sempre procurando atender os requisitos emergenciais, evitando adicionar funcionalidades ligadas à evolução do produto. O importante é ter em mente que os requisitos são passíveis de mudanças. Sendo assim, o inte intere ress ssan ante te na prát prátic icaa do XP é im impl plem emen enta tarr ap apen enas as o qu quee é real realme ment ntee necessário para que o cliente tenha seu pedido atendido. Evit Evita-s a-see su supo posi siçõ ções es,, o fu futu turo ro é ince incert rtoo e po porr ca caus usaa diss dissoo nã nãoo ne nece cess ssititaa atenção. Os requisitos evoluem gradativamente em conjunto com o sistema e a
arquitetura do projeto. Algumas vezes, o que é necessário hoje será
descartado amanhã, e outras vezes o que seria necessário num futuro próximo nunca será utilizado.
6.3 Feedback: Chamamos de feedback constante o contato incessante com o cliente a respeito do projeto. Informações sobre o código são dadas por testes tes tes periód periódico icos, s, os qua quais is ind indica icam m erros erros um tan tanto to ind indivi ividua duais is qu quant antoo do software integrado. Além disso, o cliente terá sempre uma parte do software funcional para avaliar. Com isso, novas características e informações são repassadas aos desenvolvedores, que por sua vez devem implementá-las nas próximas versões. Desta maneira, o que se pretende é entregar o software de acordo com as expectativas do cliente.
6.4 Coragem: Se encaixa na implantação dos três valores anteriores. É importante que os profissionais sejam comunicativos e com facilidade de se relaci relaciona onar. r. A corage coragem m aux auxilia ilia a sim simpli plicid cidade ade,, qua quand ndoo a pos possib sibilid ilidade ade de simplificar o software é detectada. Por fim, a coragem é necessária para garantir que o feedback do cliente ocorra com freqüência, pois esta abordagem implicará na possibilidade de mudanças constantes do produto.
6.5 Respeito: É um valor que dá sustentação a todos os demais. É preciso que os membros de uma equipe se importem uns com os outros. Só assim, irão se preocupar em comunicar-se melhor. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.
7 Equipe XP 7.1 Gerente de projeto Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento. desenvolvimento.
Os Maiores atributos do do gerente são: coragem, confiança confiança e insistência ocasional para que façam o que dizem fazer. Isto significa comunicação franca. O time quer colocar esta habilidade em prática quando precisarem dela. E querem mantê-la distante quando não precisarem.
7.2 Coach Pessoa Pessoa respon responsáv sável el pel pelas as que questõ stões es téc técnic nicas as do projet projeto, o, é ne neces cessár sário io um grande grande con conhec hecim iment entoo nos proces processos sos de des desenv envolv olvime imento nto,, nos val valore oress e práticas do XP. Sua responsabilidade é verificar o comportamento da equipe, sinalizando os eventuais erros.
7.3 Analista de teste Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes. Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.
7.4 Redator técnico Pessoa responsável em documentar o sistema, permitindo uma maior dedica ded icação ção ao trabal trabalho ho de cod codific ificaçã ação. o. Esta Esta pes pessoa soa dev devee est estar ar em ple plena na sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.
7.5 Desenvolvedor Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários
momentos do do projeto o desenvolvedor estará estará exercendo exercendo alguma destas destas atividades. É o principal membro da XP, dentre suas habilidades devem ser destacadas a programação em pares e a simplicidade, e acima de tudo coragem. Existem níveis distintos de desenvolvedores dentro de uma equipe, mas com a prática de programar em par, a tendência da equipe é se tornar uniforme em suas habilidades.
7.6 Rastreador O rastreador faz estimativas de tempo e checa se se ajustou à realidade, isto é uma questão de prática e feedback. Ele é responsável pela visão global do
andamento também, se durante uma iteração o que foi previsto será exec ex ecut utad ado, o, ou se é prec precis isoo mo modif dific icar ar algo algo.. A ma maio iorr ha habil bilida idade de aq aqui ui é a capacidade de coletar informações de que precisa sem perturbar o processo.
7.7 Treinador É o responsável por chamar a atenção das pessoas quando estas estão se desviando do processo do time. Todos no Time XP devem compreender a aplicação, mas o treinador muito mais e profundamente. A necessidade deste papel diminui proporcionalmente com o amadurecimento amadurecimento do time.
8 Princípios ou Práticas do XP Para entender as formas que movem o projeto XP, é importante entender seus princípios e suas práticas. Alguns desses princípios são apenas bom senso, outros se tornam a base da maioria dos processos futuros de desenvolvimento de software conforme apresentado a seguir:
8.1 Cliente em conjunto com os desenvolvedores O XP trabalha tem uma visão diferente em relação ao cliente. Este permanece o tempo todo presente, a par do desenvolvimento do software, indicando
modificações e esclarecendo duvidas da equipe, onde a sua ausência representa sérios riscos ao projeto. Ao terminar uma estória, com a presença do cliente, a mesma poderá ser valida val idada da rapida rapidame mente nte e a equ equipe ipe recebe receberr o feedback nec necess essári árioo so sobre bre a funcionalidade, criando ciclos rápidos e precisos.
8.2 Planejamento A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o máximo de valor para o cliente sempre determinando o escopo da próxima versão, combinando prioridades de negócio e estimativas técnicas. O consultor se reúne com as equipes duas vezes por semana. Nestas reuniões há uma permanente negociação de requisitos e prazos. Este planejamento é feito várias vezes durante o projeto. É o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja as releases e as iterações.
8.3 Uso de Metáforas Todo o desenvolvimento é guiado por uma simples estória compartilhada de como o sistema funciona e todas as funcionalidades do sistema são descritas. A metáfora ajuda a equipe a entender sobre o vocabulário utilizado pelo
domínio do projeto e assim ajuda-o a nomear funções e variávei apropriadamente. São relatadas através de pequenos cartões em que o cliente deve descrever o que deseja com suas palavras e da forma mais simples possível. Lembrando que a simplicidade também deve ser respeitada pelo cliente. Após a definição das estórias é necessário estimar o tempo das mesmas para que o cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto, que refere-se a um dia de trabalho ideal do desenvolvedor, onde o mesmo não precisaria atender telefonemas, participar de reuniões, ou seja, estaria preocupado apenas com a estória em questão. Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo uma certa dificuldade de serem estimadas. A XP recomenda que estas estórias
sejam quebradas em tarefas menores e que as mesmas não utilizem mais que alguns pontos de um desenvolvedor, recomenda-se 4 pontos ao máximo. pontos de Em cada estória é escrita a quantidade estimadas pelo
desenv des envolv olved edor, or, o XP recome recomenda nda que as est estima imativ tivas as sej sejam am efe efetua tuadas das em equipe e se possível com a presença do cliente para que durante a estimativa eventuais dúvidas sejam sanadas. O XP tem por objetivo gerar valor para o cliente ao longo do projeto, para isto o software é desenvolvido de forma incremental, onde a cada entrega o cliente possa utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como sendo releases , pequenos intervalos de tempo, máximo 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues. A divi divisã sãoo do doss releases é ef efet etua uada da no iníc início io do proj projet eto, o, ge gera ralm lmen ente te co com m tamanhos fixos e pequenos. Após esta divisão o cliente define as estórias que farão parte dos realises . Mesmo os releases sendo efetuados em curto espaço de tempo, continua representando um tempo muito longo para o feedback do cliente. Por esta razão os releases são divididos em espaços menores, chamados de iterações . Uma iteração contêm um conjunto de estórias a serem implementadas, com duração entre uma a três semanas, onde ao final da mesma o cliente possa valida val idarr as im imple pleme menta ntaçõe çõess efe efetua tuadas das e fornec fornecer er o feedback necessário necessário à equipe
8.4 Teste Primeiro Os programadores escrevem unidades de teste continuamente e os executam para que o processo de desenvolvimento continue. Esta atividade é considerada extremamente chata e dispensada por muitos desenvolvedores na modelagem conceitual por exemplo, porém para os desenvolvedores de uma equipe XP esta atividade deve ser encarada. Todo código implementando implementando deve
coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade. Em cada ciclo eles apresentam uma versão de teste do software ao cliente. Os clientes escrevem os testes para validar o sistema. É com base nestes testes automatizados que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele. Com a implementação de testes o desenvolvedor poderá amadurecer o ente en tend ndim imen ento to so sobr bree o prob proble lema ma qu quee irá so solu luci cion onar ar,, já qu quee os test testes es sã sãoo codificados antes da nova implementação. No XP existem dois tipos de testes, os testes de unidade e de aceitação. O teste de unidade verifica se os resultados gerados por cada classe estão corretos, já o teste de aceitação verifica se a interação entre as classes que implementam uma funcionalidade funcionalidade atendem a necessidade de forma correta. Os testes de aceitação são descritos pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interação entre as partes.
8.5 Simplicidade O sistema deve ser projetado da forma mais simples possível. A complexidade extra é remo removida vida assim assim que detec detectada. tada. Deve-se Deve-se imple implemen mentar tar apena apenass a funcionalidade que foi solicitada. Mas deve-se ter atenção para não confundir simplicidade com facilidade. Umas das premissas do desenvolvimento conceitual é que o custo de uma alteração no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções genéricas preparando o sistema para futuras alterações. No XP o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do projeto, esta premissa é dita em função dos avanços nas linguagens e práticas de programação, novos ambientes e ferramentas de desenvolvimento, utilização de orientação a objetos no desenvolvimento e em conjunto com estes novo no voss av avan anço çoss ex exis iste te o frut frutoo da dass ou outr tras as prát prátic icas as XP, XP, de deix ixan ando do o có códi digo go simples, legível e passível de alteração a qualquer momento.
8.6 Programação Pareada O XP exige que todo e qualquer código implementado no projeto seja efetuado em du dupl pla, a, ch cham amad adaa de prog progra rama maçã çãoo em pa par. r. É um umaa técn técnic icaa on onde de do dois is
desenvolvedores trabalham no mesmo problema. Um deles é responsável pela digitação (condutor - menos experiente) e outro acompanhando o trabalho do parceiro (navegador - mais experiente). Esta prática agrega diversas técnicas de programação, enquanto o condutor codifica o problema o navegador permanentemente revisa o código digitado, onde pequenos erros de programação que demoraria algumas horas para serem depurados, facilmente são percebidos pelo navegador da dupla. Um dos grandes benefícios da programação em par é a troca de experiências e idéias entre os desenvolvedores. A solução para um problema geralmente é a soma das idéias da dupla, tornando uma solução e codificação muito mais rápida e fácil. É com esta prática que o XP uniformiza o nível desenvolvedores da equipe, através da troca de experiências. Após alguns meses trabalhando em duplas todos os desenvolvedores conhecerão todas rotinas do sistema, prontos para qualquer modificação ou para auxiliar algum iniciante.
8.7 Padronização do Código Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se comunicar. Uma forma clara de se comunicar através do código, é mant ma nter er um pa padr drão ão no proj projet etoo pa para ra qu quee qu qual alqu quer er um po poss ssaa rapi rapida dame ment ntee entender o código lido. O XP recomen recomenda da a adoç adoção ão de de um padrão padrão desde desde o início do do projeto projeto preferencialmente padrões utilizados pela comunidade da linguagem de desenv des envolv olvime imento nto.. Haven Havendo do a nec necess essida idade de de mo modifi dificaç cações ões e ada adapta ptaçõe çõess durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas. A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. O código fonte final deve parecer ter sido feito por apenas um programador.
8.8 Propriedade Coletiva
O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações, mas que esteja funcionando, tem por obrigação alterar este código deixando-o mais legível e simples, porém esta alteração não pode mudar o comportamento do código em questão. Ou seja, o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.
8.9 Integração Contínua Visa integrar e construir o sistema muitas vezes ao dia, todas as vezes que uma tarefa tiver sido finalizada.
8.10 Refactoring
É um processo que permite a melhoria contínua da programação. Os programadores reestruturam o sistema sem mudar seu comportamento, para remover duplicação, melhorar a comunicação, simplificar ou adicionar flexibilidade.
8.11 Fases Pequenas Visa produzir um sistema simples rapidamente, planejando novas versões em um ciclo ciclo mu muito ito peq pequen ueno. o. A libera liberação ção de peq pequen uenas as versõ versões es fun funcio cionai naiss do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando.
8.12 Semanas Curtas (Semana de 40 horas) Impõe que a equipe não trabalhe mais que 40 horas por semana / 8 horas por dia. Mas se necessário que não faça hora-extra duas semanas seguidas. Trabalhar com qualidade, buscando ter ritmo de trabalho saudável.
8.13 Stand up meeting O stand up meeting é uma reunião rápida (em torno de 15 minutos) realizada no início de cada dia, onde os participantes normalmente ficam em pé (daí a origem do nome), cujo objetivo é atualizar todos os membros da equipe a
respeito do que ocorreu no dia anterior e priorizar as atividades do dia que se inicia. Ela é uma forma simples de assegurar que as pessoas obtenham feedback rápido sobre qualquer aspecto do projeto, bem como um mecanismo para pa ra plan planej ejar ar o qu quee prec precis isaa se serr fe feito ito prim primei eiro ro,, faze fazend ndoo co com m qu quee todo todoss relembrem e reavaliem frequentemente o que é mais importante de se fazer a cada dia.
9 Vantagens e Desvantagens 9.1 Vantagens As práticas do XP são usadas pelos integrantes da equipe, para facilitar no desenv des envolv olvime imento nto e agrega agregarr qua qualida lidade de no projet projeto, o, com isso isso tod todos os do tim timee devem estar cientes de cada fase do sistema. Um dos benefícios que a mesma oferece é tornar o processo mais ágil e flexível. Conforme Astels, as práticas do XP são criadas para funcionarem juntas e fornecer mais valor do que cada uma poderia fornecer individualmente. i ndividualmente. ●
Análise prévia de tudo que pode acontecer durante o desenvolvimento do projeto, oferecendo qualidade, confiança, data de entregas e custos promissores.
●
O XP é ideal para ser usada em projetos em que o cliente não sabe exatamente o que deseja e pode mudar muito de opinião durante o feedback constante, é possível desenvolvimento do projeto. Com
adaptar rapidamente eventuais mudanças nos requisitos. ●
Estas alterações nos requisitos são muitas vezes críticas nas metodologias tradicionais, que não apresentam meios de se adaptar rapidamente às mudanças.
●
Outro ponto positivo das metodologias ágeis são as entregas constantes de partes operacionais do software. Desta forma, o cliente não precisa esperar muito para ver o software funcionando, como nas metodologias tradicionais.
9.2 Desvantagens
É freqüente acontecer bugs em todos os projetos de desenvolvimento de software, e no XP não é diferente. Existem pontos fracos no uso dessa metodologia, como: ●
Não existe uma avaliação de riscos, devendo, portanto implementar uma análise e estratégias que buscam diminuir os erros.
●
A análise de requisitos é informal e com isso pode não ser bem vista pelos clientes, que poderão se sentir inseguros quanto ao bom funcionamento do sistema.
●
Refatoração do código pode ser vista como irresponsabilidade e incompetência, pois, não existe uma preocupação formal na utilização do código.
●
A fa faltltaa de do docu cume ment ntaç ação ão é ca cara ract cter erís ístic ticaa do proc proces esso so XP, XP, po pois is,, o mesmo não dá muita ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.).
●
Sendo, portanto, importante a elaboração de documentos e diagramas que facilitem no entendimento e identificação do problema.
●
Além dessas desvantagens, existem algumas situações em que não é indicado o uso do XP conforme apresentado a seguir:
●
A maior aior ba barr rrei eira ra para ara o suc uceesso sso de um proj projeeto XP é a cultur lturaa empresarial. Qualquer negócio que gerencie projetos tentando apontar o carro para a direção certa logo de cara terá conflitos com o time que insiste em ir acertando a direção continuamente.
●
Outra cultura que não contribui para o XP é aquela na qual você é
requisitado a trabalhar horas e mais horas para provar o seu “comprometimento com a empresa”. Você não consegue executar o XP se estiver cansado. Se aquilo que o seu time produz trabalhando em velocidade máxima não é suficiente para a sua empresa então o XP não é a solução. ●
E existe também uma barreira tecnológica para o XP é um ambiente no qual é necessário um longo tempo para se obter feedback . Por exemplo, se o seu sistema leva 24 horas para compilar e linkar, será difícil integrar, compilar e testar várias vezes ao dia.
10 Conclusão O XP é uma metodologia que estimula a interação contínua entre cliente e desenvolvedor para que as necessidades do cliente sejam visualizadas e compreendidas, obtendo assim, o sucesso do projeto. Ela é baseada em valores e princípios exclusivos que devem ser cultivados para que o projeto obtenha o sucesso desejado. As des desvan vantag tagens ens exi existe stem, m, porém porém,, é atravé atravéss del delas as que se dev devem em bus buscar car melhorias. É necessário satisfazer os pontos fortes dessa metodologia e buscar o aprimoramento dos pontos fracos, para que ela evolua e consiga espaço no mercado tecnológico de software cada vez mais competitivo.
Podemos, assim, concluir que a inclusão do XP, bem como outra metodologias ágeis, é fundamental para profissionais que buscam melhorias contínuas e sofisticação do software evitando redundâncias r edundâncias e erros incontroláveis no seu desenvolvimento, estando lado a lado com o cliente buscando parceria.
11 Referências ●
Extreme Programming, XP: Metodologia Desenvolvimento . Ágil [S.1], [S.1], 2008 2008.. Disponível Disponível em: . r/xp>. Acesso Acesso em: 06/03/2009.
●
GOLDMAN, Alfredo; KON, Fabio. Programação Extrema – Ime. [S.1], 2002. Disponível em:. Acesso em: 06/03/2009.
●
JEFFREIS ,Ron. What is Extreme Programming . [S.1], 2008. Disponível em: . Acesso em: 07/03/2009.
●
SANTOS, Dayse Islany Farias; CARVALHO, Emerson Silva de; MACÊDO, Juliana Kataline Lopes. Vantagens e desvantagens do XP
Extreme Extreme Programm Programming ing . [S.1 [S.1], ], 200 007. 7. Dis Dispo ponníve ível em em:: . Acesso em: 16/02/2009.
