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