XP - Extreme Programming: Onde Boas Práticas Maximizam Resultados
O XP – Extreme Programming foi criado por Kent Beck em 1997 em um projeto para a Chrysler com o objetivo de auxiliar em projetos pequenos e médios de 2 a 12 pessoas envolvidas, com boas práticas para assegurar que o cliente tenha o melhor retorno possível.
Nesta metodologia tem-se como objetivo descrever a meta de longo prazo para atender a todos requisitos da necessidade do cliente seguindo os valores:
Feedback: Ao ser analisado o sistema pelo cliente, o mesmo é avaliado e gera insights importantes que norteiam o time de desenvolvimento, dizendo o que é necessário melhorar ou acrescentar, o que deu certo e o que não é necessário.
Comunicação: Com isso é possível que sejam analisados os detalhes importantes do projeto e que seja dispendida a atenção necessária no desenvolvimento.
Simplicidade: Toda informação trocada entre cliente e time de projeto deve ser claramente compreendida e deve ser desenvolvido somente aquilo que é necessário, direcionando totalmente o foco no problema.
Coragem: O time deve ter a confiança de que partindo com os valores do XP poderá evoluir o desenvolvimento com segurança e agilidade.
Respeito: Todos os integrantes do time devem ter abertura para apresentar seus pontos de vista.
O XP possui 12 práticas diretamente relacionadas aos seus valores e que tem como missão garantir a satisfação do cliente e proporcionar um ambiente de trabalho agradável a todos, conforme demonstrado na figura 1. As 12 práticas da metodologia XP devem ser aplicadas em conjunto dentro dos projetos para que se tenha consistência nos resultados.
Figura 1 – Práticas Extreme Programming.
Fonte: Elaborada pelo autor (2021).
Test driven development (Desenvolvimento orientado a teste): O time de desenvolvimento define testes para cada funcionalidade que será desenvolvida, antes de iniciar a estruturação do código, com isso torna-se possível validar rapidamente o item desenvolvido.
Refactoring (Refatoração): Esta prática consiste em reestruturar o código de um projeto para facilitar seu entendimento e evitar duplicidade seguindo a filosofia DRY (don´t repeat yourself).
Simple design (Design simples): O projeto desenvolvido deve ser simples atendendo a real necessidade do cliente naquele momento. Caso existam necessidades futuras elas podem ser incrementadas ao projeto quando realmente se tornarem necessárias.
Pair Programming (Programação em par): Todo o código do projeto é feito em dupla, onde um desenvolvedor escreve o código e outro monitora o raciocínio fornecendo insights e em determinado momento ambos invertem os papeis, dando dinamismo ao desenvolvimento.
Collective Code Ownership (Propriedade coletiva): Todos os membros do time de desenvolvimento são responsáveis pelo código que está sendo desenvolvido, ou seja, mesmo que um membro deixe o time/empresa no decorrer do projeto, todo o restante sabe o ponto que está o desenvolvimento e pode dar continuidade rapidamente.
Code standards (Padronização de código): São estabelecidos padrões de estruturação do código para que todos os desenvolvedores tenham uma leitura rápida do que está sendo construído.
Sustainable pace (Ritmo sustentável): Nesta metodologia é recomendado que a jornada de trabalho de 8 horas seja respeitada, entendendo o limite físico de cada desenvolvedor.
Metaphor (Metáfora): É uma boa prática da metodologia XP realizar associações de termos técnicos a uma linguagem que seja compreensível por todos criando metáforas para facilitar o entendimento.
Continuous integration (Integração contínua): Ao final do desenvolvimento de cada incremento, após serem realizados todos os testes possíveis, a nova funcionalidade é incorporada ao código principal.
Planning games (Jogos de planejamento): O cliente é incumbido de descrever claramente as funcionalidades desejadas estruturando as user stories para que o time de projeto possa definir o tempo necessário para realizar o incremento e o custo, desse modo o cliente decide a ordem a qual serão desenvolvidos os itens.
Small releases (Entregas curtas): Como cada história de usuário representa o menor incremento utilizável de um projeto é utilizada esta prática para realizar entregas rápidas ao cliente.
Customer Tests (Testes de usuário): São as definições do cliente dos testes necessários para a validação do projeto.
Whole team (Equipe inteira): Nesta metodologia é buscado unir diversas áreas do time para atuarem em conjunto no mesmo ambiente para o desenvolvimento do projeto.
Como ao analisar os valores da metodologia XP pontualmente podem haver avaliações vagas dependendo da óptica utilizada entre duas pessoas, procura-se transformar os valores em princípios (feedback, simplicidade, mudanças incrementais, aceitação de mudanças e qualidade) que irão nortear o time para agregar valor. Apesar da metodologia XP possuir práticas e valores que possibilitam simplificar projetos complexos, existem ambientes onde o XP não é recomendado, em processos de produção em massa onde tem-se etapas conhecidas e é claro desde o início o que necessita ser feito para atingir certo fim ou até mesmo quando um dos focos do projeto seja a documentação, nestes ambientes culturalmente são utilizadas metodologias estruturadas pelo modelo cascata.