Apresentando XP Encante seus clientes com Extreme Programming

Apresentando XP - Extreme Programming

Resumo: Este artigo tem por objetivo apresentar a metodologia de desenvolvimento gil de software denominada Extreme Programming. Sero abordadas, de forma resumida, as prticas, valores, e os papis disponveis a cada integrante de uma equipe de XP. Alguns comparativos com outras metodologias so feitas ao decorrer do trabalho enaltecendo as propriedades que definem a Extreme Programming.

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

ndice

1. Introduo 2. Extreme Programming (XP) o 2.1. Valores da XP 2.1.1 Feedback 2.1.2 Comunicao 2.1.3. Simplicidade 2.1.4. Coragem o 2.2. Prticas 2.2.1. Cliente Disponvel ou Presente 2.2.2. Jogo do Planejamento 2.2.3. Stand up meeting 2.2.4. Programao em par 2.2.5. Refactoring 2.2.6. Desenvolvimento guiado por testes 2.2.7. Cdigo coletivo 2.2.8. Padres de desenvolvimento 2.2.9. Design Simples 2.2.10. Metfora 2.2.11. Ritmo Sustentvel 2.2.12. Integrao contnua 2.2.13. Releases curtos o 2.3. Equipe XP 2.3.1. Gerente de projeto 2.3.2. Coach 2.3.3. Analista de teste 2.3.4. Redator tcnico 2.3.5. Desenvolvedor 3. Concluses 4. Referncias 5. Autores

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

1. Introduo
A muito tempo a indstria de software vem passando por grandes transformaes e novos desafios, entre eles desenvolver softwares com qualidade, no menor tempo possvel e que atendam as necessidades dos clientes. Com estes novos desafios a indstria de software passou a dar valor a algumas reas da informtica, como a engenharia de software e qualidade de software, com intuito de atender as exigncias do mercado. A indstria comeou a utilizar metodologias de desenvolvimento de software, adotou mtricas e padres para alcanar nveis aceitveis de qualidade, prever custos e prazos em seus projetos. Porm ainda so poucos os projetos que conseguem obter pleno sucesso em seu desenvolvimento, onde prazo e oramento estabelecidos e as necessidades do cliente sejam realmente atendidas. Pesquisa feitas pelo Standish Group International em 1994, um pouco antes da adoo de metodologia de desenvolvimento pelas indstrias, apontam que apenas 16, 2 % dos projetos de software atingiam sucesso (prazo, oramento e funcionalidades atendidas). Em 2002 esta taxa havia subido para 34 %, ou seja, um aumento de 100 % em 8 anos. Mas estas taxas ainda se encontram muito aqum do esperado pelo mercado. As metodologias utilizadas nos projetos pesquisados eram as mais variadas, podemos citar modelo em cascata, modelo iterativo e alguns com modelo em prototipao. Neste trabalho ser utilizado o termo desenvolvimento tradicional para os projetos que se utilizem do modelo em cascata e todos os outros que se baseiam nele. Analisando os motivos para a baixa taxa de sucesso dos projetos desenvolvidos com modelos tradicionais, cita-se os principais motivos e bastante comuns entre eles:

Tempo elevado entre cada fase do projeto, no acompanhando as mudanas de requisitos do projeto; Falta de conhecimento por parte do cliente da sua real necessidade, dando margem s especulaes dos desenvolvedores; Forte linearidade no desenvolvimento do projeto;

Focando nas fragilidades do modelo tradicional, surgiram metodologias para desenvolvimento gil de software. Cita-se algumas caractersticas destas metodologias:

Foco nas pessoas, no no processo, evitando especulaes dos desenvolvedores; Atender as reais necessidades do cliente, na velocidade e praticidade por ele desejada; Ausncia de linearidade no desenvolvimento do projeto; O cliente aprender a suas reais necessidades durante o projeto e repassar esta novas necessidades a equipe de desenvolvimento;

Uma destas metodologias de desenvolvimento gil o Extreme Programming , metodologia que prima a qualidade do software desenvolvido, que atenda as reais necessidades do cliente e seja entregue dentro do prazo definido. Esta metodologia ser detalhada a seguir.

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

