1 / 13

Críticas sobre Extreme Programming

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

jaquelyn-porter
Download Presentation

Críticas sobre Extreme Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Críticas sobre Extreme Programming Francisco Hillesheim

  2. Roteiro • Extreme Programming • Principais Críticas • Estudo de Caso: Empresa Canadas • Conclusão

  3. Extreme Programming • Valores: • Simplicidade • Comunicação • Coragem • Feedback

  4. 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

  5. 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

  6. 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

  7. Principais Críticas • Representante do cliente acoplado ao projeto • 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)

  8. Principais Críticas • Representante do cliente acoplado ao projeto • Alternativa • Definir uma especificação de requisitos concisa • Não precisa ser completa • Estudo de caso • Representante do cliente é um membro da empresa

  9. 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

  10. 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)

  11. 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”

  12. 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

  13. 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

More Related