Title: Vis
1Visão Geral sobre o XP eXtreme Programming
2Manifesto Ágil 1/5
- Assinado por 17 desenvolvedores com
reconhecimento mundial em Utah em fevereiro/2001.
- Declaração de 4 valores
- http//www.agilemanifesto.org/
3Manifesto Á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.
4Metodologias Ágeis
- eXtreme Programming
- FDD
- Lean Software Development
- Cristal Family
- Scrum
- (...)
5O 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
6O 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
7Programando 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!
8Mudanç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
9Avanç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 ...
10Mudar não é tão caro
custo
t
Requisitos
Análise
Projeto
Implementação
Testes
Produção
11XP inclui...
- Comunicação
- Coragem
- Feedback
- Simplicidade
- Respeito
12Comunicaçã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
13Coragem
- Extreme Programming é novo e diferente
- Atitude é mais importante que processo
- Coragem pra dizer a verdade, para recomeçar do
zero, para inovar
14Feedback
- Feedback lt-gt Comunicação
- Feedback aumenta aprendizado e produtividade
15Simplicidade
- 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
16Respeito
- 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
17Boas 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.
18Boas 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.
19Boas 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 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.
20Boas Práticas
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
São definidos pelo usuário e são os critérios de
aceitação do software.
21Boas Práticas
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
22Papé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
23Papé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
24Papéis no XP
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
25Papé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
26Um Projeto XP
27(No Transcript)
28Planejamento 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.
29Conclusão
- Extreme Programming
- Atitude
- Disciplina
- Mudança é algo normal
- Aceitar, não fugir
- Conjunto de boas práticas
30Referê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