2. Extreme Programming (XP)
XP uma metodologia para desenvolvimento de software gil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prtica e a perseguio da mais clara simplicidade, aplicado ao desenvolvimento de software. Uma metodologia voltada para projetos cujos requisitos mudem com freqncia, utilizem desenvolvimento orientado a objetos, equipes de at 12 desenvolvedores e desenvolvimento incremental. A XP Busca o mximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espao de tempo o cliente ter um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido realmente o desejado. Por ser uma metodologia recente, a XP sofre mudanas em suas concepes e, portanto, comum encontrar variaes. A adaptao ao ambiente de desenvolvimento deve ser levada em conta, se um valor trouxer mais prejuzos do que benefcios necessrio relavaliar a utilizao desta metodologia. A XP organizada em torno de um conjunto de prticas e valores que atuam perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente. A seguir sero apresentados os valores e em seguida as prticas.

2.1 Valores da XP
Os valores so as diretrizes da XP. Eles definiro as atitudes das equipes e as principais prioridades da metodologia. Para uma empresa estar realmente utilizando o XP, ela deve respeitar e utilizar todos os valores e prticas listadas nos prximos captulos e caso um destes valores ou prticas no seja utilizado pela empresa, esta empresa no est trabalhando com a metodologia XP.

2.1.1 Feedback
O cliente aprende com o sistema que utiliza e com este aprendizado consegue reavaliar o produto recebido, com isso pode realimentar a equipe de desenvolvimento com as suas reais necessidades. Com o feedback , o cliente conduz o desenvolvimento do seu produto, estabelece prioridades e informa aquilo que realmente importante. Analogamente, h o feedback dado pelo desenvolvedor ao cliente, onde o mesmo aponta riscos, estimativas e alternativas de design . Este retorno o aprendizado do desenvolvedor sobre o que o cliente deseja. Com este valor, o tempo de defasagem entre as fases do projeto so extremamente pequenos, o cliente est o tempo todo em contato com a equipe de desenvolvimento, muito diferente dos modelos tradicionais, onde o cliente entrava em contato com a equipe um bom tempo depois do ltimo feedback dado. Um ponto que muitas empresas de software falham no dar valor ao que o cliente realmente deseja, utilizam cegamente metodologias e acabam esquecendo o real propsito de um software: facilitar o trabalho de pessoas. Com isto muitos sistemas acabam dificultando e burocratizando as tarefas das pessoas e como defesa as empresas alegam ter um produto genrico e que atenda as normais legais.

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

2.1.2 Comunicao
Para que o feedback entre cliente e desenvolvedor possa ser efetuado com sucesso necessrio ter uma boa comunicao entre eles. A XP prega que esta comunicao ocorra da forma mais direta e eficaz possvel, oferecendo agilidade aos assuntos tratados. Recomenda-se o contato direto (face-a-face) entre cliente e desenvolvedor, para evitar qualquer tipo de especulao ou mal entendido entre as partes e para que possveis dvidas possam ser resolvidas de imediato. Alm de sanar as dvidas no desenvolvimento, o cliente dever estar disponvel 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 confiana mtua. Algumas equipes no se adaptam bem a este valor. Este problema deve ser trabalhado em conjunto com a equipe. Enquanto no se acostumarem a falar e a trocar idias com seus companheiros o sucesso da metodologia estar comprometido. Membros introvertidos so deseconselhveis para equipes de XP.

2.1.3 Simplicidade
Para que o cliente possa aprender durante o projeto e consiga dar o feedback necessrio equipe, no basta apenas uma boa comunicao, necessrio que os desenvolvedores implementem da forma mais simples possvel o que o cliente deseja. A lei : faa a coisa mais simples que pode funcionar. Com esta filosofia, o cliente ter a funcionalidade rapidamente e da forma desejada, dando um feedback instantaneamente evitando especulaes. O desenvolvedor deve implementar apenas o necessrio para que o cliente tenha seu pedido atendido. Ser simples no um ato de desespero, um ato de conscincia e absoluta preciso. Muitas pessoas confundem simplicidade e facilidade. O mais simples nem sempre o mais fcil e tambm no escrever menos cdigo. Simplicidade significa codificar o necessrio para que um requisito seja atendido e entregue ao cliente. Evita-se suposies, o futuro incerto e por causa disso no necessita ateno. Os requisitos evoluem gradativamente em conjunto com o sistema e a arquitetura do projeto. Algumas vezes, o que necessrio hoje ser descartado amanh, e outras vezes o que seria necessrio num futuro prximo nunca ser utilizado.

2.1.4 Coragem
Por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, o XP exige que os desenvolvedores tenham coragem para:

