Visão Geral sobre o XP – eXtreme Programming

Apresentação em tema: "Visão Geral sobre o XP – eXtreme Programming"— Transcrição da apresentação:

1 Visão Geral sobre o XP – eXtreme Programming
Alexandre Vasconcelos

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

3 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. “

4 Metodologias Ágeis eXtreme Programming FDD Lean Software Development
Cristal Family Scrum (...) Melhorar esse slide

5 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

6 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

7 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!

8 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

9 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 ...

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

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

12 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

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

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

15 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

16 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

17 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.

18 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. A 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.

19 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 em todos os testes.

20 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.

21 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" à 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

22 Um Projeto XP Criar as user stories que geram casos para os acceptances tests

23

24 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.

25 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

26 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

27 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

28 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

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

30 Referências XPRecife – Grupo de Estudos de Métodos Ágeis de Recife
Xispê – Portal Brasileiro de XP