Extreme Programming Abrace a mudança!
Extreme Programming Juan di Carlo Damasceno Maurício Linhares
Manifesto Ágil Organizando a bagunça e as idéias
Princípios <ul><li>Indivíduos e interações  mais que processos e ferramentas </li></ul><ul><li>Software funcional  mais qu...
Chrysler C3 Nascimento do XP
Onde – Quando - Como <ul><li>Chrysler </li></ul><ul><li>Março de 1996 </li></ul><ul><li>Projeto C3 (Chrysler Comprehensive...
Dirigir “ Dirigir não é colocar o carro na direção certa, é manter uma atenção constante e corrigir sempre que necessário”...
Isso é XP! <ul><li>Prestar atenção </li></ul><ul><li>Adaptar </li></ul><ul><li>Mudar </li></ul>
A mudança é um problema? <ul><li>Requerimentos mudam </li></ul><ul><li>Modelos mudam </li></ul><ul><li>Negócios mudam </li...
Tudo muda! A mudança não é um problema, é uma realidade
Então, qual o problema? Lidar com a mudança!
O que é XP? <ul><li>São ciclos curtos de desenvolvimento; </li></ul><ul><li>É o planejamento incremental e baseado no conh...
O que é XP? <ul><li>É confiança na comunicação oral, testes automáticos e código para “falar” sobre o projeto; </li></ul><...
Ciclo básico de um projeto XP <ul><li>Planning Game (normalmente uma manhã no primeiro dia da semana) </li></ul><ul><ul><l...
Ciclo contínuo Modelagem Testes Planejamento Codificação
Só isso? Como é que pode? Como é que eles conseguem fazer o  Eclipse, Hibernate, MyFaces e Spring  desse jeito?
As bases do XP
Valores “ O que lhe traz problemas não é o que você não sabe, mas o que você acha que sabe e não sabe” Will Rogers
Comunicação <ul><li>Ninguém sabe tudo </li></ul><ul><li>Times só trabalham juntos quando se comunicam juntos </li></ul><ul...
Simplicidade <ul><li>Qual a coisa mais simples que poderia funcionar? </li></ul><ul><li>Simples não é simplista </li></ul>...
Feedback <ul><li>Direções mudam </li></ul><ul><li>Não é possível fazer certo “de primeira” (ou é?) </li></ul><ul><li>Feedb...
Coragem <ul><li>Heróis (burros) morrem cedo </li></ul><ul><li>É controlar o medo </li></ul><ul><li>É tomar a decisão quand...
Respeito <ul><li>Goste do que você faz </li></ul><ul><li>Goste das pessoas com as quais você trabalha </li></ul><ul><li>Go...
Outros? O que as pessoas ao seu redor valorizam?
Princípios Guiando o comportamento
Humanidade <ul><li>Pessoas... </li></ul><ul><ul><li>produzem software </li></ul></ul><ul><ul><li>tem necessidades próprias...
Economia <ul><li>Software não é de graça </li></ul><ul><li>Sucesso tecnológico nem sempre é sucesso econômico </li></ul><u...
Benefício Mútuo <ul><li>Se algo não é bom pra um dos lados, não é bom pra ninguém </li></ul><ul><li>Ganhar-Ganhar-Ganhar é...
Auto-Similaridade <ul><li>Tem algo funcionando lá embaixo? Faça o mesmo aqui em cima! </li></ul><ul><li>Soluções únicas nã...
Evolução <ul><li>“Excelência não é um modo de agir, mas um hábito” – Aristóteles </li></ul><ul><li>Faça o melhor possível ...
Diversidade <ul><li>Times homogêneos sobem e descem juntos </li></ul><ul><li>Pessoas diferentes com experiências diferente...
Reflexão <ul><li>Analisar </li></ul><ul><li>Porque? </li></ul><ul><li>Analisar </li></ul><ul><li>Como? </li></ul><ul><li>A...
Fluxo <ul><li>Não somos fábricas... </li></ul><ul><li>...mas o fluxo não pode ser descontínuo demais </li></ul><ul><li>Int...
Oportunidade <ul><li>Problemas como chances de mudar </li></ul><ul><li>“ Sobreviver” não é o suficiente </li></ul><ul><li>...
Redundancia <ul><li>“Como é que é? Não tem plano B?” </li></ul><ul><li>Existem várias maneiras de se resolver um único pro...
Falhar <ul><li>Não funciona? Jogue fora! </li></ul><ul><li>Tá “mais ou menos”? Jogue fora! </li></ul><ul><li>Fugir da falh...
Qualidade <ul><li>Menos qualidade não quer dizer menos tempo </li></ul><ul><li>Mais qualidade não quer dizer mais tempo </...
Passos de bebê <ul><li>Cuidado pra não tropeçar </li></ul><ul><li>Quanto maior a altura, pior a queda </li></ul><ul><li>Um...
Aceitar Responsabilidade <ul><li>Não está seguro pra fazer?  Diga que não faz </li></ul><ul><li>Não sabe se a pessoa pode ...
Práticas Luz! Câmeras! Ação!
Todo mundo junto Time junto, todo no mesmo lugar, todos escutando uns aos outros
Time Completo Somos uma família
Espaço informativo <ul><li>Quem está alocado em qual projeto? </li></ul><ul><li>Qual é a minha estória? </li></ul><ul><li>...
Trabalho energizado <ul><li>Nada de horas extras </li></ul><ul><li>Nada de matar o fim de semana </li></ul><ul><li>Nada de...
Programação em Par <ul><li>Duas cabeças pensam melhor que uma </li></ul><ul><li>O código é de todos... </li></ul><ul><li>....
Estórias <ul><li>Deixe o cliente definir </li></ul><ul><li>Simples e diretas, ele não deve saber nem definir implementação...
Cartão de estória
Ciclo semanal <ul><li>Planejar o trabalho para apenas uma semana; </li></ul><ul><li>Quando menor o tamanho do ciclo: </li>...
Ciclo mensal (ou de 4 semanas) <ul><li>Definição de rumos de um projeto; </li></ul><ul><li>Manter foco na implementação do...
Ócio <ul><li>É, isso mesmo que você viu aí em cima; </li></ul><ul><li>Não, ninguém tem que trabalhar o dia todo (nem ningu...
O mais famoso produto do ócio de um programador
Build em 10 minutos <ul><li>Se o seu projeto demora mais do que 10 minutos pra terminar o build, tá na hora de ajeitar iss...
Integração contínua <ul><li>Todo dia, todo turno, toda hora, o sistema deve estar funcional e executando; </li></ul><ul><l...
Teste primeiro – Programe depois <ul><li>Primeiro se escreve o teste; </li></ul><ul><li>Depois se implementa a funcionalid...
Modelagem incremental <ul><li>Ninguém conhece o modelo todo antes de começar a implementar; </li></ul><ul><li>A implementa...
Um time XP Escalando a seleção
Papéis <ul><li>Testadores </li></ul><ul><li>Desenvolvedores de interações </li></ul><ul><li>Arquitetos </li></ul><ul><li>G...
Mundo perfeito Quando não usar XP?
Quando não usar XP? <ul><li>Quando as pessoas não querem mudar; </li></ul><ul><li>Quando o cliente quer a análise toda ant...
Quando não usar XP? <ul><li>Quando os testes automáticos não são fáceis ou até mesmo possíveis de serem feitos; </li></ul>...
“ There’s no silver bullet” Frederick P. Brooks
Conclusão <ul><li>XP não é fácil de aplicar em ambientes que resistem a mudanças; </li></ul><ul><li>É provavelmente um dos...
Conclusão <ul><li>É foco no que é interessante para quem paga, não para quem recebe; </li></ul><ul><li>É valorizar as pess...
Referências <ul><li>Extreme Programming Explained: Embrace Change, Second Edition.  Kent Beck, Cynthia Andres. Addisson We...
Referências <ul><li>eXtreme Programming ->  http://www.extremeprogramming.org/ </li></ul><ul><li>Eclipse Project ->  http:...
Upcoming SlideShare
Loading in …5
×

Extreme Programming Explicada

2,011 views
1,903 views

Published on

Apresentação sobre Extreme Programming.;

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

No Downloads
Views
Total views
2,011
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
83
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Extreme Programming Explicada

  1. 1. Extreme Programming Abrace a mudança!
  2. 2. Extreme Programming Juan di Carlo Damasceno Maurício Linhares
  3. 3. Manifesto Ágil Organizando a bagunça e as idéias
  4. 4. Princípios <ul><li>Indivíduos e interações mais que processos e ferramentas </li></ul><ul><li>Software funcional mais que extensa documentação </li></ul><ul><li>Colaboração com o cliente mais que negociação de contratos </li></ul><ul><li>Responder à mudança mais que seguir um plano </li></ul>
  5. 5. Chrysler C3 Nascimento do XP
  6. 6. Onde – Quando - Como <ul><li>Chrysler </li></ul><ul><li>Março de 1996 </li></ul><ul><li>Projeto C3 (Chrysler Comprehensive Compensation) </li></ul>
  7. 7. Dirigir “ Dirigir não é colocar o carro na direção certa, é manter uma atenção constante e corrigir sempre que necessário” Mãe do Kent Beck
  8. 8. Isso é XP! <ul><li>Prestar atenção </li></ul><ul><li>Adaptar </li></ul><ul><li>Mudar </li></ul>
  9. 9. A mudança é um problema? <ul><li>Requerimentos mudam </li></ul><ul><li>Modelos mudam </li></ul><ul><li>Negócios mudam </li></ul><ul><li>Tecnologias mudam </li></ul><ul><li>Times mudam </li></ul><ul><li>Membros do time mudam </li></ul>
  10. 10. Tudo muda! A mudança não é um problema, é uma realidade
  11. 11. Então, qual o problema? Lidar com a mudança!
  12. 12. O que é XP? <ul><li>São ciclos curtos de desenvolvimento; </li></ul><ul><li>É o planejamento incremental e baseado no conhecimento atual; </li></ul><ul><li>É a habilidade de flexibilizar os prazos para entrega de implementações; </li></ul><ul><li>É apoiar-se em testes automatizados para fazer mudanças; </li></ul>
  13. 13. O que é XP? <ul><li>É confiança na comunicação oral, testes automáticos e código para “falar” sobre o projeto; </li></ul><ul><li>É se basear em uma modelagem evolucionária que abraça a mudança; </li></ul><ul><li>É apoiar a colaboração constante das pessoas envolvidas; </li></ul><ul><li>É basear-se em práticas que funcionam no curto e no longo prazo; </li></ul>
  14. 14. Ciclo básico de um projeto XP <ul><li>Planning Game (normalmente uma manhã no primeiro dia da semana) </li></ul><ul><ul><li>Definir as estórias </li></ul></ul><ul><ul><li>Definir prioridades </li></ul></ul><ul><ul><li>Pontuar histórias </li></ul></ul><ul><li>Definir quem vai implementar o que </li></ul><ul><li>Implementar </li></ul><ul><li>Entregar a estória implementada </li></ul><ul><li>Tudo outra vez até o projeto acabar </li></ul>
  15. 15. Ciclo contínuo Modelagem Testes Planejamento Codificação
  16. 16. Só isso? Como é que pode? Como é que eles conseguem fazer o Eclipse, Hibernate, MyFaces e Spring desse jeito?
  17. 17. As bases do XP
  18. 18. Valores “ O que lhe traz problemas não é o que você não sabe, mas o que você acha que sabe e não sabe” Will Rogers
  19. 19. Comunicação <ul><li>Ninguém sabe tudo </li></ul><ul><li>Times só trabalham juntos quando se comunicam juntos </li></ul><ul><li>Comunicação eficiente é a que melhor serve ao time no momento </li></ul>
  20. 20. Simplicidade <ul><li>Qual a coisa mais simples que poderia funcionar? </li></ul><ul><li>Simples não é simplista </li></ul><ul><li>Simplicidade depende do contexto (qual o nível do time?) </li></ul>
  21. 21. Feedback <ul><li>Direções mudam </li></ul><ul><li>Não é possível fazer certo “de primeira” (ou é?) </li></ul><ul><li>Feedback demais também não é bom </li></ul>
  22. 22. Coragem <ul><li>Heróis (burros) morrem cedo </li></ul><ul><li>É controlar o medo </li></ul><ul><li>É tomar a decisão quando ela deve ser tomada </li></ul><ul><li>É não se esconder atrás de uma pilha de papéis ou documentos assinados </li></ul>
  23. 23. Respeito <ul><li>Goste do que você faz </li></ul><ul><li>Goste das pessoas com as quais você trabalha </li></ul><ul><li>Goste do lugar aonde você trabalha </li></ul><ul><li>“Eu sou importante, assim como você” </li></ul>
  24. 24. Outros? O que as pessoas ao seu redor valorizam?
  25. 25. Princípios Guiando o comportamento
  26. 26. Humanidade <ul><li>Pessoas... </li></ul><ul><ul><li>produzem software </li></ul></ul><ul><ul><li>tem necessidades próprias </li></ul></ul><ul><ul><li>devem ser respeitadas </li></ul></ul><ul><ul><li>devem se sentir seguras </li></ul></ul><ul><ul><li>devem se sentir importantes </li></ul></ul>
  27. 27. Economia <ul><li>Software não é de graça </li></ul><ul><li>Sucesso tecnológico nem sempre é sucesso econômico </li></ul><ul><li>Software que não oferece valor para o cliente, não vale os recursos que consumiu </li></ul><ul><li>Primeiro o mais importante economicamente, depois o resto </li></ul>
  28. 28. Benefício Mútuo <ul><li>Se algo não é bom pra um dos lados, não é bom pra ninguém </li></ul><ul><li>Ganhar-Ganhar-Ganhar é a ordem </li></ul><ul><li>Esforços desnecessários não são toleráveis </li></ul>
  29. 29. Auto-Similaridade <ul><li>Tem algo funcionando lá embaixo? Faça o mesmo aqui em cima! </li></ul><ul><li>Soluções únicas não são ruins, mas normalmente são incomuns </li></ul>
  30. 30. Evolução <ul><li>“Excelência não é um modo de agir, mas um hábito” – Aristóteles </li></ul><ul><li>Faça o melhor possível hoje </li></ul><ul><li>Não existe processo perfeito </li></ul><ul><li>Tudo deve evoluir </li></ul>
  31. 31. Diversidade <ul><li>Times homogêneos sobem e descem juntos </li></ul><ul><li>Pessoas diferentes com experiências diferentes se completam </li></ul><ul><li>Já imaginou time de futebol só de atacantes? </li></ul>
  32. 32. Reflexão <ul><li>Analisar </li></ul><ul><li>Porque? </li></ul><ul><li>Analisar </li></ul><ul><li>Como? </li></ul><ul><li>Analisar </li></ul><ul><li>Reflexão vem após a ação </li></ul><ul><li>Aprender é refletir sobre a ação </li></ul>
  33. 33. Fluxo <ul><li>Não somos fábricas... </li></ul><ul><li>...mas o fluxo não pode ser descontínuo demais </li></ul><ul><li>Integração contínua é a lei </li></ul>
  34. 34. Oportunidade <ul><li>Problemas como chances de mudar </li></ul><ul><li>“ Sobreviver” não é o suficiente </li></ul><ul><li>Não aprender hoje é tirar nota baixa amanhã outra vez </li></ul><ul><li>Não esqueça Murphy ! </li></ul>
  35. 35. Redundancia <ul><li>“Como é que é? Não tem plano B?” </li></ul><ul><li>Existem várias maneiras de se resolver um único problema, porque não tentar elas? </li></ul><ul><li>Remover redundância apenas quando ela realmente não servir pra nada </li></ul>
  36. 36. Falhar <ul><li>Não funciona? Jogue fora! </li></ul><ul><li>Tá “mais ou menos”? Jogue fora! </li></ul><ul><li>Fugir da falha hoje é pedir pra fugir ainda mais quando o cliente ligar reclamando amanhã </li></ul>
  37. 37. Qualidade <ul><li>Menos qualidade não quer dizer menos tempo </li></ul><ul><li>Mais qualidade não quer dizer mais tempo </li></ul><ul><li>Mais qualidade – Menos bugs – Mais clientes – Mais $$$$ </li></ul>
  38. 38. Passos de bebê <ul><li>Cuidado pra não tropeçar </li></ul><ul><li>Quanto maior a altura, pior a queda </li></ul><ul><li>Um passo de cada vez, mas também não precisa se arrastar </li></ul>
  39. 39. Aceitar Responsabilidade <ul><li>Não está seguro pra fazer? Diga que não faz </li></ul><ul><li>Não sabe se a pessoa pode fazer? Não mande ela fazer </li></ul><ul><li>Não tem ninguém aqui que sabe? Encontre alguém fora que saiba! </li></ul><ul><li>Responsabilidade é aceita, não obrigada </li></ul>
  40. 40. Práticas Luz! Câmeras! Ação!
  41. 41. Todo mundo junto Time junto, todo no mesmo lugar, todos escutando uns aos outros
  42. 42. Time Completo Somos uma família
  43. 43. Espaço informativo <ul><li>Quem está alocado em qual projeto? </li></ul><ul><li>Qual é a minha estória? </li></ul><ul><li>O que foi que eu já fiz? </li></ul><ul><li>O que foi que meu par já fez? </li></ul><ul><li>O que ainda falta fazer? </li></ul>
  44. 44. Trabalho energizado <ul><li>Nada de horas extras </li></ul><ul><li>Nada de matar o fim de semana </li></ul><ul><li>Nada de matar o happy-hour </li></ul><ul><li>Nade de ficar sem CS na quinta à noite </li></ul><ul><li>Pessoas cansadas e sem motivação não produzem, enrolam </li></ul>
  45. 45. Programação em Par <ul><li>Duas cabeças pensam melhor que uma </li></ul><ul><li>O código é de todos... </li></ul><ul><li>...e o conhecimento também </li></ul>
  46. 46. Estórias <ul><li>Deixe o cliente definir </li></ul><ul><li>Simples e diretas, ele não deve saber nem definir implementação </li></ul><ul><li>Não entendeu? Pergunte a ele denovo! </li></ul><ul><li>Estória grande? Quebre-a em tarefas! </li></ul>
  47. 47. Cartão de estória
  48. 48. Ciclo semanal <ul><li>Planejar o trabalho para apenas uma semana; </li></ul><ul><li>Quando menor o tamanho do ciclo: </li></ul><ul><ul><li>Mais fácil planejar; </li></ul></ul><ul><ul><li>Mais fácil se manter no prazo; </li></ul></ul><ul><ul><li>Mais fácil de se ter feedback do cliente; </li></ul></ul>
  49. 49. Ciclo mensal (ou de 4 semanas) <ul><li>Definição de rumos de um projeto; </li></ul><ul><li>Manter foco na implementação do que é interessante para o cliente; </li></ul><ul><li>Muitas falhas? </li></ul><ul><li>Muitos problemas? </li></ul><ul><li>Hora de arrumar a casa; </li></ul>
  50. 50. Ócio <ul><li>É, isso mesmo que você viu aí em cima; </li></ul><ul><li>Não, ninguém tem que trabalhar o dia todo (nem ninguém trabalha, diga-se de passagem); </li></ul><ul><li>Ócio não quer dizer não trabalhar, mas ter tempo pra fazer alguma coisa diferente; </li></ul>
  51. 51. O mais famoso produto do ócio de um programador
  52. 52. Build em 10 minutos <ul><li>Se o seu projeto demora mais do que 10 minutos pra terminar o build, tá na hora de ajeitar isso; </li></ul><ul><li>Qual programador gosta de apertar um botão ter que esperar mais do que 10 minutos pra poder testar o que acabou de desenvolver? </li></ul>
  53. 53. Integração contínua <ul><li>Todo dia, todo turno, toda hora, o sistema deve estar funcional e executando; </li></ul><ul><li>Não se faz commit de código que não funciona ; </li></ul><ul><li>Integrando continuamente e cedo, até os problemas de comunicação desaparecem; </li></ul>
  54. 54. Teste primeiro – Programe depois <ul><li>Primeiro se escreve o teste; </li></ul><ul><li>Depois se implementa a funcionalidade até que ela passe no teste; </li></ul><ul><li>A implementação é direcionada a resolver um problema real, não a imaginação do programador; </li></ul><ul><li>É difícil de testar? Está errado! </li></ul>
  55. 55. Modelagem incremental <ul><li>Ninguém conhece o modelo todo antes de começar a implementar; </li></ul><ul><li>A implementação modifica o modelo “perfeito” pensado pelo analista; </li></ul><ul><li>O conhecimento pelo domínio do modelo vem com a implementação e a interação com pessoas que entendem “do riscado”; </li></ul>
  56. 56. Um time XP Escalando a seleção
  57. 57. Papéis <ul><li>Testadores </li></ul><ul><li>Desenvolvedores de interações </li></ul><ul><li>Arquitetos </li></ul><ul><li>Gerentes de projeto </li></ul><ul><li>Gerentes de produto </li></ul><ul><li>Executivos </li></ul><ul><li>Escritores de material técnico </li></ul><ul><li>Usuários </li></ul><ul><li>Programadores </li></ul><ul><li>Recursos humanos </li></ul>
  58. 58. Mundo perfeito Quando não usar XP?
  59. 59. Quando não usar XP? <ul><li>Quando as pessoas não querem mudar; </li></ul><ul><li>Quando o cliente quer a análise toda antes de começar o sistema; </li></ul><ul><li>Quando a empresa valoriza workaholics; </li></ul><ul><li>Quando a complexidade é absolutamente necessária; </li></ul>
  60. 60. Quando não usar XP? <ul><li>Quando os testes automáticos não são fáceis ou até mesmo possíveis de serem feitos; </li></ul><ul><li>Quando o local de desenvolvimento do projeto não ajuda; </li></ul>
  61. 61. “ There’s no silver bullet” Frederick P. Brooks
  62. 62. Conclusão <ul><li>XP não é fácil de aplicar em ambientes que resistem a mudanças; </li></ul><ul><li>É provavelmente um dos mais difíceis e “engessados” processos de software; </li></ul><ul><li>É a fonte do sucesso gigantesco de grandes projetos de software; </li></ul>
  63. 63. Conclusão <ul><li>É foco no que é interessante para quem paga, não para quem recebe; </li></ul><ul><li>É valorizar as pessoas que desenvolvem o projeto, não os papéis que elas produzem; </li></ul><ul><li>É entender que quem funciona é o código, não documentação obsoleta; </li></ul>
  64. 64. Referências <ul><li>Extreme Programming Explained: Embrace Change, Second Edition. Kent Beck, Cynthia Andres. Addisson Wesley, 2004; </li></ul><ul><li>Extreme Programming Explained. Kent Beck. Addisson Wesley, 1999; </li></ul><ul><li>The Mythical Man-Month: Essays on Software Engineering. Frederick P. Brooks. Addisson Wesley, 1975-1995. </li></ul>
  65. 65. Referências <ul><li>eXtreme Programming -> http://www.extremeprogramming.org/ </li></ul><ul><li>Eclipse Project -> http://eclipse.org/ </li></ul><ul><li>JUnit -> http://junit.org/ </li></ul><ul><li>Wikipedia -> http://en.wikipedia.org/ </li></ul>

×