Desenvolver software de forma incremental; Manter o sistema simples; Permitir que o cliente defina prioridades; Fazer desenvolvedores trabalharem em pares: Investir tempo em refactoring ; Investir tempo em testes automatizados; Estimar estrias na presena do cliente;

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

Expor cdigo a todos os membros da equipe; Integrar o sistema diversas vezes ao dia; Adotar ritmo sustentvel de desenvolvimento; Abrir mo de documentos que servem como defesa; Propor contratos de escopo varivel; Propor a adoo de um processo novo. Assumir em relao ao cliente possveis atrasos e problemas de implementao; Colocar desenvolvedores e clientes frente a frente; Implantar uma nova verso do sistema no cliente semanalmente; Apostar em seus colaboradores aumentando suas responsabilidades; Modelar e documentar apenas quando for de extrema necessidade.

2.2 Praticas da XP
Como o nome j diz, as prticas so um conjunto de atividades que devero ser seguidas pelas equipes que desejam utilizar a XP. Os valores j apresentados somados a estas prticas so um conjunto ? entrelaado ? de boas atitudes. A fraquesa de umas compensado por outra e assim fecha-se um ciclo fortemente dependente.

2.2.1 Cliente disponvel ou presente

O XP trabalha com uma viso diferente do modelo tradicional em relao ao cliente. O XP sugere que o cliente esteja no dia-a-dia do projeto, acompanhando os passos dos desenvolvedores, onde a sua ausncia representa srios riscos ao projeto. As funcionalidades do sistema so descritas brevemente em estrias em conjunto com os testes conceituais e sero estes os indicadores para uma boa implementao. No momento que os desenvolvedores iro implementar as estrias nada mais eficaz do que dialogar com o cliente para entender a estria, fazendo-se necessria a presena do cliente no ambiente de desenvolvimento. Ao terminar uma estria, com a presena do cliente, a mesma poder ser validada rapidamente e a equipe receber o feedback necessrio sobre a funcionalidade, criando ciclos rpidos e precisos.

2.2.2 Jogo de planejamento

A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o mximo de valor para o cliente. Este planejamento feito vrias vezes durante o projeto. o momento onde o cliente solicita as funcionalidades desejadas atravs de estrias, onde a equipe estima o custo de cada estria e planeja as releases e as iteraes. Todas as funcionalidades do sistema so descritas em estrias, pequenos cartes em que o cliente deve descrever o que deseja com suas palavras e da forma mais simples possvel. Lembrando que a simplicidade tambm deve ser respeitada pelo cliente. Aps a definio das estrias necessrio estimar o tempo das mesmas para que o cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto , que referese a um dia de trabalho ideal do desenvolvedor, onde o mesmo no precisaria atender telefonemas, participar de reunies, ou seja, estaria preocupado apenas com a estria em

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

questo. Muitas vezes algumas estrias consomem semanas de trabalho, oferecendo uma certa dificuldade de serem estimadas. A XP recomenda que estas estrias sejam quebradas em tarefas menores e que as mesmas no utilizem mais que alguns pontos de um desenvolvedor, recomenda-se 4 pontos ao mximo. Em cada estria escrita a quantidade de pontos estimadas pelo desenvolvedor, o XP recomenda que as estimativas sejam efetuadas em equipe e se possvel com a presena do cliente para que durante a estimativa eventuais dvidas 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 benefcios do mesmo. Estas entregas o XP denomina como sendo releases , pequenos intervalos de tempo, mximo 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues. A diviso dos releases efetuada no incio do projeto, geralmente com tamanhos fixos e pequenos. Aps esta diviso o cliente define as estrias que faro parte dos releases e tenta-se evitar um planejamento muito longo, pois na entrega de cada release o cliente aprender com o sistema e possivelmente ir alterar as estrias para o prximo release . Mesmo os releases sendo efetuados em curto espao de tempo, continua representando um tempo muito longo para o feedback do cliente. Por esta razo os releases so divididos em espaos menores, chamados de iteraes . Uma iterao contm um conjunto de estrias a serem implementadas, com durao entre uma a trs semanas, onde ao final da mesma o cliente possa validar as implementaes efetuadas e fornecer o feedback necessrio equipe.

2.2.3 Stand up meeting

O dia de trabalho de uma equipe XP sempre comea com um stand up meeting . uma reunio rpida pela manh, com aproximadamente 20 minutos de durao e onde seus integrantes permaneam preferencialmente em p. Segundo estudos uma reunio em p mais rpida, evita bate-papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, gil e simples. A reunio tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experincias das dificuldades enfrentadas. Neste momento tambm so decididas as estrias que sero implementadas no dia e em conjunto definir os responsveis por cada uma delas.

