Críticas sobre Críticas sobre Extreme Extreme

ProgrammingProgramming

Francisco HillesheimFrancisco Hillesheim

RoteiroRoteiro

►Extreme ProgrammingExtreme Programming►Principais CríticasPrincipais Críticas

Estudo de Caso: Empresa CanadasEstudo de Caso: Empresa Canadas

►ConclusãoConclusão

Extreme ProgrammingExtreme Programming

►Valores:Valores: SimplicidadeSimplicidade ComunicaçãoComunicação CoragemCoragem FeedbackFeedback

Extreme ProgrammingExtreme Programming

►CaracterísticasCaracterísticas Desenvolvimento incremental (Small releases)Desenvolvimento incremental (Small releases) Programação em paresProgramação em pares RefactoringRefactoring Design simplesDesign simples Interação com o usuário final (Onsite Interação com o usuário final (Onsite

Costumer)Costumer) Código coletivoCódigo coletivo Escrever testes antes de implementarEscrever testes antes de implementar

Principais Críticas Principais Críticas

►Várias críticas são remetidas a XPVárias críticas são remetidas a XP InovadorInovador Abordagem diferente com relação as Abordagem diferente com relação as

metodologias tradicionaismetodologias tradicionais►PrincipaisPrincipais

Falta de documentaçãoFalta de documentação Representante do cliente acoplado ao Representante do cliente acoplado ao

projetoprojeto Programação em paresProgramação em pares TDDTDD

Principais CríticasPrincipais Críticas

►Falta de documentaçãoFalta de documentação Dificulta o uso e a manutenção do códigoDificulta o uso e a manutenção do código Muito centrado no códigoMuito centrado no código

►Dificuldade de leituraDificuldade de leitura►Maior manutenção de códigoMaior manutenção de código

AlternativaAlternativa►Automatizar o processo de documentaçãoAutomatizar o processo de documentação

Utilizando XML, por exemploUtilizando XML, por exemplo

Estudo de casoEstudo de caso►Código é documentadoCódigo é documentado►Alguns requisitosAlguns requisitos

Principais CríticasPrincipais Críticas

►Representante do cliente acoplado ao Representante do cliente acoplado ao projetoprojeto Dedicação 100% ao projetoDedicação 100% ao projeto Membros experientes dificilmente Membros experientes dificilmente

aceitariam tal tarefaaceitariam tal tarefa Grande dificuldade de encontrar um Grande dificuldade de encontrar um

representanterepresentante Exemplo: Saída do representante no Exemplo: Saída do representante no

projeto C3 (Chrysler)projeto C3 (Chrysler)

Principais CríticasPrincipais Críticas

►Representante do cliente acoplado ao Representante do cliente acoplado ao projetoprojeto AlternativaAlternativa

►Definir uma especificação de requisitos Definir uma especificação de requisitos concisaconcisa

►Não precisa ser completaNão precisa ser completa

Estudo de casoEstudo de caso►Representante do cliente é um membro da Representante do cliente é um membro da

empresaempresa

Principais CríticasPrincipais Críticas

►Programação em paresProgramação em pares 100% do tempo é exagero100% do tempo é exagero Programar sozinho favorece a criatividadeProgramar sozinho favorece a criatividade Pode gerar aborrecimentosPode gerar aborrecimentos

►Programadores de níveis diferentesProgramadores de níveis diferentes

Com relação a inspeção e revisão de Com relação a inspeção e revisão de códigocódigo►Existem estudos mostrando que não há Existem estudos mostrando que não há

evidências sobre a eficácia da programação em evidências sobre a eficácia da programação em parespares

Principais CríticasPrincipais Críticas

►Programação em paresProgramação em pares AlternativaAlternativa

►Utilizar programação mútuaUtilizar programação mútua►Um programador garante a qualidade do Um programador garante a qualidade do

software do outro e vice-versasoftware do outro e vice-versa

Estudo de casoEstudo de caso►Programação em pares é utilizada na maioria Programação em pares é utilizada na maioria

das vezesdas vezes►Útil na questão de treinamento (e também Útil na questão de treinamento (e também

feedback)feedback)

Principais CríticasPrincipais Críticas

►TDDTDD Testes podem conter bugsTestes podem conter bugs Testes de unidade e aceitaçãoTestes de unidade e aceitação

►Baixo nível -> unidadeBaixo nível -> unidade►Alto nível -> aceitaçãoAlto nível -> aceitação►Lacuna entre os doisLacuna entre os dois

Automatização 100% dos testes é Automatização 100% dos testes é impraticávelimpraticável►Testes manuais ainda são necessáriosTestes manuais ainda são necessários►Maior esforço para criação de “small releases”Maior esforço para criação de “small releases”

Principais CríticasPrincipais Críticas

►TDDTDD AlternativaAlternativa

►Utilizar não somente testes, mas também Utilizar não somente testes, mas também revisões e inspeções do código modificadorevisões e inspeções do código modificado

Estudo de casoEstudo de caso►Principal desafioPrincipal desafio►Testes são feitos manualmente e via JUnit Testes são feitos manualmente e via JUnit

ConclusãoConclusão

►XP é um processo simbióticoXP é um processo simbiótico Todas as práticas ou nada feitoTodas as práticas ou nada feito Requer disciplinaRequer disciplina Problemas:Problemas:

►Quando alguma prática não é bem realizadaQuando alguma prática não é bem realizada►Efeito cascataEfeito cascata