Engenharia de Software
XP – eXtreme Programming
Prof. José Jorge Dias
Departamento de Ciências Exatas
Qualidade de Software
• Por que estudar o XP?
eXtreme Programming (XP)
• “
Metodologia ágil
para equipes pequenas a
médias desenvolvendo software com
requisitos
vagos
ou que
mudam freqüentemente
.” [Beck
2000]
• A
codificação
é a principal atividade
• Partes do XP:
– Valores – Princípios – Práticas
• XP pega essas
práticas do senso comum
e as
utiliza a
níveis extremos
Os 4 Valores da XP
• São as diretrizes da XP
• Define as
atitudes
da equipe XP
– Feedback
– Comunicação
– Simplicidade
– Coragem
Feedback
• Garante um rápido feedback sobre várias etapas do desenvolvimento
– O desenvolvedores sabem sobre a qualidade do código e do sistema
– Clientes sabem se os requisitos foram desenvolvidos
– Os desenvolvedores sabem as decisões e os problemas do projeto
• O cliente está o tempo todo em contato com a equipe • possibilita que as pessoas aprendam cada vez mais
sobre o sistema e assim corrijam os erros e melhorem o sistema
Comunicação
• Muitos problemas são causados porque
alguém não se comunicou com outro
• Uso
mínimo de documentação
e uso
máximo
de cara-a-cara
• Preferência a
comunicação ágil
• O próprio
código
é uma
forma de
comunicação
• Membros
introvertidos não são aconselháveis
Simplicidade
• “faça a coisa
mais simples que funcione
”
• Evita-se suposições
– Evita-se a criação de requisitos antecipados
• Faz-se o necessário
para entregar o requisito
do cliente
• Usa-se as tecnologias, algoritmos e técnicas
Coragem
• Necessária para que realmente se aplique XP
como deve ser aplicada
• Exemplos de atitude que exigem coragem:
– alterar código já escrito e que está funcionando – jogar código fora e reescrever tudo de novo
– permitir código compartilhado por todos – pedir ajuda a quem sabe mais
– ter a documentação em forma de código
– colocar desenvolvedores e clientes frente a frente – investir tempo em refactoring
Respeito
• Sustenta os 4 valores do XP
• Cada integrante precisa
– Saber Ouvir
– Saber compreender
– Respeitar o ponto de vista do outro
– Ter empatia pelo próximo
Princípios da XP
• Valores são abstratos demais para serem seguidos
– Conecta os valores às práticas do XP
• Princípios que as equipes que querem adotar XP devem seguir
• Ajuda na identificação de soluções de problemas
– A solução deve atender os princípios
• Os princípios são: – Feedback rápido – Assumir simplicidade – Mudança incremental – Abraçando mudanças – Trabalho de qualidade
Princípios da XP
• Feedback rápido
– Os participantes devem estar sempre se comunicando para facilitar o aprendizado coletivo
• Assumir simplicidade
– Deixe o seu modelo tão simples quanto possível e assuma que a solução mais simples é a melhor
• Mudança incremental
– O modelo não será perfeito na primeira tentativa, ele irá mudar de acordo com o desenvolvimento do
Princípios da XP
• Abraçando mudanças
– XP procura facilitar o ato de incluir alterações
através do uso de vários princípios e práticas
– Mudanças devem ser sempre bem vindas
independentemente do estágio de evolução do
projeto
• Trabalho de qualidade
– qualidade
não é um critério opcional, mas sim
obrigatório
Estórias do Usuário (User Stories)
• Representa os
requisitos do cliente
– Evita documentação pesada de um DDR
– escritas pelos clientes, como tarefas que o sistema
deve efetuar
– sem jargões
– usadas para criar estimativas de tempo, também
geram testes de aceitação
– um ou mais testes de aceitação devem ser escritos
para cada estória de uso
Exemplo
• "Uma palavra-chave não deve aceitar caracteres que não os A-Z, a-z e 0-9."
• "Depois de registrado, o cliente deve receber uma confirmação provisória do registro."
• "Se o código de utilizador estiver errado, o cliente deve ser informado do motivo."
“Um cliente deve-se registrar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica."
Estórias do Usuário (User Stories)
Práticas da XP
• Processo de
planejamento (Planning
Game)
• Releases curtos
• Metáfora
• Projeto simples
• Testes
• Refactoring
• Stand up meeting
• Programação em pares
• Propriedade coletiva do
código
• Integração contínua
• Semana de 40 horas
• On-site customer
(Cliente sempre
presente)
• Padrões de codificação
Cliente sempre presente
• Um
cliente
deve estar
sempre presente
– ajuda a equipe a responder questões
– resolver disputas
– colocar pequenas prioridades em tarefas.
• Sua
ausência
é um
risco
ao projeto
• As
funcionalidades
do sistema são descritas
brevemente em
estórias
– É necessário que o cliente esteja presente para
tirar as dúvidas sobre elas (Feedback)
Jogo do planejamento (Planning
Game)
• Planejamento de
releases
e
iterações
– Baseadas em estórias do usuário – As estórias são medidas
– Métrica utilizada: pontos (dias ideais)
• Um dia trabalhando sem nenhuma interferência externa • É aconselhável que uma estória tenha no máximo 4 pontos
– Um conjunto de estórias são definidas para serem desenvolvidas em uma release
– Cada release pode ter uma ou mais iterações – Iterações possuem de 1 a 3 semanas
• Possui um conjunto de estórias a serem desenvolvidas • As estórias podem ser quebradas em atividades
Jogo do planejamento (Planning
Game)
• Envolve equipe de negócio e equipe técnica
• A equipe deve trabalhar naquilo que tem mais
valor de negócio para o cliente
Releases pequenos/curtos
• Quanto menor a release, mais feedback
– Possibilita o aprendizado
– Maior correção de defeitos
Metáfora
• A metáfora é um meio de ajudar a
todos(clientes e desenvolvedores) a
compreender melhor o objetivo e propósito
do produto sendo criado.
• Pode ser uma analogia com algum outro
sistema (computacional, natural, abstrato)
que facilite a comunicação entre os membros
da equipe e cliente
Programação em pares
• Uma técnica onde dois desenvolvedores
trabalham no
mesmo problema
, ao
mesmo
tempo
e no
mesmo computador
– Condutor (piloto): digita
– Navegador (co-piloto): acompanha – Papéis são alternados
– Pares são trocados periodicamente
• O navegador revisa o que o condutor digita
• Troca de experiências e ideias
entre os
desenvolvedores
– Todos aprendem sobre o sistema – Código com mais qualidade
Propriedade coletiva do código
• Encoraja
a equipe inteira a trabalhar
mais
unida
em busca de
qualidade no código
fazendo melhorias
• Controle de versões
tem um papel
importante!
Refactoring
• Todo desenvolvedor tem
obrigação
de
melhorar o
código
– duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações
• A
alteração não pode mudar o comportamento
do código em questão
• Aumenta a
padronização
e facilita a
manutenção
• Deve ser apoiada pelos
testes automatizados
para verificar se ainda está funcionando
Testes constantes
• Dois tipos de testes: teste unitário e teste de aceitação • Testes fazem parte da documentação do sistema
• Teste de aceitação
– Verifica se a estória foi implementada de acordo com o que o usuario deseja
• Teste unitário
– Utiliza a abordagem TDD (Test Driven Development) – “Test first, then code”
– Testes automatizados
– Através deles o programador tem coragem de refatorar o código
Padrões de desenvolvimento
• O
código
também é uma forma da equipe se
comunicar
!
• O código escrito em projetos XP segue um
padrão de codificação
, definido pela equipe
– Padrão para nomes de métodos, classes, variáveis
– Organização do código
– Design patterns
• Facilita o
entendimento
e a
manutenção
do
código
Projeto (Design) simples
• Foco
no que a
estória
deve fazer
• O projeto se inicia simples e se mantém simples
– Vai melhorando com os refactorings
• Implementação ideal
é aquela que
– Roda todos os testes
– Expressa todas as idéias que você deseja expressar – Não contém código duplicado
Integração contínua
• Mantém o sistema
integrado
o tempo todo
• Pode ocorrer
várias vezes
ao dia
• Todos os
testes
devem ser executados
– Testes unitários
– Testes de integração
• Expõe o
estado atual
do desenvolvimento
• Oferece
mais feedback
sobre o sistema
Stand up meeting
• O dia de trabalho inicia com uma stand up
meeting (
reunião em pé
)
• Aproximadamente
20 min
de duração
– A ideia é que seja rápida!
• Foco
nas
atividades
que serão realizadas e nos
Ritmo sustentável (Semana de 40
horas)
• Não submete
r os desenvolvedores a
cargas
adicionais
de trabalho
– Horas extras, trabalhos no finais de semana – Utilizar apenas as 40h semanais
• Com o tempo a equipe vai perdendo
rendimento
– Pode-se tornar mais desmotivada – Perda de concentração
– Aumenta o stress na comunicação – Mais falhas na implementação
• A ideia é
respeitar
a individualidade e o físico de
cada um
Fases do XP
• Fase de exploração
– São analisadas possíveis soluções e a viabilidade
delas
– Possíveis arquiteturas são propostas
– Essa fase é executada até os desenvolvedores
conseguirem uma confiança adequada e estórias
suficientes para iniciar a primeira release
Fases do XP
• Fase do Planejamento Inicial
– Deve ser usada para que o cliente concorde com a data da primeira entrega das release
• Fase das iterações
– Os casos de testes funcionais de unitários são desenvolvidos
– Desenvolvimento seguindo as práticas vistas
• Fase de produção
– O sistema é colocado no ambiente de produção – Testes de aceitação são descritos para averiguar o
Fases do XP
• Fase da manutenção
– Inclusão de novas funcionalidades
– Refatoração do código
– Deve ser feito com cautela
• Fase da morte
– As funcionalidades já satisfazem o cliente
– O sistema não consegue mais evoluir e é inviável
continuar
Papéis no XP
• Não existe papeis definitivos. O XP sugere alguns:
• Treinador (coach)
– Se preocupa com a evolução técnica e evolução do processo
– Deve ser um bom comunicador e ter um bom conhecimento técnico
• Rastreador (tracker)
– O objetivo dele é coletar métricas e verificar possíveis divergências
Papéis no XP
• Programador
– Analisa, codifica, testa, integra o sistema – Estima as estórias
• Cliente
– Escolhe o que vai agregar ao seu negócio – Prioriza as estórias e as releases
• Testador
– Cria os testes funcionais
– Também pode ser o programador
• Consultor
Barreiras para o usar o XP
• Cultura
– Equipe acostumada com o desenvolvimento tradicional
• Tamanho da equipe
– Acima de 12 pessoas a comunicação começa a ser afetada drasticamente
• Tecnologia
– Complicado para realizar testes
• Espaço físico
– A equipe precisa estar junta para facilitar a comunicação
• Cliente
