Programação Extrema (XP) Explicada – Acolha as mudanças - II

Seguem comentários da minha leitura do livro "Programação Extrema (XP) Explicada – Acolha as mudanças" do Kent Beck* - segunda parte.

SEÇÃO 2 – A SOLUÇÃO
São doze práticas interdependentes que acompanham o XP assim resumidas:

• O Jogo do Planejamento
• Um jogo de decisões entre a área de negócios e área técnica
• Decisões sobre:
• Negócios - Escopo, prioridade, composição das versões, datas de entrega
• Técnica - Estimativas, consequencias, processo, cronograma detalhada
• Consequencias está relacionada com os impactos de negócios ter escolhido, por exemplo, uma tecnologia específica.
• Entregas Freqüentes
• Metáfora
• Todo projeto é guiado por uma metáfora
• A metáfora fornece uma visão geral e simples do software
• Uma alternativa à arquitetura que também fornece uma visão geral mas técnica do software
• Projeto Simples
• Executa testes a qualquer momento
• Não tem lógica duplicada
• Expressão todas as intenções aos programadores
• Menor número possível de classes e métodos (cada parte justifica sua razão de existir)
• Testes
• Com o tempo o programa se torna cada vez mais confiável
• Testes apenas para o que pode falhar
• Refatoração
• Refatorar é simplificar mais ainda o código com os testes ainda executando
• Pós-teste
• Programação em Pares
• Dois papéis: um pensar melhor forma de implementar enquanto o outro pensa mais estrategicamente (outros casos de testes por exemplo)
• Dinâmica, numa manhã pode fazer par com um e na tarde com o outro
• A motivação pode ser a falta de conhecimento numa determinada tarefa, podendo fazer com quem conhece mais
• Propriedade Coletiva
• Integração Contínua
• No máximo em algumas horas de cada dia de desenvolvimento, os testes são integrados e executados
• Integrar uma parte das modificações de cada vez antecipa problemas e permite rastrear de forma mais ágil quem ou o quê gerou as falhas
• É preciso ter um ambiente de integração contínua: máquina e servidor dedicados
• Semana de 40 Horas
• Horas extras por mais de uma semana são o sintoma de um problema sério no projeto
• “Mas ninguém consegue agüentar 60 horas por semana durante muitas semanas, e ainda estar disposto, criativo, cuidadoso e confiante. Não fala isso.”
• Cliente Presente
• Um “cliente real” próximo da equipe de desenvolvimento para:
• Responder questões
• Resolver disputas
• Definir prioridades de menor escala
• Um “cliente real” é o futuro usuário do software
• Padrões de Codificação

As práticas são entrelaçadas: as fraquezas de uma prática são balanceadas com as forças de outra

• Programação em Pares
• Seria lenta se não houvesse:
• Padrões de Codificação – evita discussões mesquinhas;
• Semana de 40 Horas – evita conflitos pelo estresse;
• Testes (antes) – alinha os pensamentos antes da implementação;
• Metáfora;
• Projeto Simples.
• Quem programa sozinho sob pressão gera mais erros, retrabalho e desobedece as práticas
• Refatoração
• Seria difícil se não houvesse:
• Propriedade Coletiva
• Padrões de Codificação
• Programação em Pares
• Projeto (Design) Simples
• Testes
• Integração Contínua
• Semanas de 40 Horas

Estratégia de gerenciamento do projeto em XP é apoiada por:

• Métricas
• Basta apenas três ou quatro por vez
• Geralmente num mural
• Temporárias
• Qualquer métrica perto de 100% é inútil
• Devem incentivar a mudança
• Funções
• Treinador
• Procura desenvolver na equipe a maturidade para tomar e assumir decisões
• Auxilia novos, refatoração e testes
• Explica o processo
• Procura fazer reuniões com lanche e brinquedos
• Diminuir a tensão das reuniões
• Rastreador
• Mantém a memória das estimativas viva (útil)
• Torna real o aprendizado contínuo por meio dessa memória
• O tempo de rastreamento deve ser efetivo, mas sem aborrecer os programadores
• Intervenção
• Decisões impopulares às vezes são necessárias
• Tipos de decisões
• Saída de membro da equipe, porque não está funcionando
• Alteração do processo
• Matar o projeto

O processo não funciona se o ambiente de trabalho não tem:

• Espírito comunitário
• Lugar comum para relaxar

Programação em Pares

• Funciona se as pessoas se dão bem
• É necessário haver rotatividade
• No começo pode ser comum haver mais tutoria
• É um instrumento para melhorar a comunicação da equipe e não apenas o código!

XP é contra o hábito do programador antecipar soluções para o futuro. XP não é desenhar e depois implementar, mas iniciar e alinhar de forma incremental.

Estratégia de Projeto

• XP adota uma abordagem para reduzir o custo da mudança em produção diferente do tradicional
• “Se você sabe exatamente o que vai acontecer, e sabe exatamente como resolver isso, normalmente é melhor adicionar aquilo que você precisa agora e também que precisará mais tarde”.
• Estratégia tradicional é problemática
• Procura diminuir a probabilidade e o custo de refazer algo
• Razão: incerteza
• A funcionalidade antecipada nunca vai ser usada (o futuro nunca chega)
• Aprende-se uma melhor forma de fazer quando chegar o futuro
• Custosa
• Arcar com o custo de remover o excesso
• Arcar com o custo de manter uma complexidade que não agrega valor
• Entendimento
• “O segredo é que risco é dinheiro da mesma forma que tempo é dinheiro. (...) Se existe incerteza suficiente, o valor da opção de esperar é alto o suficiente para que seja melhor esperar.”.
• “Quando você acrescenta mais ao projeto hoje, você aumenta a sobrecarga do sistema. (...) Há mais coisas para testar, entender e explicar.”
• “Você também não consegue avaliar o custo de algo que acontecerá amanhã. (...) e a probabilidade (...)”.
• “Assim, o custo de tomar uma decisão de projeto hoje é igual ao custo de tomar a decisão somada aos juros que pagamos sobre esse custo mais a inércia que isso adicionar ao sistema”.
• “Os problemas de hoje já são suficientes”.
• Solução: estratégia de programação simples através dos seguintes passos
1. Crie o teste;
2. Projete e implemente o suficiente para o teste;
• Simplifique (refatore) quando ver a oportunidade.
3. Repita os passos 1 e 2.
• Não ignore os diagramas, mas precisam ser:
• Poucos
• Aos que sabem usá-los
• Descartáveis
• Diagrama é uma forma de comunicar assim como os casos de testes
• Testes são uma forma de comunicação viva

Testes

• Equipe XP possui um testador dedicado
• Tipos de testes
• Unidade
• Feito por programador
• Alto nível de intolerância: 100% ou nada
• Funcional
• Feito por cliente
• Focado em histórias
• Nível maleável de tolerância
• Paralelo
• Comparativo entre versões
• Estresse
• Macaco
• Verifica a reação com entradas sem sentido

* BECK, Kent. Programação Extrema (XP) Explicada – Acolha as mudanças. Porto Alegre: Bookman, 2004.