Your SlideShare is downloading. ×
Extreme programming explicada
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 explicada

517

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
517
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
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

Transcript

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

×