EXTREME PROGRAMMING



INTRODUÇÃO

Entre os principais desafios das indústrias de software está o desenvolvimento de softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes. Para isso, a indústria começou a utilizar metodologias de desenvolvimento, adotando métricas e padrões para alcançar níveis aceitáveis de qualidade, prever custos e prazos em seus projetos. Considerando as fragilidades do modelo tradicional (em cascata, iterativo e prototipação), desenvolveram-se metodologias para desenvolvimento ágil de software, possuindo como características básicas:

* Foco nas pessoas, não no processo, evitando especulações dos desenvolvedores;

* Atendimento às reais necessidades do cliente, na velocidade e praticidade por ele desejada;

* Ausência de linearidade no desenvolvimento do projeto;

* Aprendizado do cliente quanto as suas reais necessidades durante o projeto, e oportunidade de repassá-las à equipe de desenvolvimento.

Neste artigo será apresentada a metodologia "Extreme Programming".

EXTREME PROGRAMMING

Uma das metodologias de desenvolvimento ágil é o Extreme Programming, que prima pela qualidade do software desenvolvido, atende às reais necessidades do cliente e é entregue dentro do prazo definido. É também conhecida por XP.

Esta metodologia está voltada para projetos cujos requisitos mudem com freqüência, utilizem desenvolvimento orientado a objetos, equipes de até 12 desenvolvedores e desenvolvimento incremental.

Teve seu início em 1996, quando Kent Beck, (que na década de 80 trabalhou na empresa Tektronixs, Inc, EUA, desenvolvendo na linguagem Smaltalk), conhecido como um dos criadores dos padrões do desenvolvimento ágil, colocou-os em prática no "Sistema de Compensação Abrangente da Chrysler" (Chrysler Comprehensive Compensation System), também conhecido como sistema C3.

A XP busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espaço 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.

Diretrizes e valores da Extreme Programming

As diretrizes da XP são seus valores e práticas, que definirão as atitudes das equipes e as principais prioridades da metodologia. Para uma empresa estar realmente utilizando a XP, ela deve respeitar e utilizar todos os valores e práticas relacionados a seguir:

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 desenvolvimento. Este retorno é o aprendizado do desenvolvedor sobre o que o cliente deseja.

2.Comunicação

Para que o feedback entre cliente e desenvolvedor possa ser efetuado com sucesso é necessário ter uma boa comunicação entre eles. A XP prega que esta comunicação ocorra da forma mais direta e eficaz possível, oferecendo agilidade aos assuntos tratados. Recomenda-se o contato direto (face a face) entre cliente e desenvolvedor, para evitar qualquer tipo de especulação ou mal entendido entre as partes e para que possíveis dúvidas possam ser resolvidas de imediato.

Além de sanar as dúvidas no desenvolvimento, o cliente deverá estar 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.

3.Simplicidade

Para que o cliente possa aprender durante o projeto e consiga dar o feedback necessário à equipe, não basta apenas uma boa comunicação; é necessário que os desenvolvedores implementem da forma mais simples possível o que o cliente deseja.

A lei é: faça a coisa mais simples que pode funcionar. Com esta filosofia, o cliente terá a funcionalidade rapidamente e da forma desejada, dando um feedback instantaneamente e evitando especulações. O desenvolvedor deve implementar apenas o necessário para que o cliente tenha seu pedido atendido.

O mais simples nem sempre é o mais fácil e também não significa escrever menos código. Simplicidade significa codificar o necessário para que um requisito seja atendido e entregue ao cliente.

4.Coragem

Por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, a 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 estórias na presença do cliente; expor código a todos os membros da equipe; integrar o sistema diversas vezes ao dia; adotar ritmo sustentável de desenvolvimento; abrir mão de documentos que servem como defesa; propor contratos de escopo variável; propor a adoção de um processo novo; assumir em relação ao cliente possíveis atrasos e problemas de implementação; colocar desenvolvedores e clientes frente a frente; implantar uma nova versão do sistema no cliente semanalmente; apostar em seus colaboradores, aumentando suas responsabilidades; modelar e documentar apenas quando for de extrema necessidade.

Praticas da XP

As práticas são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP. Os valores apresentados anteriormente somados a estas práticas formam um conjunto "entrelaçado" de boas atitudes. A fraqueza de uma é compensada por outra e assim fecha-se um ciclo fortemente dependente.

*Cliente disponível ou presente

