CONCEITOS BÁSICOS
DEFINIÇÃO E SURGIMENTO
Extreme Programming (XP) é uma metodologia de desenvolvimento de software, criada nos Estados Unidos por Kent Beck em 1997 em um projeto para a Chrysler (fabricante de veículos norte-americana). Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem-se substancialmente da forma tradicional de se desenvolver software.
“XP é o mais importante movimento de nosso campo hoje. Eu vejo que ele será tão essencial para a geração presente quanto o SEI e o CMM foram para a anterior.” - Tom DeMarco.
Existe uma categoria de processos de desenvolvimento conhecida como Processos Ágeis de Desenvolvimento, dentro da qual o XP e outros processos se encaixam. Eles compartilham a premissa de que o cliente aprende sobre suas necessidades, na medida em que é capaz de manipular o sistema que está sendo produzido. Com base no feedback do sistema ele re-avalia as suas necessidades e prioridades, gerando mudanças que devem ser incorporadas ao software. O aprendizado é importante, porque permite que o cliente direcione o desenvolvimento de modo que a equipe produza sempre aquilo que tem o maior valor para o seu negócio.
XP descreve uma maneira de desenvolver software que combina melhores práticas existentes na área há muito tempo. Essas práticas se complementam e controlam uma à outra. O XP “pega” essas práticas do senso comum e as utiliza a níveis extremos.
Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para:
· Projetos cujos requisitos são vagos e mudam com freqüência;
· Desenvolvimento de sistemas orientados a objeto;
· Equipes pequenas, preferencialmente até 12 desenvolvedores;
· Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo.
O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software.
VALORES
O Extreme Programming se baseia em cinco valores fundamentais para guiar o desenvolvimento de software, ou seja, toda a equipe de desenvolvimento de software deve se concentrar nesses cinco conceitos básicos:
· Comunicação
· Feedback
· Simplicidade
· Coragem
· Respeito
Comunicação
O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em desenvolvimento e possui algumas idéias sobre que funcionalidades podem resolvê-los. Por sua vez, desenvolvedores possuem conhecimento sobre aspectos técnicos que influenciam a forma de solucionar o problema do cliente. Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes, isto é, para que o cliente possa compartilhar o seu aprendizado com a equipe, é necessário que ele utilize permanentemente o valor da comunicação.
A comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem. O XP procura assegurar que a comunicação ocorra da forma mais direta e eficaz possível. Sendo assim, ele busca aproximar todos os envolvidos do projeto de modo que todos possam se comunicar face-a-face ou da forma mais rica que for viável.
Existem diversas formas de comunicação, mas é importante que se dê preferência sempre àquela que for mais expressiva e que tenha mais elementos que ajudem na compreensão do que quer ser dito, pois quanto maior a capacidade de compreensão, maiores as chances de evitar problemas como ambigüidades, entendimentos equivocados. Dessa forma, a comunicação presencial é sempre mais valorizada pelo XP, porque apresenta características como gestos, expressões faciais, tom de voz, postura, entre outros, que colaboram para que as idéias trocadas sejam bem entendidas por todos os envolvidos no projeto. É interessante observar que diálogos são mais eficazes que videoconferências, que são melhores que telefonemas, que são mais expressivos que emails e assim sucessivamente.
Feedback
O projeto de software provavelmente enfrentará falhas e problemas. Isso pode ser tratado de forma mais econômica e eficaz se as falhas forem detectadas rapidamente. Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as conseqüências daquilo que pediu. Os clientes, por sua vez, procuram se manter próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que eles tenham ao longo do desenvolvimento.
Quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, ele gera feedback para a equipe de desenvolvimento. Isto é, ele realimenta a equipe com alterações nas necessidades que ainda serão implementadas e, eventualmente, naquelas que já fazem parte do software.
O feedback é o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente e garanta que a equipe direcione as suas atenções para aquilo que irá gerar mais valor.
Simplicidade
Estudos mostram que, em muitos softwares, diversas funcionalidades não são utilizadas. Isso configura não só uma inutilidade dessas funcionalidades, mas principalmente um desperdício de tempo e recursos.
A comunicação, embora seja essencial, não é suficiente para garantir que o cliente possa aprender durante o projeto e gerar feedback rapidamente. Também é necessário que a equipe compreenda e utilize o valor da simplicidade, que nos ensina a implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente. Ou seja, ao codificar uma funcionalidade devemos nos preocupar apenas com os problemas de hoje e deixar os problemas do futuro para o futuro. Não devemos tentar prever o futuro, pois raramente acertamos nas previsões. Ao evitar especular sobre o que acontecerá amanhã, ganhamos tempo e permitimos que o cliente tenha acesso à funcionalidade mais rapidamente. Isso permite que ele a utilize no seu negócio, gerando valor para ele e tornando viável que ele dê feedback para a equipe o quanto antes.
Eventualmente, com base no feedback, a equipe poderá fazer generalizações quando elas se fizerem necessárias. Neste caso, entretanto, elas virão na forma de uma necessidade explícita e não como a especulação de algo que poderia vir a ser necessário no futuro.
Sucintamente, o XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.
Coragem
Dado que o sistema é desenvolvido de forma incremental, a equipe está continuamente fazendo a manutenção do software e criando novas funcionalidades. Em muitos casos, ela irá alterar algo que vinha funcionando corretamente, o que leva ao risco de gerar falhas no sistema. Por esta razão, a equipe precisa ser corajosa e acreditar que, utilizando as práticas e valores do XP, será capaz de fazer o software evoluir com segurança e agilidade.
Certamente um projeto de software passará por diversas mudanças. Isso acontece porque clientes mudam de idéia com freqüências, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriadas de resolvê-los. Embora isso seja natural, gera uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de gerar erros no sistema. Esse risco existe em um projeto XP, como existe em qualquer outro. O que muda é a forma de lidar com ele. Equipes XP acreditam que errar é natural e “quebrar” o que vinha funcionando pode acontecer eventualmente. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em confiança nos seus mecanismos de proteção. As práticas são voltadas, entre outras coisas, para proteger o software de inúmeras formas. As equipes confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças.
Assim, ao invés de frear a criatividade do cliente e evitar mudanças, equipes consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção, tais como desenvolvimento orientado a testes, programação em par e integração contínua.
Respeito
Respeito é um valor que dá sustentação a todos os demais. Num projeto XP, como em qualquer outra situação da vida, o respeito é peça fundamental para o prosseguimento do mesmo. Se em determinado momento o respeito vir a faltar ele comprometerá todo o projeto. A equipe deve respeitar as opiniões do cliente e vice-versa. Um membro de uma equipe deve analisar o ponto de vista do outro e, se acreditar que o seu é melhor que o do colega, saber argumentar e mostrar ao outro, da forma mais respeitosa possível, o porquê da sua idéia ser a melhor. E assim por diante. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, caso se importem uns com os outros.
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.
CARACTERÍSTICAS
Essa metodologia ágil apresenta as seguintes características, também chamadas de práticas em que o XP se baseia, já que durante a realização de um projeto todas essas características são percebidas constantemente, se comportando como práticas, atividades que realizamos freqüentemente.
· Cliente Presente
· Processo de Planejamento (Planning Game)
· Stand Up Meeting
· Programação em Par
· Desenvolvimento Guiado pelos Testes
· Refactoring
· Código Coletivo
· Código Padronizado
· Design Simples
· Metáfora
· Ritmo Sustentável
· Integração Contínua
· Releases Curtos
Práticas dependem da situação, do contexto. Se a situação muda, você seleciona práticas diferentes para abordar estas condições. Seus valores, por sua vez, não têm que mudar para se adaptar a uma nova situação. Alguns novos princípios podem vir a ser necessários quando se muda de domínio.
As práticas são descritas como coisas absolutas. São vetores de onde você está para onde você pode chegar com XP. Em XP, você progride em direção ao estado ideal de desenvolvimento eficaz. Por exemplo, implantação diária talvez não faça sentido se você só colocar o sistema no ar uma vez ao ano. Implantar o sistema de forma bem sucedida com maior freqüência é uma melhoria, que ajuda a criar confiança para o próximo passo. As práticas do XP tendem a funcionar bem em conjunto. A interação entre as práticas amplifica o efeito das mesmas.
Cliente Presente
Cliente acompanhando e conduzindo o desenvolvimento do projeto.
O XP trabalha com a premissa de que o cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema. Para que a troca de feedback possa ocorrer e o cliente possa obter o máximo de valor do projeto, é essencial que ele participe ativamente do processo de desenvolvimento. Além disso, a sua presença viabiliza a simplicidade do processo em diversos aspectos, especialmente na comunicação.
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.
Processo de Planejamento (Planning Game)
Equipe trabalhando no que é mais importante para o cliente. Reuniões no início de cada etapa (release ou iteração) para revisar o planejamento e avaliar as funcionalidades que devem ser implementadas e aquelas que farão parte da nova etapa.
O XP utiliza diversas formas de planejamento para assegurar que a equipe esteja sempre trabalhando naquilo que é o mais importante para o cliente. Por esta razão, todo projeto em XP é dividido em releases e iterações, de modo que cliente e equipe tenham diversas oportunidades de se reunir para revisar o planejamento. Releases são módulos do sistema que geram um valor bem definido para o cliente. Iterações, por sua vez, são períodos de tempo de poucas semanas (em torno de duas, em média) no qual a equipe implementa um conjunto de funcionalidades acordado com o cliente. No início de cada release e de cada iteração ocorre o jogo do planejamento. Trata-se de uma reunião onde o cliente avalia as funcionalidades que devem ser implementadas e prioriza aquelas que farão parte do próximo release ou da próxima iteração. O cliente pode mudar suas prioridades de requisitos a cada iteração que passa. Como elas são curtas, isso garante que mudanças sejam incorporadas tranqüilamente.
No XP, as funcionalidades são descritas em pequenos cartões e são chamadas de estórias. Durante o jogo do planejamento as estórias são estimadas, para que o cliente possa conhecer o custo da implementação de cada uma delas. A estimativa é feita utilizando-se uma unidade especial que recebe o nome de ponto.
O ponto representa uma unidade de tempo que varia ao longo do desenvolvimento de acordo com a velocidade da equipe, onde a velocidade indica o quanto a equipe foi capaz de implementar na iteração anterior.
Stand Up Meeting
Encontro rápido e em pé onde se analisa o que deve ser feito durante o dia e o que foi feito no dia anterior. Pode ser só entre membros da equipe ou também entre equipe e cliente.
O dia de trabalho de uma equipe XP sempre começa com um stand up meeting (que em inglês significa reunião em pé), que é uma reunião rápida pela manhã, com aproximadamente 20 minutos de duração e onde seus integrantes permanecem 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
Implementação de funcionalidades por pares de desenvolvedores. Em cada computador dois membros da equipe trabalham juntos para produzir o mesmo código.
O XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla, prática essa 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. A programação em par permite que o código seja revisado permanentemente, enquanto é construído. Também contribui para que a implementação seja mais simples e eficaz, já que os desenvolvedores se complementam e têm mais oportunidades de gerar soluções inovadoras.
Desenvolvimento Guiado pelos Testes
Testes codificados antes de cada nova implementação.
O XP é destinado à construção de sistemas com alta qualidade, o que leva à necessidade de diversos mecanismos de validação para assegurar que o software está correto.
Um destes mecanismos é a programação em par, tal como foi citado anteriormente. Além dela, o XP também utiliza a técnica de desenvolvimento guiado pelos testes.
Os desenvolvedores escrevem testes para cada funcionalidade antes de codificá-las. Fazendo isso, eles aprofundam o entendimento das necessidades do cliente (o que aprimora a análise), se preocupam com as interfaces externas dos métodos e classes antes de codificá-los (o que melhora o design), sabem até onde codificar cada funcionalidade (o que ajuda a manter o sistema simples) e passam a contar com uma massa de testes que pode ser usada a qualquer momento para validar todo o sistema.
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.
Refactoring
Alterações de códigos pouco legíveis, mal codificados ou sem padronização sem alterar suas funcionalidades com o objetivo de facilitar as manutenções dos mesmos.
Para que o sistema possa evoluir de forma incremental, a equipe deve fazer com que ele expresse os seus objetivos facilmente e esteja sempre claro e fácil de compreender. 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.
O refactoring é o ato de alterar um código sem afetar a funcionalidade que ele implementa. É utilizado para tornar o software mais simples de ser manipulado e se utiliza fortemente dos testes descritos anteriormente para garantir que as modificações não interrompam o seu funcionamento.
Código Coletivo
Todos os desenvolvedores têm acesso e podem alterar qualquer parte do código.
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 de inúmeras alterações, apenas uma pessoa estará capacitada para alterá-la. No XP o sistema não é segmentado em partes, de modo que cada desenvolvedor fique responsável por uma delas. Os desenvolvedores têm acesso a todas as partes do código e podem alterar aquilo que julgarem importante sem a necessidade de pedir autorização de outra pessoa, pois o código é coletivo.
Isso fornece maior agilidade ao processo e cria mais um mecanismo de revisão e verificação do código, já que aquilo que é escrito por um par hoje, acaba sendo manipulado por outro amanhã. Se alguma coisa estiver confusa no código, o par deverá fazer refactoring para torná-lo mais legível.
Código Padronizado
Padrões de codificação são mantidos para que toda a equipe possa entender e manipular os códigos de maneira mais célere e eficiente.
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. Esses padrões deverão ser decididos por consenso e todos devem concordar em utilizá-lo.
Os padrões de codificação que a equipe estabelece também servem para que todos os desenvolvedores possam manipular qualquer parte do software de forma mais rápida, tornar o sistema mais homogêneo e permitir que qualquer manutenção futura seja efetuada mais rapidamente.
Design Simples
Códigos simples que atendam apenas as necessidades da funcionalidade em questão ao invés de se criar soluções para problemas futuros que, além de ficarem ociosas, atrasarão o desenvolvimento do projeto.
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.
Para que o cliente possa obter feedback logo, a equipe precisa ser ágil no desenvolvimento, o que a leva a optar pela simplicidade do design. Ao invés de criar generalizações dentro do código, de modo a prepará-lo para possíveis necessidades futuras, a equipe deve sempre optar por um código que seja suficiente para atender às necessidades da funcionalidade que está implementando. Os desenvolvedores se baseiam na premissa de que serão capazes de incorporar qualquer necessidade futura quando e se ela surgir. Para isso, eles contam com o refactoring, os testes e as demais práticas do XP para apoiá-los.
Metáfora
Uso de comparações para facilitar o entendimento e a memorização de idéias por parte dos membros da equipe e do cliente.
Para facilitar a criação de um design simples, a equipe de desenvolvimento utiliza metáforas (comparações), já que elas têm o poder de transmitir idéias complexas de forma simples, através de uma linguagem comum que é estabelecida entre a equipe de desenvolvimento e o cliente. Ao criar comparações e analogias com o assunto em questão, torna-se mais fácil a compreensão de um assunto. Este tipo de artifício 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
Desenvolvedores trabalham apenas 40 horas por semana se tornando mais produtivos e menos propensos a falhas.
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 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 qualidade do design, do código, das metáforas e do sistema é determinada diretamente pela qualidade dos desenvolvedores e a capacidade que eles têm de se manter atentos, criativos e dispostos a solucionar problemas. Para garantir que a equipe tenha sempre o máximo de rendimento e produza software com melhor qualidade possível, o XP recomenda que os desenvolvedores trabalhem apenas oito horas por dia e evitem fazer horas-extras, visto que é essencial estar descansado a cada manhã, de modo a utilizar a mente na sua plenitude ao longo do dia, respeitando-se assim, a saúde e os limites de cada desenvolvedor.
Integração Contínua
Os códigos são, por várias vezes no dia, integrados ao resto do sistema.
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.
Quando uma nova funcionalidade é incorporada ao sistema, ela pode afetar outras que já estavam implementadas. Para assegurar que todo o sistema esteja sempre funcionando de forma harmoniosa, a equipe pratica a integração contínua que leva os pares a integrarem seus códigos com o restante do sistema diversas vezes ao dia. Cada vez que um par faz isso, ele executa todos os testes para assegurar que a integração tenha ocorrido de forma satisfatória.
Uma integração sempre pode produzir erros no sistema. Sendo assim, a equipe utiliza os testes para descobrir eventuais defeitos o mais rapidamente possível já que descobri-los logo facilita e acelera a correção e diminui a probabilidade de pequenos problemas tomarem maiores proporções no futuro.
Em resumo, 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
Conjuntos de atividades bem definidas e que representam algum valor para o cliente são produzidos ligeiramente durante todo o projeto.
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.
O XP tem como objetivo gerar um fluxo contínuo de valor para o cliente e o máximo de valor econômico em curto espaço de tempo. Sendo assim, ele trabalha com releases curtos, ou seja, a equipe produz um conjunto reduzido de funcionalidades e coloca em produção rapidamente de modo que o cliente já possa utilizar o software no dia-a-dia e se beneficiar dele. Durante todo o projeto, a equipe colocará o sistema em produção diversas vezes, cada vez incorporando mais funcionalidades e gerando mais valor. O release deve fazer sentido como um todo. Não deve existir um release com metade de um requisito (o que não faz sentido).
Características da equipe
Uma equipe que utilize o XP normalmente é composta por pessoas que representam os seguintes papéis:
· Gerente de Projeto
· Coach
· Analista de Teste
· Redator Técnico
· Desenvolvedor
Gerente de Projeto
O gerente de projeto é responsável pelos assuntos administrativos do projeto. Ele procura filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras liberando, dessa forma, a equipe de questões que não estejam diretamente ligadas à atividade diária de desenvolvimento. Além disso, administra o relacionamento com o cliente assegurando que o mesmo participe ativamente do desenvolvimento e forneça as informações essenciais para que a equipe possa implementar o sistema desejado.
Coach (Técnico)
O coach é o responsável técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas práticas recomendadas pelo XP. É interessante que o coach seja a pessoa que possua maior conhecimento do processo de desenvolvimento, dos valores e práticas da XP, já que ele verificará o comportamento da equipe frente ao processo XP e sinalizará os eventuais erros cometidos.
Embora também possa atuar na implementação do sistema, sua tarefa principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.
Analista de Teste
O analista de teste é responsável por ajudar o cliente a escrever os testes de aceitação. Quando estes testes não são automatizados, o analista de teste deve fazer com que eles sejam executados diversas vezes ao longo das iterações do projeto e verifica se o software atende todos os casos de testes. Ele procura fazer com que os eventuais defeitos do sistema sejam identificados tão logo apareçam. Desta forma, fornece feedback para a equipe rapidamente, de modo que ela possa fazer as correções com rapidez e evitar que os problemas se propaguem.
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.
Redator Técnico
O redator técnico ajuda a equipe de desenvolvimento a documentar o sistema. A sua presença evita um forte trabalho dos desenvolvedores neste tipo de atividade e permite que os desenvolvedores se concentrem prioritariamente na implementação do software. Embora eles possam continuar fazendo algumas documentações, o redator técnico é quem faz a maior parte do trabalho de documentaçã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.
Desenvolvedor
O desenvolvedor é a pessoa que analisa, projeta e codifica o sistema. Em suma, é a pessoa que efetivamente constrói o software. Dentro do XP, não existem divisões entre analista, projetista, programador etc. Cada desenvolvedor exerce estes diferentes papéis em diversos momentos do projeto.
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.
REFERÊNCIAS BIBLIOGRÁFICAS
http://improveit.com.br/xp
http://onnclick.net/blog/?p=534
http://www.novateceditora.com.br/livros/extreme/capitulo8575220470.pdf
http://www.spinsp.org.br/apresentacao/SpinXP.pdf
http://www.improveit.com.br/xp/dissertacaoXP.pdf
http://www.artigocientifico.com.br/uploads/artc_1196095637_11.pdf
