A XP – Extreme Programming (em português, programação extrema) é outra metodologia Agile bastante popular de desenvolvimento de software. Já provou ser bastante bem-sucedida noutras áreas e empresas com dimensões variadas. O artigo desta semana dá a conhecer as principais características desta metodologia Agile.

 XP - o que é?

A Extreme Programming, ou programação extrema, é uma estrutura agile de desenvolvimento de software que visa produzir software de alta qualidade e aumentar a qualidade de vida da equipa de desenvolvimento. A XP é a estrutura do Agile mais específica no que concerne as práticas de engenharia para o desenvolvimento de software. É uma metodologia de desenvolvimento de software desenhada para melhorar a qualidade do software e a sua habilidade de se adaptar, de forma correta, às necessidades sempre em mudança do cliente.

Os cinco valores da XP

São cinco os valores que servem de base ao paradigma da Extreme Programming, permitindo que as pessoas envolvidas no projeto se sintam confiantes na direção que o projeto está a levar, e a entender que tanto o seu feedback pessoal e visão é tao necessária quanto bem-vinda como outra qualquer.

1. Simplicidade – só é feito o que é necessário e pedido, e nada mais. Isto maximiza o valor gerado no investimento feito até ao momento. A equipa dá pequenos passos em direção ao seu objetivo e eliminaos erros à medida que aparecem.
2. Comunicação – todos os elementos fazem parte da equipa de igual modo e comunicam uns com os outros diariamente. Os membros da equipa trabalham juntos em tudo, desde os requisitos ao código. Juntos, criam a melhor solução que conseguem para o problema.
3. Feedback – a equipa leva a sério todos os compromissos de interação ao entregar o software. Entregam o software teste cedo e a miude, depois ouvem com atenção e fazem as alterações necessárias. Falam entre si sobre o projeto e adaptam todo o seu processo a ele, e não ao contrário.
4. Respeito – todos os elementos da equipa dão e sentem o real valor que têm por serem membros da equipa. Todos os elementos contribuem com valor, mesmo que seja apenas com entusiasmo. Os desenvolvedores respeitam as especialidades dos seus clientes e vice-versa.
5. Coragem – os elementos da equipa são corajosos e assumem a verdade sobre o progresso e as estimativas. Não usam desculpas para os erros porque planeiam para o sucesso. Adaptam-se às mudanças sempre que estas surgem.

As práticas da XP

As práticas de XP têm mudado ao longo dos anos, mas listamos as 12 originais, de seguida:

1. O jogo do planeamento: Este jogo é quase sempre feito através de reuniões frequentes a intervalos de tempo muito bem definidos (semanais ou de duas em duas semanas), altura onde é feita a maioria do planeamento do projeto.É aqui que se faz o planeamento de quando se vai lançar o software, onde são feitas as deliberações em relação ao que é necessário para futuros lançamentos. Isto inclui: a) fase exploratória, onde os cartões com as histórias são usados para detalhar os requisitos mais valiosos do cliente; b) a fase do compromisso, onde o planeamento e o compromisso da equipa são feitos por forma a cumprir com o próximo lançamento do calendário; e c) a fase de direção, que permite que os planos feitos previamente sejam ajustados, tendo em conta as necessidades do projeto.
2. Lançarmentos de software pequenos e regulares: O conceito de lançamentos pequenos e regulares permite que, tanto o cliente como os membros da equipa, terem uma perceção de como o projeto está a decorrer e proceder aos ajustes necessários, caso se verifique essa necessidade.
3. Metáfora do sistema: Utilizar um vocabulário que seja familiar, tanto ao cliente como a todos os membros da equipa, facilita a comunicação e diminui eventuais problemas de entendimento relativamente a um determinado requisito. Ao criar comparações e analogias com o assunto em questão, o cliente e os membors da equipa vão conseguir ter uma percepção mais clara e rápida de todo o projeto.
4. Design simples: Manter os componentes e o código o mais simples que for possível garante que toda a equipa consegue avaliar continuamente se as coisas podem ser feitas de uma forma mais fácil.
5. Teste: Este conceito significa que são gerados testes para cada requisito do projeto. Só depois de serem feitos estes testes é que é desenvolvido o código que irá passar nesses mesmos testes.
6. Refatoração do código: A ideia atrás da refatoração do código é melhorar e redesenhar a estrutura de um código já existente, mas sem alterar o seu comportamento principal. Dois exemplos de refatoração de código podem ser mudar os nomes incorretos de variáveis, ou reduzir código repetido a apenas um único método ou função.
7. Programação aos pares: Programação aos pares significa ter duas pessoas que trabalham juntas no desenvolvimento do código. Através da rotação frequente dos elementos do par, a XP promove uma melhor comunicação entre todos os elementos da equipa, bem como o team-building.
8. Propriedade coletiva: Esta prática permite a qualquer desenvolvedor que faz parte da equipa mudar uma secção do código, caso seja necessário. Enquanto que esta prática pode representar um perigo para alguns desenvolvedores, ela acaba por acelerar o tempo de desenvolvimento, e quaisquer potenciais problemas podem ser tratados através das unidades de teste.
9. Integração contínua: A ideia por detrás da integração contínua é a que o código desenvolvido por toda a equipa é colocado num local comum, várias vezes ao dia. Isto faz com que todos os problemas de integração com o projeto sejão identificados e resolvidos o mais rapidamente possível.
10. Semanas de 40 horas de trabalho: Um conceito-chave para um melhor equilíbrio entre a vida pessoal e a profissional é a noção de que ninguém deve ser obrigado a trabalhar mais do que as 40 horas de trabalho semanais.
11. Cliente no local: A XP promove a inclusão dos clientes no decorrer de todo o processo, tirando partido dos constantes feedbacks que estes vão dando e que ajuda a moldar o projeto a qualquer instante.
12. Padrão de codificação: O padrão de codificação é um conjunto de práticas dentro do próprio código, tais como a formatação e o estilo, que toda a equipa cumpre, dentro da duração de vida do projeto. Isto promove uma melhor compreensão do código, não apenas dos membros atuais, mas de futuros desenvolvedores.

