Aula 7: Programação Extrema (XP) e Desenvolvimento Orientado a Testes (TDD)

A Programação Extrema (XP) é um dos métodos ágeis mais conhecidos e completos, criado por Kent Beck em 1996 — antes até de o termo 'Agile' ser cunhado. Nesta aula, vamos conhecer os quatro valores centrais do XP (Simplicidade, Comunicação, Feedback e Coragem) e as 12 práticas na formulação original

Resumindo: o XP diz 'pegue as coisas boas que já fazemos e as amplifique' — comunicação, simplicidade, feedback e coragem. E o TDD diz: primeiro escreva um teste que falha, depois escreva só o código necessário para que ele passe — e então pare.

Programação Extrema (XP): Um método de desenvolvimento ágil criado por Kent Beck em 1996, um dos mais completos e conhecidos; construído sobre quatro valores (Simplicidade, Comunicação, Feedback, Coragem) e 12 práticas de engenharia, com base na ideia de 'pegar o que funciona e ampliá-lo'.
Desenvolvimento Orientado a Testes (TDD): Um método em que você primeiro escreve um teste de unidade que precisa rodar e falhar, depois escreve código até que o teste passe, parando no momento em que ele passa — sem adicionar funcionalidades extras; nenhum teste que já passava antes pode voltar a falhar.
Jogo do Planejamento (Planning Game): Uma prática de planejamento do XP que separa as decisões de negócio das decisões dos desenvolvedores: o negócio apresenta e prioriza as histórias de usuário, os desenvolvedores estimam o esforço, e as iterações são curtas (1-2 semanas) e nunca ultrapassam o tempo alocado.
História de Usuário (User Story): Um cartão curto (nome + descrição) de uma funcionalidade que traz valor ao cliente, escrito pelo cliente e estimado pelos desenvolvedores; substitui grandes documentos de requisitos, com um propósito parecido ao de um caso de uso (use case).
Programação em Pares (Pair Programming): Todo o código é escrito em pares em uma única estação: um escreve, o outro pensa se vai funcionar, em formas melhores de fazer e em cenários de teste; eles trocam de posição a cada duas horas, aproximadamente, e os pares se revezam — o que favorece a propriedade coletiva e a revisão informal.
Refatoração (Refactoring): Melhorar a estrutura do código existente sem mudar seu comportamento, para manter o design simples; uma atividade contínua, não pontual, na qual os testes garantem que o comportamento não foi quebrado.
Integração Contínua (CI): Construir e testar o sistema inteiro várias vezes ao dia (integrando pelo menos uma vez por dia), com testes automatizados; os testes de unidade precisam passar 100% antes e depois da integração.
Ritmo Sustentável (semana de 40 horas): 'Programar é uma maratona, não uma corrida de velocidade': a equipe trabalha até 40 horas por semana; pessoas cansadas não são produtivas; em uma crise, permite-se até uma semana de horas extras, mas semanas seguidas são sinal de que algo não vai bem.