0
Extreme Programming<br />
Kent Beck<br />Criador do XP Programming e Test Driven Development<br />
Engenheiro de software<br />Popularizoucartões CRC e desenvolveu o JUnitjunto a Erich Gamma<br />Kent Beck<br />
Leva as práticas benéficas de outros modelos de desenvolvimento a níveis “extremos”, na teoria de que se algo é bom, mais ...
Metodologiaágilparaequipespequenas e médias.<br />Desenvolvimento de softwares com requisitosvagos e emconstantemudança.<b...
Codificar<br />Testar<br />Ouvir<br />Modelar<br />Atividades<br />
O único produto realmente importante do processo de desenvolvimento de software é o código. Sem o código, não há um produt...
Se alguns testes podem eliminar algumas falhas, muitos testes podem eliminar muitas falhas.<br />Testes de Unidade determi...
Programadoresdevemouvir o que o clienteprecisaque o sistemafaça.<br />Deve-se compreender as necessidades o suficientepara...
Um bom modelo evita várias dependências no sistema, de forma que alterar uma parte do sistema não afeta as outras.<br />Na...
Comunicação<br />Simplicidade<br />Feedback<br />Coragem<br />Respeito<br />Valores<br />
Passar a todososdesenvolvedoresumavisão do sistemaqueequivaleàvisão dos usuáriosfinais.<br />Designs simples<br />Metáfora...
Começar com a solução mais simples. Funcionalidades extras podem ser adicionadas depois.<br />Não investir em requisitos q...
Feedback do Sistema: testes de unidade, testes de integração. Feedback direto do estado do sistema.<br />Feedback do Clien...
Reestruturar o código quando necessário.<br />Revisar o sistema atual e modificá-lo para que futuras implementações sejam ...
Respeitopelos outros e peloprópriotrabalho.<br />Programadoresnuncadevemsubmeteralteraçõesquedeixam de compilar, fazem tes...
Jogo do planejamento: reuniãosemanal entre desenvolvedores e clienteemque se identificamprioridades e estimativaspara as f...
Teste de aceitação: testes construídospeloclienteparaaceitar um determinadorequisito de sistema.<br />Padrões de codificaç...
Programaçãoem pares:Duaspessoasprogramam juntas no mesmocomputador. Desta forma o códigosempreérevistoporduaspessoas, dimi...
Métodotãoeficientequanto as pessoasenvolvidas.<br />Necessitade de reuniõesfrequentes.<br />Podelevar a dificuldadescontra...
Upcoming SlideShare
Loading in...5
×

XP Programming

542

Published on