Os papeis na XP

Embora a XP especifique práticas específicas para a equipa seguir, não estabelece funções específicas para os membros da sua equipa. No entanto, existem alguns papeis associados ao XP:

• O Cliente – é responsável por tomar todas as decisões relativas ao negócio, nomeadamente:
  
  • O que deve o sistema fazer?
  • Quando é que sabemos quando o sistema está completo?
  • Quando é que temos de gastar?
  • O que fazer de seguida?
• O desenvolvedor – uma vez que a XP não necessita de uma definição rígida de papeis, todos os elementos da equipa (à exceção do cliente) são rotulados de desenvolvedores. Estes são responsáveis por perceber as histórias identificadas pelo cliente. Uma vez que cada projeto necessita de um conjunto diferente e específico de habilidades, e porque o método XP assenta numa equipa multifuncional, os criadores da XP não sentiram necessidade de criar mais papeis.
• O Tracker – geralmente é um dos desenvolvedores que fazem parte da equipa. O seu propósito principal é acompanhar as métricas relevantes necessárias ao acompanhamento do progresso e identificar as áreas a melhorar. As métricas chave que podem ser descobertas incluem a velocidade, as razões da mudança de velocidade, a quantidade de tempo gasto no trabalho, e os testes (executá-los, passá-los e/ou falhá-los).
• O Coach – normalmente é um consultor externo ou de uma área da empresa que nada tenha a ver com a equipa de trabalho e que já tenha usado a XP anteriormente, e o seu propósito é o de ensinar as práticas XP ao resto da equipa, ajudando a equipa a manter a sua autodisciplina.

 O ciclo de vida da XP

O primeiro passo é descrever o resultado desejado pelo projeto, deixando os clientes definirem o conjunto das histórias. À medida que estas histórias são criadas, a equipa vai estimando o tempo de duração de cada história.

Se a equipa identificar algumas histórias para as quais não consegue estimar o tempo de cada uma por não entenderem todas as considerações técnicas envolvidas, eles podem introduzir um pico que faça alguma pesquisa focalizada naquela história particular ou um aspeto comum a múltiplas histórias. Os picos são curtos e cronometrados, reservados para efeitos de pesquisa sobre um aspeto específico do projeto.

De seguida, toda a equipa junta-se para criar um plano de lançamento que todos achem razoável. Este plano de lançamento é passo no qual as histórias serão entregues num trimestre particular. As histórias lançadas deverão ser baseadas no valor que dão e nas considerações de como variadas histórias se baseiam umas às outras.

Então, a equipa lança-se numa série de ciclos semanais. No início de cada ciclo semanal, a equipa (cliente incluído) reúne-se para decidir qual história será realizada no decorrer dessa semana. A equipa transforma as histórias em tarefas a serem concluídas durante essa semana. No final da semana, a equipa e o cliente reveem o progresso até ao momento e o cliente pode decidir se o projeto é para continuar ou se já foi entregue valor suficiente.

A eXTreme programming pode ser comparada a um puzzle. Há imensas pequenas peças. Sozinhas, as peças não fazem qualquer sentido, mas quando juntas, mostram a imagem geral. As regras até podem parecer estranhas, mesmo ingénuas, mas são baseadas em sólidos valores e princípios. Os clientes gostam de ser parceiros no projeto, os desenvolvedores contribuem ativamente, independentemente do nível de experiência e/ou conhecimento, e os gerentes concentram-se na comunicação e no relacionamento entre todos.

Até à próxma!