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

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

INTRODUÇÃO
O livro é dividido em três seções:

• O Problema – trata do entendimento dos problemas envolvidos no desenvolvimento de software;
• A Solução – trata das práticas XP necessárias para resolver os problemas;
• Implementando a XP – trata de como usar as práticas.

SEÇÃO 1 – O PROBLEMA
Lista de riscos inerentes a todo desenvolvimento de software e abordagens que podem tratá-las:

• Deslizes no cronograma – ciclos curtos diminuem a extensão do deslize;
• Projeto cancelado – menor release com maior valor possível;
• Sistema “azedo” – testes a cada modificação;
• Azedo = Quando o custo, a manutenção e os bugs são maiores que o lucro.
• Alta taxa de erros – testes do programador e do cliente;
• Compreensão negativa – colaboração do cliente;
• Mudanças negativas – menor ciclo de release;
• Funções “pobres” – foco nas prioridades
• Pobre = Excitantes para o programador, mas que não geram dinheiro
• Rotatividade de pessoas – estimativas respeitadas e modelo de rotatividade da equipe

É importante pensar testes que falham e não que mostrem o óbvio.
XP é aplicado a requisitos vagos e instáveis.
Todo projeto de software precisa lidar com quatro variáveis interdependentes:

• Custo
• Tempo
• Qualidade
• Começar pelos testes vai gerar uma maior qualidade interna, que a longo prazo gera uma qualidade externa, caso contrário, “sacrificar temporariamente a qualidade interna para reduzir o tempo de entrega (...) é uma jogada de curto prazo tentadora (...)  mas, no final, farão o seu software extremamente caro de ser mantido, ou incapaz de alcançar um nível competitivo de qualidade externa”.
• Qualidade interna é mensurada pelos programadores.
• Qualidade externa é mensurada pelo cliente.
• Escopo
• XP lida com escopo maleável que gera oportunidade e não problema através de duas estratégias
• Feedback de estimativas;
• Implementação focada em prioridades.

Há um custo para a mudança do software em produção:

• Tradicionalmente o custo da mudança aumenta exponencialmente com o tempo.
• No XP esse aumento é achatado, porque o código é fácil de modificar.
• Fatores
• Projeto simples
• Testes automatizados
• Muito prática de modificar o sistema (refactoring)
• Código difícil de modificar é acompanhado de medo e da falta de testes para verificar se houve efeito colateral

Mudança é uma constante, o problema é a falta de habilidade.

XP trabalha com quatro valores e um inerente a esses:

• Comunicação
• Maioria dos problemas no projeto está relacionada com comunicação.
• Alcançada com práticas como testes de unidade, programação em pares e estimativas.
• Participação do treinador.
• Simplicidade
• Normalmente programador tem dificuldade de fazer a coisa mais simples que funcione e procura antecipar coisas pelo medo do custo exponencial das modificações.
• Participação do treinador.
• Feedback
• Alcançada com o rastreador, com testes unitários (em minutos/dias) e funcionais (em semanas/meses) e com ciclos curtos de entrega.
• Participação do treinador.
• Coragem
• Coragem de mudar, refatorar, simplificar e corrigir mesmo em momento críticos!
• Participação do treinador.
• Combinada com os outros valores é extremamente importante
• Comunicação fornece o que precisa ser modificado
• Feedback fornece a segurança para alterar
• Respeito
• “Se os membros do time não se importarem uns com os outros e com o que eles estão fazendo, a XP estará condenada. (...) A XP é mais sensível a isso”.

A partir de valores abstratos, a XP trabalha com os seguintes princípios fundamentais:

• Feedback rápido – por meio do aprendizado contínuo;
• Simplicidade presumida – por meio do foco no problema, não no reuso nem no futuro;
• Mudanças incrementais – mudanças aplicadas aos poucos e não em paralelo;
• Aceitação das mudanças
• Alta qualidade

Alguns dos outros princípios menos fundamentais

• Experimentação concreta
• “Toda decisão abstrata deve ser testada” com uma “série de experimentos” relacionados a uma decisão de projeto (design).
• Viajar com pouca bagagem
• Os artefatos precisam ser poucos, simples e valiosos.
• Métricas genuínas
• Evitar um nível de detalhamento que não é suportado pelos nossos instrumentos. É mais interessante falar que vai atrasar mais ou menos duas semanas do que 14.17 horas.
• “Linhas de código, por exemplo, são uma métrica inútil (...) quando aprendemos melhores formas de programar”.

As seguintes atividades são básicas no XP

• Codificar
• Testar
• Melhora a confiança, a sanidade do código e a produtividade.
• “Os testes me dão a chance de pensar sobre o que eu quero independentemente da implementação. Assim, os testes me dizem se eu implementei aquilo que eu pensei ter implementado”.
• Ouvir
• Entender melhor as necessidades do cliente evita o problema de construir a coisa errada (o software) mesmo usando a coisa certa (o processo).
• Projetar (Design)
• O bom projeto (design) permite as mudanças sem efeitos colaterais.
• Complexidade é fonte de projeto ruim.

“Infectado por testes”

• Expressão cunhada por Erich Gamma para aquelas pessoas que não escrevem código se não tiver um teste.
• Testes automatizados não são essenciais, mas necessários em:
• Longo prazo
• Mantêm o programa vivo, SE os testes são executados e mantidos;
• Mas não há argumentos fortes para escrever testes pensando em longo prazo (é trabalhar contra a natureza humana). “Algumas pessoas escreveriam testes por obrigação ou porque alguém está as observando.”
• Curto prazo
• A motivação para escrever testes é programar com confiança e de forma divertida.
• Programar e testar ao mesmo tempo é mais rápido do que apenas programar.
• O ganho vem da redução na depuração.
• Os testes podem ser uma armadilha quando se procura associar 100% de testes passados com ausência total de bugs, apesar do número bem reduzido de falhas em produção. É preciso trabalhar com um nível de erros tolerável.

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