Upload
jaquelyn-porter
View
64
Download
0
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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