A Programação Extrema (XP) é uma metodologia ágil de desenvolvimento de software. Como outras metodologias ágeis, a XP possui suas ferramentas, processos e papéis únicos. O criador da XP, o desenvolvedor americano Kent Beck, não inventou nada completamente novo, mas tomou as melhores práticas do desenvolvimento ágil e as amplificou ao extremo, daí o nome Programação Extrema.
O autor da metodologia, Kent Beck, liderou o projeto do Sistema de Compensação Abrangente da Chrysler no final dos anos 90, onde aplicou pela primeira vez as práticas da XP. Ele documentou sua experiência e o conceito criado no livro “Programação Extrema Explicada,” publicado em 1999. Este livro foi seguido por outros que detalhavam as práticas da XP. Contribuidores para o desenvolvimento da metodologia incluem Ward Cunningham, Martin Fowler e outros.
Diferentemente de outras metodologias ágeis, a XP é exclusivamente usada no desenvolvimento de software. Não pode ser aplicada a outros negócios ou à vida cotidiana como Scrum, Kanban ou Lean.
O objetivo da XP é lidar com requisitos em constante mudança para o produto de software e melhorar a qualidade do desenvolvimento. Portanto, a XP é adequada para projetos complexos e incertos.
A XP gira em torno de quatro atividades principais: codificação, teste, design e escuta. Além disso, a Programação Extrema tem valores centrais: simplicidade, comunicação, feedback, coragem e respeito.
13 Práticas da Programação Extrema
1. A Equipe Completa
Todos os participantes do projeto que utilizam a XP trabalham como uma única equipe. Essa equipe deve incluir um representante do cliente, de preferência um usuário final real que conheça o negócio. O cliente define os requisitos do produto e prioriza a funcionalidade. Analistas de negócios podem auxiliar o cliente. Do lado dos executores, a equipe inclui desenvolvedores, testadores, às vezes um coach orientando a equipe, e um gerente fornecendo recursos.
2. Jogo de Planejamento
O planejamento na XP ocorre em duas etapas: planejamento de liberação e planejamento de iteração.
- Planejamento de Liberação: A equipe de programação se encontra com o cliente para determinar a funcionalidade desejada para a próxima liberação, tipicamente em 2 – 6 meses. Uma vez que os requisitos do cliente são frequentemente vagos, os desenvolvedores os esclarecem e os dividem em tarefas que podem ser concluídas em um dia ou menos. O cliente deve entender o ambiente operacional onde o produto funcionará.
As tarefas são registradas em cartões, e o cliente as prioriza. Os desenvolvedores então estimam o tempo necessário para cada tarefa. Uma vez que as tarefas são descritas e estimadas, o cliente revisa a documentação e aprova o início do trabalho. Para o sucesso do projeto, é crítico que o cliente e a equipe de programação joguem no mesmo campo: o cliente escolhe a funcionalidade genuinamente necessária dentro do orçamento, e os programadores alinham adequadamente os requisitos do cliente com suas capacidades. - Planejamento de Iteração: Realizado a cada duas semanas, às vezes com mais ou menos frequência. O cliente está presente para definir a funcionalidade da próxima iteração e fazer alterações nos requisitos do produto.
3. Lançamentos Pequenos
Os lançamentos da XP são frequentes, mas com funcionalidade limitada. Essa abordagem facilita o teste e a manutenção da operabilidade do sistema e fornece ao cliente a funcionalidade de valor comercial a cada iteração.
4. Testes do Cliente
O cliente especifica testes de aceitação automatizados para verificar a funcionalidade do produto. A equipe escreve esses testes e os utiliza para testar o código.
5. Propriedade Coletiva do Código
Na XP, qualquer desenvolvedor pode modificar qualquer parte do código, uma vez que o código não pertence ao seu autor, mas a toda a equipe.
6. Integração Contínua
Novas partes do código são integradas ao sistema imediatamente — equipes XP lançam uma nova build a cada poucas horas ou mais frequentemente. Essa prática garante que o impacto das mudanças recentes no sistema seja visível imediatamente. Se uma nova parte do código quebra algo, identificar e corrigir o erro é muito mais fácil.
7. Padrões de Codificação
Com a propriedade coletiva do código, adotar padrões comuns de codificação é crucial para que o código pareça ter sido escrito por um único profissional. As equipes podem desenvolver seus padrões ou adotar os existentes.
8. Metáfora do Sistema
A metáfora do sistema é uma comparação com algo familiar para criar uma visão compartilhada dentro da equipe. Normalmente, a pessoa que desenvolve a arquitetura e vê o sistema como um todo elabora a metáfora.
9. Ritmo Sustentável
As equipes XP trabalham com a máxima produtividade enquanto mantêm um ritmo sustentável. A Programação Extrema desencoraja horas extras e promove uma semana de trabalho de 40 horas.
10. Desenvolvimento Orientado a Testes (TDD)
Uma das práticas mais desafiadoras na XP. Os programadores escrevem testes antes de escrever o código a ser testado. Essa abordagem garante que cada parte da funcionalidade esteja completamente coberta por testes. Quando os desenvolvedores enviam código, testes de unidade são executados imediatamente, e todos os testes devem passar, garantindo que a equipe está se movendo na direção certa.
11. Programação em Par
Imagine dois desenvolvedores trabalhando em um computador em uma única peça de funcionalidade. Essa prática é a programação em par, a prática mais controversa na XP. O ditado “duas cabeças pensam melhor que uma” ilustra bem sua essência. De duas soluções para um problema, a melhor é escolhida, o código é otimizado imediatamente, e erros são detectados antes que ocorram, resultando em um código limpo compreendido por ambos os desenvolvedores.
12. Design Simples
Design simples na XP significa fazer apenas o que é necessário agora, sem tentar prever funcionalidades futuras. Design simples e refatoração contínua criam um efeito sinérgico — quando o código é simples, é mais fácil de otimizar.
13. Refatoração
A refatoração é o processo contínuo de melhorar o design do sistema para atender novos requisitos. Isso inclui remover duplicação de código, aumentar a coesão e reduzir o acoplamento. A XP exige refatoração constante, para que o design do código sempre permaneça simples.
Vantagens e Desvantagens da XP
A XP é controversa e frequentemente criticada por aqueles que não conseguiram implementá-la. No entanto, seus benefícios são evidentes quando a equipe utiliza plenamente pelo menos uma prática da XP.
Os benefícios de buscar a XP incluem:
- Satisfação do Cliente: Os clientes recebem o produto de que precisam, mesmo que inicialmente não tenham uma visão clara.
- Flexibilidade: A equipe faz alterações no código rapidamente e adiciona nova funcionalidade devido ao design de código simples, planejamento frequente e lançamentos.
- Confiabilidade: O código sempre funciona devido a testes constantes e integração contínua.
- Facilidade de Manutenção: A equipe pode manter o código facilmente porque é escrito a um único padrão e constantemente refatorado.
- Produtividade: Pace de desenvolvimento rápido devido à programação em par, sem horas extras e envolvimento do cliente.
- Código de Alta Qualidade
- Mitigação de Risco: Os riscos de desenvolvimento são reduzidos, pois a responsabilidade é distribuída uniformemente, e o projeto não é prejudicado pela saída ou chegada de membros da equipe.
- Eficiência de Custos: Os custos de desenvolvimento são mais baixos, pois a equipe se concentra no código em vez de na documentação e nas reuniões.
Apesar de suas vantagens, a XP nem sempre funciona e possui várias fraquezas:
- Envolvimento do Cliente: O sucesso depende do envolvimento do cliente, o que pode ser desafiador de se alcançar.
- Linhas do Tempo Imprevisíveis: É difícil prever os custos de tempo do projeto, uma vez que a lista completa de requisitos é desconhecida no início.
- Dependência do Nível de Habilidade: A XP depende fortemente do nível de habilidade dos programadores e funciona melhor com profissionais seniores.
- Resistência da Gestão: A gestão frequentemente se opõe à programação em par, questionando a necessidade de pagar dois programadores em vez de um.
- Custo: Reuniões frequentes com programadores podem ser caras para os clientes.
- Mudanças Culturais: Implementar a XP requer mudanças culturais significativas.
- Falta de Estrutura: A falta de estrutura e documentação da XP a torna inadequada para projetos grandes.
- Requisitos Não Funcionais: Requisitos funcionais são desafiadores de descrever como histórias de usuários em metodologias ágeis.
Princípios da XP
No seu primeiro livro, Kent Beck delineou os seguintes princípios da XP: simplicidade, comunicação, feedback e coragem. Em uma edição subsequente, ele adicionou um quinto princípio — respeito.1. Simplicidade
O desenvolvimento XP começa com a solução mais simples que atende à necessidade funcional atual. Os membros da equipe consideram apenas o que precisa ser feito agora e não incorporam funcionalidades que possam ser necessárias no futuro.
2. Comunicação
A comunicação na XP ocorre ao vivo, em vez de por meio de documentação. A equipe se comunica ativamente entre si e com o cliente.
3. Feedback
O feedback na XP é implementado de três maneiras:
- Feedback do Sistema: Por meio de testes constantes de módulo.
- Feedback do Cliente: O cliente é parte da equipe e participa da redação dos testes de aceitação.
- Feedback da Equipe: Durante o planejamento, em relação às estimativas de tempo de desenvolvimento.
4. Coragem
Algumas práticas da XP são tão não convencionais que exigem coragem e autocontrole constante.5. Respeito
Respeito na XP significa respeitar a equipe e auto-respeito. Os membros da equipe não devem fazer alterações que quebrem a compilação, os testes de módulo ou ralentem o trabalho dos colegas. Cada membro se esforça pela mais alta qualidade de código e design.
Implementando XP e o Fluxo de Trabalho
Kent Beck recomenda implementar a XP para resolver problemas de projeto. A equipe seleciona o problema mais urgente e o resolve utilizando uma das práticas da XP. Depois, eles passam para o próximo problema, utilizando outra prática. Essa abordagem garante que os problemas motivem a adoção da XP, e a equipe gradualmente domina todas as ferramentas da metodologia.
Para implementar a XP em um projeto existente, adote gradualmente suas práticas nas seguintes áreas:
- Testes: A equipe cria testes antes de escrever novo código e gradualmente refatora o código antigo.
- Design: A equipe refatora continuamente o código antigo, tipicamente antes de adicionar nova funcionalidade.
- Planejamento: A equipe deve interagir de perto com o cliente.
- Gestão: Os gerentes garantem que todos os membros da equipe sigam as novas regras.
- Desenvolvimento: Comece organizando estações de trabalho para programação em par e incentive as duplas a programar na maior parte do tempo.
Exemplo de um Fluxo de Trabalho Usando XP
Quem Usa a XP
De acordo com uma pesquisa da VersionOne de 2016, apenas 1% das empresas ágeis utilizam a XP em sua forma pura. Outros 10% utilizam um híbrido de Scrum e XP.Embora a XP não seja a metodologia mais comum, suas práticas são usadas pela maioria das empresas que empregam metodologias ágeis. Por exemplo, a Pivotal Software, Inc. atribui seu sucesso à XP.
Pivotal Software, Inc.
A Pivotal Software, Inc. desenvolve análises de negócios baseadas em big data e oferece serviços de consultoria. Seus produtos são usados por corporações como Ford, Mercedes, BMW, GAP, Humana, grandes bancos, agências governamentais e companhias de seguros.
A Pivotal defende que metodologias ágeis são essenciais para o desenvolvimento moderno. Entre as variantes ágeis, escolheram a XP, uma abordagem ganha-ganha para clientes e equipes de programação. Seu dia de trabalho começa com reuniões rápidas e termina às 18:00 — sem horas extras. A Pivotal utiliza jogos de planejamento, programação em par, testes constantes, integração contínua e outras práticas da XP.
O que Ler para Entender a XP
- “Programação Extrema Explicada,” “Planejando a Programação Extrema,” “Desenvolvimento Orientado a Testes” de Kent Beck: Esses livros do criador da XP fornecem uma compreensão profunda da metodologia e suas vantagens.
- “Refatoração: Melhorando o Design do Código Existente” de Martin Fowler: Um livro de um co-autor da XP explicando os princípios e técnicas de refatoração.
- “Programação Extrema Aplicada: Jogando para Vencer” de Ken Auer e Roy Miller: Um guia prático sobre as práticas da XP com exemplos.
Ferramentas para Implementar a XP em Equipes
Redmine
Um gerenciador de tarefas gratuito e de código aberto, com recursos como suporte para projetos múltiplos, gerenciamento flexível de tarefas, gráficos de Gantt, rastreamento de tempo, gerenciamento de documentação e criação de tarefas via e‑mail.
Basecamp
Um serviço simples e amigável para trabalho colaborativo em projetos, incluindo um gerenciador de tarefas, fóruns, chat integrado, armazenamento de arquivos e calendário.
Jira
Um serviço robusto projetado para desenvolvedores de projetos ágeis, combinando um rastreador de bugs e ferramenta de gerenciamento de projetos com muitos recursos e opções de sincronização.
Worksection
Um serviço seguro para trabalho em projetos, permitindo definição de tarefas e controle de processos, rastreamento de correspondência, personalização de filtros, rastreamento de tempo e financeiro, e gerenciamento de arquivos.
Conclusão
A Programação Extrema é uma metodologia ágil focada na produção de código funcional de alta qualidade com uma arquitetura simples. Seu propósito é reduzir a incerteza em projetos e responder de maneira flexível às mudanças nos requisitos do produto.
A XP é exclusivamente para desenvolvimento de software e não pode ser adaptada a outros negócios.
É uma das metodologias mais desafiadoras de implementar devido às suas treze práticas. No entanto, suas práticas são amplamente utilizadas em projetos ágeis, provando sua eficácia.
Os autores aconselham a dominar gradualmente as práticas da XP enquanto resolvem problemas do projeto. Se você perceber os benefícios, continue nesse espírito. Não há obrigação de implementar a XP de forma total — afinal, as metodologias ágeis devem ser flexíveis na aplicação, adaptando-se às necessidades da equipe de projeto específica.