A XP trabalha com uma visão diferente do modelo tradicional em relação ao cliente. Ele sugere que o cliente esteja no dia-a-dia do projeto, acompanhando os passos dos desenvolvedores, onde a sua ausência representa sérios riscos ao projeto. As funcionalidades do sistema são descritas brevemente em estórias em conjunto com os testes conceituais e serão estes os indicadores para uma boa implementação. No momento que os desenvolvedores irão implementar as estórias, nada mais eficaz do que dialogar com o cliente para entender a estória, fazendo-se necessária a presença do cliente no ambiente de desenvolvimento.

Ao terminar uma estória, com a presença do cliente, a mesma poderá ser validada rapidamente e a equipe receber o feedback necessário sobre a funcionalidade, criando ciclos rápidos e precisos.

* Jogo de 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. Este planejamento é feito várias vezes durante o projeto, sendo o momento onde o cliente solicita as funcionalidades desejadas através de estórias, e onde a equipe estima o custo de cada estória e planeja as releases e as iterações. Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo 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.

* Stand up meeting

O dia de trabalho de uma equipe XP sempre começa com um stand up meeting, queé uma reunião rápida pela manhã, com aproximadamente 20 minutos de duração e onde seus integrantes permaneçam preferencialmente em pé. Segundo estudos, uma reunião em pé é mais rápida, evita bate-papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, ágil e simples.

A reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiências das dificuldades enfrentadas. Neste momento também são decididas as estórias que serão implementadas no dia e em conjunto definir os responsáveis por cada uma delas.

* Programação em par

O XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla, chamada de programação em par. É uma técnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles é responsável pela digitação (condutor) e outro acompanhando o trabalho do parceiro (navegador).

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 simples e eficaz.

* Refactoring

Um desenvolvedor, ao deparar com um código mal escrito ou pouco legível, mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alterações neste código, mesmo que tivesse que implementar novas funcionalidades.

A 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, 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.

Esta prática anda de mãos dadas com o código coletivo, já que todo desenvolvedor tem a possibilidade de melhorar qualquer código do sistema.

* Desenvolvimento guiado por testes

Esta atividade é considerada chata e dispendiosa por muitos desenvolvedores na modelagem tradicional, porém para os desenvolvedores de uma equipe XP, esta atividade deve ser encarada com extrema naturalidade. Todo código implementado 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 código que não tenha sido implementada por ele, já que executando os testes automatizados poderá verificar instantaneamente se a modificação efetuada alterou o comportamento do sistema. Com a implementação de testes, o desenvolvedor poderá amadurecer o entendimento sobre o problema que irá solucionar, já que os testes são codificados antes da nova implementação.

* Código coletivo

No modelo tradicional de desenvolvimento, é comum dividir o projeto em partes e colocar responsáveis por cada uma destas partes. Porém apenas uma pessoa torna-se conhecedora daquela parte. Este tipo de divisão traz sérios problemas ao projeto, uma vez que se aquela parte necessitar inúmeras alterações, apenas uma pessoa estará capacitada para alterá-la. Com estas inúmeras alterações, esta pessoa pode se tornar um gargalo no projeto.

Em XP, não existe uma pessoa responsável por uma parte do código. 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 prática tem como conseqüência um código revisado por diversas pessoas e caso algo não esteja claro, com certeza será alterado por alguma pessoa (refactoring) para que o mesmo torne-se legível.

* Padrões de desenvolvimento

Um dos valores da 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, é manter um padrão no projeto para que qualquer um possa rapidamente entender o código lido. A XP recomenda a adoção de um padrão desde o início do projeto, preferencialmente padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificações e adaptações durante o projeto, que visem agilizar o desenvolvimento, as mesmas devem ser efetuadas.

* Design simples

Umas das premissas do desenvolvimento tradicional é 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.

Este tipo de pensamento dá margens para especulações e implementações que na maioria dos casos não terá utilidade para o cliente. XP parte do princípio que 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 novos avanços existe o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração a qualquer momento.

* Metáfora

Muitas vezes pessoas tentam explicar um assunto ou problema a outras pessoas por um período sem obter o êxito necessário na explicação dada, simplesmente as outras pessoas não conseguem entender a mensagem que está se tentando repassar.

Ao criar comparações e analogias com o assunto em questão, torna-se mais fácil a compreensão deste assunto. Este tipo de artifício é chamado de metáfora na XP, e deve ser utilizado com intensidade durante o projeto, uma vez que facilita a comunicação e fixação dos assuntos entre as partes. Esta prática anda em conjunto com o ritmo sustentável, já que para o desenvolvedor criar boas metáforas exige criatividade e desenvolvimento de idéias, o que torna necessária uma boa condição física e bem estar por parte do desenvolvedor.

