1
Extreme Programming
2 2
Manifesto do Desenvolvimento Ágil
www.agilealliance.org
Aplicar os ideais do desenvolvimento ágil ao nosso processo particular poderia nos ajudar a ser mais ágeis, mesmo que não pudéssemos adotar XP.
Indivíduos e interações mais que processos e ferramentas.
Trabalhar no software mais que documentação abrangente.
Colaboração do cliente mais que negociação contratual.
Responder às mudanças mais que seguir um plano.
3 3
O que é XP?
Processo de desenvolvimento de software Projetos com requisitos muito voláteis Equipes pequenas (até ~10 pessoas)
Desenvolvimento incremental
4 4
O que é um projeto de sucesso?
Cumpre o orçamento Cumpre o prazo Cliente fica feliz Equipe fica feliz
5 5
Premissas do desenvolvimento
Cliente é capaz de especificar um software antes de iniciar o desenvolvimento
Equipe de desenvolvimento é capaz de quantificar o esforço
Equipe é capaz de criar o software imaginado pelo cliente
Cliente ficará feliz
6 6
Resumo
Divisão nítida entre “produção” e “consumo”
Cliente produz uma especificação que é consumida pela equipe de desenvolvimento
Equipe de desenvolvimento produz o software que é consumido pelo cliente
7 7
Motivação: custo de uma alteração
Tempo de Projeto
Cu
sto
$ 1Requisitos
$ 10Análise
$ 100Design
$ 1.000Implem.
$ 10.000Testes
8 8
Premissas Básicas do Modelo Tradicional
É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema.
É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la.
É necessário testar o sistema completamente antes de mandar a versão final para o cliente.
9 9
Por que software falha?
10 10
Problemas desta premissa
Premissa é irreal em vários casos O cliente não é capaz de especificar o
software previamente Grande problema:
DETALHE
11 11
Premissa do desenvolvimento ágil APRENDIZADO FEEDBACK DESENVOLVIMENTO
ITERATIVO
12 12
Aprendizado O cliente aprende durante
o desenvolvimento Descobre novas
possibilidades Muda as prioridades
13 13
Trabalho intelectual
Retrabalho é uma característica do trabalho intelectual
ExperimentaçãoCriaçãoRevisãoExperimentação ...
14 14
Premissa: custo de uma alteração
Tempo de Projeto
Cu
sto
15 15
E se essa fosse a realidade?
A atitude dos desenvolvedores de software seria completamente diferente:Tomaríamos as grandes decisões o mais
tarde possível. Implementaríamos agora somente o que
precisamos agora.Não implementaríamos flexibilidade
desnecessária (não anteciparíamos necessidades).
16 16
E essa é a nova realidade !(pelo menos em muitos casos)
Orientação a Objetos facilita e cria oportunidades para mudanças
Técnicas de Refatoramento possibilita melhorar continuamente a implementação
aumentando constantemente a qualidade do código produzido
Testes automatizados nos dão segurança quando fazemos mudanças
Prática / cultura de mudanças aprendemos técnicas e adquirimos experiência em
lidar com código mutante
17 17
As 4 Variáveis do Desenvolvimento de Software
• Tempo
• Custo
• Qualidade
• Escopo (foco principal de XP)
18 18
Valores
FeedbackComunicaçãoSimplicidadeCoragem
19 19
User Stories
Funcionalidades são informadas através de user stories
Estórias devem ser simples
Desenvolvedores estimam tempo
20 20
Planejamento
De posse das estimativas, é possível priorizar
Cliente entrega as estórias priorizadas para serem implementadas
Desenvolvedores respeitam as prioridades dos clientes
Projeto é dividido em partes: releases e iterações
21 21
Priorização
Cliente deve priorizar as estórias
Para obter o máximo de valor rapidamente
Se baseia nas suas necessidades e nas estimativas dos desenvolvedores
22 22
Release e Iteração
R1 R2 R3 R4
I1
S1
8 Sem.
I2 I3 I4
2 Sem.
1 Sem.
S2
Projeto: 8 meses = 32 semanas
23 23
Release Planning
Cliente recebe um “orçamento” dos desenvolvedores
Seleciona as estórias prioritárias que possam ser implementadas dentro do orçamento
Pode trocar estórias durante o release
R1 R2 R3 R4
8 Sem.
24 24
Iteration Planning
Cliente recebe um “orçamento” Não pode haver troca de funcionalidades
durante uma iteração Velocidade: quantidade de estórias que a
equipe consegue implementar em uma iteração
I1 I2 I3 I4
2 Sem.
25 25
Stand-up meeting
Reunião rápida
Diária Usada para
atualização da equipe
26 26
Desenvolvimento: orientação a objetos Sistema é composto
por pequenas peças Peças têm objetivos
específicos Facilita construção Facilita evolução
27 27
Buscando bugs
Sistemas podem ter defeitos
É difícil descobrir qual é a peça defeituosa
É mais fácil se o problema for detectado logo após a adoção da peça
28 28
Test Driven Design
No XP, primeiro se especifica o teste
Depois se constrói a peça
29 29
Unit Test
Nome dado à verificação feita sobre cada peça
Cada peça possui um unit test associado a ela
Testes são automatizados Quando uma nova peça entra
no sistema, todos os testes são executados
30 30
31 31
32 32
Acceptance Test
Cliente deve especificar testes de aceitação para cada funcionalidade de uma iteração
Sistema deve passar nestes testes ao término da iteração
33 33
Pair Programming
Todo código é escrito em par
Duas pessoas trabalham em um único computador
Uma digita, enquanto a outra revisa, corrige e sugere
34 34
Collective code ownership
Todos são responsáveis por todas as partes do sistema
Código tem que estar sempre “limpo”
Todos são capazes de modificá-lo
35 35
Refactoring Uma [pequena] modificação no sistema
que não altera o seu comportamento funcional
mas que melhora alguma qualidade não-funcional:simplicidade flexibilidadeclarezadesempenho
36 36
Exemplos de Refactoring
Mudança do nome de variáveis
Mudanças nas interfaces dos objetos
Pequenas mudanças arquiteturais
Encapsular código repetido em um novo método
Generalização de métodos• raizQuadrada(float x) raiz(float x, int n)
37 37
Desenvolvimento em equipe
Como conciliar diversos desenvolvedores? Estrutura de diretórios Atualização do código por várias pessoas
diferentes
38 38
CVS – Repositório de fontes Check out Add Commit Update Conflict Remove
39 39
CVS
40 40
40 hour week
Desenvolvimento de software é um trabalho intelectual intenso
Não é produtivo trabalhar além do limite
41 41
Customer onsite Fator mais
importante no XP:ComunicaçãoFeedback
Viabiliza a simplicidade da metodologia
War room c / quadro branco
42 42
Feedback constante
Permite que pequenas mudanças sejam feitas
Evita a necessidade de mudanças bruscas
Mantém o projeto em curso
43 43
Integração contínua Máquina destacada para a integração Integração ocorre diversas vezes ao dia Os testes são executados em cada
integração Correções são feitas imediatamente
44 44
Ambientes para deployment
Como lidar com diferentes ambientes?
Exemplo:DesenvolvimentoAceitaçãoProdução
45 45
Ambientes para deployment
Desenvolvimento
Aceitação
Produção
46 46
Problemas de ter vários ambientes
Possíveis erros devido a tarefas manuais repetitivas
Gasto de tempo
47 47
Automatização do deployment
Agiliza as integrações Evita erros
48 48
Ant
49 49
Exemplo simples
<project name="projeto" default="desenvolvimento">
<target name="desenvolvimento"> <mkdir dir="build"/> <javac srcdir="src" destdir="build"/> <junit> <test name="test.SystemTester"/> </junit> </target>
</project>
targ
et
tasks
50 50
Ambiente de Desenvolvimento
Desejável que tenha:Code completionValidação on-lineSuporte à depuraçãoSuporte a Refactoring Integração com jUnit Integração com CVS Integração com Ant
51 51
Exemplos
52 52
Importância da IDE para o XP
Ganho de tempo Automação Facilidade de uso Verificação permanente do código
53 53
Importância da IDE para o XP
54 54
Steering Pequenas mudanças Ajustes simples ao
longo do tempo
X
55 55
Segredo do sucesso
O conjunto é o que faz a diferença
A ausência de uma prática mostra a deficiência de outras
Metáfora do time de futebol
56 56
XP e RUP
XP RUP
Foco nas práticas da equipe Foco nos artefatos
Comportamental Prescritivo
Projetos de determinados tamanhos
Qualquer projeto
57 57
Negociação
Venda técnica Venda focada em negócio Duas propostas:
Escopo fechadoEscopo variável
58 58
Resistências
Dificuldades com a área de TI Grande resistência dos desenvolvedores Pouca resistência na área usuária do
cliente Estratégia: pedido de tempo
59 59
Ambiente de desenvolvimento
Sala dedicada unicamente ao projeto Mural Quadros brancos Mesas que suportam programação em par Equipamentos com bom desempenho
60 60
XP no Brasil
2000: algumas práticas começam a ser usadas em projetos no Sul
Dez/2002: primeiro XP Brasil Jan/2003: fundação do XP Rio Fev/2003: primeiro projeto full-XP em uma
grande empresa brasileira (em andamento) Nov/2003: lançamento previsto do primeiro
livro brasileiro sobre XP
61 61
Referências Site Xispê
http://www.xispe.com.br XP Rio
http://www.yahoogroups.com/groups/xprio Lista Xpers
http://www.yahoogroups.com/groups/xpers
Top Related