Um pouco sobre o Método XP (Extreme Programming)
- É uma metodologia ágil para desenvolvimento de software;
- Leve e não prescritivo;
- Com foco na agilidade das equipes e na qualidade dos projetos;
- Recomendado para equipes pequenas e médias de até 12 pessoas;
- Indicado para desenvolvimento de software com requisitos vagos e em constante mudança;
- Desenvolvimento de sistemas orientados a objetos e incremental;
- A principal tarefa é a codificação;
- Necessário constante acompanhamento e realização de pequenos ajustes durante o desenvolvimento.
“Na hora do desenvolvimento do software, para aplicar os princípios e valores, o XP sugere uma série práticas porque há uma grande confiança na união entre elas pois os pontos fracos de cada uma são cobertos pelo ponto forte das outras.” (Vinícius Teles)
Valores
- Simplicidade — Conceito de simplificar e tentar não complicar, otimizando a codificação;
- Comunicação — A comunicação precisa ser muito clara, deve levar a informação correta para o público alvo;
- Feedback — Retornos constantes em relação ao time (profissionais);
- Coragem — Ambiente encorajador;
- Respeito — Ambiente respeitoso entre os membros do time.
Princípios
- Feedback rápido — Se existe a oportunidade para feedback, use;
- Presumir simplicidade — Codificar de forma simples;
- Mudanças incrementais — XP está aberto para mudanças no seu projeto;
- Abraçar mudanças — Aceitar as mudanças que chegam no seu projeto;
- Trabalho de alta qualidade — Realizar um trabalho que gera valor.
Práticas
Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas, essas são divididas em 3 grupos:
- Práticas organizacionais;
- Práticas de equipe;
- Práticas de pares.
Práticas Organizacionais
Equipe Inteira (Whole Team)
- É composto pelo cliente (customer), a equipe (desenvolvedores, analistas de negócios, equipe de qualidade) e coach/facilitador/gerente.
Jogos de Planejamento (Planning Games)
- Planejamento e priorização das entregas e releases (lançamentos para o usuário final);
- No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades, as estórias já devem estar criadas.
- Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem liberadas em produção.
Entregas Curtas (Small Releases)
- Liberação de pequenas versões (releases) em curtos períodos de tempo, é importante para obter-se feedback.
Testes de Usuário/Aceitação (Customer Tests)
- São testes construídos pelo cliente em conjunto com analistas e testadores, para aceitar o requisito do sistema.
Reuniões em pé (Stand-up Meeting)
- Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
Práticas de Equipe
Propriedade Coletiva (Colletive Code Ownership)
- O código não possui um dono ou responsável, toda a equipe pode trabalhar nele, sem necessidade de solicitar permissão.
Padronização de Código (Code Standards)
- Criar padronização de código para que todos possam ter o mesmo entendimento.
Ritmo Sustentável (Sustainable Pace)
- Trabalhar em ritmo sustentável (40 horas/semana, 8 horas/dia), evitando excesso de horas extras;
- Manter a equipe sempre motivada.
Metáfora (Metaphor)
- Criar metáforas para compartilhar designs e visão técnica. Facilitar a comunicação entre cliente e programadores (negócio x técnico).
Integração Contínua (Continuous Integration)
- Testes automatizados cada vez que um código é atualizado no repositório. Juntamente com a integração contínua das funcionalidades.
Práticas de Pares
Desenvolvimento Orientado a Teste (“TDD” Test-Driven Development)
- Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Os testes unitários são essenciais para que a qualidade do projeto seja mantida.
Refatoração (Refactoring)
- Refatorar o código melhorando a codificação existente sem alterar o comportamento da funcionalidade, permitindo a melhoria contínua da programação.
Design Simples (Simple Design)
- Focar na simplicidade. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples ao cliente. Código fácil deve ser identificado e substituído por código simples.
Programação em Par (Pair Programming)
- Enquanto uma pessoa escreve o código, a outra pessoa observa, comenta e fornece feedback. Esse conceito ajuda a disseminar e compartilhar o conhecimento. Além do sistema sempre ser revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos.
Papéis e funções
Cliente
- Escrever as estórias;
- Definir as prioridades;
- Definir o escopo (entrega) em acordo com os programadores.
Programadores
- Estima a duração das tarefas;
- Delega as tarefas internamente.
Gerente
- Fazer a mediação das interações externas;
- Formar a equipe;
- Obter os recursos necessários (reuniões, papel, entre outros);
- Gerenciar o time;
- Gerenciar problemas do time.
Já dizia o ditado…
- Se testar é bom, então, todos testem o tempo todo;
- Se revisão é bom, então, revisaremos o código o tempo todo;
- Se o projeto é bom, ele fará parte das funções diárias de todos;
- Se testes de integração é bom, então, que se integre o tempo todo;
- Se simplicidade é bom, desenvolva uma solução não apenas que funcione, mas que seja a mais simples possível;
- Se a arquitetura é importante, todo trabalham para definir e refinar a arquitetura;
- Se iterações curtas é bom, então mantenha-as realmente curtas.
Referências
CANAL TI. Extreme Programming (XP) — Programação Extrema. Acesso em Fev/19. Disponível em: https://www.youtube.com/watch?v=ALvpFMcL-dI
DEVMEDIA. Agile Development: XP e Scrum em uma Abordagem Comparativa. Acesso em Fev/19. Disponível em: https://www.devmedia.com.br/agile-development-xp-e-scrum-em-uma-abordagem-comparativa/30808
SITE CAMPUS. Aula 8-Método XP. Acesso em Fev/19.Disponível em https://sitecampus.com.br/aula/aula-8-metodo-xp/
