Críticas sobre Extreme
Programming
Francisco Hillesheim
Roteiro
► Extreme
Programming
► Principais Críticas
 Estudo de Caso: Empresa Canadas
► Conclusão
Extreme Programming
► Valores:




Simplicidade
Comunicação
Coragem
Feedback
Extreme Programming
► Características







Desenvolvimento incremental (Small releases)
Programação em pares
Refactoring
Design simples
Interação com o usuário final (Onsite Costumer)
Código coletivo
Escrever testes antes de implementar
Principais Críticas
► Várias
críticas são remetidas a XP
 Inovador
 Abordagem diferente com relação as
metodologias tradicionais
► Principais




Falta de documentação
Representante do cliente acoplado ao projeto
Programação em pares
TDD
Principais Críticas
► Falta
de documentação
 Dificulta o uso e a manutenção do código
 Muito centrado no código
►Dificuldade
de leitura
►Maior manutenção de código
 Alternativa
►Automatizar o processo de documentação
 Utilizando XML, por exemplo
 Estudo de caso
►Código
é documentado
►Alguns requisitos
Principais Críticas
► Representante
projeto
do cliente acoplado ao
 Dedicação 100% ao projeto
 Membros experientes dificilmente aceitariam tal
tarefa
 Grande dificuldade de encontrar um
representante
 Exemplo: Saída do representante no projeto C3
(Chrysler)
Principais Críticas
► Representante
projeto
do cliente acoplado ao
 Alternativa
►Definir
uma especificação de requisitos concisa
►Não precisa ser completa
 Estudo de caso
►Representante
do cliente é um membro da empresa
Principais Críticas
► Programação
em pares
 100% do tempo é exagero
 Programar sozinho favorece a criatividade
 Pode gerar aborrecimentos
►Programadores
de níveis diferentes
 Com relação a inspeção e revisão de código
►Existem
estudos mostrando que não há evidências
sobre a eficácia da programação em pares
Principais Críticas
► Programação
em pares
 Alternativa
►Utilizar
programação mútua
►Um programador garante a qualidade do software do
outro e vice-versa
 Estudo de caso
►Programação
em pares é utilizada na maioria das
vezes
►Útil na questão de treinamento (e também feedback)
Principais Críticas
► TDD
 Testes podem conter bugs
 Testes de unidade e aceitação
►Baixo
nível -> unidade
►Alto nível -> aceitação
►Lacuna entre os dois
 Automatização 100% dos testes é impraticável
►Testes
manuais ainda são necessários
►Maior esforço para criação de “small releases”
Principais Críticas
► TDD
 Alternativa
►Utilizar
não somente testes, mas também revisões e
inspeções do código modificado
 Estudo de caso
►Principal
desafio
►Testes são feitos manualmente e via JUnit
Conclusão
► XP
é um processo simbiótico
 Todas as práticas ou nada feito
 Requer disciplina
 Problemas:
►Quando
alguma prática não é bem realizada
►Efeito cascata