|
1
|
|
|
2
|
- Vinicius Manhaes Teles, Extreme Programming, Novatec Editora
- Agile Software Development
- Scrum and XP from the Trenches
- Martin Fowler, Analysis Patterns - Reusable Object Models,
Addison-Wesley,1997
- Martin Fowler, Refatoração - Aperfeiçoando o projeto de código existente,
Ed Bookman
|
|
3
|
- Introdução
- Valores do XP
- Bugs e Tests
- Valores e Princípios do XP
- Praticas do XP
|
|
4
|
|
|
5
|
- Grupos de 2 a 10 programadores
- Projetos de 1 a 36 meses (calendário)
- De 1000 a 250 000 linhas de código
- Papéis:
- Programadores (foco central)(sem
hierarquia)
- “Treinador” ou “Técnico” (coach)
- “Acompanhador” (tracker)
- Cliente
|
|
6
|
- Você ainda pode aprender muito sobre desenvolvimento de software.
- Terá elementos para repensar as suas práticas.
- No início se dizia:
- “Ou você é 100% eXtremo ou não é eXtremo. Não dá prá ser 80% XP.”
- XP is now like teenage sex.
- Hoje não é mais necessariamente assim.
|
|
7
|
- Metodologia de desenvolvimento de software aperfeiçoada nos últimos 10
anos.
- Ganhou notoriedade a partir da OOPSLA’2000.
- Projetos com requisitos muito voláteis
- Equipes pequenas (até ~10 pessoas)
- Desenvolvimento incremental
- Nomes: Kent Beck, Ward Cunningham, and Ron Jeffries em 2000
|
|
8
|
- Valores:
- Simplicidade
- Comunicação
- Feedback
- Coragem
|
|
9
|
- Jogo do Planejamento
- Pequenas Versões
- Projeto Simples
- Refatoração
- Teste Primeiro
- Programação em Pares
|
|
10
|
- Modelo Tradicional:
- Tempo
- Escopo
- Custo
- Manipula-se a Qualidade
|
|
11
|
|
|
12
|
- XP é o mais importante movimento
em nosso campo hoje em dia. Eu estou prevendo que ele será tão essencial
para a geração atual quanto o SEI e o Capability Maturity Model (CMM)
foram para o passado.
- Tom DeMarco (2000)
|
|
13
|
|
|
14
|
|
|
15
|
- XP não é uma idéia totalmente terminada
- Os limites de sua aplicação ainda não estão bem definidos
- As práticas do método não precisam ser adotadas todas de um vez
- O principal objetivo do XP é reduzir o cliclo de desenvolvimento de
alguns anos para alguns dias ou horas...
|
|
16
|
- As práticas do XP:
- Jogo de planejamento
- As decisões sobre os prazos e escopo são tomadas pelos clientes...
- Pequenas liberações
- Devem ser feitas liberações o mais rápido possível para o ambiente de
produção...
- Metáfora
- É definida uma metáfora para o objetivo do sistema...
- Projeto simplificado
- O código deve ser sempre o mais simples possível...
- Testes
- Os testes unitários são escritos pelos programadores com bastante
frequência. Os clientes escrevem os testes de aceitação. Os resultados
dos testes são pu-blicados e ficam visíveis para todos da equipe...
|
|
17
|
- As práticas do XP...
- Redesenho
- O código vai sendo melhorado aos poucos...
- Programação em pares
- Todo o código é escrito por um par de programadores...
- Integração contínua
- Novas classes e métodos são integrados imediatamente...
- Propriedade coletiva do código
- Qualquer programador, a qualquer momento, pode alterar qualquer porção
do código fonte...
- Cliente disponível
- O cliente ou usuário fica integralmente disponível para a equipe...
|
|
18
|
- As práticas do XP...
- Semana de 40 horas
- Se houver necessidade de trabalho extra, é sinal que há problemas...
- Ambiente aberto
- O time trabalha em um ambiente bastante espaçoso. O grupo de
pro-gramação trabalha em estações de trabalho localizadas no centro do
ambiente
- Somente regras
- As regras podem ser adaptadas e melhoradas, de acordo com a
ne-cessidade. Elas são importantes mas são apenas regras...
|
|
19
|
- Sobre o processo proposto pelo XP...
- Ele se inicia com o cliente escolhendo as funcionalidades que serão
implementadas. Estas funcionalidades são chamadas de estórias do
usuário (user stories). A escolha leva em conta a estimativa de
custo/tempo feita pelos programadores
- o desenvolvimento é fortemente guiado a testes (TDD: Test-Driven
Development). Os programadores escrevem testes unitários, que são
classes que automatizam sequências de testes sobre outras classes. São
escritos antes do código estar completo...
- Normalmente no par de programadores procura-se unir um com muita
experiência em TDD e outro com pouca ou nenhuma ex-periência nesta
técnica.
|
|
20
|
- Sobre as estórias dos usuários...
- Uma estória do usuário é uma unidade funcional...
- Ela deve ser entendida pelos clientes e usuários, deve ser testável,
deve ter valor para o cliente e deve ser pequena o bastante para que os
programadores possam construir dúzias delas em um ciclo de iteração...
- Ela é formada por uma ou duas sentenças que descrevem algo com valor
para o cliente:
- o sistema deve verificar se o CPF do cliente é um número válido...
- Os programadores deverão ser capazes de estimar o custo/tempo para
implementar a estória. Caso isto não seja possível, a estória deve ser
subdividida em estórias menores, para serem estimadas...
- As estórias do usuários devem ser criadas pelos clientes e usuários. Os
desenvolvedores concentram-se nas decisões técnicas...
|
|
21
|
- Priorizando as estórias dos usuários...
- O principal critério de ordenamento das estórias é o valor para o
negócio...
- Não existe consenso nisto:
- “vamos confessar que nós não concordamos neste ponto (priorização das
estórias com base no risco técnico). Martin é muito mais inclina-do a
trazer as estórias de maior risco técnico para o início do plano do
que Kent o é. Kent considera Martin um covarde por esta atitude.
Martin concorda.”
- Kent Beck e Martin Fowler, em
- Planning Extreme Programming,
- Addison-Wesley, 2000
- Busca-se consenso negociado quando houver problemas de priori-zação.
Entretanto, a última palavra é dos clientes: eles é que estão pagando o
projeto...
|
|
22
|
- Reportanto o progresso de um projeto XP
- O progresso de cada iteração é medido e reportado por uma pessoa
chamada tracker...
- A cada programador, o tracker faz duas perguntas básicas:
- Quantos dias ideais você já trabalhou nesta tarefa?
- Mais quantos dias ideais você precisa para completar a tarefa?
- Se o tracker descobre que um programador não vai conseguir terminar sua
tarefa, ele tenta redistribuir o encargo para outro programa-dor que
esteja com alguma folga. Caso isto não seja possível, o cliente deve
ser informado...
- As iterações no XP terminam na data estimada. As estórias
implementadas, são apresentadas aos clientes, que decidirá se está
adequada, a qual, neste caso, será considerada completa. As estórias
incompletas serão consideradas para a próxima iteração...
|
|
23
|
- APRENDIZADO
- O cliente aprende durante o desenvolvimento
- Descobre novas possibilidades
- Muda as prioridades
- Sistema deve acompanhar o aprendizado
- FEEDBACK
- DESENVOLVIMENTO ITERATIVO
|
|
24
|
- O cliente aprende durante o desenvolvimento
- Descobre novas possibilidades
- Muda as prioridades
- Sistema deve acompanhar o aprendizado
|
|
25
|
|
|
26
|
- Feedback
- Comunicação
- Simplicidade
- Coragem
|
|
27
|
- Escrever código.
- Mudar de idéia.
- Ir em frente sem saber tudo sobre o futuro.
- Confiar em outras pessoas.
- Mudar a arquitetura de um sistema em funcionamento.
- Escrever testes.
|
|
28
|
- Feedback rápido
- Simplicidade é o melhor negócio
- Mudanças incrementais
- Abraçar mudanças - Carregue a bandeira das mudanças / não valorize o medo (Embrace change)
- Alta qualidade.
|
|
29
|
|
|
30
|
- Planejamento
- Fases Pequenas
- Metáfora
- Design Simples
- Testes
- Refatoramento
- Programação Pareada
- Propriedade Coletiva
- Integração Contínua
- Semana de 40 horas
- Cliente junto aos desenvolvedores
- Padronização do código
|
|
31
|
- Funcionalidades são informadas através de user stories
- Estórias devem ser simples
- Desenvolvedores estimam tempo
|
|
32
|
- Responsável por escrever “histórias”.
- Muitas vezes é um programador ou é representado por um programador do
grupo.
- Trabalha no mesmo espaço físico do grupo.
- Novas versões são enviadas para produção todo mês (ou toda semana).
- Feedback do cliente é essencial.
- Requisitos mudam (e isso não é mau).
|
|
33
|
- Em geral, o mais experiente do grupo.
- Identifica quem é bom no que.
- Lembra a todos as regras do jogo (XP).
- Eventualmente faz programação pareada.
- Não desenha arquitetura, apenas chama a atenção para oportunidades de
melhorias.
- Seu papel diminui à medida em que o time fica mais maduro.
|
|
34
|
- A “consciência” do time.
- Coleta estatísticas sobre o andamento do projeto. Alguns exemplos:
- Número de historias definidas e implementadas.
- Número de unit tests.
- Número de testes funcionais definidos e funcionando.
- Número de classes, métodos, linhas de código
- Mantém histórico do progresso.
- Faz estimativas para o futuro.
|
|
35
|
- 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
|
|
36
|
|
|
37
|
- 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
|
|
38
|
- 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
|
|
39
|
- Reunião rápida
- Diária
- Usada para atualização da equipe
|
|
40
|
- Sistema é composto por pequenas peças
- Peças têm objetivos específicos
- Facilita construção
- Facilita evolução
|
|
41
|
- Todo código é escrito em par
- Duas pessoas trabalham em um único computador
- Uma digita, enquanto a outra revisa, corrige e sugere
|
|
42
|
- Erro de um detectado imediatamente pelo outro (grande economia de
tempo).
- Maior diversidade de idéias, técnicas, algoritmos.
- Enquanto um escreve, o outro pensa em contra-exemplos, problemas de
eficiência, etc.
- Vergonha de escrever código feio (gambiarras) na frente do seu par.
- Pareamento de acordo com especialidades.
- Ex.: Sistema Multimídia Orientado a Objetos
|
|
43
|
- 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
|
|
44
|
- Modelo tradicional: só autor de uma função pode modificá-la.
- XP: o código pertence a todos.
- Se alguém identifica uma oportunidade para simplificar, consertar ou
melhorar código escrito por outra pessoa, que o faça.
- Mas rode os testes!
|
|
45
|
- Padrões de estilo adotados pelo grupo inteiro.
- O mais claro possível.
- XP não se baseia em documentações detalhadas e extensas (perde-se
sincronia).
- Comentários sempre que necessários.
- Comentários padronizados.
- Programação Pareada ajuda muito!
|
|
46
|
- Melhorar o código permanentemente
- Alterações na implementação sem afetar a interface
|
|
47
|
- Uma [pequena] modificação no sistema que não altera o seu comportamento
funcional
- mas que melhora alguma qualidade não-funcional:
- simplicidade
- flexibilidade
- clareza
- desempenho
|
|
48
|
- 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)
|
|
49
|
|
|
50
|
- Sistemas podem ter defeitos
- É difícil descobrir qual é a peça defeituosa
- É mais fácil se o problema for detectado logo após a concepção da peça
|
|
51
|
- Fundamento mais importante de XP.
- É o que dá segurança e coragem ao grupo.
- Testes de unidades (Unit tests)
- escritos pelos programadores para testar cada elemento do sistema
(e.g., cada método em cada caso).
- Testes de funcionalidades (Functional tests)
- escritos pelos clientes para testar a funcionalidade do sistema.
|
|
52
|
- Testes das unidades do sistema
- Tem que estar sempre funcionando a 100%.
- São executados várias vezes por dia.
- Executados à noite automaticamente.
- Testes das funcionalidades
- Vão crescendo de 0% a 100%.
- Quando chegam a 100% acabou o projeto.
|
|
53
|
- Teste feito sobre cada classe
- Cada classe possui um unit test associado a ela
- Testes são automatizados
- Quando uma nova classe entra no sistema, todos os testes são executados
|
|
54
|
|
|
55
|
|
|
56
|
- Fase de Exploração
- duração: 2 a 6 meses.
- termina quando a primeira versão do software é enviada ao cliente.
- clientes escrevem “historias” (story cards).
- programadores interagem com clientes e discutem tecnologias.
- Não só discutem, experimentam diferentes tecnologias e arquiteturas
para o sistema.
- Planejamento: 1 a 2 dias.
|
|
57
|
- Escolhe uma história do cliente.
- Procura um par livre.
- Escolhe um computador para programação pareada (pair programming).
- Seleciona uma tarefa claramente relacionada a uma característica (feature)
desejada pelo cliente.
|
|
58
|
- Discute modificações recentes no sistema
- Discute história do cliente
- Testes
- Implementação
- Desenho
- Integração
|
|
59
|
- Atos constantes no desenvolvimento:
- Executa testes antigos.
- Busca oportunidades para simplificação.
- Modifica desenho e implementação incrementalmente baseado na
funcionalidade exigida no momento.
- Escreve novos testes.
- Enquanto todos os testes não rodam a 100%, o trabalho não está
terminado.
- Integra novo código ao repositório.
|
|
60
|
- Como conciliar diversos desenvolvedores?
- Estrutura de diretórios
- Atualização do código por várias pessoas diferentes
|
|
61
|
|
|
62
|
|
|
63
|
|
|
64
|
|
|
65
|
|
|
66
|
|
|
67
|
- 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
|
|
68
|
- Como lidar com diferentes ambientes?
- Exemplo:
- Desenvolvimento
- Aceitação
- Produção
|
|
69
|
|
|
70
|
- Possíveis erros devido a tarefas manuais repetitivas
- Gasto de tempo
|
|
71
|
- Agiliza as integrações
- Evita erros
|
|
72
|
|
|
73
|
- <project name="projeto" default="desenvolvimento">
- <target name="desenvolvimento">
- <mkdir dir="build"/>
- <javac srcdir="src"
destdir="build"/>
- <junit>
- <test name="test.SystemTester"/>
- </junit>
- </target>
- </project>
|
|
74
|
- Desejável que tenha:
- Code completion
- Validação on-line
- Suporte à depuração
- Suporte a refactoring
- Integração com jUnit
- Integração com CVS
- Integração com Ant
|
|
75
|
|
|
76
|
- Ganho de tempo
- Automação
- Facilidade de uso
- Verificação permanente do código
|
|
77
|
|
|
78
|
- 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: projeto full-XP em uma grande empresa brasileira (em
andamento)
- Set/2003: lançamento previsto do primeiro livro brasileiro sobre XP
|
|
79
|
- Site Xispê
- http://www.xispe.com.br
- XP Rio
- http://www.yahoogroups.com/groups/xprio
- Lista Xpers
- http://www.yahoogroups.com/groups/xpers
|
|
80
|
- jUnit
- http://www.junit.org
- CVS
- http://www.cvshome.org
- Ant
- http://ant.apache.org
- IntelliJ
- http://www.intellij.com
|
Anotações
