Grupo Pará
<ul><li>“ XP é a arte de maximizar a quantidade de software que você não vai fazer”  ImprovIT </li></ul><ul><li>“ XP   é u...
<ul><li>Comunicação </li></ul><ul><li>Simplicidade </li></ul><ul><li>Feedback </li></ul><ul><li>Coragem </li></ul>
<ul><li>Sincroniza o time em torno do mesmo objetivo </li></ul>
<ul><li>Práticas de comunicação </li></ul><ul><ul><li>Programação em par colocam as pessoas lado a lado sem individualismo...
<ul><li>Coisas simples são mais fáceis de entender, manter, construir em cima e, se for necessário, derrubar e refazer </l...
<ul><li>A tendência de software é o custo de mudança aumentar ao longo do tempo </li></ul>
<ul><li>A proposta é achatar essa curva </li></ul>
<ul><li>Itens complexos demoram. Você vai perder tempo em algo que não será usado? </li></ul>
<ul><li>Quanto antes você tiver feedback sobre uma situação, mais rápido você pode agir </li></ul>
<ul><li>Formas de feedback: </li></ul><ul><ul><li>Estimativa imediata do time para o cliente </li></ul></ul><ul><ul><li>Le...
<ul><li>“ Coragem é resistência ao medo, domínio do medo, e não ausência do medo.”  Mark Twain </li></ul>
<ul><li>Gerente de projetos </li></ul><ul><ul><li>Responsável pelo relacionamento entre equipe e cliente. Reporta o andame...
<ul><li>Gerente de projetos </li></ul><ul><ul><li>Deve compreender os valores e práticas da XP.  </li></ul></ul><ul><ul><l...
<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><li>Analista de testes </li></ul><ul><ul><li>Testa e garante a qualidade do sistema. </li></ul></ul><ul><ul><li>Ajuda ...
<ul><li>Redator técnico </li></ul><ul><ul><li>Mantém a documentação do sistema atualizada. </li></ul></ul><ul><ul><li>Evit...
<ul><li>Desenvolvedor </li></ul><ul><ul><li>Analisa, projeta, codifica. </li></ul></ul><ul><ul><li>Equipe multidisciplinar...
 
<ul><li>Sugere que os usuários finais sejam envolvidos diretamente no processo de desenvolvimento. </li></ul><ul><li>Vanta...
<ul><li>Melhor fazer pequenos lotes de trabalho de cada vez, validá-los e só então seguir adiante. </li></ul><ul><li>Quand...
<ul><li>O que fazer na próxima semana </li></ul><ul><li>Estórias ( cliente escreve ) </li></ul><ul><li>Estimativa </li></u...
Estórias ( Cliente escreve )
Estimativa
Seleção de estórias
Aguarde e confie...
 
