Um pouco sobre XP

A programação extrema (eXtreme Programming ou XP) é um método leve para que equipes pequenas ou médias desenvolvam software em face a requisitos vagos ou que mudem constantemente. Pela definição de seu autor, Kent Beck, o XP é leve porque é focado na realização das tarefas que criem valor para o cliente. Seu principal objetivo é o desenvolvimento de software com qualidade, por meio de um estilo de desenvolvimento focado nas melhores práticas de programação, comunicação clara e trabalho em equipe.

Como outras metodologias ágeis, o XP se opõe a diversas premissas assumidas pelas metodologias tradicionais de engenharia de software. Uma dessas premissas é a possibilidade de prever todos os passos necessários para o desenvolvimento de um sistema, por um detalhado levantamento de características do problema a ser resolvido e da solução a ser desenvolvida. O XP assume a presença constante das mudanças durante o processo de desenvolvimento e propõe uma série de práticas para lidar com elas.

A programação extrema é descrita por meio de seus valores, princípios e práticas. As práticas são uma série de técnicas a serem aplicadas no dia-a-dia de trabalho da equipe. Os valores são a noção do que é certo e do que é errado no relacionamento da equipe com o trabalho e entre si. Os valores fundamentam as práticas. Porém, os valores do XP são universais e independem do contexto do desenvolvimento de software, estando assim muito distante das práticas. A ponte entre os valores e as práticas são os princípios, que trazem orientações para um contexto específico.

Uma equipe usando XP possui quatro papéis principais:

• Programadores: foco central da metodologia, sem hierarquia.
• Coach: pessoa com mais experiência no time, responsável por lembrar os outros das práticas e dos valores de XP. O coach não é necessariamente o melhor programador da equipe, mas deve ser o que mais entende da metodologia XP.
• Tracker: pessoa responsável por coletar dados e informações, e apresentar para a equipe em algum formato que possa ser facilmente entendido (por exemplo usando gráficos). O intuito é mostrar o andamento do projeto e ajudar a tomar decisões de implementação, arquitetura e design. O próprio coach pode fazer esse papel ou o time escolhe quem o exercerá.
• Cliente: em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto para responder às dúvidas dos programadores.

Valores
O primeiro dos valores do XP é a Comunicação, por pressupor que a maioria dos problemas de um projeto ocorrem por dificuldades nesse aspecto. A comunicação constante e eficaz entre os membros da equipe permeia todo processo de desenvolvimento, e é ressaltado em diversas das práticas do XP.

Outro princípio é a Simplicidade, que leva a equipe a buscar sempre as soluções mais simples a um dado problema, sem tentar otimizações precoces ou a a tentativa de resolução de um problema futuro.

Como não há uma direção pré-definida a ser seguida, a equipe de XP precisa constantemente saber onde se encontra para poder determinar seus próximos passos. O valor que orienta a equipe à rápida resposta sobre as ações realizadas é o Feedback.

Coragem é a ação efetiva frente à insegurança, para a tomada de decisões necessárias ao projeto.

O último valor é o Respeito. Os membros da equipe devem se importar uns com os outros e com as ações realizadas.

Princípios

Os princípios definidos na segunda edição do livro Extreme Programming Explained do Kent Bech são as seguintes:

• Humanidade: O software é desenvolvido por pessoas. As necessidades pessoais dos membros da equipe devem ser levadas em consideração no processo de desenvolvimento.
• Economia: A produção de software não está à parte do processo econômico, e seus aspectos devem ser considerados.
• Benefício mútuo: Qualquer atividade deve beneficiar todas as pessoas envolvidas (desenvolvedores e clientes). Decisões emergenciais, que custem a uma pessoa, representam uma perda ao projeto como um todo.
• Auto semelhança: A estrutura de uma solução deve ser utilizada em outros contextos, mesmo que em diferentes escalas.
• Aperfeiçoamento: Deve-se sempre buscar a realização do melhor trabalho possível no dia de hoje.
• Diversidade: As equipes devem ser formadas por pessoas com diferentes perfis. Os conflitos que possam surgir dessa escolha são compensados pelo benefício das múltiplas visões sobre um problema.
• Reflexão: Não é suficiente realizar tarefas, é necessário constantemente revisitar o trabalho feito e refletir sobre as decisões tomadas, analisando as razões dos sucessos e das falhas.
• Fluxo: O fluxo é a realização simultânea de várias etapas do processo de desenvolvimento, ao invés de separar as fases e trabalhá-las isoladamente.
• Oportunidade: Problemas devem ser vistos como oportunidades de mudança.
• Redundância: Normalmente vista como desperdício, a redundância é o melhor caminho para lidar com as falhas, e deve ser empregada em diversos contextos (múltipla resolução de um problema, programação pareada, etc.).
• Falha: Quando não se sabe a maneira de resolver um problema, deve-se implementar uma alternativa que falhe e aprender com ela. As falhas não são um desperdício, e sim conhecimento.
• Qualidade: Qualidade não deve ser vista como uma variável de controle, negociável, e deve ser sempre buscada.
• Pequenos passos: Ao dar grandes passos, leva-se muito tempo para realizá-los e, caso tenham sido dados na direção errada, é mais difícil voltar atrás. Agindo dessa maneira, é frequente o temor da necessidade de mudanças. Pequenos passos são uma postura mais adequada em processos complexos.
• Aceitação de responsabilidade: A responsabilidade não deve ser designada, deve ser aceita.

Uma figura que é resume bem os valores, os princípios e as práticas está mostrada abaixo.