Visão geral da metodologia de desenvolvimento XP Programming feita pelo Trainee Artur de Azevedo no dia 19/05/2011

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
542
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "XP Programming"

  1. 1. Extreme Programming<br />
  2. 2. Kent Beck<br />Criador do XP Programming e Test Driven Development<br />
  3. 3. Engenheiro de software<br />Popularizoucartões CRC e desenvolveu o JUnitjunto a Erich Gamma<br />Kent Beck<br />
  4. 4. Leva as práticas benéficas de outros modelos de desenvolvimento a níveis “extremos”, na teoria de que se algo é bom, mais é melhor.<br />Programação Extrema<br />
  5. 5. Metodologiaágilparaequipespequenas e médias.<br />Desenvolvimento de softwares com requisitosvagos e emconstantemudança.<br />Constanteacompanhamento e realização de váriospequenosajustesdurante o desenvolvimento.<br />O Queé?<br />
  6. 6. Codificar<br />Testar<br />Ouvir<br />Modelar<br />Atividades<br />
  7. 7. O único produto realmente importante do processo de desenvolvimento de software é o código. Sem o código, não há um produto funcional.<br />Pode-se usar código para facilitar a comunicação: o código é sempre claro e conciso, não possibilitando ambiguidade.<br />Codificar<br />
  8. 8. Se alguns testes podem eliminar algumas falhas, muitos testes podem eliminar muitas falhas.<br />Testes de Unidade determinam se uma funcionalidade funciona como desejado.<br />Testes de aceitação determinam se os requisitos compreendidos pelos programadores satisfazem o cliente.<br />“Testathon”: evento em que programadores se juntam para desenvolver testes, como um “brainstorm de testes”.<br />Testar<br />
  9. 9. Programadoresdevemouvir o que o clienteprecisaque o sistemafaça.<br />Deve-se compreender as necessidades o suficienteparapassar um feedbacksobrecomopodemserresolvidas, ounãopodem.<br />Ouvir<br />
  10. 10. Um bom modelo evita várias dependências no sistema, de forma que alterar uma parte do sistema não afeta as outras.<br />Na teoria seria mais simples apenas codificar, mas após um certo ponto o sistema se torna muito complexo e suas dependências deixam de ser claras.<br />Modelar<br />
  11. 11. Comunicação<br />Simplicidade<br />Feedback<br />Coragem<br />Respeito<br />Valores<br />
  12. 12. Passar a todososdesenvolvedoresumavisão do sistemaqueequivaleàvisão dos usuáriosfinais.<br />Designs simples<br />Metáforascomuns<br />Colaboração de usuários e desenvolvedores<br />Comunicação verbal frequente.<br />Comunicação<br />
  13. 13. Começar com a solução mais simples. Funcionalidades extras podem ser adicionadas depois.<br />Não investir em requisitos que podem ser alterados antes de se tornarem relevantes.<br />Facilidade na Comunicação.<br />Simplicidade<br />
  14. 14. Feedback do Sistema: testes de unidade, testes de integração. Feedback direto do estado do sistema.<br />Feedback do Cliente: testes funcionais, de aceitação. O cliente pode direcionar o desenvolvimento.<br />Feedback da Equipe: novos requisitos, alteração nos requisitos. A equipe estima diretamente o tempo de implementação.<br />Feedback<br />
  15. 15. Reestruturar o código quando necessário.<br />Revisar o sistema atual e modificá-lo para que futuras implementações sejam mais simples.<br />Saber quando descartar código obsoleto, não importando o esforço de sua implementação.<br />Persistência! Pode-se perder um dia inteiro em um problema e resolvê-lo rapidamente no dia seguinte.<br />Coragem<br />
  16. 16. Respeitopelos outros e peloprópriotrabalho.<br />Programadoresnuncadevemsubmeteralteraçõesquedeixam de compilar, fazem testes de unidadeexistentesfalharemouatrasam de alguma forma o trabalho de outros.<br />Ninguémdeve se sentirignorado: alto nível de motivação e dedicaçãoaoprojeto.<br />Respeito<br />
  17. 17. Jogo do planejamento: reuniãosemanal entre desenvolvedores e clienteemque se identificamprioridades e estimativaspara as funcionalidades.<br />Reuniõesempé:reuniõessemanaisrápidasabordandotarefasrealizadas e tarefas a realizar.<br />Projeto simples:desenvolverestritamente o necessário, sem se preocuparemimplementarfuturasfuncionalidades antes do tempo.<br />Práticas<br />
  18. 18. Teste de aceitação: testes construídospeloclienteparaaceitar um determinadorequisito de sistema.<br />Padrões de codificação: a equipe de desenvolvimentodeveestabelecerregras de codificaçãoparatodososdesenvolvedores.<br />Integraçãocontínua:nuncaesperarparaintegrar a nova funcionalidadedesenvolvida, issosóaumenta a chance de conflitoouerro.<br />Práticas<br />
  19. 19. Programaçãoem pares:Duaspessoasprogramam juntas no mesmocomputador. Desta forma o códigosempreérevistoporduaspessoas, diminuindo a ocorrência de erros.<br />Práticas<br />
  20. 20. Métodotãoeficientequanto as pessoasenvolvidas.<br />Necessitade de reuniõesfrequentes.<br />Podelevar a dificuldadescontratuais.<br />Falta de documentaçãorobusta.<br />Críticas<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×