Viso Geral sobre o XP e Xtreme Programming

Visão Geral sobre o XP – e. Xtreme Programming Alexandre Vasconcelos (amlv@cin. ufpe. br) 1/30

Manifesto Ágil [1/5] n n n Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001. Declaração de 4 valores http: //www. agilemanifesto. org/ 2/30

Manifesto Ágil [2/2] “Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a entender que: n n Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o cliente é mais importante do que negociação de contratos. Adaptação a mudanças é mais importante do que seguir o plano inicial. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. “ 3/30

Metodologias Ágeis n n n e. Xtreme Programming FDD Lean Software Development Cristal Family Scrum (. . . ) 4/30

O surgimento do XP n Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software n n Identificou o que tornava simples e o que dificultava o desenvolvimento de software Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia XP - e. Xtreme Programming 5/30

O que é e. Xtreme Programming? “Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” Kent Beck 6/30

Programando ao Extremo n Levar todas as boas práticas ao Extremo n n Se testar é bom, vamos testar toda hora!! Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! Se integrar é bom, vamos integrar a maior quantidade de vezes possível! Se iterações curtas é bom, vamos deixar as iterações realmente curtas! 7/30

Mudanças sempre ocorrem n n n Clientes não sabem o querem no início Desenvolvedores não sabem qual a melhor maneira de fazer o software no início Medo da mudança trava o desenvolvimento 8/30

Avanços n Nos últimos 30 anos. . . n Melhoria nos processos n n Melhorias nas ferramentas n n Iterativo Incremental IDEs, automação. . . Maior abstração no desenvolvimento n n n Orientação a Objetos Orientação a Aspectos Orientação a. . . 9/30

Mudar não é tão caro custo Requisitos Análise Projeto Implementação Testes Produção t 10/30

XP inclui. . . n n n Comunicação Coragem Feedback Simplicidade Respeito 11/30

Comunicação n n n Soluções de problemas normalmente já são conhecidas. . . O problema é a solução chegar a quem precisa Comunicação face a face é a maneira mais rápida de “espalhar” conhecimento 12/30

Coragem n n n Extreme Programming é novo e diferente Atitude é mais importante que processo Coragem pra dizer a verdade, para recomeçar do zero, para inovar 13/30

Feedback n n Feedback <-> Comunicação Feedback aumenta aprendizado e produtividade 14/30

Simplicidade n n n Regra geral Pensar sempre : “ O que pode ser feito que seja o mais simples que funciona? ” Simplicidade normalmente gera mais valor Geração de valor overhead Simplicidade 15/30

Respeito n n n Coragem, Feedback, Simplicidade, Comunicação. . . Respeito é necessário para tirar o máximo desses valores Respeito pelo próximo n n Feedback, Comunicação Respeito por si mesmo n Coragem, Simplicidade 16/30

Boas Práticas n n Test First Design Refactoring Stand-up Meeting Continuous Integration A criação de testes leva em conta não o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema. A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos. Reuniões rápidas e diárias com a equipe Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários. 17/30

Boas Práticas n n Pair Programming Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. Move People Around As duplas de programação são revezadas em média a cada 2 h. Collective Code Ownership A equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo. Coding Standards Todo código é desenvolvido seguindo um padrão. 18/30

Boas Práticas n n n The Customer is Always Available O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades. Small Release O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos. Simple Design O código está, a qualquer momento, na forma mais simples que passe em todos os testes. 19/30

Boas Práticas n 40 -Hour Week n On-Site Customer n Acceptance Tests Cada programador trabalha 40 horas por semana. Se o horário for flexível, deve -se respeitar o horário do par naquele período, senão enquanto um trabalha o outro vai pra casa Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas São definidos pelo usuário e são os critérios de aceitação do software. 20/30

Boas Práticas n A Fábrica O Correio Turista System Metaphor Ajuda a manter todos os desenvolvedores em sintonia com o projeto quando dando nomes a objetos ou classes. A idéia é que exista um objeto "produto" que sofre várias modificações ao longo da "linha de montagem", onde outros objetos trabalham sobre o produto. A vantagem é que é simples adicionar "máquinas novas" à linha de montagem. Quando o "produto" precisa passar pela mão de várias pessoas, às vezes para conhecimento, aprovação ou modificação do conteúdo. Podem existir modificações feitas pelo sistema, nesse caso, existem "destinatários virtuais" que recebem a mensagem, analisam e despacham para quem deve. A diferença básica do Correio para a Fábrica é que ele não segue uma linha. O objeto é um "turista", o Servlet e o Banco são hospedagens, os dados são a bagagem, o objeto que tira os dados do "turista" e coloca ou no Servlet (em XML) ou no Banco são "carregadores de bagagem". Quando a "bagagem" está guardada no hotel "Banco de Dados“, o "turista" recebe um ticket da bagagem para poder pegar ela depois (o Identificador único da tabela). 21/30

Um Projeto XP 22/30

23/30

Planejamento das iterações n n n Divida o projeto em etapas de 1 ou 2 semanas; Considere prazos fixos e escolha um dia da semana para integrações e entregas; (segunda ou sextafeira); Planeje reuniões diárias para acompanhar a evolução do projeto (“stand-up”, meeting matinal); As iterações serão as unidades de referência para fazer estimativas; Entre no jogo para entregar um produto a cada iteração. 24/30

Papéis no XP Big Boss / Xp. Manager Deve fazer: • Agendar reuniões; • Escrever atas; • Manter o XP Tracker informado dos acontecimentos das reuniões Não deve fazer: • Deixar que problemas externos interfiram no desenvolvimento • Dizer quando as coisas devem acontecer • Dizer às pessoas o que fazer • Cobrar das pessoas 25/30

Papéis no XP Xp Gold Owner (Cliente - O proprietário do ouro) ouro É quem paga pelo sistema, geralmente o dono da empresa. Xp Goal Donor Deve fazer: • Escrever User Stories • Definir prioridades • Definir testes de aceitação Não deve fazer: • Implementar código • Definir quanto tempo uma tarefa leva para ser feita • Validar testes de aceitação • Esclarecer dúvidas 26/30

Papéis no XP Xp Coach Coordenadores Xp Tracker Responsável pela negociação com o cliente quanto ao escopo e pela coordenação do Planning Game. Deve fazer: • Coletar métricas • Manter todos informados do que está acontecendo • Definir testes de aceitação • Tomar atitudes diante de problemas • Sugerir sessões de CRC (Class, Responsabilities, Collaboration) 27/30

Papéis no XP Programador (Driver/Partner) Deve fazer: • Estimar prazos de User Stories • Implementar código de produção • Trabalhar em par • Fazer refactoring • Corrigir bugs Não deve fazer: • Criar/Alterar novas funcionalidades • Escrever testes de aceitação 28/30

Conclusão n Extreme Programming n n n Mudança é algo normal n n Atitude Disciplina Aceitar, não fugir Conjunto de boas práticas 29/30

Referências n XPRecife – Grupo de Estudos de Métodos Ágeis de Recife n n www. cin. ufpe. br/~xprecife Xispê – Portal Brasileiro de XP n www. xispe. com. br 30/30