Crticas sobre Extreme Programming Francisco Hillesheim Roteiro Extreme

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 C 3 (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