1/30 Visão Geral sobre o XP – eXtreme Programming Alexandre Monteiro
Jan 12, 2016
1/30
Visão Geral sobre o XP – eXtreme Programming
Alexandre Monteiro
2/30
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/
3/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:
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/30
Metodologias Ágeis eXtreme ProgrammingeXtreme Programming FDD Lean Software Development Cristal Family Scrum (...)
5/30
Em meados de 1990, Kent BeckKent 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 surgimento do XPO surgimento do XP
6/30
“Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança”
O que é eXtreme Programming?O que é eXtreme Programming?
Kent BeckKent Beck
7/30
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/30
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/30
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/30
Mudar não é tão caro
Requisitos Análise Projeto Implementação
Testes Produção t
custo
11/30
XP inclui... Comunicação Coragem Feedback Simplicidade Respeito
12/30
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/30
Coragem Extreme Programming é novo e
diferente Atitude é mais importante que
processo Coragem pra dizer a verdade, para
recomeçar do zero, para inovar
14/30
Feedback Feedback <-> Comunicação Feedback aumenta aprendizado e
produtividade
15/30
Simplicidade Regra geral Pensar sempre : “ O que pode ser
feito que seja o mais simples que funciona?”
Simplicidade normalmente gera mais valoroverhead
Geração de valor
Simplicidade
16/30
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/30
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.
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.
Reuniões rápidas e diárias com a equipe
A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos.
18/30
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.
Todo código é desenvolvido seguindo um padrão.
E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo.
As duplas de programação são revezadas em média a cada 2h.
19/30
Boas Práticas 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 código está, a qualquer momento, na forma mais simples que passe todos os testes.
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.
20/30
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 .
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/30
Boas Práticas 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" 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/30
Papéis no XPBig Boss / XpManagerBig 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/30
Papéis no XPXp Gold Owner (Cliente - Xp Gold Owner (Cliente - O proprietário do O proprietário do ouroouro)
É quem paga pelo sistema, geralmente o dono da empresa.
Deve fazer:
• Escrever User Stories
• Definir prioridades
• Definir testes de aceitação
• Validar testes de aceitação
• Esclarecer dúvidas
Xp Goal DonorXp Goal Donor
Não deve fazer:
• Implementar código
• Definir quanto tempo uma tarefa leva para ser feita
24/30
Papéis no XPXp Coach Xp TrackerXp Coach Xp Tracker
Responsável pela negociação com o cliente quanto ao escopo e pela coordenação do Planning Game.
CoordenadoresCoordenadores
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)
25/30
Papéis no XP
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
Programador Programador (Driver/Partner)(Driver/Partner)
26/30
Um Projeto XP
27/30
28/30
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/30
Conclusão Extreme Programming
Atitude Disciplina
Mudança é algo normal Aceitar, não fugir
Conjunto de boas práticas
30/30
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