2.2.4 Programao em par

O XP exige que todo e qualquer cdigo implementado no projeto seja efetuado em dupla, chamada de programao em par. uma tcnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles responsvel pela digitao (condutor) e outro acompanhando o trabalho do parceiro (navegador). Esta prtica agrega diversas tcnicas de programao, enquanto o condutor codifica o problema o navegador permanentemente revisa o cdigo digitado, onde pequenos erros de programao que demoraria algumas horas para serem depurados, facilmente so percebidos pelo navegador da dupla.

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

Um dos grandes benefcios da programao em par a troca de experincias e idias entre os desenvolvedores. A soluo para um problema geralmente a soma das idias da dupla, tornando uma soluo e codificao muito mais simples e eficaz. com esta prtica que o XP uniformiza o nvel dos desenvolvedores da equipe, atravs da troca de experincias. Aps alguns meses trabalhando em duplas todos os desenvolvedores conhecero todas rotinas do sistema, prontos para qualquer modificao ou para auxiliar algum iniciante. Um grande questionamento sobre esta prtica com questo a produtividade dos desenvolvedores. Porm, um erro pensar que somente uma pessoa estar codificando enquanto o outro apenas observa. O membro que no est codificando no apenas observa, mas tambm troca idias, gera solues e evita praticamente todos erros de codificao alm de cobrar padres de desenvolvimento da equipe. Estudos indicam que a produtividade de uma equipe que utiliza pair programming e de equipes que tenham desenvolvedores sozinhos praticamente a mesma, porm a qualidade do cdigo gera facilidade de manuteno e outros ganhos a mdio e longo prazo.

2.2.5 Refactoring
Um desenvolvedor ao deparar com um cdigo mal escrito ou pouco legvel mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alteraes neste cdigo, mesmo que tivesse que implementar novas funcionalidades. O XP prega que todo desenvolvedor ao encontrar um cdigo duplicado, pouco legvel, mal codificado, sem padronizao, lento, com cdigo legado ou uso incorreto de outras implementaes, tem por obrigao alterar este cdigo deixando-o mais legvel e simples, porm esta alterao no pode mudar o comportamento do cdigo em questo. Esta prtica anda de mos dadas com o cdigo coletivo, j que todo desenvolvedor tem a possibilidade de melhorar qualquer cdigo do sistema. A padronizao oferece facilidades aos desenvolvedores no momento de implementar novas funcionalidades ou efetuar qualquer tipo de manuteno, uma vez que o cdigo se encontra simples e claro. Uma questo importante que a prtica de refactoring esta apoiada pelos testes automatizados, pois facilmente o desenvolvedor ter um feedback se a alterao por ele efetuada ir gerar qualquer tipo de comportamento anormal no sistema, sofrendo o aprendizado sobre a alterao por ele efetuada.

2.2.6 Desenvolvimento guiado por testes

Esta atividade considerada extremamente chata e dispendiosa por muitos desenvolvedores na modelagem tradicional, porm para os desenvolvedores de uma equipe XP esta atividade deve ser encarada com extrema naturalidade. Todo cdigo implementando deve coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade. com base nestes testes automatizados que qualquer desenvolvedor ter coragem para alterar uma parte do cdigo que no tenha sido implementada por ele, j que executando os testes automatizados poder verificar instantaneamente se a modificao efetuada alterou o comportamento do sistema. Com a implementao de testes o desenvolvedor poder amadurecer o entendimento sobre o

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

problema que ir solucionar, j que os testes so codificados antes da nova implementao. No XP existem dois tipos de testes, os testes de unidade e de aceitao. O teste de unidade tem por objetivo verificar se os resultados gerados por cada classe esto corretos, j o teste de aceitao tem por objetivo verificar se a interao entre as classes que implementam uma funcionalidade (estria) atendem a necessidade de forma correta. Os testes de aceitao so descritos pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interao entre as partes.

2.2.7 Cdigo coletivo