* Ritmo sustentável

Um grande problema nos projetos de software é a falta de tempo para encerrar o mesmo, e uma das técnicas 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, porém passados alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentração no desenvolvimento, justamente pelo cansaço físico do desenvolvedor.

A XP proíbe que os desenvolvedores trabalhem até mais tarde, sugerindo um ritmo sustentável de 40 horas semanais, respeitando assim a individualidade e a saúde de cada desenvolvedor. Desta forma a equipe estará sempre concentrada e muito menos propensa a pequenas falhas na implementação.

* Integração contínua

No desenvolvimento tradicional, geralmente as equipes são organizadas de modo que uma parte (módulo) fique sob responsabilidade de um desenvolvedor, cabendo a esta pessoa efetuar testes e codificação que dizem respeito à sua parte. Esta estratégia reduz a complexidade e as preocupações de um desenvolvedor.

Interfaces de integração são convencionadas para que futuramente estas partes possam se comunicar; este tipo de desenvolvimento está propenso a sérios erros de integração, uma vez que os períodos em que as partes são integradas e testadas são extremamente longos.

A XP propõe uma integração contínua, se possível devendo ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém-desenvolvido. Com esta prática, o feedback sobre a alteração efetuada será dado em menor espaço de tempo.

* Releases curtos

Release é um conjunto de funcionalidades bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento.

No modelo tradicional o projeto é dividido em fases, de modo que o cliente começará a ter benefício com o sistema muito próximo de o mesmo estar finalizado. A maior parte do investimento do projeto é feita antes mesmo de estar concluído, sem ter gerado qualquer tipo de valor econômico ao cliente.

A XP recomenda que pequenos investimentos sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possível. Com a prática de releases curtos, a XP pretende dar o máximo de valor econômico ao cliente em curto espaço de tempo.

A Equipe XP

Em uma equipe de XP existem papéis a serem desempenhados por um ou mais desenvolvedores. São eles:

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. O gerente de projeto é responsável por filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras.

2. Coach (técnico): pessoa responsável pelas questões técnicas do projeto. Recomenda-se que esta pessoa seja a que possua maior conhecimento do processo de desenvolvimento, dos valores e práticas da XP. É de responsabilidade do coach verificar o comportamento da equipe frente ao processo XP, sinalizando os eventuais erros cometidos pela equipe.

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.

4. Redator técnico: pessoa responsável em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicação ao trabalho de codificação. Esta pessoa deve estar em plena sintonia com os desenvolvedores e clientes para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.

5. Desenvolvedor: pessoa responsável em analisar, projetar e codificar o sistema. Na XP não existe diferença entre analista, projetista e programador, uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades. Naturalmente existem níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas da XP, como a programação em par, a tendência é a equipe se tornar uniforme em suas habilidades.

CONCLUSÃO

Extreme Programming é um método de desenvolvimento que procura sanar problemas como atraso nas entregas de softwares, desperdício de tempo, dinheiro e pessoal nos processos de desenvolvimento, falta de organização e comunicação que atrapalham este processo numa empresa prestadora de serviços.

Ao adotar os valores e práticas da XP, as empresas só têm a ganhar. O desenvolvimento de softwares de forma simples, ágil e econômico, com certeza será um diferencial positivo para a empresa que presta este serviço a um cliente.

REFERÊNCIAS BIBLIOGRÁFICAS

KUHN, Giovane Roslindo. PAMPLONA, Vitor Fernando. Apresentando XP. Encante seus clientes com Extreme Programming. Disponível em: <http://www.javafree.org/content/view.jf?idContent=5> Acesso em 15 ago. 2007

TELES, Vinicius Manhães. UM ESTUDO DE CASO DA ADOÇÃO DAS PRÁTICAS E VALORES DO EXTREME PROGRAMMING. (Dissertação de Mestrado). Disponível em: <http://www.improveit.com.br/xp/dissertacaoXP.pdf> Acesso em 12 fev 2008.


Autor: Kátia Malzoni Silvério


Artigos Relacionados


O Líder Na Crise

A Morte Anunciada De Um Lóbulo

Estratégias Comerciais

Solução Qaweb Para Teste De Software

A Perspectiva Construtivista De Ensino

Como Fidelizar E Satisfazer Clientes

Raça Barbet