O objetivo principal do XP é levar ao extremo as práticas que são ditas
como boas na engenharia de software. Estas práticas estão diretamente ligadas
aos valores (comunicação, simplicidade, feedback e
coragem) da metodologia. Estarei trazendo agora para vocês estas
práticas e uma breve explicação de cada uma.
Versões Pequenas: Release é algo que é
implantado no cliente, ou seja, está pronto para ser utilizado. As Releases
normalmente são pequenas e frequentes (a cada 2-3 meses) sendo que
funcionalidades prioritárias são desenvolvidas mais cedo para serem entregues
mais rapidamente ao cliente, pois prioriza-se o que ele mais precisa no
momento. Obviamente que algumas organizações não querem essas entregas frequentes
e pequenas, pois precisam dar treinamentos antes do sistema ser entregue e isso
leva um certo tempo ou então não faz parte da cultura organizacional. Nesse
caso, se a organização não seguir isso não está seguindo realmente o que mandam
as metodologias ágeis como o XP.
Jogo do
Planejamento: Seu objetivo é determinar rapidamente o escopo da próxima Release,
combinando prioridades do negócio e estimativas técnicas. Portanto no XP
planejamos o tempo todo, diferente do que alguns pensam. Com um cliente presente
ele define o escopo para a próxima Release. Dessa forma, define-se as features,
prioridades e o escopo da release
Teste: A prática de teste no XP é bastante técnica, e
envolve a presença do cliente no desenvolvimento e na validação de testes. O cliente
compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes
também se tornam as especificações da programação, visto que o teste diz o que
deve estar de acordo e o que não deve estar de acordo, é como uma
especificação.Os testes são escritos antes da funcionalidade, o que também é
conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um
pouco e codificar um pouco. Além disso, o TDD impõe o programador à saber o que
deve ser verdadeiro no programa e o que não deve ser para que ele funcione
corretamente, portanto, pensa-se primeiramente no problema e depois na solução.
Dessa forma, os testes são automatizados, diferente de anteriormente onde o
desenvolvedor fazia a implementação e entregava para alguém testar. Com os
testes automatizados podemos executá-los a qualquer momento, e dessa forma,
novas funcionalidade ou alterações podem ser imediatamente testadas para ver se
essas mexidas não acarretaram outros problemas. Dessa forma, o teste impõem
também confiança ao sistema e dão coragem para altera-lo, pois podemos saber
imediatamente se algo introduziu um bug no sistema.
Programação
em pares: Trata-se de duas pessoas trabalhando com UMA máquina onde um codifica,
e o outro critica ou dá sugestões. Os pares trocam de lugar periodicamente.
Essa prática é excelente e favorece comunicação e aprendizado. Com essa troca
constante de ideias temos como resultado um Projeto de maior qualidade e como
estudos comprovam temos maior produtividade e maior qualidade (com padrão de
codificação e entendimento do código e partes do código que não eram
entendidos). Essa prática também facilita aprendizado dos novos integrantes.
Projeto
Simples: Projetos
flexíveis são considerados uma defesa contra mudanças imprevistas no software,
porém, projetos flexíveis também têm custos, tempo para desenvolvimento e
manutenção, além de um código mais complexo e que muitas vezes nunca será
utilizado.
O
XP preconiza que a mudança é barata, pois ele utiliza ciclos curtos, projetos
simples, refatorações, por isso mantém-se o projeto o mais simples possível,
modificando-o quando for necessário suportar mais funcionalidade. Portanto, o
XP diz que o melhor e mais simples projeto é aquele que passa em todos os
testes, não contém duplicação de funcionalidade, salienta as decisões de
projeto importantes e tem o menor número possível de classes e métodos.
Refatoração: A
refatoração significa melhorar o código sem alterar sua funcionalidade. Antes
de uma mudança sempre refatoramos o código para facilitar a realização de
mudanças. Ou seja, se após a refatoração o código continua funcionando como
anteriormente, incluímos as novas mudanças. A refatoração contínua possibilita
manter um bom projeto, apesar das mudanças frequentes. O Projeto é uma
atividade diária, de responsabilidade de todos.
Propriedade Coletiva: Todos podem
modificar o código a qualquer momento. Códigos não pertencem a apenas uma
pessoa. A melhor forma de evitarmos problemas como trocas de pessoas da equipe
e com isso a perda de conhecimento é a propriedade coletiva, onde todos mexem
em todas as partes do programa e conhecem de tudo um pouco.
Integração Contínua: Todo código deve
ser integrado diariamente e todos testes devem passar antes e depois da
integração. Se algum problema é encontra do ele deve ser corrigido
imediatamente.
Cliente presente: Clientes devem
estar presentes para escrevem testes de aceitação, definirem prioridades e
histórias para as futuras iterações.
Semana de 40 horas: O XP preconiza que
não se pode trabalhar horas extras por mais de uma semana, pois trabalho extra
é sintoma de que algo está errado. Devemos manter um ritmo sustentável.
Padrões de
Codificação:
Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares.
Assim é interessante mantermos um padrão para termos algo solidificado. Por
isso a melhor forma é a equipe definir um padrão de codificação sempre no início
dos projetos.
Nenhum comentário:
Postar um comentário