- 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.
Os desenvolvedores irão definir estimativas, consequências técnicas de adotar determinadas plataformas ou componentes (por exemplo, os programadores podem dizer que determinado componente dá muito problema e seria mais adequado utilizar um componente pago que economizará muito tempo), e por fim os desenvolvedores também ajudam no detalhamento de prazos para as atividades. Por fim, mantemos o plano atualizado sempre que houver um novo “toque de realidade” no projeto como algum imprevisto ou algo desejável que não contava-se que iria acontecer, ou qualquer outra coisa que possa afetar o plano atual. - Teste: é uma pratica bastante técnica, e envolve a
presença do cliente no desenvolvimento e na validação de testes. Cada
componente do sistema deve possuir testes de unidades, afim de se ter confiança
no comportamento do sistema, fazendo com que seja parte do próprio sistema.
Existem também casos em que os testes de unidades são desenvolvidos antes mesmo
do próprio código do trabalho real, também chamado de Test-Driven.
Teste automatizado é a prática que sustenta e viabiliza muitas outras práticas como Integração contínua, Projeto Simples, Versão Pequena, Refatoração, e Propriedade Coletiva. - Programação em pares: há literalmente uma programação em dupla, dois desenvolvedores utilizando-se de uma mesma máquina, ela tende a melhorar a qualidade do código produzido, mas sem afetar em sua velocidade de desenvolvimento. Outro fator, é que está prática tende a melhorar também a comunicação entre todos os membros da equipe, principalmente quando estes pares se alteram com frequência, ou todos os dias. Um dos critérios para definir os pares, não é só a sua disponibilidade, mas também deve ser levado em consideração a experiência de cada pessoa. Por exemplo, quando se necessita desenvolver algo que necessite da utilização de duas tecnologias, como interface Web e banco de dados, haverá dois integrantes, cada um experiente em uma área necessária.
- 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: 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. A refatoração provê um aumento contínuo de qualidade do código.
- 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. Estando sempre disponível afim de responder possíveis perguntas. Não importando o que venha a ocorrer com o projeto, nunca haverá para o cliente uma grande surpresa, se o mesmo estiver presente no desenvolvimento diariamente.
- Semana de 40 horas, é uma prática muito importante, pois deve-se respeitar o ritmo de trabalho que se pode sustentar, sem prejudicar os integrantes, no caso, 40 horas semanais. Uma equipe desgastada fisicamente e intelectualmente, possui grandes chances de produzir um software de baixa qualidade. Caso seja necessário fazer horas extras, essa condição é aceitável, contanto que não se torne uma rotina. Este pode ser um sinal de que pode haver algo errado com o projeto.
- 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. Tendo em vista esta questão, todos os integrantes possuirão a mesma visão diante do código. Isto permite que grupos de vários desenvolvedores, possam produzir um código consistente, e também facilita a sua devida comunicação.
- Metáfora: a sua função é melhorar a comunicação, tanto dentro da equipe, como para com o cliente. Uma linguagem comum que todos devem possuir. Por exemplo, ao invés de descrevermos como uma certa arquitetura funciona apenas comunicamos o seu nome e todos entendem o que um programador quis dizer.
- Reunião diária: é uma prática vinda do SCRUM em que todos fazem uma rápida reunião de pé para discutir o que foi feito no dia anterior, o que será feito no dia atual e se existe algum impedimento.
Fontes: http://www.desenvolvimentoagil.com.br/xp/praticas/
http://blog.locaweb.com.br/artigos/metodologias-ageis/programacao-extrema-extreme-programming-ou-simplesmente-xp/
https://www.devmedia.com.br/introducao-ao-extreme-programming-xp/29249
https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330
http://www.redspark.io/metodologias-parte-2-xp-extreme-programming/
Nenhum comentário:
Postar um comentário