eXtreme Programming (XP)

3.666 visualizações

Publicada em

eXtreme Programming (XP)

Publicada em: Tecnologia
  • Seja o primeiro a comentar

eXtreme Programming (XP)

  1. 1. Carlos Henrique M. da Silva carloshenrique.85@globo.com eXtreme Programming
  2. 2. Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores e práticas, que diferem substancialmente da forma tradicional de se desenvolver software. Estudos demonstram que a maioria dos projetos de software falha, seja porque não cumprem o orçamento, ou não cumprem o cronograma, ou as funcionalidades não atendem às necessidades dos usuários ou porque todos estes fatores estão presentes em conjunto. VINÍCIUS MANHÃES TELES eXtreme Programming - Conceito
  3. 3. eXtreme Programming - Introdução Por que cerca de 80% a 90% dos projetos de Software fracassam?
  4. 4. eXtreme Programming - Introdução Desenvolver software é uma atividade arriscada. Segundo as estatísticas, os principais problemas são:  Gastos que superam o orçamento;  Consumo de tempo que supera o cronograma;  Funcionalidades que não resolvem os problemas dos usuários;  Mudanças constantes podendo estar relacionadas a requisitos, cronograma, equipe...  Baixa qualidade dos sistemas desenvolvidos.
  5. 5. eXtreme Programming - Introdução Há algumas décadas a indústria de software vem buscando técnicas de desenvolvimento que possam reduzir os riscos dos projetos de software e tornar essa atividade mais produtiva. Um marco neste sentido é a criação da disciplina de Engenharia de Software em 1968. De lá para cá, inúmeras propostas foram feitas para melhorar o desempenho dos projetos, começando pelo processo de desenvolvimento linear e seqüencial (em cascata) até chegar aos atuais processos ágeis de desenvolvimento. O XP é um dos representantes destes processos e foi criado por Kent Beck em 1997 em um projeto para a Chrysler (fabricante de veículos norte-americana). O XP é composto por um conjunto reduzido de práticas de desenvolvimento que se organizam em torno de valores básicos. Essas práticas possuem fortes inter-relacionamentos formando um conjunto de elevada sinergia.
  6. 6. eXtreme Programming - Introdução Desenvolvimento de SW no passado  Processos Tradicionais Analisar, projetar e só depois iniciar codificação  Prever 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 Custo Análise Projeto Codificação Testes Tempo
  7. 7. eXtreme Programming - Introdução Desenvolvimento de SW hoje  Processos modernos incentivam pequenas iterações Mudanças em etapas posteriores se tornam mais baratas  Adotar a mudança - A Engenharia de SW é diferente das outras engenharias - Componentes, frameworks, BDs podem absorver o alto custo da mudança
  8. 8. eXtreme Programming - Introdução A crise do software  Em média, os atrasos representaram 63% mais tempo do que o estimado;  Os projetos que não cumpriram o orçamento custaram em média 45% mais;  No geral, apenas 67% das funcionalidades prometidas foram efetivamente entregues. Resultado final de projetos de software (Standish Group,2000)
  9. 9. eXtreme Programming - Introdução Utilização de Funcionalidades
  10. 10. eXtreme Programming - Introdução Utilização de Funcionalidades
  11. 11. eXtreme Programming - Introdução Desperdício Falha na comunicação Falta de tempo
  12. 12. eXtreme Programming - Introdução Manifesto Ágil Estamos evidenciando maneiras melhores de desenvolver software 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;  Colaboração com o cliente MAIS QUE negociação de contratos;  Responder a mudanças MAIS QUE seguir um plano. “Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.” Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward Cunningham, 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
  13. 13. Referência eXtreme Programming
  14. 14. eXtreme Programming Extreme Programming ou XP, é um processo de desenvolvimento de software voltado para:  Projetos cujos requisitos são vagos e mudam com frequência;  Desenvolvimento de sistemas orientados a objetos;  Equipes pequenas, preferencialmente até 12 desenvolvedores;  Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo. VISÃO GERAL O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e prática que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software.
  15. 15. Valores do XP  Comunicação  Simplicidade  Feedback  Coragem  Respeito Práticas do XP  Cliente Presente  Jogo do Planejamento  Stand Up Meeting  Programação em Par  Desenvolvimento Guiado pelos Testes  Refactoring  Código Coletivo  Código Padronizado  Design Simples  Metáfora  Ritmo Sustentável  Integração Contínua  Releases Curtos eXtreme Programming
  16. 16. Valores do XP eXtreme Programming
  17. 17. Comunicação A comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem. O XP procura assegurar que a comunicação ocorra da forma mais direta e eficaz possível. Sendo assim, ele busca aproximar todos os envolvidos do projeto de modo que todos possam se comunicar face-a-face ou da forma mais rica que for viável. eXtreme Programming
  18. 18. Simplicidade A comunicação, embora seja essencial, não é suficiente para garantir que o cliente possa aprender durante o projeto e gerar feedback rapidamente. Também é necessário que a equipe compreenda e utilize o valor da simplicidade, que nos ensina a implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente. Ou seja, ao codificar uma funcionalidade devemos nos preocupar apenas com os problemas de hoje e deixar os problemas do futuro para o futuro (NÃO DEVEMOS TENTAR PREVER O FUTURO), pois raramente acertamos as previsões. eXtreme Programming
  19. 19. Feedback Quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, ele gera feedback para a equipe de desenvolvimento. O feedback é o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente e garanta que a equipe direcione as suas atenções para aquilo que irá gerar mais valor. eXtreme Programming
  20. 20. Coragem Existem temores que costumam assombrar os participantes de um projeto de software. Beck e Fowler (2001) destacam alguns destes medos que exercem influência significativa nos processos de desenvolvimento. Desenvolvedores, por sua vez, temem:  Ser solicitados a fazer mais do que sabem fazer;  Ser ordenados a fazer coisas que não façam sentido;  Ficar defasados tecnicamente;  Receber responsabilidades, sem autoridade;  Não receber definições claras sobre o que precisa ser feito;  Sacrificar a qualidade em função de prazo;  Ter que resolver problemas complicados sem ajuda e  Não ter tempo suficiente para fazer um bom trabalho. Clientes temem:  Não obter o que pediram;  Pedir a coisa errada;  Pagar demais por muito pouco;  Jamais ver um plano relevante;  Não saber o que está acontecendo e  Fixarem-se em suas primeiras decisões e não serem capazes de reagir a mudanças nos negócios. eXtreme Programming
  21. 21. Respeito eXtreme Programming Todo mundo dá e se sente o respeito que merecem como um membro da equipe valorizada. Todos contribuem valor mesmo que seja simplesmente entusiasmo. Desenvolvedores respeitam a experiência dos clientes e vice-versa. Gestores respeitam o direito de aceitar a responsabilidade e receber autoridade sobre nosso próprio trabalho. Respeito é um valor que dá sustentação a todos os demais. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se importarem uns com os outros. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.
  22. 22. eXtreme Programming
  23. 23. eXtreme Programming Equipe (Whole Team) Equipe XP = Cliente + Time de Desenvolvimento Os 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) As 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 Software
  24. 24. eXtreme Programming Jogo de Planejamento (Planning Game)  Principais definições • Estimativas de cada tarefa • 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 • Ideia clara do avanço do projeto • Clareza: Redução de Riscos, aumentando a chance de sucesso
  25. 25. eXtreme Programming Pequenos Lançamentos (Small Releases)  Disponibiliza a cada iteração Software 100% funcional • Versão • Redução (se o projeto terminar, parte existe e funciona) • Detecção prévia de problemas • Comunicação entre cliente e desenvolvedor  Cada lançamento possui funcionalidades prioritárias para a iteração  Lanç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
  26. 26. eXtreme Programming Testes de Aceitação (Customer 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  Ótimo feedback para o cliente • Pode se saber, a qualquer momento, o percentual de implementação do Software e quanto falta
  27. 27. eXtreme Programming Projetos Simples (Simple Design)  Projeto está presente em todas as etapas XP • Projeto começa simples e se mantém assim através de testes de refinamento de código (refactoring)  Em XP, é levado ao extremo • Não é Permitido qualquer funcionalidade adicional que não será usada na iteração atual  Implementação ideal é aquela que • Passa por todos os testes • Expressa as ideias definidas no planejamento • Não contém código duplicado ou que “cheire”  Prever o futuro é impossível e é “anti-XP”
  28. 28. eXtreme Programming Programação em Pares (Pair Programming)  Software é desenvolvido em pares • “2 cabeças juntas são melhores que 2 cabeças separadas” • 1 piloto e 1 copiloto • Papéis são alternados frequentemente  Benefícios •Melhor qualidade de código (refactoring e 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
  29. 29. eXtreme Programming Desenvolvimento Dirigido por Testes (Test-driven Development)
  30. 30. eXtreme Programming Refinamento de código (Refactoring) http://www.refactoring.com/catalog/
  31. 31. eXtreme Programming Integração Contínua (Continuous Integration)
  32. 32. eXtreme Programming Posse Coletiva (Collective Ownership)
  33. 33. eXtremme Programming Padrões de Codificação (Coding Standards)
  34. 34. eXtremme Programming Ritmo Saudável (Sustainable Pace)
  35. 35. eXtremme Programming Metáfora (Metaphor)
  36. 36. eXtremme Programming Reuniões em Pé (Stand-up Meeting)
  37. 37. eXtremme Programming Spikes de Planejamento (Spike Solution)
  38. 38. eXtremme Programming Como Implantar?  Uma prática de cada vez • Enfatize o problema mais importante  Dificuldades culturais • Deixar alguém mexer no seu código • Trabalhar em pares  Dificuldades devido a mudança de hábitos • Manter as coisas simples (e não tentar prever o futuro escrevendo "design flexível") • Jogar fora código desnecessário • Escrever testes antes de codificar • Refatorar com frequência (vencer o medo)
  39. 39. eXtremme Programming Quando Não Usar XP  Equipes grandes e espalhadas geograficamente • Comunicação é um valor fundamental do XP • Não é fácil garantir o nível de comunicação requerido em projetos XP em grandes equipes  Situações onde não se tem controle sobre o código • Código legado que não pode ser modificado  Situações onde o feedback é demorado • Compile-link-build-test que leva 24 horas • Testes muito difíceis, arriscados e que levam tempo • Programadores espalhados em ambientes físicos distantes e sem comunicação eficiente
  40. 40. eXtreme Programming Características da Equipe Uma equipe que utilize o XP normalmente é composta por pessoas que representam os seguintes papéis:  Gerente de Projeto  Coach  Analista de Teste  Redator Técnico  Desenvolvedor
  41. 41. eXtreme Programming Gerente de Projeto O gerente de projeto é responsável pelos assuntos administrativos do projeto. Ele procura liberar a equipe de questões que não estejam diretamente ligadas à atividade diária de desenvolvimento. Além disso, administra o relacionamento com o cliente assegurando que o mesmo participe ativamente do desenvolvimento e forneça as informações essenciais para que a equipe possa implementar o sistema desejado.
  42. 42. eXtreme Programming Coach O coach é o profissional técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas práticas recomendadas pelo XP. Embora também possa atuar na implementação do sistema, sua tarefa principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.
  43. 43. eXtreme Programming Analista de Testes O analista de teste é responsável por ajudar o cliente a escrever os testes de aceitação. Quando estes testes não são automatizados, o analista de teste deve fazer com que eles sejam executados diversas vezes ao longo das iterações do projeto. Ele procura fazer com que os eventuais defeitos do sistema sejam identificados tão logo apareçam. Desta forma, fornece feedback para a equipe rapidamente, de modo que ela possa fazer as correções com rapidez e evitar que os problemas se propaguem.
  44. 44. eXtreme Programming Redator Técnico O redator técnico ajuda a equipe de desenvolvimento a documentar o sistema. A sua presença permite que os desenvolvedores se concentrem prioritariamente na implementação do software. Embora eles possam continuar fazendo algumas documentações, o redator técnico é quem faz a maior parte do trabalho de documentação.
  45. 45. eXtreme Programming Desenvolvedor O desenvolvedor é a pessoa que analisa, projeta e codifica o sistema. Em suma, é a pessoa que efetivamente constrói o software. Dentro do XP, não existem divisões entre analista, projetista, programador, etc. Cada desenvolvedor exerce estes diferentes papéis em diversos momentos do projeto.
  46. 46. eXtreme Programming Desafios de Desenvolvimento de Software Modelo em Cascata
  47. 47. eXtreme Programming  Análise: a equipe faz o levantamento de requisitos e busca compreendê-lo detalhadamente  Design: com base na análise a equipe projeta a arquitetura do sistema  Implementação: a equipe se baseia na arquitetura e na análise para implementar as diversas partes do software  Teste: para verificar se o sistema atende às necessidades especificadas pelo usuário, a equipe testa o software e faz as correções necessárias  Implantação: o sistema é colocado em produção e os usuários finais passam a utilizá-lo  Manutenção: até o fim da sua vida, o software poderá sofrer alterações por diversas razões, tais como correção e inclusão de novas funcionalidades Desafios de Desenvolvimento de Software
  48. 48. eXtreme Programming Desenvolvimento Ágil O termo “desenvolvimento ágil”, faz referência ao desenvolvimento iterativo, em espiral. Ele recomenda que todas as fases descritas no modelo em cascata sejam executadas diversas vezes ao longo do projeto, produzindo ciclos que se repetem ao longo de todo o desenvolvimento. Cada ciclo (da análise à implementação) recebe o nome de iteração. No desenvolvimento iterativo, o software cresce a cada iteração, isto é, o resultado de cada iteração é um software pronto, testado e aprovado, sendo que a primeira contém poucas funcionalidades, enquanto a última contém todas as funcionalidades do sistema.
  49. 49. eXtreme Programming Cliente Presente Introdução Tradicionalmente, quando pensamos no desenvolvimento de software, delegamos ao cliente a tarefa de manifestar as suas necessidades e à equipe de desenvolvimento a de implementar. Ou seja, há uma divisão implícita entre as responsabilidades de cada parte e um certo distanciamento entre elas.
  50. 50. eXtreme Programming O XP trabalha com uma visão diferente O XP sugere que o cliente esteja presente durante o dia-a-dia do projeto. A sua participação contribui para o sucesso do projeto, enquanto sua a sua ausência é um sério fator de risco. A participação do cliente viabiliza a simplicidade do processo. Além disso, ela permite que o projeto seja conduzido através de uma série de pequenos ajustes e não através de mudanças bruscas ao longo do caminho.
  51. 51. eXtreme Programming Estórias As funcionalidades do sistemas são descritas brevemente em cartões e recebem o nome de estórias. Estas estórias nada mais são do que um convite ao diálogo. Sendo assim, quando os desenvolvedores decidem começar a implementar uma determinada estória, eles precisam dialogar com o cliente para entendê-las melhor. Essa é uma das razões pelas quais é essencial que o cliente esteja presente no dia-a-dia do desenvolvimento.
  52. 52. eXtreme Programming Dúvidas Durante a Implementação Enquanto os desenvolvedores se aprofundam na modelagem da nova funcionalidade e começam a implementá-la, dúvidas podem surgir. Mais uma vez, a presença do cliente permite que as dúvidas sejam respondidas rapidamente. Isso contribui com a agilidade do processo e evita o trabalho especulativo.
  53. 53. eXtreme Programming O Trabalho Especulativo O trabalho especulativo, que ocorre quando a equipe não consegue ter as dúvidas respondidas e assume premissas, representa um enorme risco de retrabalho negativo. Assumindo premissas, a equipe pode vir a construir partes da funcionalidades de forma completamente incorreta, o que poderia ter sido evitado se o cliente estivesse presente para responder às dúvidas.
  54. 54. eXtreme Programming Confiança: um sub-produto da presença do cliente Além do feedback entre cliente e equipe de desenvolvimento, a participação do cliente no desenvolvimento também contribui para melhorar o relacionamento de ambas as partes. A aproximação aumenta a confiança de todos os envolvidos. É preciso notar que serviço é um produto intangível, como o próprio software. Normalmente, temos mais facilidade em medir o valor de algo que é concreto, que podemos ver, tocar, manipular. Ou seja, normalmente, é mais fácil medir o valor de um carro, por exemplo, que o valor de um serviço.
  55. 55. eXtreme Programming Para a equipe de desenvolvimento, a aproximação do cliente permite que muitas dúvidas sejam respondidas. Além disso, com o cliente próximo, a equipe pode apontar questões que tenham passados desapercebidas aos olhos dele. Desta forma, a equipe pode preveni-lo de situações incorretas. Aproximação da equipe com o cliente
  56. 56. eXtreme Programming  Por que é difícil ter o cliente presente?  A sala de guerra (war room) com o cliente presente  A sala de guerra com o cliente ausente  A sala de guerra em outro prédio  O que acontece com os projetos quando o cliente não está presente? Questionamentos importantes Equipe X Cliente
  57. 57. eXtreme Programming O Jogo do Planejamento O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar mais valor para o cliente a cada dia de trabalho. Este planejamento é feito diversas vezes ao longo do projeto, para que todos tenham a oportunidade de revisar as prioridades (Beck e Fowler, 2001).  Dividindo as Responsabilidades  Escrevendo Estórias  Estimando Estórias  Planejando os Releases  Planejando as Iterações  Encerrando uma Iteração  Encerrando um Release
  58. 58. eXtreme Programming Dividindo as Responsabilidades A chave para gestão de um projeto de software é o equilíbrio de poderes entre o cliente e a equipe de desenvolvimento. Por esta razão, o XP procura separar claramente o papel de cada um, para assegurar que o cliente tome todas as decisões de negócio, enquanto a equipe de desenvolvimento cuida das decisões técnicas. (Beck e Fowler, 2001). Isso dá origem a declaração de direitos do cliente e do desenvolvedor (Jeffries et al., 2001).
  59. 59. eXtreme Programming Direitos do Cliente  Receber um plano geral para que saiba o que poderá ser feito, quando e com que custo;  Receber o máximo de valor de cada semana de trabalho da equipe de desenvolvimento;  Acompanhar o progresso do projeto através de um sistema executável, que demonstra estar correto por passar nos testes que você especifica;  Mudar de ideia, substituir funcionalidades e alterar prioridades sem ter que pagar um preço exorbitante;  Ser informado sobre mudanças no cronograma a tempo de decidir como reduzir o escopo para ser capaz de manter a data original;  Cancelar o projeto a qualquer momento e receber um sistema executável que reflete todo o investimento que foi feito até a data do cancelamento.
  60. 60. eXtreme Programming Direitos do Desenvolvedor  Saber quais são as necessidades, bem como suas prioridades;  Produzir um trabalho de alta qualidade permanentemente;  Pedir e receber ajuda de seus colegas e do cliente;  Gerar e atualizar as suas estimativas;  Escolher as suas responsabilidades, ao invés delas serem determinadas para você.
  61. 61. eXtreme Programming Escrevendo Estórias Todas as funcionalidades do sistema são levantadas através de estórias que são registradas em pequenos cartões. Estas estórias devem ser escritas pelo cliente, com suas próprias palavras.
  62. 62. eXtreme Programming Escrevendo Estórias Embora possa parecer estranho pedir ao cliente para escrever as estórias, existem fortes razões para isso:  O cliente é forçado a pensar melhor na funcionalidade;  O cliente se torna responsável sobre aquilo que está sendo solicitado;  Fazer o cliente perceber que está gastando ao pedir uma funcionalidade.
  63. 63. eXtreme Programming Tarefas A equipe de desenvolvimento utiliza os cartões para saber quais são as funcionalidades desejadas pelo cliente. Os desenvolvedores escolhem as estórias que irão implementar a cada dia de trabalho. Entretanto, em projeto muito grande, os cartões podem acabar representando estórias que consomem muito esforço para implementar. Nestes casos, é comum a equipe dividir os cartões em tarefas. Elas são registradas em novos cartões de modo que possam ser distribuídas facilmente entre a equipe de desenvolvedores. Exemplos: 1. Apresente ao cliente 10 tarifas mais baratas para uma determinada rota; 2. O usuário deve poder alterar o seu perfil (email, senha, primeiro nome, ultimo nome e filiação). Dois campos de senha para confirmação.
  64. 64. eXtreme Programming Estimando Estórias Para estimar a equipe de desenvolvimento precisa adotar uma unidade de medida que será usada para todas as estórias. Os desenvolvedores costumam estimar indicando a quantidade de tempo (horas) que uma funcionalidade irá consumir. O XP utiliza o conceito de dia ideal de desenvolvimento, que representa um dia no qual o desenvolvedor trabalha na implementação de funcionalidades, sem ter que se preocupar com nenhuma atividade extra. Usando pontos para estimar Estimando por comparação Estimando em equipe
  65. 65. eXtreme Programming Planejando os Releases O XP trabalha com o objetivo de gerar valor para o cliente ao longo de todo o projeto. Para fazer isso, é importante que o software seja entregue de forma incremental, de modo que após cada entrega o cliente possa começar a utilizar o sistema e obter os benefícios que ele oferece. Estas entregas recebem o nome de release em XP. Os projetos em XP costumas ser divididos em releases, de modo que cada release implementa um conjunto de funcionalidades que possui um valor bem definido para o cliente. Por exemplo, imagine que o projeto de oito meses seja dividido em quatro releases, como ilustrado na figura abaixo. 8 sem. Projeto dividido em releases
  66. 66. eXtreme Programming Projeto Dividido em Releases Suponha que este seja o projeto de um site de vendas on-line de uma grande loja de departamentos. Poderíamos imaginar a seguinte distribuição para os releases:  R1: Consulta dos produtos em estoque;  R2: Processamento de compras on-line;  R3: Acompanhamento de pedidos;  R4: Campanha de marketing de relacionamento. Projetos XP procuram trabalhar com o conceito de releases pequenos, isto é, os releases têm curta duração. Preferencialmente, devem ter em torno de dois meses. Com isso, o cliente pode começar a usufruir os benefícios do software e a equipe de desenvolvimento passa a ter a oportunidade de receber feedback dos usuários finais do sistema, o que permite que ela faça ajustes, de modo a aprimorar a qualidade dos releases subsequentes.
  67. 67. eXtreme Programming Priorizando as Estórias de Cada Release  As releases devem ter tamanhos fixos e pequenos  Estabelecer a ordem (necessidades do cliente)  Verificar a NECESSIDADE X ASPECTOS TÉCNICOS. Observar as dependências técnicas  Distribuir as estórias nos seus respectivos releases  Não é necessário escrever todas as estórias do sistema no início do projeto  O cliente deve se concentrar nas estórias da primeira release (as outras, deixar para o futuro para evitar trabalho especulativo)  Dedicação nas estórias do release corrente e criar estórias para os releases futuros
  68. 68. eXtreme Programming Planejando as Iterações Uma iteração é basicamente um pequeno espaço de tempo dedicado para a implementação de um conjunto de estórias. Em sua maioria, os projetos XP utilizam iterações de duas semanas. O início de cada iteração é caracterizado por uma reunião que recebe o nome de reunião de planejamento da iteração. Tamanho da iteração = 2 semanas = 10 dias úteis Deve-se descontar:  1 dia útil para a reunião de planejamento de iteração  1 dia útil para o encerramento da iteração Dias úteis para desenvolvimento = 10 – 2 = 8  Número de desenvolvedores = 4 = 2 x 2 = 2 pares  1 par/dia = 1 ponto  1 par em 8 dias = 1 x 8 = 8 pontos  2 pares em 8 dias = 2 x 8 = 16 pontos
  69. 69. eXtreme Programming Dependências Técnicas A ordem em que o cliente deseja que as estórias sejam implementadas é afetada por dependências técnicas que a equipe deve identificar e lhe apresentar. O XP recomenda que a equipe procure sempre respeitar a ordem indicada pelo cliente. Na maioria dos casos isso é perfeitamente possível, desde que a equipe implemente algumas simplificações. As dependências técnicas costumam ser bem menos criticas do que aparentam. Para contorná-las a equipe deve ser criativa e buscar soluções que permitam ao cliente acesso às estórias tal como ele as ordena. Iterações são diferentes de releases: O XP apresenta um meio termo que permite que o cliente tenha flexibilidade e a equipe trabalhe com estabilidade. Durante todo o projeto, o cliente pode fazer alterações nas estórias. Já dentro de uma iteração, e apenas neste caso, o cliente tem que respeitar o acordo da reunião de planejamento.
  70. 70. eXtreme Programming Encerrando uma Iteração O último dia da iteração é reservado para uma reunião de encerramento. Nela, o cliente executa todos os teste de aceitação que foram escritos para as estórias da iteração. O objetivo é que ele valide todo sistema e verifique se o resultado da iteração está satisfatório. Utilizando o sistema ele poderá detectar eventuais erros, bem como aprender mais sobre os requisitos e, se houver necessidade, fazer mudanças nos mesmos.
  71. 71. eXtreme Programming Encerrando um Release Um release se encerra ao final da ultima iteração prevista pra ele. Ao final do release, a equipe coloca o sistema em produção para que todos os usuários passem a ter acesso a ele. Quanto mais entradas em produção o projeto tiver, melhor será o seu resultado para os usuários, visto que a cada release eles terão a oportunidade de fornecer feedback para a equipe de desenvolvimento. Isso ajudará a equipe a direcionar seus esforços pata fazer com que o sistema fique cada vez mais adequado às necessidades de seus usuários.
  72. 72. eXtreme Programming Stand up Meeting Um dia de trabalho de uma equipe XP sempre começa com um stand up meeting. Este nome significa “reunião em pé” em inglês. Esta reunião não tem apenas o objetivo de avaliar o passado. Ela também é utilizada para decidir o que será feito no dia que se inicia. Ela serve para priorizar as atividades dos membros da equipe ao longo do dia.
  73. 73. eXtreme Programming Diariamente, no stand up meeting, a equipe decide em conjunto que cartões serão tratados naquele dia e quem cuidará de cada cartão. No fim do stand up meeting, cada membro da equipe sabe o que deverá fazer ao longo do dia. É importante notar que a decisão sobre o que fazer ao longo do dia não é tomada por uma única pessoa. Essa decisão é tomada em equipe. Stand up Meeting
  74. 74. eXtreme Programming Programação em Par Os desenvolvedores não trabalham sozinhos em um projeto que utilize XP. Eles sempre trabalham em pares. Trata-se da programação em par ou pair programming, como é conhecido em inglês.
  75. 75. eXtreme Programming Os efeitos sobre a produtividade da equipe A ideia da programação em par parece estranha a princípio porque “enquanto um desenvolvedor o outro fica parado”. Isto é, “um trabalha enquanto o outro não faz nada”. Obviamente não é isso o que ocorre, mas é isso o que muita gente acaba interpretando erroneamente. Na verdade, um desenvolvedor digita enquanto o outro não digita. Mas, ambos estão programando juntos. A programação em par pressupõe uma comunicação contínua entre os desenvolvedores que formam o par. Através da conversa, eles discutem as melhores alternativas, corrigem erros, analisam cenários, enfim, discutem as melhores ideias para a resolução de cada problema. Portanto, é absolutamente incorreto acreditar que um trabalha enquanto o outro fica parado. Ambos estão trabalhando o tempo todo.
  76. 76. eXtreme Programming A pressão do Par O ato de programar demanda grande concentração e produz um gasto de energia considerável. Entretanto, no dia-a-dia de um programador, ele se depara com diversas fontes de distração: email, bate-papo com colegas, cansaço. Isto diminui seu ritmo de trabalho no código. A programação em par corrige estes desvios através da pressão em par. O programador quando está acompanhado de outra pessoa, ele deixa de ter um compromisso apenas consigo mesmo. O seu compromisso se expande e passa a englobar também o seu colega. Ou seja, sua responsabilidade aumenta já que passa a envolver mais alguém. O efeito disso é que diversos focos de distração são eliminados.
  77. 77. eXtreme Programming Revezamento A condução da programação é uma atividade que deve ser realizada sempre por ambos os programadores que formam um par. Um de cada vez, naturalmente. Para isso, é fundamental que eles se revezem diversas vezes ao longo de um dia de trabalho. O revezamento não se aplica apenas à questão de quem conduz o teclado. Ele também nos leva à questão de quem será o nosso par. Em um projeto, devemos trocar de par com frequência. Esta troca de par é importante para a disseminação do conhecimento.
  78. 78. eXtreme Programming Desafios  A organização do escritório  A visão gerencial  O relacionamento humano  Competição
  79. 79. eXtreme Programming Refactoring Desenvolvimento Guiado por Testes (TDD)
  80. 80. eXtreme Programming Refactoring – Conceitos básicos Refactoring é o processo de modificar um software para melhorar a estrutura interna do código. Esse processo não repara erros e nem adiciona novas funcionalidades. Outra consequência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão de bugs. Esta melhora no entendimento vem da constante alteração do código com objetivo de facilitar a comunicação de motivações, intenções e objetivos por parte do programador.
  81. 81. eXtreme Programming  Obter um código-fonte claro e de fácil manutenção  Reduzir a complexidade da aplicação  Remover redundâncias desnecessárias  Reutilizar código  Otimizar o desempenho do software. Objetivos Básicos
  82. 82. eXtreme Programming Desenvolvimento Guiado pelos Testes (TDD) Teste é parte do desenvolvimento de software que todo mundo sabe que precisa ser feita, mas ninguem quer fazer. Testar costuma ser considerado uma atividade chata, que consome tempo e só é valorizada depois que o sistema entra em produção e diversos problemas começam a surgir. Grande parte dos projetos deixam os testes para serem feitos no final (isso quando são feitos!)
  83. 83. eXtreme Programming Por que Devemos Testar? Se o desenvolvedor escreve um código incorreto e descobre isso dois meses depois, a sua capacidade de aprendizado é muito baixa. Por outro lado, se ele descobre alguns segundos após introduzir o erro, ele aprende rapidamente que tipo de coisa ele fez que gera erro. Sendo assim, ele provavelmente não errará de novo no futuro. Quando os testes fazem parte do desenvolvimento, os programadores recebem feedback rapidamente sobre aquilo que estão fazendo. Com isso aprendem mais, resolvem os defeitos e tem mais tempo para desenvolver funcionalidades e gerar valor para o cliente.
  84. 84. eXtreme Programming Testar é Investir Quando testamos, estamos fazendo um investimento e esperamos que ele gere um retorno no futuro. No caso de testes, este retorno acontece quando: • O desenvolvedor testa alguma coisa que deveria falhar e ela simplesmente funciona. • O teste falha quando já vinha funcionando normalmente, ou seja, surgiu um defeito no sistema e o teste detectou.
  85. 85. eXtreme Programming Testando o XP O XP trabalha com dois tipos de testes: testes de unidade e testes de aceitação. Testes de unidade: é aquele realizado em cada classe do sistema para verificar se os resultados gerados são corretos. Testes de aceitação: São efetuados sobre cada funcionalidade, ou estória do sistema.
  86. 86. eXtreme Programming Testes de Unidade  Devem ser automatizados  100% deles devem rodar corretamente ao longo de todo o desenvolvimento Desafios  Visto como aumento de trabalho pela equipe  A programação em par  Início difícil de trabalhar e automatizar Fatores essenciais  Conhecimento  Ferramentas  Programação em par  Persistência
  87. 87. eXtreme Programming Questões sobre os Testes de Unidade  Testes com acesso a um BD?  Testes rodando muito lentamente?  E quando não consigo imaginar como testar uma classe?  Como saber se testei tudo que podera quebrar?  Código já escrito e não existem testes pra ele?  Erros que aparecem da colaboração entre diferentes classes?  GUIs?  Meu código não pode ser testado porque…  Testar a entrega
  88. 88. eXtreme Programming Testes de Aceitação Além de verificar se cada classe está funcionando corretamente, é importante verificar se as classes englobadas por uma estória estão se relacionando corretamente. Quem cria e executa estes testes? Cliente? Analista de testes? Os dois? Testando em cada iteração  Descrever os testes em cartões, depois juntem estes aos cartões da estória.  Um cartão só pode ser considerado finalizado quando o teste de aceitação do mesmo for executado com sucesso. Automatizando HTML  HttpUnit Java  Jbehave, Selenium WebDriver, …
  89. 89. Exemplo de Teste de Aceitação Estória Visualizar os itens do carrinho de compras Número Ação Resultado esperado 1  Entrar no site  Visualizar os itens do carrinho de compras Mostra a mensagem: “Seu carrinho de compras está vazio” 2  Adicionar ao carrinho o produto: “Geladeira 380L”  Visualizar os itens do carrinho de compras Mostra uma linha contendo a informação: Geladeira 380L – 1 unidade – R$1500,00 3  Adicionar ao carrinho o produto: “Fogão 4 bocas”  Visualizar os itens do carrinho de compras Mostra uma linha contendo a informação: Geladeira 380L – 1 unidade – R$1500,00 Fogão 4 bocas – 1 unidade – R$750,00 4  Visualizar os itens do carrinho de compras  Clicar em “Excluir” ao lado da linha que contém a geladeira Mostra uma linha contendo a informação: Fogão 4 bocas – 1 unidade – R$750,00 5  Visualizar os itens do carrinho de compras  Clicar em “Excluir” ao lado da linha que contém o fogão Mostra a mensagem: “Seu carrinho de compras está vazio”
  90. 90. eXtreme Programming
  91. 91. eXtreme Programming Código Coletivo Padrões de Codificação
  92. 92. eXtreme Programming Código Coletivo Quando um projeto é implementado por uma equipe, é comum dividi-lo em partes, de modo que cada membro da equipe fique responsável por uma ou mais partes. Desta forma, cada pessoa é responsável por um subconjunto do código que forma o projeto. A divisão do trabalho é uma prática comum em diversa áreas profissionais. A forma como esta divisão é feita afeta diretamente o resultado final de um projeto. É bastante comum encontrarmos “ilhas de conhecimento” nos projetos de software. Uma “ilha de conhecimento” pode ser compreendida como sendo uma pessoa que possui um domínio sobre uma área do projeto. Somente ela conhece aquela parte ou aquele código. Se outra pessoa precisar mexer naquela parte, deverá solicitar à ilha de conhecimento que entre em ação.
  93. 93. eXtreme Programming A programação em par, por si só, já colabora para evitar a formação de “ilhas de conhecimento”. Porém, o código coletivo vai além. Ele dá a todas as pessoas a chance de mexer em qualquer parte do sistema. É importante que ele seja sempre escrito da maneira mais legível possível. Pois isto é o que garantirá que a equipe conseguirá continuar a implementar o sistema. Vale notar também que o código coletivo leva a equipe a ser mais ágil no desenvolvimento. Como não existe um responsável por certa parte do código, qualquer pessoa pode mexer nela tão logo sinta a necessidade de fazê-lo. Não é necessário esperar por ninguém, não é necessário esperar pelo especialista. Código Coletivo
  94. 94. eXtreme Programming Padrões de Codificação Se você analisar o código de diferentes programadores, provavelmente irá notar que existem diferenças de estilo. Por exemplo, um programador prefere colocar { no final da declaração de um método, enquanto outro prefere colocar na linha posterior. O XP recomenda que a equipe adote um padrão no início do projeto. Ela pode construir este padrão em conjunto ou pode adotar um que já exista e esteja documentado em algum lugar, como por exemplo: http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html
  95. 95. eXtreme Programming Padrões de Codificação Procure adotar um padrão que seja fácil e simples. Isso evita resistência e facilita a compreensão do código, ou seja, melhora a comunicação. Jeffries et al. (2001, p.79) apresenta alguns tópicos a considerar:  Identação  Letras maiúsculas e minúsculas  Comentários (evitá-los tanto quanto possível)  Nomes
  96. 96. eXtreme Programming Design Simples Metáfora
  97. 97. eXtreme Programming Design Tradicional “O custo de se corrigir um problema em um software cresce exponencialmente ao longo do tempo. Um problema que poderia ter custado um dólar para ser corrigido se tivesse sido encontrado durante a análise pode custar milhares de dólares para ser resolvido depois que o software já estiver em produção.”
  98. 98. eXtreme Programming O custo de uma alteração no XP A comunidade de desenvolvimento de software investiu uma enorme quantidade de recursos nas últimas décadas no sentido de reduzir os custos de uma alteração em um software. Estes investimentos gerou diversos avanços:  Melhores linguagens de programação  Avanços na tecnologia de banco de dados  Melhores práticas de programação  Novos ambientes e ferramentas de desenvolvimento  Computadores mais rápidos e mais baratos  Orientação a objetos
  99. 99. eXtreme Programming Infelizmente a única constante em um projeto de software é a mudança:  Os requisitos mudam  O design muda  A tecnologia muda  A equipe muda  Os membros da equipe mudam O problema não está na mudança em si, porque ela vai acontecer de qualquer jeito. O problema é a incapacidade de lidar com ela quando ela chegar. Design Tradicional
  100. 100. eXtreme Programming Estratégia Para alcançar um design simples, o XP recomenda que você utilize a seguinte estratégia: 1. Comece escrevendo um teste. 2. Faça o design e implemente apenas o suficiente para passar nos testes. 3. Execute os passos 1 e 2 novamente tanto quanto necessário. 4. Se você identificar a oportunidade de tornar o design mais simples, faça isso. No XP, o design é criado de forma incremental. Sendo assim, ao final da primeira iteração, o seu software terá um design bastante simples, suficiente para as funcionalidades daquela iteração. Na segunda, terá que fazer alguns refactorings e fará alterações no design, de modo a incorporar novas funcionalidades.
  101. 101. eXtreme Programming Simplicidade Exemplo de quatro regras básicas para definir simplicidade: 1. O sistema (código e testes em conjunto) deve expressar tudo aquilo que você deseja comunicar 2. O sistema não deve conter nenhum código duplicado 3. O sistema deve ter o menor número de classes possível 4. O sistema deve ter o menor número de métodos possível Atualmente, existe uma verdadeira febre pela utilização de frameworks que possam facilitar o desenvolvimento de sistemas. Tais frameworks contêm uma série de funcionalidades genéricas que podem poupar esforço da equipe ao longo do desenvolvimento. Entretanto, existem custos associados à utilização de frameworks: curva de aprendizado e são abrangentes demais.
  102. 102. eXtreme Programming Metáfora Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico.
  103. 103. eXtreme Programming XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua. Metáfora
  104. 104. eXtreme Programming Ritmo Sustentável Integração Contínua Releases Curtos
  105. 105. eXtreme Programming Ritmo Sustentável O XP PROÍBE que os desenvolvedores trabalhem até mais tarde. O XP sugere um ritmo sustentável de 40 HORAS SEMANAIS, respeitando assim a individualidade e o físico de cada desenvolvedor. Desta forma a equipe estará sempre concentrada e muito menos propensa a pequenas falhas na implementação.
  106. 106. eXtreme Programming Integração Contínua O XP propõe uma integração contínua, se possível deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém-desenvolvido. Com esta prática o feedback sobre a alteração efetuada será obtido em um menor espaço de tempo. Dificuldades em integrar diversas vezes ao dia:  Tempo de build  Código Coletivo  Programação em Par
  107. 107. eXtreme Programming Integração Contínua Segundo Jeffries et al. (2001), em XP o código avança em 3 fases:  Local: As mudanças que o par executou no código ainda não estão disponíveis para os demais.  Candidato à Liberação: O par terminou a tarefa e está tudo pornto para a disponibilização.  Disponibilizado: Código pronto. Testes 100%.
  108. 108. eXtreme Programming Integração Contínua Ferramentas: Para que seja feita a integração contínua, são necessárias ao menos duas categorias de ferramentas para auxiliá-lo:  Ferramenta de build – Ant ou Maven  Sistema de controle de versão (Repositório) – CVS, Git, ClearCase, SourceSafe (Team Foundation Server) etc.
  109. 109. eXtreme Programming Releases Curtos O XP recomenda que pequenos investimentos sejam efetuados de forma gradual e que busquem grandes recompensas o mais rapidamente possível. Com a prática de releases curtos, o XP pretende dar o máximo de valor econômico ao cliente em um curto espaço de tempo. Release é um conjunto de funcionalidades bem definidas e que representam algum valor para o cliente.
  110. 110. eXtreme Programming Releases Curtos
  111. 111.  Formado em Análise de Sistemas  Pós-Graduado em Auditoria em T.I.  Gerente de TI da CLIOC – Coleção de Leishmania do Instituto Oswaldo Cruz – Fiocruz  Certificado em Gestão de Segurança da Informação e Gerenciamento de T.I. pela Academia Latino-Americana (Microsoft TechNet / Módulo Security) Carlos Henrique M. da Silva carloshenrique.85@globo.com

×