A estrutura do xp também é constituida de práticas que são sustentadas pelos valores já citados na postagem anterior. Antes de qualquer coisa, é necessário ter confiança nestas boas práticas
e consciência de que elas devem ser aplicadas em conjunto. Quando
aplicadas isoladamente, elas não trazem os mesmos resultados por que os
pontos fracos de cada prática são protegidos pelos pontos fortes das
outras práticas. As práticas são:
- O jogo do planejamento: entre o cliente e os técnicos são estimuladas reuniões usando quadros brancos, com o objetivo de captar e definir as "user stories" e também para poder estimar o tempo ideal das interações, o projeto como um todo, elaborar estratégias e tentar prever as contingências para projeto.
- Releases pequenas: cada release deve ser tão pequena quanto possível, contendo apenas os requisitos mais importanter para o negócio.
- Metáfora: a intenção é oferecer uma visão geral do sistema em um formato simples, que possa ser compartilhada por clientes e programadores, a ideia da metáfora é que seja feita uma analogia entre o sistema que está sendo desenvolvido e um sistema que todos entendam, com o objetivo de obter um "vocabulário comum".
- Projeto Simples: o código está, a qualquer momento, na forma mais simples e mais clara, conforme os padrões definidos pela equipe de desenvolvimento, facilitando a compreensão e possível continuidade por qualquer um de seus membros.
- Testes constantes: os testes no xp são feitos antes da programação. Existem os testes funcionais e os de unidade, os testes de unidade são feitos para verificar tudo que possa dar errado e os funcionais são usados para verificação junto ao cliente do sistema como um todo.
- Refatoramento: são constantes melhorias no projeto do software para aumentar sua capacidade de se adaptar a mudanças.
- Programação em pares: todo o código produzido em xp é escrito por um par de programadores sentados lado-a-lado e olhando para o computador. Um parceiro será responsável pela codificação e o outro observa o código e pensará mais estratégicamente em como melhorá-lo e torná-lo mais simples.
- Propriedade coletiva do código: uma vez aplicados a programação em pares, a equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo, mantendo claro, um padrão prático de comunicação da equipe.
- Integração contínua: os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários, facilitando, dessa forma, o trabalho de implementação da solução
- Semana de quarenta horas: trabalhar por longos períodos é contraproducente. Portanto, sempre que possível, deve-se evitar a sobrecarga de trabalho de todos da equipe, criando condições favoráveis ao uso da carga normal de trabalho. É necessário deixar a equipe livre para relaxar, brincar, ou fazer o quem bem entender para equilibrar o trabalho mental e físico. Existe até uma frase que diz: trabalhe a 100% durante as 40 horas e descanse a 100% no resto. Se algum deles não for feito com 100%, um afetará o outro.
- Cliente no local: Constante disponibilidade do cliente para colaborar em dúvidas, alterações, e prioridades em um escopo, ou seja, dando um dinamismo ativo ao projeto
- Padrões de codificação: todo código é desenvolvido seguindo um padrão, qualquer que seja, mas toda equipe deve seguir o mesmo padrão. Dessa forma, todos da equipe terão a mesma visão do código.
Nenhum comentário:
Postar um comentário