Um pouco sobre XP

Já que eu falei um pouco sobre XP no post anterior, resolvi dar uma explicada melhor nisso nesse post para aqueles que ainda não conhecem sobre essa metodologia.

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ípiosOs 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.

Publicado originalmente em: http://febracev.wordpress.com/

Leave a Reply

Your email address will not be published. Required fields are marked *