Your SlideShare is downloading. ×
0
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
eXtreme Programming
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

eXtreme Programming

3,771

Published on

eXtreme Programming - Apresentação do Grupo Pará na disciplina Métodos Ágeis de Desenvolvimento de Software (prof. Márcio Sete) da Pós-graduacao em engenharia de software centrada em métodos ágeis - …

eXtreme Programming - Apresentação do Grupo Pará na disciplina Métodos Ágeis de Desenvolvimento de Software (prof. Márcio Sete) da Pós-graduacao em engenharia de software centrada em métodos ágeis - UNA - 03/09/2010

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,771
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
108
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Se revisar código é bom, faremos o tempo inteiro (programação em par). Se testar é bom, vamos testar o tempo inteiro (testes unitários) e o cliente também (testes funcionais). Se um projeto eficiente é bom, será uma rotina (refatoração). XP como disciplina: é uma questão cultural.
  • Transcript

    • 1. Grupo Pará
    • 2. <ul><li>“ XP é a arte de maximizar a quantidade de software que você não vai fazer” ImprovIT </li></ul><ul><li>“ XP é um jeito leve, eficiente, de baixo risco, flexível, preditivo, científico e divertido de se desenvolver software” Kent Beck </li></ul><ul><li>“ XP é uma disciplina, porque existem coisas que você precisa fazer para dizer que está fazendo XP ” Kent Beck </li></ul>
    • 3. <ul><li>Comunicação </li></ul><ul><li>Simplicidade </li></ul><ul><li>Feedback </li></ul><ul><li>Coragem </li></ul>
    • 4. <ul><li>Sincroniza o time em torno do mesmo objetivo </li></ul>
    • 5. <ul><li>Práticas de comunicação </li></ul><ul><ul><li>Programação em par colocam as pessoas lado a lado sem individualismo </li></ul></ul><ul><ul><li>Testes unitários esclarecem os objetivos do código fonte </li></ul></ul><ul><ul><li>Estimativas envolvem programadores, gerentes e clientes </li></ul></ul>
    • 6. <ul><li>Coisas simples são mais fáceis de entender, manter, construir em cima e, se for necessário, derrubar e refazer </li></ul>
    • 7. <ul><li>A tendência de software é o custo de mudança aumentar ao longo do tempo </li></ul>
    • 8. <ul><li>A proposta é achatar essa curva </li></ul>
    • 9. <ul><li>Itens complexos demoram. Você vai perder tempo em algo que não será usado? </li></ul>
    • 10. <ul><li>Quanto antes você tiver feedback sobre uma situação, mais rápido você pode agir </li></ul>
    • 11. <ul><li>Formas de feedback: </li></ul><ul><ul><li>Estimativa imediata do time para o cliente </li></ul></ul><ul><ul><li>Leitura do código (pergunte ao sistema) </li></ul></ul><ul><ul><li>Testes unitários / TDD </li></ul></ul><ul><ul><li>Testes funcionais </li></ul></ul><ul><ul><li>Integração Contínua </li></ul></ul><ul><ul><li>Deploy Contínuo </li></ul></ul>
    • 12. <ul><li>“ Coragem é resistência ao medo, domínio do medo, e não ausência do medo.” Mark Twain </li></ul>
    • 13. <ul><li>Gerente de projetos </li></ul><ul><ul><li>Responsável pelo relacionamento entre equipe e cliente. Reporta o andamento, os problemas e os riscos. </li></ul></ul><ul><ul><li>Filtra para a equipe de desenvolvimento os aspectos administrativos e burocráticos. </li></ul></ul><ul><ul><li>Contatar clientes, agendar, garantir a presença do cliente; </li></ul></ul><ul><ul><li>Garantem à equipe: equipamentos, softwares, itens de escritório. </li></ul></ul>
    • 14. <ul><li>Gerente de projetos </li></ul><ul><ul><li>Deve compreender os valores e práticas da XP. </li></ul></ul><ul><ul><li>Mentalidade industrial representa ameaça ao projeto. (programação em par, equipe gerenciável. ritmo sustentável (40h/semana, industria: repetição, software: criatividade/esforço mental, cansaço)) </li></ul></ul><ul><ul><li>Desaconselháveis fazer com que uma pessoa assuma o papel de gerente e coach. proximidade: coach-equipe-tecnico, gerente=cliente=admin </li></ul></ul>
    • 15. <ul><li>Coach </li></ul><ul><ul><li>Assegura que a equipe respeita e utiliza os valores e práticas do XP. </li></ul></ul><ul><ul><li>Possui conhecimento técnico e do processo de desenvolvimento de software. </li></ul></ul><ul><ul><li>Sendo o XP voltado para o comportamento humano, o coach verifica o andamento e mostra eventuais erros. </li></ul></ul>
    • 16. <ul><li>Analista de testes </li></ul><ul><ul><li>Testa e garante a qualidade do sistema. </li></ul></ul><ul><ul><li>Ajuda o cliente a escrever testes de aceitação e que assegura que o sistema os respeite. </li></ul></ul><ul><ul><li>Não envolvido com o desenvolvimento. (Visão de fora, não da codificação.) </li></ul></ul>
    • 17. <ul><li>Redator técnico </li></ul><ul><ul><li>Mantém a documentação do sistema atualizada. </li></ul></ul><ul><ul><li>Evita envolver o desenvolvedor na documentação. </li></ul></ul><ul><ul><li>Sintonia com a equipe e cliente </li></ul></ul>
    • 18. <ul><li>Desenvolvedor </li></ul><ul><ul><li>Analisa, projeta, codifica. </li></ul></ul><ul><ul><li>Equipe multidisciplinar (membros exercem vários papéis em momentos diferentes do projeto). </li></ul></ul><ul><ul><li>Não existe aristocracia ou hierarquia. </li></ul></ul><ul><ul><li>Todos aprendem com todos (programação em par) </li></ul></ul>
    • 19.  
    • 20. <ul><li>Sugere que os usuários finais sejam envolvidos diretamente no processo de desenvolvimento. </li></ul><ul><li>Vantagens: </li></ul><ul><ul><li>Feedback rápido </li></ul></ul><ul><ul><li>Percepção se o que está implementado consegue ser usado facilmente pelos usuários finais. </li></ul></ul>
    • 21. <ul><li>Melhor fazer pequenos lotes de trabalho de cada vez, validá-los e só então seguir adiante. </li></ul><ul><li>Quando os erros são descobertos rapidamente e abrangem um escopo pequeno , solucionar torna-se mais fácil. </li></ul>
    • 22. <ul><li>O que fazer na próxima semana </li></ul><ul><li>Estórias ( cliente escreve ) </li></ul><ul><li>Estimativa </li></ul><ul><li>Seleção de cartões </li></ul><ul><li>Aguarde e confie </li></ul><ul><li>Reunião diária </li></ul>
    • 23. Estórias ( Cliente escreve )
    • 24. Estimativa
    • 25. Seleção de estórias
    • 26. Aguarde e confie...
    • 27.  
    • 28. Reuniões diárias
    • 29. <ul><li>Reunião diária </li></ul><ul><ul><li>Ocorre todos os dias, com todos os membros da equipe. </li></ul></ul><ul><ul><li>Objetiva,15 min, em pé. </li></ul></ul><ul><ul><li>O que cada um fez no dia anterior (equipe atualizada com o andamento do projeto) </li></ul></ul><ul><ul><li>O que será feito (quais cartões,quem faz o quê, decisões tomadas em equipe). </li></ul></ul>
    • 30. <ul><li>Une várias técnicas em uma só: </li></ul><ul><ul><li>Revisão de código </li></ul></ul><ul><ul><li>Correções imediatas </li></ul></ul><ul><ul><li>Evita acumulo de pequenos erros. </li></ul></ul><ul><ul><li>Melhor Modelagem da Solução </li></ul></ul><ul><li>Todo desenvolvimento feito em pares. </li></ul><ul><ul><li>Um computador, dois programadores. </li></ul></ul><ul><ul><li>Um piloto, um co-piloto </li></ul></ul><ul><ul><li>Papéis são alternados freqüentemente </li></ul></ul><ul><ul><li>Pares são trocados periodicamente </li></ul></ul>
    • 31. <ul><li>Um digita, outro revisa código, e os dois discutem soluções juntos. </li></ul><ul><li>Interpretação errada: uma pessoa trabalha, e a outra fica parada (desperdício). </li></ul>
    • 32. <ul><li>Pressão do Par </li></ul><ul><ul><li>Minimiza focos de distração (bate papo, email, etc...). </li></ul></ul><ul><ul><li>Responsabilidade compartilhada. </li></ul></ul>
    • 33. <ul><li>Revezamento </li></ul><ul><ul><li>Fundamental. </li></ul></ul><ul><ul><li>Não há regra definida. </li></ul></ul><ul><ul><li>Desenvolvedores sabem hora de trocar. </li></ul></ul>
    • 34. <ul><li>Disseminação de Conhecimento </li></ul><ul><ul><li>Troca de par incentiva disseminação de conhecimento. </li></ul></ul><ul><ul><li>Nivela equipe por alto . </li></ul></ul><ul><ul><li>Facilita inserção de novos membros. </li></ul></ul>
    • 35. <ul><li>Benefícios: </li></ul><ul><ul><li>Melhor qualidade do design, código e testes </li></ul></ul><ul><ul><li>Revisão constante do código </li></ul></ul><ul><ul><li>Nivelamento da equipe </li></ul></ul><ul><ul><li>Maior comunicação </li></ul></ul>
    • 36. <ul><li>Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores trabalhando sozinho. </li></ul>
    • 37. <ul><li>Principais Desafios </li></ul><ul><ul><li>Exige que as pessoas envolvidas sejam receptivas , compreensivas umas com as outras, engajadas e, sobretudo, humildes . </li></ul></ul><ul><ul><li>Organização física do escritório. </li></ul></ul><ul><ul><li>Visão Gerencial: desenvolvedores vistos como operários. </li></ul></ul>
    • 38. <ul><li>Testar é a parte do desenvolvimento de software que todo mundo sabe que precisa ser feita, mas ninguém quer fazer. </li></ul><ul><li>Software é complexo, erros são inevitáveis (natureza lógica, atenção, interpretação de requisitos). </li></ul>
    • 39. <ul><li>ACEITE ISSO! </li></ul>
    • 40. <ul><li>É possível fazer algo QUANDO os erros são detectados e diminuir QUANTO de impacto será causado no cronograma. </li></ul><ul><li>Diminuir o tempo entre uma ação e o feedback que ela gera é essencial para o aprendizado. </li></ul>
    • 41. <ul><li>Plano de saúde </li></ul><ul><li>Prevenir x Remediar </li></ul>
    • 42. <ul><li>Prevenindo… </li></ul><ul><ul><li>Investimento monetário inicial </li></ul></ul><ul><ul><li>Benefícios a longo prazo </li></ul></ul><ul><ul><li>Custo inferior comparado à necessidade de remediar em caso de fatalidade </li></ul></ul>
    • 43. <ul><li>Doenças = Bugs = Tempo de depuração </li></ul><ul><li>Aumento do custo </li></ul><ul><ul><li>(tempo de inserção ............. tempo de descoberta) </li></ul></ul>
    • 44. <ul><li>Testes expõem o defeito assim que ele entra no sistema. </li></ul><ul><li>Testes dizem exatamente ONDE está o erro. </li></ul>
    • 45. <ul><li>TESTES DE UNIDADE - realizado em cada classe do sistema para verificar se o resultado gerado é correto. </li></ul><ul><li>TESTE DE ACEITAÇÃO - realizado sobre cada funcionalidade, ou estórias do sistema. A interação entre várias classes que implementam uma funcionalidade. </li></ul>
    • 46. <ul><li>TESTES AUTOMATIZADOS - Classes que testam outras classes </li></ul>
    • 47. <ul><li>Testes dão confiança ao time, pois diminuem o risco da mudança </li></ul>
    • 48. <ul><li>Conceito </li></ul><ul><li>Porque Refatorar? </li></ul><ul><li>Quando Refatorar?  </li></ul><ul><li>Como Refatorar? </li></ul><ul><li>Riscos e impedimentos </li></ul><ul><li>Reflexão </li></ul>
    • 49. <ul><li>&quot;Refatoração é o processo de alteração  </li></ul><ul><li>de um sistema de software de modo que  </li></ul><ul><li>o comportamento externo do código  </li></ul><ul><li>não mude, mas que sua estrutura interna  </li></ul><ul><li>seja melhorada.&quot; </li></ul><ul><li>Vinícius Teles, citando ASTELS </li></ul>
    • 50. <ul><li>Conceito </li></ul><ul><ul><li>A Refatoração é utilizada após a implementação da funcionalidade, ou seja, depois que a função estiver sendo executada perfeitamente, usa-se a Refatoração. </li></ul></ul>
    • 51. <ul><li>Por que refatorar? </li></ul><ul><ul><li>Mudança contínua de Requisitos </li></ul></ul><ul><ul><li>Refatorar melhora o projeto do software </li></ul></ul><ul><ul><li>Torna o software mais fácil de entender </li></ul></ul><ul><ul><li>Ajuda a encontrar falhas </li></ul></ul><ul><ul><li>Ajuda a programar mais rapidamente  </li></ul></ul>
    • 52. <ul><li>Quando refatorar? </li></ul><ul><ul><li>Regra de três </li></ul></ul><ul><ul><li>Quando acrescentar funções </li></ul></ul><ul><ul><li>Quando existe duplicação </li></ul></ul><ul><ul><li>Quando precisar consertar uma falha </li></ul></ul><ul><ul><li>Enquanto revisa o código </li></ul></ul>
    • 53. <ul><li>Como refatorar? </li></ul><ul><ul><li>O primeiro passo para Refatorar é criar um sólido conjunto de testes para o  trecho de código. </li></ul></ul>
    • 54. <ul><li>Riscos e impedimentos </li></ul><ul><ul><li>Desenvolver códigos com erros </li></ul></ul><ul><ul><li>Sem metodologia de Refatoração o risco aumenta </li></ul></ul><ul><ul><li>Tempo: pode ocorrer atraso no término do produto </li></ul></ul><ul><ul><li>Gera custos </li></ul></ul>
    • 55. <ul><li>Reflexão </li></ul><ul><ul><li>Se Refatorar me toma mais tempo, me dá mais trabalho, que a implementação da funcionalidade em si, então porque Refatorar? </li></ul></ul><ul><li>Trabalhando desta maneira você se assegura que conseguirá adicionar uma próxima funcionalidade com menos esforço, e assim sucessivamente </li></ul>
    • 56. <ul><li>Integrar e testar o sistema inteiro diversas vezes por dia. Ferramentas: SVN, TFS, etc </li></ul><ul><li>O build rápido é uma prioridade. </li></ul><ul><li>Código coletivo. </li></ul>
    • 57. <ul><li>Construir ideais para explicar outras ideias. </li></ul>
    • 58. <ul><li>Documentar não é o Objetivo Principal. </li></ul><ul><li>Documenta-se o mínimo necessário antes. </li></ul><ul><li>A documentação mais abrangente acontece quando o código está pronto. </li></ul>
    • 59. <ul><li>Documentos que compõem a documentação: </li></ul><ul><ul><li>Estória. </li></ul></ul><ul><ul><li>Testes. </li></ul></ul><ul><ul><li>Javadoc </li></ul></ul><ul><ul><li>Diagramas de classe. – Rational Rose </li></ul></ul><ul><ul><li>Modelos de dados. </li></ul></ul><ul><ul><li>Manual do usuário. </li></ul></ul><ul><ul><li>UML. </li></ul></ul><ul><ul><li>Fotos. </li></ul></ul>
    • 60. <ul><li>XP leva princípios e práticas do senso comum a níveis extremos: </li></ul><ul><ul><li>Se revisar o código é bom, revisaremos o tempo inteiro (programação em par); </li></ul></ul><ul><ul><li>Se testar é bom, todos vão testar o tempo inteiro; </li></ul></ul><ul><ul><li>Se o projeto é bom, ele fará parte das funções diárias de todos (refatoração); </li></ul></ul>
    • 61. <ul><ul><li>Se simplicidade é bom, sempre deixaremos o sistema com o projeto mais que simples que suporte a funcionalidade atual; </li></ul></ul><ul><ul><li>Se testes de integração são importantes, vamos integrar e testar várias vezes ao dia; </li></ul></ul><ul><ul><li>Se iterações são boas, faremos iterações muito, muito pequenas - horas e semanas, não meses e anos; </li></ul></ul>
    • 62. <ul><li>[Beck 2004] Kent Beck. Extreme Programming Explained. Addison- Wesley, 2004. </li></ul><ul><li>[Teles 2004] Vinícius Manhães Teles. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. Novatec, 2004. </li></ul><ul><li>[Improve IT] http://improveit.com.br </li></ul>
    • 63. <ul><li>? </li></ul>

    ×