Extreme Programming

O XP adopta 12 práticas que estabelecem um conjunto de regras e métodos. Muitas equipas ágeis que adoptam outras frameworks, como o Scrum, usam práticas do XP. Isto porque, estas práticas mitigam os riscos de desenvolvimento de produtos, e provem melhores melhores resultados. Vejamos em maior detalhe as 12 práticas:

The Planning Game (O Jogo do Planeamento)

No início de cada ciclo, os developers e o cliente discutem mas também aprovam as funcionalidades do produto. Em seguida os developers planeiam o sprint, distribuindo tarefas a cada um deles.

Small Releases (Pequenas entregas)

O objetivo desta prática é disponibilizar o mínimo produto viável, ou minimum viable product (MVP) o mais cedo possível. Dessa forma, os utilizadores e clientes podem interagir com o produto  e perceber como funciona o produto em produção.  Além disso, podem também detectar necessidades de ajustamentos e correcções de defeitos. Em seguida, realizam-se pequenas melhorias incrementais com base no feedback obtido.  

System Metaphor (Metáfora do Sistema)

Esta prática procura que os produtos tenham um design simples e um conjunto de qualidades. Ou seja, o produto deve ser tão fácil e simples de compreender que qualquer pessoa que entre no projecto consiga contribuir. Além disso, deve-se usar uma linguagem simples e comum para facilitar a compreensão de todos.

Simple Design (Design Simples)

O design do produto deve ser o mais simples possível e deve-se remover qualquer complexidade. Ou seja, o produto deve ser claro para qualquer pessoa. Dessa forma é mais fácil desenvolver e manter o produto.

Test-Driven Development (Desenvolvimento Orientado a Testes)

As equipas XP usam a técnica de test-driven development, escrevendo primeiro os testes e depois desenvolvendo um produto para passar os testes. Dessa forma conseguem, obter feedback mais rapidamente e incorporar o feedback que deriva dos testes realizados. Além disso, a prática contribui para que o produto desenvolvido esteja em conformidade com os requisitos. Em seguida, consulte este artigo para saber mais sobre test-driven development. 

Code Refactoring (Refatoração de Código)

Na prática de refactoring as equipas melhoram o produto já desenvolvido sem adicionar mais funcionalidades. O objectivo desta prática, é desse modo, melhorar a estrutura do produto, removendo redundâncias, inconsistências e desperdícios para dar maior coerência ao produto. Dessa forma, será mais fácil melhorar e manter o produto.

Pair Programming (Programação em Par)

Na prática de pair programming, ou pairing, dois elementos da equipa trabalham em conjunto na mesma estação de trabalho. Desse modo, um desenvolve o produto e o outro revê o trabalho feito, sugere alterações e corrige erros. Dessa forma, esta prática contribui para uma partilha de conhecimento. Ainda mais, o pair programming ajuda a entregar melhor produtos com menos defeitos. Contudo, como pode ser mais demorado, só se deve usar em projectos com uma duração longa. Em seguida, consulte este artigo para saber mais sobre pair programming. 

Collective Code Ownership (Propriedade Coletiva do Código)

Esta prática responsabiliza toda a equipa pelo desenvolvimento do produto. Desse modo, cada membro deve rever e actualizar o produto por forma a evitar duplicações, incentivando a colaboração da equipa e a promoção de novas ideias.

Continuous Integration (Integração Contínua)

O objectivo desta prática é manter o produto completamente integrado. Dessa forma, à medida que a equipa desenvolve novos incrementos, vai integrando cada incremento com o produto. Dessa forma, reduz-se os problemas de integração.

On-site Customer (Cliente Presencial)

O cliente é envolvido nas fases de especificação. Contudo ele também deve participar nas fases de desenvolvimento, para poder responder a todas as perguntas da equipa, definir prioridades e resolver problemas.

Coding Standards (Padrões de Codificação)

A equipa dever ter práticas comuns para desenvolver o produto, usando os mesmos formatos e estilos. Isto porque, a utilização de padrões facilita o desenvolvimento do produto, o refactoring, e a manutenção do produto quando já estiver em produção.

40-Hour Week (Semana de 40 Horas)

Esta última prática refere-se à qualidade de vida dos developers. Se o XP exige que os developers trabalhem rapidamente, eficientemente e que mesmo assim mantenham um produto de qualidade, estes tem de estar felizes e descansados. Dessa forma, para evitar problemas de excesso de trabalho, estes só devem trabalhar 40 horas por semana para conseguirem equilibrar o trabalho com o descanso e a vida pessoal.