IPA Conhecendo XP

476 views
438 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
476
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

IPA Conhecendo XP

  1. 1. Conhecendo oeXtreme Programming
  2. 2. Quem sou eu? Guilherme Lacerdaguilhermeslacerda@gmail.com Mestre em Ciência da Computação, área de Engenharia de Software (UFRGS) Professor de Graduação (FACENSA e UniRitter) e Pós-Graduação (UniRitter) Consultor de TI, com mais de 15 anos na área de desenvolvimento de Software e 10 anosde experiência em modelagem e desenvolvimento OO Instrutor/Consultor de Metodologias Ágeis da TargetTrust Pioneiro em Metodologias Ágeis no Brasil (Lean, SCRUM e XP) Fundador do XP-RS (Grupo de Usuários de Metodologias Ágeis do RS) e Vice-Coordenadordo GUMA (Grupo de Usuários de Metodologias Ágeis) vinculado a SUCESU-RS Editor do Portal InfoQ Brasil Membro do IASA e da Scrum Alliance
  3. 3. Quem faz programa?Por que 80% a 90% dos projetos de SW fracassam? Fonte: Standish Group
  4. 4. Principais Problemas Sistemas entregues com atrasos e/ou orçamento estourado Não atendem os requisitos de negócio Clientes descontentes (sem confiança nos desenvolvedores) Clientes não têm compreensão clara do que é desenvolvido Clientes não dão suporte correto para o desenvolvimento Clientes não estão interessados em participar de processoscomplexos
  5. 5. Principais ProblemasDesenvolvedores trabalham muitas horas!Desenvolvedores relaxam na disciplinaDesenvolvedores perdem o focoProcessos prescritivos são atrativos para a gerência mas não paraos desenvolvedores Baseados no paradigma do comando e controle Tenta minimizar o papel do clienteFoco em tecnologia e não no negócio
  6. 6. Como resolvê-los?
  7. 7. Como resolvê-los?
  8. 8. O que é ser Ágil?Ágil é ser rápido, ligeiro (dicionário) Eficaz: produz o resultado esperado Eficiente: produz o resultado esperado, mas com qualidadeCaracterísticas importantes: Foco nas necessidades do cliente (resultado!) Liderança Envolvimento das pessoas Melhoria Contínua Tomada de decisões baseada em análise de dados e informações (controle!)
  9. 9. Direitos do Cliente (Ron Jeffries) Planejamento Geral, definindo o que pode ser realizado, quando e aque custo Ver e acompanhar o andamento do projeto e, principalmente, oprogresso do SW, passando por testes definidos em conjunto com aequipe Mudar de idéia, substituir funcionalidades, sem pagar custosexorbitantes Ser informado de mudanças no cronograma, em tempo de escolher ereduzir o escopo Poder cancelar o projeto a qualquer momento e ainda assim ter umsistema funcionando, refletindo o investimento realizado até omomento
  10. 10. Direitos do Desenvolvedor (Ron Jeffries) Saber o que é necessário, com declarações claras deprioridade Produzir trabalho de qualidade o tempo todo Pedir e receber ajuda da equipe, superiores e clientes Fazer e atualizar suas próprias estimativas Aceitar as suas responsabilidades, ao invés de tê-las impostas
  11. 11. Processos de SoftwareProcessos Tradicionais Analisar, projetar e só depois iniciar codificaçãoPrever o futuro Ter certeza do que se sabe hoje será exatamente o que se quer amanhãTemores Mudança de requisitos depois de concluída a fase de análise e projeto
  12. 12. Manifesto Ágil“Estamos evidenciando maneiras melhores de desenvolversoftware fazendo-o nós mesmos e ajudando outros a fazê-lo.Através desse trabalho, passamos a valorizar: Interação entre pessoas MAIS QUE processos e ferramentas; Software em funcionamento MAIS QUE documentação abrangente; Responder a mudanças MAIS QUE seguir um plano. Colaboração com o cliente MAIS QUE negociação de contratos;Ou seja, mesmo tendo valor os itens à direita, valorizamosmais os itens à esquerda.”Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, WardCunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum,Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick,Ken Schwaber, Jeff Shuterland, Dave Thomas Utah – Fevereiro de 2001
  13. 13. Waterfall X Ágil
  14. 14. Cone da Incerteza
  15. 15. RiscosRiscos de Planejamento Será que conseguiremos terminar até outubro?Riscos de Custo Será que conseguiremos comprar o servidor pelo preço definido anteriormente?Riscos de Requisitos Será que temos todas as informações para começar o trabalho?
  16. 16. Risco X Valor Alto Risco Alto Risco Baixo Valor Alto ValorRisco Baixo Risco Baixo Risco Baixo Valor Alto Valor Valor Evitar Fazer PrimeiroRisco Fazer por último Fazer depois Valor
  17. 17. Waterfall, Iterativo
  18. 18. eXtreme Programming
  19. 19. eXtreme Programming
  20. 20. XP Criado por Kent Beck, Ron Jeffries e Ward Cunningham Disciplina de desenvolvimento de SW, voltada para equipespequenas e médias, com requisitos vagos ou que mudamfreqüentemente Principal tarefa é a codificação
  21. 21. XP
  22. 22. ValoresComunicação Práticas valorizam a comunicação, não limitada a procedimentos formaisSimplicidade Incentiva ao extremo práticas que reduzam a complexidadeFeedback Práticas garantem um rápido feedback sobre várias partes do projetoCoragem Práticas aumentam a confiança dos desenvolvedores e do próprio cliente
  23. 23. Comunicação
  24. 24. Comunicação
  25. 25. Comunicação
  26. 26. Variáveis de um ProjetoProcessos Tradicionais Tempo Escopo Manipula-se a Custo QualidadeeXtreme Programming Tempo Manipula-se a Qualidade Escopo Custo
  27. 27. XPPráticas organizacionaisPráticas de equipePráticas de pares
  28. 28. Equipe (Whole Team) Equipe XP = Cliente + Time de DesenvolvimentoAs funções do cliente englobam: Definição dos requisitos do projeto Definição de prioridades Controle do rumo do projeto Definir os testes de aceitação do SWOs papéis do time de desenvolvimento englobam: desenvolvedores testadores (ajudam o cliente com os testes de aceitação) analistas/projetistas (ajudam o cliente a definir requisitos) gerente (garante os recursos necessários) coach (orienta a equipe, controlando a aplicação do XP) tracker (coleta as métricas do projeto)
  29. 29. Equipe (Whole Team)
  30. 30. Jogo de Planejamento (Planning Game)Principais definições Definição das User Stories (atividade + tarefas) Estimativas de User Stories Prioridades (tarefas + importantes)Próximos passos Planejamento de release (cliente propõe as funcionalidades e desenvolvedores avaliam) Planejamento da iteração (define as funcionalidades da iteração e os desenvolvedores estimam)Ótimo feedback para o cliente, que dirige o projeto Idéia clara do avanço do projeto Clareza: Redução de Riscos, aumentando a chance de sucesso
  31. 31. Produto, Release, Planejamento Release 1 Release 2 Release 3Planejamento Iteração 1 Iteração 2 Iteração 3-5 Tarefa A Tarefa B Tarefa C
  32. 32. Releases, Iterações, VelocidadeUm release é formado de múltiplas iteraçõesCada iteração pode ser planejada com o mesma caixa de tempoStories são colocadas dentro de cada caixa, até estar completaO tamanho da caixa é a velocidade planejada 3 4 2 3 7 4 5 4 5 2 6 4 2 5 6
  33. 33. Testes de Aceitação (Acceptance Tests)São elaborados pelo cliente em conjunto com analistas e testadores São automatizados Quando rodarem com sucesso, funcionalidade foi implementada Devem ser rodados a cada iteração Roteiro com um conjunto de respostas esperadasÓtimo feedback para o cliente Pode se saber, a qualquer momento, o % de implementação do SW e quanto falta
  34. 34. Pequenos Lançamentos (Small Releases)Disponibiliza a cada iteração SW 100% funcional Versão disponibilizada imediatamente Redução de riscos (se o projeto terminar, parte existe e funciona) Detecção prévia de problemas Comunicação entre cliente e desenvolvedorCada lançamento possui funcionalidades prioritárias para a iteraçãoLançamento pode ser destinado a usuário/cliente (testa, avalia e oferece feedback) usuário/final (sempre que possível)Design simples e integração contínua são práticas essenciais
  35. 35. Projeto Simples (Simple Design)Projeto está presente em todas as etapas XP Projeto começa simples e se mantém assim através de testes e refinamento de código (refactoring)Em XP, é levado ao extremo Não é permitido implementar qualquer funcionalidade adicional que não será usada na iteração atualImplementação ideal é aquela que Passa por todos os testes Expressa todas as idéias definidas no planejamento Não contém código duplicado ou que “cheire”Prever o futuro é impossível e é “anti-XP”
  36. 36. Programação em Pares (Pair Programming)SW é desenvolvido em pares “2 cabeças juntas são melhores que duas cabeças separadas” 1 piloto e 1 co-piloto Papéis são alternados freqüentementeBenefícios Melhor qualidade de código (refactoring, testes) Revisão constante do código Nivelamento da equipe Maior comunicação“Um” pelo preço de “Dois”?? Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos
  37. 37. Programação em Pares (Pair Programming)Efeitos sobre a produtividade da equipe “Um trabalha enquanto o outro não faz nada...” Pressupõe comunicação contínua pesquisas mostram atividades desempenhadas na metade do tempo de desenvolvimento Produtividade a curto prazo X longo prazoPressão do Par Concentração, incentivo, responsabilidade Revezamentos Disseminação do conhecimentoDesafios Organização do escritório, visão gerencial, relacionamento humano, competição
  38. 38. Desenvolvimento Dirigido por Testes (Test-Driven Development)XP valoriza o desenvolvimento dirigido por testes São automatizados, executados o tempo todoTestes “puxam” o desenvolvimento Cada unidade de código só tem valor se o teste funcionar 100%Testes dão coragem para mudar De que adianta a OO isolar a interface da implementação se o desenvolvedor tem medo de mudar a implementação?
  39. 39. Desenvolvimento Dirigido por Testes (Test-Driven Development) TDDObtertarefa Criar Código de Codificar Fazer Teste para a tarefa Refactoring Passou nos testes? Sim: Nova tarefa Não: Revisar código
  40. 40. Refatoração (Refactoring)Design é melhorado continuamente através de refinamento Mudança proposital no código que está funcionando Melhorar sua estrutura interna sem alterar a funcionalidade Visa simplificar o código, remover o código duplicadoPrincipal referência é o catálogo de refactorings de Martin Fowler Existência prévia de testes é fundamental para utilização desta prática (elimina o medo dos desenvolvedores de adotar a mudança)“Software é como a nossa casa” Organizados X desorganizadosXP enfatiza código de alta qualidade
  41. 41. Integração Contínua (Continuous Integration)XP mantém o SW integrado o tempo todo Realizada pelo menos uma vez por dia Para integrar, deve-se realizar os testes primeiro“Reduz o tempo passado no inferno da integração” - Martin FowlerBenefícios Expõe o estado atual de desenvolvimento Oferece feedback Estimula agilidade e versões freqüentes do SW
  42. 42. Posse Coletiva (Collective Ownership)O código tem um único dono: a equipe Qualquer par de programadores pode melhorar o código Revisão constante do código Aumenta a comunicação Aumenta a qualidade (menos duplicação, maior coesão) e diminui os riscos de dependência de indivíduosTodos compartilham a responsabilidade pelas alteraçõesIdeal que se troque os pares periodicamente “Todos conhecem tudo” Testes e integração contínua são essenciais e dão segurança
  43. 43. Padrões de Codificação (Coding Standards)Os padrões de codificação são definidos pela equipe Organização de código NomenclaturasCódigo com aspecto de escrito por um único desenvolvedor Competência OrganizaçãoPráticas e valores favorecidos Posse coletiva Comunicação Programação em Pares Refactoring Projeto Simples
  44. 44. Metáfora (Metaphor) Equipes XP mantém uma visão compartilhada do sistema Analogia com outros sistemas (natural, computacional, abstrato) Exercício de criatividade e abstração Ótima fonte de comunicação entre a equipe, facilitando inclusive asestimativas Pattern de alto nível
  45. 45. Ritmo Saudável (Sustainable Pace) XP está na arena para ganhar Projetos vampiros não são projetos XP Semanas de 80 horas Código ruim, relaxamento da disciplina, stress da equipe Tempo ganho será perdido depois São aceitáveis eventuais horas extras quando a produtividade émaximizada
  46. 46. Reuniões em Pé (StandUp Mettings)A maioria dos desenvolvedores odeiam reuniões Assuntos demorados e desgastantes Impedem os desenvolvedores de codificarAs reuniões são valiosas quando Não perdem o foco São brevesSão abordadas tarefas realizadas e a realizar
  47. 47. Spikes de Planejamento (Spike Solution) São investigações de tecnologias que podem ser utilizadas noprojeto Auxiliam nas estimativas e na especificação do projeto Podem durar horas ou dias, porém devem ser curtos Englobam Avaliações de arquiteturas Algoritmos componentes e frameworks BDs Servidores de aplicação, Web Utilização de artefatos e ferramentas
  48. 48. Ambiente de TrabalhoO ambiente deve apoiar a aplicação das práticas Tem importância vital para um projeto de software Trabalhar próximo dos colegas Facilitar a comunicaçãoEquipamentos Mesas e cadeiras Equipamentos tecnológicos Telefones Mural Quadro Branco Calendário Comida ☺ Isolamento (equipes e projetos)
  49. 49. Documentação ÁgilComplexidade do Software Tempo de desenvolvimento Equipes Futuras manutençõesAté que ponto documentar? Uso incorreto da documentação Quando documentar?Documentos que compõem a documentação User stories, testes de aceitação, testes de unidade, documentação de código fonte, Modelo de Classes, Modelo de Dados, Processos de Negócio, Manual de usuário, Acompanhamento diário, Acompanhamento do Projeto
  50. 50. Ferramentas de ApoioMais em http://xprogramming.com/software.htm
  51. 51. IDEs
  52. 52. IDEs
  53. 53. Teste de Unidade
  54. 54. Teste de Unidade
  55. 55. Teste de Unidade
  56. 56. Testes Funcionais
  57. 57. Patterns, Boas Práticas, Refactoring
  58. 58. Patterns, Boas Práticas, Refactoring
  59. 59. Code Coverage
  60. 60. Code Coverage
  61. 61. Code Coverage
  62. 62. Code Coverage
  63. 63. Code Coverage
  64. 64. Code Coverage
  65. 65. Documentação
  66. 66. Integração Contínua
  67. 67. Integração Contínua
  68. 68. Padrões de Codificação
  69. 69. Padrões de Codificação
  70. 70. MercadoHP Objective SolutionsFord ImproveItSymantec Brasil TelecomMotorola EmbrapaChrysler QualitiBMW Trevisan TecnologiaBorland ArgonavisIBM CETIPFirst National Bank Secretaria da Fazenda SPThought Works Smart Tech ConsultingCC Pace Systems iQualyIndustrial Logic IME-USPMoore EverSystemsWorkshare PowerLogic ConsultoriaXerox UFRJSiemens PUC-RioObject Mentor Surya Tecnologia
  71. 71. Principais Eventos
  72. 72. Adotando e Escalando XPAdote as práticas em doses homeopáticas Não seja afobado, saboreie a mudança Enfatize o problema mais importanteDificuldades culturais Deixar alguém mexer no seu código Pedir ajuda Ânsia de tentar prever o futuro Escrever testes antes de codificar Refatorar com freqüência (superar o medo)Situações difíceis de aplicar XP Equipes grandes e distribuídas geograficamente Perda do controle sobre código Feedback demorado
  73. 73. Adotando e Escalando XPXP e os processos ágeis valorizam as pessoas Bons desenvolvedores criam bons SWsProcessos ágeis são suplementos aos outros métodos São atitudes São efetivos Não é um ataque à documentação e sim a criação de documentos que tem valor Não são para todosO segredo está na sinergia de suas práticas Menos formalidade, mais diversão
  74. 74. Considerações Finais XP é uma disciplina de desenvolvimento ágil de SW baseada emcomunicação, feedback, simplicidade e coragem Para usar XP é preciso fazer com que a equipe se una em torno depráticas simples, obtendo feedback e reajustando estas práticas paracada situação particular XP pode ser implementada aos poucos, porém, a maior parte daspráticas são essenciais Nem todos os projetos são bons candidatos para XP. XP não é para todo mundo, mas todo mundo pode aprender com XP Adotar Processos Ágeis não é simplesmente aplicá-lo É preciso entender sua filosofia
  75. 75. Combinando Lean + SCRUM + XP
  76. 76. Combinando Lean + SCRUM + XP
  77. 77. Formação em Metodologias Ágeis Introdução ao Lean – Promovendo a Mudança Cultural (8h) Projetos Ágeis com SCRUM – Gestão e Acompanhamento (20h) Técnicas para gerar Código de Qualidade com eXtreme Programming(12h) Cursos In Company e Consultorias
  78. 78. Apoio

×