A Programação Extrema é uma das metodologias ágeis mais conhecidas. Foi criada por Kent Beck e ganhou notoriedade a partir da OOPLSA 2000 (a maior conferência internacional de Orientação a Objetos). A primeira reação a XP foi bem controversa. Alguns amaram (normalmente os programadores), outros odiaram. Em XP, o bom programador se sente mais livre para fazer o que faria se não existissem regras. Ao mesmo tempo, XP obriga o “mau” programador a se comportar de forma similar ao bom.
A Programação Extrema é baseada em cinco valores, alguns princípios e várias práticas. Ela se destina a times de até dez programadores, projetos de curto e médio prazo.
Os cinco valores de XP são:
- Comunicação – para um projeto de sucesso é necessária muita interação entre os membros da equipe, programadores, cliente, treinador. Para desenvolver um produto, o time precisa ter muita qualidade nos canais de comunicação. Conversas cara-a-cara são sempre melhores do que telefonemas, e-mails, cartas ou fax.
- Feedback – as respostas às decisões tomadas devem ser rápidas e visíveis. Todos devem ter, o tempo todo, consciência do que está acontecendo.
- Coragem – alterar um código em produção, sem causar bugs, com agilidade, exige muita coragem e responsabilidade.
- Simplicidade – para atender rapidamente às necessidades do cliente, quase sempre um dos valores mais importantes é simplicidade. Normalmente o que o cliente quer é muito mais simples do que aquilo que os programadores constróem.
- Respeito – todos têm sua importância dentro da equipe e devem ser respeitados e valorizados. Isso mantém o trabalho energizado.
Em XP existem quatro papéis principais:
- Programadores - foco central da metodologia, sem hierarquia.
- Treinador (ou coach) - pessoa com mais experiência no time, responsável por lembrar os outros das regras do jogo (que são as práticas e os valores de XP). O treinador não precisa necessariamente ser o melhor programador da equipe e sim o que mais entende da metodologia XP.
- Acompanhador (ou tracker) - responsável por trazer para o time dados, gráficos, informações que mostrem o andamento do projeto e ajudem a equipe a tomar decisões de implementação, arquitetura e design. Algumas vezes o próprio coach faz papel de tracker. Outras o time escolhe sozinho quem exercerá este papel.
- Cliente – em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto para responder às dúvidas dos programadores.
A parte principal da metodologia são as Práticas. Para descrevê-las precisaremos de alguns posts. Existem vários livros que falam das práticas de XP e podem ajudar o leitor a obter maiores detalhes. Os principais são os escritos pelo próprio criador da metodologia (Extreme Programming Explained: Embrace Change). Neste post faremos um breve resumo das práticas e em breve entraremos nos detalhes de algumas delas.
- Planejamento - assim como no Scrum, existe uma fase de planejamento, quando desenvolvedores e cliente se encontram para priorizar e estimar histórias.
- Fases Pequenas - cada fase é chamada de iteração (Sprint no Scrum). Elas devem durar no máximo 30 dias, mas o ideal é que seja 15 ou até 7 dias.
- Design Simples - seguindo o valor simplicidade, os projetos devem ser simples e atender a cada passo somente o que foi pedido. Nada de matar formigas com canhão!
- Testes - todo desenvolvimento inclui testes. Kent Beck diz que código sem teste não existe. Os testes devem ser escritos de preferência antes do desenvolvimento (TDD - test driven development) e sempre devem rodar de forma automatizada.
- Refatoração - é um conjunto de técnicas para modificar o código do sistema sem alterar nenhuma funcionalidade. O objetivo é simplificar, melhorar o design, limpar, enfim, deixar o código mais fácil de entender e dar manutenção.
- Programação Pareada - em XP dois programadores sentam juntos no mesmo computador e programam juntos. Enquanto um programador digita, o outro observa, pensa em melhorias, alternativas. Falaremos mais sobre a programação em pares e seus benefícios
- Propriedade Coletiva - O código fonte não pertence a um único programador. Todos da equipe são responsáveis. Todos alteram código de todos (mas sempre rodando os testes para se certificar que nada foi quebrado)
- Integração Contínua - depois de testada, cada nova funcionalidade deve ser imediatamente sincronizada entre todos os desenvolvedores. Quanto mais freqüente for essa integração, menores são as chances de conflitos de arquivos que vários programadores alteram simultaneamente
- Semana de 40 horas - programar é uma atividade intensa e que não rende se o programador não estiver descansado e disposto. Por isso, 40 horas de trabalho por semana é essencial para a saúde do time.
- Cliente Sempre Presente - o cliente não é alguém de fora, mas sim um membro da equipe. Ele deve estar sempre disponível e pronto para atender às dúvidas dos desenvolvedores.
- Padronizações - se todo o time seguir padrões pré-acordados de codificação, mais fácil será manter e entender o que já está feito. O uso de padrões é uma das formas de reforçar o valor comunicação.
São muitas práticas! Para colocá-las em produção é preciso paciência e conhecimento. O ideal é começar com 2 ou 3 delas e ir inserindo lentamente as outras, sentindo as dificuldades, refletindo e avaliando as mudanças. Muitas das práticas só serão aprendidas na prática (ha ha! por isso chamam práticas). Aos poucos falaremos mais sobre cada uma delas e daremos dicas de como podem ser aplicadas em conjunto. O mais legal é que as práticas se sustentam: uma ajuda a outra a tornar o projeto mais eficiente e ágil.
Dia 26/junho às 15h farei uma palestra online sobre XP. O endereço para quem quiser se inscrever é:
http://www.locawebcast.com.br/webcast.aspx