Reuniões diárias
<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...
<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 imedi...
<ul><li>Um digita, outro revisa código, e os dois discutem soluções juntos. </li></ul><ul><li>Interpretação errada: uma pe...
<ul><li>Pressão do Par </li></ul><ul><ul><li>Minimiza focos de distração (bate papo, email, etc...). </li></ul></ul><ul><u...
<ul><li>Revezamento </li></ul><ul><ul><li>Fundamental. </li></ul></ul><ul><ul><li>Não há regra definida. </li></ul></ul><u...
<ul><li>Disseminação de Conhecimento </li></ul><ul><ul><li>Troca de par incentiva  disseminação  de conhecimento. </li></u...
<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 c...
<ul><li>Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o  mesmo tempo  que program...
<ul><li>Principais Desafios </li></ul><ul><ul><li>Exige que as pessoas envolvidas sejam  receptivas ,  compreensivas  umas...
<ul><li>Testar é a parte do desenvolvimento de software que todo mundo sabe que precisa ser feita, mas ninguém quer fazer....
<ul><li>ACEITE ISSO! </li></ul>
<ul><li>É possível fazer algo QUANDO os erros são detectados e diminuir QUANTO de impacto será causado no cronograma. </li...
<ul><li>Plano de saúde </li></ul><ul><li>Prevenir x Remediar </li></ul>
<ul><li>Prevenindo… </li></ul><ul><ul><li>Investimento monetário inicial </li></ul></ul><ul><ul><li>Benefícios a longo pra...
<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 .....
<ul><li>Testes expõem o defeito assim que ele entra no sistema. </li></ul><ul><li>Testes dizem exatamente ONDE está o erro...
<ul><li>TESTES DE UNIDADE - realizado em cada classe do sistema para verificar se o resultado gerado é correto. </li></ul>...
<ul><li>TESTES AUTOMATIZADOS - Classes que testam outras classes </li></ul>
<ul><li>Testes dão confiança ao time, pois diminuem o risco da mudança </li></ul>
<ul><li>Conceito </li></ul><ul><li>Porque Refatorar? </li></ul><ul><li>Quando Refatorar?  </li></ul><ul><li>Como Refatorar...
<ul><li>&quot;Refatoração é o processo de alteração  </li></ul><ul><li>de um sistema de software de modo que  </li></ul><u...
<ul><li>Conceito </li></ul><ul><ul><li>A Refatoração é utilizada após a implementação da funcionalidade, ou seja, depois q...
<ul><li>Por que refatorar? </li></ul><ul><ul><li>Mudança contínua de Requisitos </li></ul></ul><ul><ul><li>Refatorar melho...
<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><li>Como refatorar? </li></ul><ul><ul><li>O primeiro passo para Refatorar é criar um sólido conjunto de testes para o ...
<ul><li>Riscos e impedimentos </li></ul><ul><ul><li>Desenvolver códigos com erros </li></ul></ul><ul><ul><li>Sem metodolog...
<ul><li>Reflexão </li></ul><ul><ul><li>Se Refatorar me toma mais tempo, me dá mais trabalho, que a implementação da funcio...
<ul><li>Integrar e testar o sistema inteiro diversas vezes por dia. Ferramentas: SVN, TFS, etc </li></ul><ul><li>O build r...
<ul><li>Construir ideais para explicar outras ideias. </li></ul>
<ul><li>Documentar não é o Objetivo Principal. </li></ul><ul><li>Documenta-se o mínimo necessário antes. </li></ul><ul><li...
<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><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, r...
<ul><ul><li>Se simplicidade é bom, sempre deixaremos o sistema com o projeto mais que simples que suporte a funcionalidade...
<ul><li>[Beck 2004]  Kent Beck. Extreme Programming Explained. Addison- Wesley, 2004. </li></ul><ul><li>[Teles 2004]  Viní...
<ul><li>? </li></ul>
Upcoming SlideShare
Loading in …5
×

eXtreme Programming

4,023 views

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 - UNA - 03/09/2010

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

No Downloads
Views
Total views
4,023
On SlideShare
0
From Embeds
0
Number of Embeds
1,738
Actions
Shares
0
Downloads
112
Comments
0
Likes
1
Embeds 0
No embeds

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.
  • eXtreme Programming

    1. 1. Grupo Pará
    2. 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. 3. <ul><li>Comunicação </li></ul><ul><li>Simplicidade </li></ul><ul><li>Feedback </li></ul><ul><li>Coragem </li></ul>
    4. 4. <ul><li>Sincroniza o time em torno do mesmo objetivo </li></ul>
    5. 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. 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. 7. <ul><li>A tendência de software é o custo de mudança aumentar ao longo do tempo </li></ul>
    8. 8. <ul><li>A proposta é achatar essa curva </li></ul>
    9. 9. <ul><li>Itens complexos demoram. Você vai perder tempo em algo que não será usado? </li></ul>
    10. 10. <ul><li>Quanto antes você tiver feedback sobre uma situação, mais rápido você pode agir </li></ul>
    11. 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. 12. <ul><li>“ Coragem é resistência ao medo, domínio do medo, e não ausência do medo.” Mark Twain </li></ul>
    13. 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. 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. 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. 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. 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. 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>
    20. 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>
    21. 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>
    22. 23. Estórias ( Cliente escreve )
    23. 24. Estimativa
    24. 25. Seleção de estórias
    25. 26. Aguarde e confie...
    26. 28. Reuniões diárias
    27. 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>
    28. 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>
    29. 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>
    30. 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>
    31. 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>
    32. 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>
    33. 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>
    34. 36. <ul><li>Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores trabalhando sozinho. </li></ul>
    35. 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>
    36. 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>
    37. 39. <ul><li>ACEITE ISSO! </li></ul>
    38. 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>
    39. 41. <ul><li>Plano de saúde </li></ul><ul><li>Prevenir x Remediar </li></ul>
    40. 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>
    41. 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>
    42. 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>
    43. 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>
    44. 46. <ul><li>TESTES AUTOMATIZADOS - Classes que testam outras classes </li></ul>
    45. 47. <ul><li>Testes dão confiança ao time, pois diminuem o risco da mudança </li></ul>
    46. 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>
    47. 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>
    48. 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>
    49. 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>
    50. 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>
    51. 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>
    52. 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>
    53. 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>
    54. 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>
    55. 57. <ul><li>Construir ideais para explicar outras ideias. </li></ul>
    56. 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>
    57. 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>
    58. 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>
    59. 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>
    60. 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>
    61. 63. <ul><li>? </li></ul>

    ×