No modelo tradicional de desenvolvimento, comum dividir o projeto em partes e colocar responsveis por cada uma destas partes. Porm apenas uma pessoa torna-se conhecedora daquela parte. Este tipo de diviso traz srios problemas ao projeto, uma vez que se aquela parte necessitar inmeras alteraes, apenas uma pessoa estar capacitada para alter-la. Com estas inmeras alteraes, esta pessoa pode se tornar um gargalo no projeto. O XP trava uma batalha contra este tipo de diviso, j que no existe uma pessoa responsvel por uma parte do cdigo. Cada desenvolvedor tem acesso a qualquer parte do sistema e tem liberdade para alter-la a qualquer momento e sem qualquer tipo de aviso. Esta prtica tem como conseqncia um cdigo revisado por diversas pessoas e caso algo no esteja claro, com certeza ser alterado por alguma pessoa ( refactoring ) para que o mesmo torne-se legvel.

2.2.8 Padres de desenvolvimento

Um dos valores do XP a comunicao, e o cdigo tambm uma forma da equipe se comunicar. Uma forma clara de se comunicar atravs do cdigo, manter um padro no projeto para que qualquer um possa rapidamente entender o cdigo lido. O XP recomenda a adoo de um padro desde o incio do projeto, preferencialmente padres utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificaes e adaptaes durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas.

2.2.9 Design simples

Nota-se que todas as prticas do XP focam que o maior valor possvel seja gerado para o cliente, para tal premissa ser verdadeira o XP prega um design do sistema da forma mais simples possvel para que atenda a necessidade do cliente. Umas das premissas do desenvolvimento tradicional que o custo de uma alterao no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar solues genricas preparando o sistema para futuras alteraes. Este tipo de pensamento d margens para especulaes e implementaes que na maioria dos casos no ter utilidade para o cliente. O XP parte do princpio que o custo de uma alterao tende a crescer lentamente e se estabilizar ao longo do projeto, esta premissa dita em funo dos avanos nas linguagens e prticas de programao, novos ambientes e ferramentas de desenvolvimento, utilizao de orientao a objetos no desenvolvimento e em conjunto

http://qualidade-de-software.blogspot.com

Apresentando XP Encante seus clientes com Extreme Programming

com estes novos avanos existe o fruto das outras prticas XP, deixando o cdigo simples, legvel e passvel de alterao a qualquer momento.

2.2.10 Metfora
Muitas vezes pessoas tentam explicar um assunto ou problema a outras pessoas por um perodo sem obter o xito necessrio na explicao dada, simplesmente as outras pessoas no conseguem entender a mensagem que est se tentando repassar. Ao criar comparaes e analogias com o assunto que est em questo as pessoas passaro a entender deste assunto de uma forma muito mais rpida e possivelmente no a esquecero mais. Este tipo de artifcio chamado de metfora no XP, e deve ser utilizado com intensidade durante o projeto, uma vez que facilita a comunicao e fixao dos assuntos entre as partes. Esta prtica anda em conjunto com o ritmo sustentvel, j que para o desenvolvedor criar boas metforas exige criatividade e desenvolvimento de idias, o que torna necessrio uma boa condio fsica e bem estar por parte do desenvolvedor.

2.2.11 Ritmo sustentvel

Uma grande problema nos projetos de software a falta de tempo para encerrar o mesmo, e uma das tcnicas mais adotadas para compensar a falta de tempo submeter os desenvolvedores (humanos) a trabalharem at mais tarde e muitas vezes sacrificarem seus finais de semana. Nos primeiros momentos este tipo de atitude tem efeitos positivos, porm passado alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentrao no desenvolvimento, justamente pelo cansao fsico do desenvolvedor. O XP probe que os desenvolvedores trabalhem at mais tarde. O XP sugere um ritmo sustentvel de 40 horas semanais, respeitando assim a individualidade e o fsico de cada desenvolvedor. Desta forma a equipe estar sempre concentrada e muito menos propensa a pequenas falhas na implementao.

2.2.12 Integrao contnua

No desenvolvimento tradicional geralmente as equipes so organizadas de modo que uma parte (mdulo) fiquei sob responsabilidade de um desenvolvedor, cabe a esta pessoa efetuar testes e codificao que dizem respeito a sua parte. Esta estratgia reduz a complexidade e as preocupaes de um desenvolvedor. Interfaces de integrao so convencionadas para que futuramente estas partes possam se comunicar, este tipo de desenvolvimento esta propenso a srios erros de integrao, uma vez que os perodos em que as partes so integradas e testadas so extremamente longos. O XP prope uma integrao contnua, se possvel deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do cdigo recm desenvolvido. Com esta prtica o feedback sobre a alterao efetuada ser retornado em um menor espao de tempo.

2.2.13 Releases curtos

