O que é XP (Extreme Programming) e quais são suas práticas
Entender o que é XP (Extreme Programming) costuma vir de um incômodo concreto: o time já faz Sprints, reuniões diárias e retrospectivas, mas cada entrega quebra alguma coisa que funcionava, a homologação demora semanas e ninguém tem coragem de mexer no código antigo. O processo de gestão está lá; o que falta é disciplina técnica. É exatamente esse vazio que o XP preenche.
Extreme Programming, ou programação extrema, é um método ágil para equipes de desenvolvimento de software. Ele combina um conjunto pequeno de valores com práticas de engenharia muito concretas: escrever o teste antes do código, programar em dupla, integrar várias vezes por dia, manter o design simples e trabalhar em ciclos curtos com o cliente por perto.
A seguir estão a origem do método, os valores e princípios, as práticas explicadas uma a uma, o encaixe com Scrum e um roteiro para começar sem parar o projeto.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
De onde veio a metodologia XP
O XP nasceu num projeto de folha de pagamento da Chrysler, conhecido como C3. Kent Beck foi chamado para ajudar no desempenho do sistema, percebeu que o problema maior estava no processo de desenvolvimento e assumiu a liderança do projeto em março de 1996. Ron Jeffries entrou em seguida, como coach, para transformar as práticas em hábito da equipe.
O nome vem da ideia que Beck descreveu ao relatar o início do trabalho: pegar as práticas que considerava essenciais, levá-las ao grau máximo e deixar de fora o resto. Aplicada às práticas, a lógica fica assim: se revisar código é bom, revisa-se o tempo todo (programação em par). Se testar é bom, testa-se antes de escrever (testes primeiro). Se integrar é bom, integra-se várias vezes por dia.
O método foi publicado no livro Extreme Programming Explained, de Kent Beck, em outubro de 1999. A segunda edição, de 2004, escrita com Cynthia Andres, reorganizou as práticas e é a referência usada aqui.
Os cinco valores do XP
O XP parte de valores, porque prática sem propósito vira ritual. A segunda edição lista cinco:
- Comunicação. Muitos problemas de projeto nascem de uma informação que não chegou a quem precisava dela. As práticas do XP forçam a conversa.
- Simplicidade. Fazer a coisa mais simples que resolve o problema de hoje, sem construir para necessidades imaginadas.
- Feedback. Saber cedo se o caminho está certo: o teste diz em segundos, o cliente diz em dias, o uso em produção diz em semanas.
- Coragem. Mudar o design, jogar código fora, dizer a verdade sobre prazo. A coragem é sustentada pelos outros valores, principalmente pelos testes.
- Respeito. Acrescentado na segunda edição: as pessoas da equipe se importam umas com as outras e com o projeto.
Entre os valores e as práticas, Beck coloca catorze princípios, como humanidade, economia, benefício mútuo, melhoria, reflexão, fluxo, qualidade e passos pequenos. Eles servem para decidir o que fazer quando nenhuma prática se aplica diretamente.
Quais são as práticas do XP
Na segunda edição, as práticas foram divididas em dois grupos: primárias, que funcionam sozinhas e já trazem ganho quando adotadas, e corolárias, que só dão certo depois que as primárias estão firmes. As treze práticas primárias são:
| Prática | O que significa no dia a dia |
|---|---|
| Sentar junto | A equipe trabalha no mesmo espaço (ou com canais equivalentes no remoto), para que dúvidas virem conversa de minutos. |
| Equipe inteira | Todas as habilidades necessárias estão no time: desenvolvimento, testes, negócio, design. |
| Espaço de trabalho informativo | Quem chega entende em segundos como está o projeto, com histórias e progresso à vista. |
| Trabalho energizado | Trabalhar só as horas em que se é produtivo; cansaço gera defeito. |
| Programação em par | Duas pessoas, um computador: uma escreve, a outra revisa e pensa à frente, alternando. |
| Histórias | O planejamento usa unidades de funcionalidade visíveis para o cliente, com estimativa. |
| Ciclo semanal | Toda semana a equipe planeja, escolhe as histórias e entrega software testado. |
| Ciclo trimestral | A cada trimestre, a equipe olha o quadro maior: temas, gargalos, metas. |
| Folga | Incluir no plano tarefas que podem ser descartadas se houver atraso, para cumprir o compromisso. |
| Build de dez minutos | Compilar e rodar todos os testes automaticamente em até dez minutos. |
| Integração contínua | Integrar e testar as mudanças várias vezes ao dia, em vez de juntar tudo no fim. |
| Programação com teste primeiro | Escrever um teste automatizado que falha antes de mudar o código. |
| Design incremental | Investir no design um pouco todos os dias, melhorando o código existente conforme a necessidade aparece. |
As práticas corolárias incluem envolvimento real do cliente, implantação incremental, continuidade da equipe, análise de causa raiz, código compartilhado, base de código única, implantação diária e contrato com escopo negociado.
As doze práticas da primeira edição
Muitos materiais ainda citam as doze práticas de 1999: jogo do planejamento, pequenas entregas, metáfora, design simples, testes, refatoração, programação em par, propriedade coletiva, integração contínua, semana de 40 horas, cliente no local e padrões de código. A segunda edição não as descartou; ela as redistribuiu. O jogo do planejamento virou os ciclos semanal e trimestral, a semana de 40 horas virou trabalho energizado, o cliente no local virou sentar junto, equipe inteira e envolvimento real do cliente, e a refatoração passou a fazer parte do design incremental. Se você estudar por material antigo, os conceitos são os mesmos com outros nomes.
XP e Scrum: concorrentes ou complementares?
Scrum e XP são comparados com frequência, mas os dois cuidam de coisas diferentes. O Scrum é um framework de gestão: define responsabilidades, eventos e artefatos e deliberadamente não diz como o time deve construir o produto. O XP é, acima de tudo, um conjunto de práticas de engenharia.
| Aspecto | Scrum | XP |
|---|---|---|
| Foco | Organizar o trabalho e a inspeção do produto | Qualidade técnica e resposta rápida a mudanças |
| Ciclo | Sprint de até um mês | Ciclo semanal, dentro de um ciclo trimestral |
| Práticas de código | Não define | Teste primeiro, par, integração contínua, design incremental |
| Onde se aplica | Qualquer trabalho complexo | Desenvolvimento de software |
Por isso a combinação é tão comum: o Scrum dá o ritmo, a Meta da Sprint e a inspeção com o cliente; o XP garante que o Incremento seja de fato utilizável ao fim de cada Sprint. Uma comparação com Kanban e critérios de escolha está em Kanban, Scrum e XP: comparação e como escolher, e o lugar do XP entre os demais métodos ágeis, em tipos de metodologias ágeis.
Quando o XP faz mais diferença
O XP rende mais em projetos de software com requisitos que mudam e com custo alto de defeito. Alguns cenários típicos, descritos aqui como exemplos ilustrativos:
- Sistema interno de uma operadora de saúde, com regras de negócio que mudam por norma e um histórico de correções que quebram outras partes. Testes automatizados escritos antes do código e integração contínua reduzem o medo de mudar.
- Aplicativo de uma rede de varejo em evolução contínua, com entregas frequentes. Build rápido e implantação incremental encurtam o caminho entre a ideia e o cliente.
- Equipe de um órgão público que herdou um sistema sem documentação. Programação em par espalha o conhecimento e diminui a dependência de uma única pessoa.
Ele sofre quando a equipe não tem autonomia sobre o próprio processo técnico, quando o cliente não está disponível para conversar e quando a organização mede produtividade por horas trabalhadas, o que vai contra o trabalho energizado.
Como começar a usar XP no seu time
Não é preciso adotar tudo de uma vez. Um caminho seguro:
- Comece pelo build e pelos testes. Automatize a compilação e um primeiro conjunto de testes. Sem isso, as outras práticas não têm rede de proteção.
- Adote integração contínua. Combine que ninguém fica mais de um dia sem integrar e que build quebrado é prioridade de todos.
- Experimente programação em par em tarefas difíceis. Código crítico, correções delicadas e entrada de pessoas novas são bons pontos de partida.
- Escreva o teste antes da mudança nas partes mais instáveis do sistema.
- Torne o trabalho visível. Um quadro com as histórias da semana e o estado do build ao alcance de todos.
- Revise na retrospectiva. A cada ciclo, a equipe escolhe uma prática para aprofundar ou ajustar.
Para ver como essas práticas se encaixam no ciclo completo de um projeto de software, do planejamento à implantação, leia metodologia ágil no desenvolvimento de software. O panorama de valores, métodos e escolha da abordagem está no guia completo de métodos ágeis e Scrum.
O próximo passo
Escolha uma única prática para as próximas duas semanas, de preferência o build automatizado com testes, e combine com o time como saber se ela funcionou: menos defeitos devolvidos pela homologação, por exemplo. Se você quer consolidar a base de gestão ágil que sustenta essas práticas, o curso Agile Scrum Foundation da Projeto Diário cobre papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
