Visão Geral sobre o XP – eXtreme Programming Alexandre Monteiro
Manifesto Ágil [1/5] Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001. Declaração de 4 valores http://www.agilemanifesto.org/
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: 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. “
Metodologias Ágeis eXtreme Programming FDD Lean Software Development Cristal Family Scrum (...) Melhorar esse slide
O surgimento do XP Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software 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 - eXtreme Programming
O que é eXtreme 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
Programando ao Extremo Levar todas as boas práticas ao Extremo 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!
Mudanças sempre ocorrem Clientes não sabem o que 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
Avanços Nos últimos 30 anos... Melhoria nos processos Iterativo Incremental Melhorias nas ferramentas IDEs, automação... Maior abstração no desenvolvimento Orientação a Objetos Orientação a Aspectos Orientação a ...
Mudar não é tão caro custo t Requisitos Análise Projeto Implementação Testes Produção
XP inclui... Comunicação Coragem Feedback Simplicidade Respeito
Comunicação 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
Coragem Extreme Programming é novo e diferente Atitude é mais importante que processo Coragem pra dizer a verdade, para recomeçar do zero, para inovar
Feedback Feedback <-> Comunicação Feedback aumenta aprendizado e produtividade
Simplicidade 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
Respeito Coragem, Feedback, Simplicidade, Comunicação... Respeito é necessário para tirar o máximo desses valores Respeito pelo próximo Feedback, Comunicação Respeito por si mesmo Coragem, Simplicidade
Boas Práticas 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.
Boas Práticas Pair Programming Move People Around Collective Code Ownership Coding Standards Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. As duplas de programação são revezadas em média a cada 2h. E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo. Todo código é desenvolvido seguindo um padrão.
Boas Práticas Small Release Simple Design The Customer is Always Available Small Release Simple Design O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades. 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. O código está, a qualquer momento, na forma mais simples que passe todos os testes.
Boas Práticas 40-Hour Week On-Site Customer 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 . 40-Hour Week On-Site Customer Acceptance Tests 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.
Boas Práticas System Metaphor A Fábrica O Correio Turista Ajuda a manter todos os desenvolvedores em sintonia com o projeto quando dando nomes a objetos ou classes. System Metaphor 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" a linha de montagem. A Fábrica 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 Correio 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). Turista
Papéis no XP Big Boss / XpManager 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
Papéis no XP Xp Gold Owner (Cliente - O proprietário do 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 Validar testes de aceitação Esclarecer dúvidas Não deve fazer: Implementar código Definir quanto tempo uma tarefa leva para ser feita
Papéis no XP métricas Coordenadores Xp Coach 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) métricas
Programador (Driver/Partner) 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
Um Projeto XP Criar as user stories que geram casos para os acceptances tests
Planejamento das iterações 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 sexta-feira); 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.
Conclusão Extreme Programming Mudança é algo normal Atitude Disciplina Mudança é algo normal Aceitar, não fugir Conjunto de boas práticas
Referências XPRecife – Grupo de Estudos de Métodos Ágeis de Recife www.cin.ufpe.br/~xprecife Xispê – Portal Brasileiro de XP www.xispe.com.br