Introdução à Programação Extrema (Extreme Programming - XP)
4 gostaram1,724 visualizações
O documento apresenta os princípios e práticas da metodologia de desenvolvimento de software extrema (XP). Ele descreve os valores fundamentais de XP como comunicação, feedback e simplicidade, assim como as 12 práticas centrais como planejamento, testes e programação pareada. Também discute papéis como programador, treinador e cliente, assim como um dia típico na vida de um programador XP.
![19
PROGRAMAÇÃO
PAREADA
https://www.flickr.com/photos/provoost/2246718091
• Erro de um detectado imediatamente
pelo outro (grande economia de tempo)
• Maior diversidade de ideias, técnicas,
algoritmos
• Enquanto um escreve, o outro pensa
em contra-exemplos, problemas de
eficiência, etc
• Vergonha de escrever código feio
(gambiarras) na frente do seu par
• Pareamento de acordo com
especialidades
– Ex.: Sistema Multimídia Orientado a Objetos
• Experimentos controlados mostraram
que a qualidade do código produzido
aumenta sem perda de velocidade
[Livro Pair Programming Illuminated: Laurie
Williams, Robert Kessler]](https://image.slidesharecdn.com/introxp-180413013250/85/Introducao-a-Programacao-Extrema-Extreme-Programming-XP-19-320.jpg)
![REFATORAÇÃO (REFACTORING)
• Uma [pequena] modificação no sistema que não
altera o seu comportamento funcional
• mas que melhora alguma qualidade não-funcional:
– simplicidade
– flexibilidade
– clareza
– [desempenho]
22](https://image.slidesharecdn.com/introxp-180413013250/85/Introducao-a-Programacao-Extrema-Extreme-Programming-XP-22-320.jpg)
Introdução à Programação Extrema (Extreme Programming - XP)
- 1. 1 ENGENHARIA DE SOFTWARE - AULA 03 INTRODUÇÃO À PROGRAMAÇÃO EXTREMA (XP) PROF. DRA. CLAUDIA MELO 19/Mar/2018 @claudia_melo claudiamelo.org
- 2. PROGRAMAÇÃO EXTREMA - XP •Metodologia de desenvolvimento de software aperfeiçoada nos últimos 10 anos •Ganhou notoriedade a partir da OOPSLA’2000 •Nome principal: Kent Beck 2
- 3. A QUEM SE DESTINA XP? • Papéis (sem hierarquia): – Programadores (foco central) – “Treinador” ou “Técnico” (coach) – “Acompanhador” (tracker) – Cliente 3
- 4. E SE EU NÃO ME ENCAIXO NESSES CASOS? • Você ainda pode aprender muito sobre desenvolvimento de software • Terá elementos para repensar as suas práticas • No início se dizia: – “Ou você é 100% eXtremo ou não é eXtremo. Não dá para ser 80% XP” • Hoje não é mais necessariamente assim (definitivamente) 4
- 6. OS VALORES DE XP • Comunicação • Feedback • Coragem • Simplicidade • Respeito – Valor criado na versão de 2004 6
- 7. AS 12 PRÁTICAS DE XP 1.Planejamento 2.Fases Pequenas 3.Metáfora 4.Design Simples 5.Testes 6.Refatoração 7.Programação Pareada 7 1.Propriedade Coletiva 2.Integração Contínua 3.Semana de 40 horas 4.Cliente junto aos desenvolvedores 5.Padronização do código
- 8. PRINCÍPIOS BÁSICOS DE XP • Feedback rápido • Simplicidade é o melhor negócio • Mudanças incrementais • Carregue a bandeira das mudanças / não valorize o medo (Embrace change) • Alta qualidade do código 8
- 9. AS 4 VARIÁVEIS DO DESENVOLVIMENTO • Tempo • Custo • Qualidade • Escopo (foco principal de XP) 9
- 10. 10https://www.atlassian.com/agile/agile-iron-triangle/sectionWrap/00/column/00/moreContent/05/imageBinary/waterfall-v-agile-iron-triangle-v03.png 4 VARIÁVEIS E O TRIÂNGULO DE FERRO (A.K.A. COBERTOR CURTO)
- 11. UM PROJETO XP • Fase de Exploração – duração: 1 a 6 meses – termina quando a primeira versão do software é enviada ao cliente – clientes escrevem “histórias” (story cards) – programadora/es interagem com clientes e discutem tecnologias – Não só discutem, experimentam diferentes tecnologias e arquiteturas para o sistema 11
- 12. 12 UM DIA NA VIDA DO/A PROGRAMADOR/A XP
- 13. UM DIA NA VIDA DE • Escolhe a próxima história mais importante do cliente • Procura um par livre • Escolhe um computador para programação pareada • Seleciona um “cartão de história” contendo uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente 13
- 14. • Discute modificações recentes no sistema • Discute história do cliente (Business Analysis) • Testes (Test-Driven Development) • Implementação • Projeto (design) • Integração do código 14 UM DIA NA VIDA DE https://www.slideshare.net/SunilMundra/agile-101-36992572 Analyze Design Code Test Deploy Develop & deploy Working software showcased to the business
- 15. • Atos constantes no desenvolvimento: – Executa testes antigos – Busca oportunidades para simplificação – Modifica desenho e implementação incrementalmente baseado na funcionalidade exigida no momento – Escreve novos testes – Enquanto todos os testes não rodam a 100%, o trabalho não está terminado – Integra novo código ao repositório 15 UM DIA NA VIDA DE
- 16. TESTES • Fundamento mais importante de XP • É o que dá segurança e coragem ao grupo • Testes de unidade (Unit tests) – escritos, por quem desenvolve, para testar cada elemento do sistema (p.ex., cada método em cada caso) • Testes de funcionalidades (Functional tests) – escritos pelos clientes para testar a funcionalidade do sistema (Testes de Aceitação) 16
- 17. TESTES • Testes das unidades do sistema – Tem que estar sempre funcionando a 100% – São executados várias vezes por dia – Executados à noite automaticamente • Testes das funcionalidades – Vão crescendo de 0% a 100% – Quando chegam a 100% acabou o projeto 17
- 18. O CÓDIGO • Padrões de estilo adotados pelo grupo inteiro • O mais claro possível – nomes claros (intention-revealing names) – XP não se baseia em documentações detalhadas e extensas (perde-se sincronia) • Comentários sempre que necessários • Comentários padronizados • Programação Pareada ajuda muito! 18
- 19. 19 PROGRAMAÇÃO PAREADA https://www.flickr.com/photos/provoost/2246718091 • Erro de um detectado imediatamente pelo outro (grande economia de tempo) • Maior diversidade de ideias, técnicas, algoritmos • Enquanto um escreve, o outro pensa em contra-exemplos, problemas de eficiência, etc • Vergonha de escrever código feio (gambiarras) na frente do seu par • Pareamento de acordo com especialidades – Ex.: Sistema Multimídia Orientado a Objetos • Experimentos controlados mostraram que a qualidade do código produzido aumenta sem perda de velocidade [Livro Pair Programming Illuminated: Laurie Williams, Robert Kessler]
- 20. QUANDO PROGRAMAR EM PAR? • Princípios para a seleção de pares • Conselhos práticos, tais como montagem de mobiliário, rodízio de pares e eliminação de pares ‘ruins’ • Sete hábitos de programadores em par eficazes 20 Dybå, T. et al, 2007. Are Two Heads Better than One? On the Effectiveness of Pair Programming
- 21. PROPRIEDADE COLETIVA DO CÓDIGO • Modelo tradicional: só autor de uma função pode modificá-la • XP: o código pertence a todos • ps: não por ser software livre, mas por ser um princípio • Se alguém identifica uma oportunidade para simplificar, consertar ou melhorar código escrito por outra pessoa, que o faça • Mas rode os testes! 21
- 22. REFATORAÇÃO (REFACTORING) • Uma [pequena] modificação no sistema que não altera o seu comportamento funcional • mas que melhora alguma qualidade não-funcional: – simplicidade – flexibilidade – clareza – [desempenho] 22
- 23. EXEMPLOS DE REFATORAÇÃO • Mudança do nome de variáveis • Mudanças nas interfaces dos objetos • Pequenas mudanças arquiteturais • Encapsular código repetido em um novo método • Generalização de métodos • raizQuadrada(float x)⇒ raiz(float x, int n) 23
- 24. CLIENTE/PRODUCT OWNER • Responsável por escrever “histórias” • Mas pessoas do time acompanham e auxiliam OU • Pode estar representado por alguém do time (menos ideal) • Trabalha no mesmo espaço físico do grupo • Novas versões são enviadas para produção todo mês (ou toda semana) • Feedback do cliente é essencial • Requisitos mudam (e isso não é mau) 24
- 25. COACH (TREINADOR) • Em geral, o mais experiente do grupo – (eXPeriente em metodologia, não na tecnologia) • Identifica quem é bom no quê • Lembra a todos as regras do jogo (XP) • Eventualmente faz programação pareada • Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias • Seu papel diminui à medida em que o time fica mais maduro 25
- 26. TRACKER (ACOMPANHADOR) • A “consciência” do time • Coleta estatísticas sobre o andamento do projeto • Alguns exemplos: ● Número de histórias definidas e implementadas ● Número de testes de unidade ● Número de testes funcionais definidos e funcionando ● Número de classes, métodos, linhas de código • Mantém histórico do progresso • Faz estimativas para o futuro 26
- 27. CONCLUSÃO: SER ÁGIL = VENCER MEDOS • Escrever código • Mudar de ideia • Ir em frente sem saber tudo sobre o futuro • Confiar em outras pessoas • Mudar a arquitetura de um sistema em funcionamento • Escrever testes 27
- 28. PRÁTICAS PRIMÁRIAS •Sentar Junto • Desenvolva num ambiente grande o suficiente para o time todo ficar junto •Time Completo • Monte um time multi-disciplinar, com todas as habilidades necessárias para o sucesso do projeto •Área de Trabalho Informativa • Um observador interessado deve ser capaz de ter uma idéia do andamento do projeto andando pela área de trabalho 28
- 29. PRÁTICAS PRIMÁRIAS •Trabalho Energizado • Trabalhe apenas enquanto puder ser produtivo e o número de horas que puder agüentar •Programação Pareada •Histórias • Unidades de funcionalidade visíveis ao cliente • Estimativa é feita o mais cedo possível para facilitar a interação entre o cliente e a equipe 29
- 30. PRÁTICAS PRIMÁRIAS •Ciclo Semanal • Representa uma iteração • Planeje o trabalho uma semana de cada vez • Reunião no início da semana para discutir o progresso, escolher histórias e dividi-las em tarefas •Ciclo de Estação (Release) • Identificar gargalos e iniciar reparos • Planejamento do tema da estação • Foco no todo: onde o projeto se encaixa na organização 30
- 31. PRÁTICAS PRIMÁRIAS •Folga • Inclua no plano algumas tarefas menores que podem ser removidas caso ocorra um atraso • Não se comprometa além do que é possível ser realizado •Build de 10 minutos • Faça o build AUTOMÁTICO do sistema INTEIRO e rode TODOS os testes em até 10 minutos •Desenvolvimento Orientado por Testes 31
- 32. PRÁTICAS PRIMÁRIAS •Integração Contínua • Integração pode ser síncrona ou assíncrona (no build) •Design Incremental • Invista no design do sistema todos os dias • O conselho não é minimizar o investimento em design no curto prazo, mas manter o investimento proporcional às necessidades do sistema • Design feito mais próximo de quando é usado é mais eficiente 32
- 33. COMO COMEÇAR? •Práticas dependem da situação e do contexto, são um guia para onde você pode chegar •Adote XP em passos pequenos (mude uma coisa de cada vez) •Crie consciência da necessidade de uma prática usando métricas •Avalie a experiência de adoção 33
- 34. PRÁTICAS COROLÁRIAS •Envolvimento Real com o Cliente • Faça com que as pessoas cujas vidas e negócios serão afetados pelo sistema façam parte do time •Implantação Incremental • Ao substituir um sistema legado, troque partes da funcionalidade gradualmente •Continuidade do Time • Mantenha times eficientes trabalhando juntos 34
- 35. PRÁTICAS COROLÁRIAS •Redução do Time • Mantenha a carga de trabalho constante e distribua as tarefas de modo a deixar alguém ocioso • Com o tempo, essa pessoa pode ser liberada para formar novos times •Análise de Causa Inicial • Sempre que encontrar um defeito, elimine o defeito e sua causa • “Os 5 Porquês” •Código Compartilhado 35
- 36. PRÁTICAS COROLÁRIAS •Código e Testes • Os únicos artefatos permanentes •Repositório Único de Código • Desenvolva num repositório único. Branches podem existir, mas devem ser incorporados logo •Implantação Diária • Coloque software novo em produção toda noite 36
- 37. PRÁTICAS COROLÁRIAS •Contrato de Escopo Variável • Contratos devem fixar tempo, custo e qualidade, mas a negociação de escopo deve ser aberta •Pague-Pelo-Uso • Cobre por cada vez que o sistema é usado • O dinheiro é o feedback máximo 37
- 38. SOBRE A EQUIPE •Diversos papéis • Testadores, Projetistas de Interface, Arquitetos, Gerentes de Projeto etc. 38
- 39. EQUIPES DISTRIBUÍDAS •Valores se aplicam para equipes distribuídas geograficamente •É necessário nutrir comunicação e feedback devido à separação •Adaptar as práticas, base de código única é a conexão entre as equipes •Não abandonar práticas difíceis de manter à distância • eg.: programação pareada usando VNC 39
- 40. QUANDO NÃO USAR XP •Quando os valores reais da sua organização não se alinham com os valores de XP 40
- 41. COMUNIDADE •O suporte de uma comunidade é muito importante •Reconhecimento e crítica dos seus pares •Oferece uma perspectiva de pessoas que compartilham os mesmo valores, mas estão em outras organizações •Melhoria através de grupos de estudo 41
- 42. MAIS INFORMAÇÕES • Vários conteúdos desta apresentação foram trazidos do Curso de Verão 2010 - IME/USP AgilCoop - da qual faço parte :) • www.agilcoop.org.br • Outros: • www.agilealliance.org • www.xispe.com.br • www.extremeprogramming.org • www.agilealliance.com.br 42
- 43. CLAUDIA MELOPEOPLE TECHNOLOGY RESEARCHER @claudia_melo claudiamelo.org @claudiameloblog /claudiamelo