No modelo tradicional o projeto dividido em fases, de um modo que o cliente comear a ter benefcio com o sistema muito prximo de o mesmo estar finalizado. A maior parte do

http://qualidade-de-software.blogspot.com

10

Apresentando XP Encante seus clientes com Extreme Programming

investimento do projeto feita antes mesmo de estar concludo, sem ter gerado qualquer tipo de valor econmico ao cliente. O XP recomenda que pequenos investimento sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possvel. Com a prtica de releases curtos, o XP pretende dar o mximo de valor econmico ao cliente em um curto espao de tempo. Release um conjunto de funcionalidade bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento.

2.3 Equipe XP
Em uma equipe de XP existem papis a serem desempenhados por um ou mais desenvolvedores. Estes papis sero listados a seguir.

2.3.1 Gerente de projeto

Pessoa responsvel pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento. O gerente de projeto responsvel por filtrar assuntos no relevantes aos desenvolvedores e aspectos que s devam ser implementados em iteraes futuras. Para um bom exerccio de gerente de projeto necessrio que a pessoa conhea e acredite nos valores e prticas do XP para que possa cobrar isto da sua equipe.

2.3.2 Coach
Pessoa responsvel pelas questes tcnicas do projeto, recomenda-se que esta pessoa seja a com maior conhecimento do processo de desenvolvimento, dos valores e prticas do XP. de responsabilidade do coach verificar o comportamento da equipe frente o processo XP, sinalizando os eventuais erros cometidos pela equipe.

2.3.3 Analista de teste

Pessoa responsvel em garantir a qualidade do sistema atravs dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iterao verificar se o software atende todos os casos de testes. Recomenda-se que esta pessoa no seja um desenvolvedor, para evitar uma viso tendenciosa j que no conhece o cdigo desenvolvido. O analista de teste deve ter uma viso muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator tcnico.

2.3.4 Redator tcnico

Pessoa responsvel em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicao ao trabalho de codificao. Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentao reflita o cdigo escrito e as regras de negcio atendidas pelo sistema.

http://qualidade-de-software.blogspot.com

11

Apresentando XP Encante seus clientes com Extreme Programming

2.3.5 Desenvolvedor
Pessoa responsvel em analisar, projetar e codificar o sistema. No XP no existe diferena entre analista, projetista e programador uma vez que em vrios momentos do projeto o desenvolvedor estar exercendo alguma destas atividades. Naturalmente existe nveis distintos de desenvolvedores dentro de uma equipe, mas com as prticas do XP, como pair programming , a tendncia a equipe se tornar uniforme em suas habilidades.

3 Concluses
A metodologia de desenvolvimento Extreme Programming pode ser considerada extremamente nova, porm vem acompanhando as necessidades humanas dos desenvolvedores pelo mundo. Gurus da tecnologia da informao vem aprimorando as concepes desta metodologia para atender as necessidades do mercado e principalmente das pessoas. Um empresa ao utilizar este processo por completo, s estar agregando valor aos seus negcios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Est chave no mundo dos negcios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um lao de confiana ou at mesmo um sentimento de amizade. Entender as necessidades do cliente no cincia, arte. Dar incentivo a ela o mnimo que podemos fazer.

4 Referncias
AMBROSI, Cleison Vander; GRAHL, Everaldo Artur. Extreme Programming: Um modelo de processo para o desenvolvimento de software. Blumenau ? SC: Instituto Catarinense de PsGraduao. ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming: Guia prtico. Rio de Janeiro ? RJ: Campus, 2002. BECK, Kent. Programao extrema (XP) explicada: acolha as mudanas. Porto Alegre ? RS: Bookman, 2004. POHREN, Daniel. XP Manager: Uma Ferramenta de Gerncia de Projetos Baseados em Extreme Programming. Novo Hamburgo ? RS: Centro Universitrio Feevale, 2004. TELES, Vincius Manhes. Extreme Programming: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. So Paulo - SP: Novatec Editora Ltda, 2004. WUESTEFELD, Klaus. Xisp: Extreme Programming. Disponvel em http://www.xispe.com.br/index.html . Acesso em: 23 / 07 / 2004. Palavras-chave: Extreme Programming , Engenharia de Software, Qualidade de Software, Metodologia de Desenvolvimento, Processos geis de Desenvolvimento, XP. Por: Giovane Roslindo Kuhn e Vitor Fernando Pamplona

http://qualidade-de-software.blogspot.com

12