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 Monteiro

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

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

22 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

23 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

24 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

25 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

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

27

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

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