Este documento descreve o processo de programação extrema (XP), incluindo suas características, valores, princípios e práticas-chave. As principais características do XP são equipes pequenas, comunicação frequente, documentação mínima e desenvolvimento orientado a testes. O XP define doze práticas centrais como planejamento, versões curtas, design simples, programação em pares e integração contínua. O documento também discute a evolução do XP para o IXP, focado em projetos maiores em grandes empresas.

1. Processo de Produção
de Software
Bacharelado em Engenharia de Software – Aula 21
Prof.ª M.ª Elaine Cecília Gatto

2. EXTREME PROGRAMMING
PROGRAMAÇÃO EXTREMA
XP

3. Introdução
• Uma das primeiras metodologias ágeis
• Kent Beck
• Projeto C3
• Empresa Chrysler Corporation

4. Características
• Equipes pequenas
• Trabalham na mesma sala
• Encoraja a comunicação
• Somente documentação estritamente necessária é
gerada
• Código e teste de unidade servem como
documentação
• Metodologia orientada a objetos
• Possui um conjunto de regras e práticas

5. Valores
• Comunicação frequente entre os membros da
equipe e o cliente.
• Simplicidade no design e no código.
• Feedback em muitos níveis diferentes.
• Implementação de decisões duras, mas
necessárias

6. Princípios Centrais
• Retorno rápido
• Simplicidade
• Mudanças incrementais: mudanças pequenas que
façam sentido
• Mudança abrangente: preservar opções para o
futuro enquanto resolve os problemas urgentes
• Trabalho de qualidade: invista sempre o melhor
de si no trabalho.

7. Outros Princípios
1. Aprendizado
contínuo
2. Pequeno
investimento inicial
3. Experimentos
concretos
4. Comunicação franca
e honesta
5. Trabalhar com os
instintos das pessoas
1. Aceitar
responsabilidades
2. Mensuração
correta
3. Avançar aos
poucos
4. Adaptação local

9. As 12 Práticas-Chave do XP
1. Planejamento ou Jogo do Planejamento:
• Determinar rapidamente as características a
serem incluídas na próxima versão.
• Utilizar uma combinação de prioridades
comerciais e estimativas técnicas.
• Desenvolvedores estimam o esforço.
• Clientes definem o escopo e prazo.
• Histórias de usuário: variante simplificada dos
casos de uso da UML.

10. As 12 Práticas-Chave do XP
1. Planejamento ou Jogo do Planejamento:
A. ATIVIDADE OUVIR:
• Levantamento de requisitos.
• Capacitar os membros técnicos a entender o
ambiente de negócios do software.
• Permite obter percepção ampla sobre:
• resultados solicitados.
• fatores principais.
• funcionalidades.
• Conduz a criação de um conjunto de histórias do
usuário.

11. As 12 Práticas-Chave do XP
1. Planejamento ou Jogo do Planejamento:
• Histórias do usuário: Descreve o resultado,
as características e as funcionalidades do
software.
• OBS.: novas histórias podem ser escritas a
qualquer momento.

12. As 12 Práticas-Chave do XP
Para cada história:
Cliente Equipe
Escreve Avalia
Posta em uma ficha Atribui custo
Atribui um valor de prioridade
Prioridade: dada com base
no valor de negócio global
do recurso/função.
CUSTO: medido em semanas

13. As 12 Práticas-Chave do XP
• Se a história exigir mais que 3 semanas de
desenvolvimento o Cliente deve:
• Dividir essa história em história menores.
• Atribuir valor novamente.
• Atribuir custo novamente.

14. As 12 Práticas-Chave do XP
• Para o próximo INCREMENTO de software,
clientes e equipe devem:
• Agrupar histórias .
• Concordar sobre quais histórias serão
incluídas.
• Data de entrega.
• Etc.

15. As 12 Práticas-Chave do XP
• Para o próximo INCREMENTO de software, a
equipe XP deve:
• Ordenar as histórias para implementação
em uma das 3 formas a seguir:
• Todas as histórias.
• Histórias de maior prioridade.
• Histórias de maior risco.

16. As 12 Práticas-Chave do XP
• O primeiro Incremento de software é entregue
• Equipe XP DEVE:
• Calcular a velocidade do projeto
Velocidade do projeto:
É o NÚMERO de histórias de clientes
implementadas durante a primeira versão.
É uma medida sutil da produtividade de uma
equipe.

17. As 12 Práticas-Chave do XP
• A velocidade do projeto é usada para:
• Estimar as datas de entrega.
• Estimar o cronograma para as próximas
versões.
• Determinar se foi assumido um compromisso
EXAGERADO para todas as histórias ao longo de
todo o projeto. Se sim:
• Modificar o conteúdo das versões.
• Modificar as datas de entrega.

18. As 12 Práticas-Chave do XP
2. Versões Curtas:
• Obter sistema funcional rapidamente.
• Liberar novas versões em um ciclo bem curto.
• Intervalos de tempo comuns: 2 a 4 semanas.
• Cliente:
• Executa testes.
• Verifica o funcionamento.
• Fornece retro informação imediata para a equipe.
• Faz-se novos planos detalhados para a próxima versão.

19. As 12 Práticas-Chave do XP
3. Metáfora:
• DEFINIÇÃO DE METÁFORA:
• É uma figura de linguagem onde se usa
uma palavra ou uma expressão em um
sentido que não é muito comum,
revelando uma relação de semelhança
entre dois termos.

20. As 12 Práticas-Chave do XP
3. Metáfora:
• Não usar uma arquitetura formal.
• Usar uma simples visão comum de como o
sistema completo funciona (metáfora do
sistema).
• Fácil de entender, por ser simples, mas
difícil de produzir.
• Utilizada para orientar o design.

21. As 12 Práticas-Chave do XP
4. Design Simples:
• Manter o design do sistema o mais simples
possível.
• Eliminar qualquer complexidade desnecessária.
• Escolher a solução mais simples que funcione
agora.
• Não pensar no futuro.
• Design pode ser alterado no futuro.

22. As 12 Práticas-Chave do XP
5. Desenvolvimento Orientado a Teste:
• Testes devem ser realizados
continuamente.
• Testes devem ser o mais automatizado
possível.
• Manter os testes em execução o tempo
todo.
• Testes de aceitação com o cliente.

23. As 12 Práticas-Chave do XP
5. Desenvolvimento Orientado a Teste:
• Testes de unidades individuais são organizados
em um conjunto de testes universal.
• Testes de integração e validação ocorrem
diariamente.
• Corrigir pequenos problemas em intervalos de
poucas horas leva menos tempo do que corrigir
problemas enormes próximo ao prazo de
entrega [WELLS, 99]

24. As 12 Práticas-Chave do XP
5. Desenvolvimento Orientado a Teste:
• Testes de aceitação:
• Testes de cliente
• Especificados pelo cliente
• Mantem foco nas características e
funcionalidade do sistema total
• São obtidos das histórias dos usuários
implementados como um incremento

25. As 12 Práticas-Chave do XP
5. Desenvolvimento Orientado a Teste:
• Após:
• Desenvolver histórias
• Elaborar projeto preliminar
• Deve-se:
• Desenvolver testes de unidades que
exercitarão as histórias no incremento de
software corrente

26. As 12 Práticas-Chave do XP
6. Aprimoramento de Design (refatoração):
• DEFINIÇÃO DE REFATORAÇÃO:
• É o processo de modificar um sistema de
software para melhorar a estrutura
interna do código sem alterar o seu
comportamento externo.

27. As 12 Práticas-Chave do XP
6. Aprimoramento de Design (refatoração):
• Visa eliminar a duplicação.
• Melhora a comunicação.
• Simplifica ou acrescenta flexibilidade.
• Design:
• Não é concluído de uma vez no inicio.
• É modificado quando necessário
• É aprimorado ao longo do tempo.

28. As 12 Práticas-Chave do XP
6. Aprimoramento de Design (refatoração):
• É uma forma disciplinada de organizar
código, modificar, simplificar o projeto
interno que minimiza as chances de
introdução de bugs.
• Forma de controlar as alterações,
sugerindo mudanças que possam melhorar
o projeto

29. As 12 Práticas-Chave do XP
7. Programação em Pares:
• Todo o código de produção deve ser gerado
por dois programadores trabalhando na
mesma máquina.
• Todo código é sempre revisado por outra
pessoa.
• A melhoria da qualidade compensa o
decréscimo na produtividade.

30. As 12 Práticas-Chave do XP
7. Programação em Pares:
• Deve-se compor código de programa com um
parceiro.
• Dessa forma:
• Não se gera código “feio”.
• Não se gera código incompreensível.
• Papéis:
• Piloto: codifica
• Navegador: revisa e sugere

31. As 12 Práticas-Chave do XP
7. Programação em Pares:
• Duas cabeças pensam melhor que uma.
• O código é revisto enquanto é criado.
• Mecanismo para solução de problemas em
tempo real.
• A medida que o trabalho é concluído, o
código é integrado ao trabalho de outros.

32. As 12 Práticas-Chave do XP
8. Posse Coletiva:
• Toda a equipe deve deter a propriedade do
código.
• Qualquer um pode alterar qualquer parte do
código a qualquer momento.
• As mudanças efetuadas no código não
desestabilizarão outras partes do sistema.
• Motivo: testes de unidade e integração
contínua.

33. As 12 Práticas-Chave do XP
9. Integração Contínua:
• Integrar o sistema e montá-lo várias vezes ao
dia sempre que uma tarefa for concluída – de
poucas em poucas horas.
• Sistema funcional sempre disponível.
• Detecção imediata de erros de integração.
• Código novo só é aceito se passar nessa
integração.
• Evita problemas de compatibilidade e interface.

34. As 12 Práticas-Chave do XP
10. Ritmo Sustentado:
• Trabalhar em um ritmo que pode ser
sustentado.
• Exemplo: 40 horas semanais.
• Nunca fazer horas extras duas semanas
seguidas.

35. As 12 Práticas-Chave do XP
10. Ritmo Sustentado.
• Se é necessário fazer horas extras constantemente:
• A estimativa original está incorreta.
• O plano precisa ser reajustado.
• Programação é uma atividade intelectual difícil.
• Mente cansada:
• Queda na produtividade
• Menos tarefas são concluídas
• Mais enganos ocorrem (erros são cometidos).

36. As 12 Práticas-Chave do XP
11. Cliente no local de trabalho:
• Incluir um cliente real na equipe para
responder perguntas sempre que
necessário.
• Permite o trabalho sem um conjunto de
requisitos pré especificado.

37. As 12 Práticas-Chave do XP
11. Cliente no local de trabalho:
• PROBLEMA:
• Dificilmente a maioria dos clientes
dispõe de um representante com
profundo conhecimento dos requisitos e,
ao mesmo tempo, com autonomia de
decisão.

38. As 12 Práticas-Chave do XP
12. Padrões de Codificação:
• Todos os programadores devem gerar todo
o código segundo o mesmo conjunto de
regras.
• Regras são criadas para facilitar a
comunicação.
• Programadores trabalham em pares.

39. As 12 Práticas-Chave do XP
12. Padrões de Codificação:
• Membros da equipe modificam o código de
outros.
• Padrão de codificação (já que o código é
modificado por várias pessoas diferentes)
• Importante que todos utilizem as mesmas
regras.

40. Outras Práticas Chave
1. Medir a velocidade do projeto
2. Trocar as pessoas com frequência
3. Realizar rápida reunião todos os dias (em
pé)
4. Criar plano de liberações e detalhados de
cada iteração
5. Deixar otimizações para o final

41. Outras Práticas Chave
6. Usar cartões CRC:
• Classe – Responsabilidade – Colaboração.
• Mecanismo eficaz para pensar o software
em um contexto orientado a objetos.
• Identificam e organizam as classes
relevantes para o incremento corrente.

42. Outras Práticas Chave
7. Princípio YAGNI: só deve ser desenhado e
implementado o que for estritamente
necessário para atender aos requisitos

43. Outras Práticas Chave
8. Testar ideias por meio de protótipos:
• Spike solutions ou solução pontual.
• São usados também quando se encontra um
problema de projeto difícil.
• Objetivo é reduzir o risco para a verdadeira
implementação.
• Validar as estimativas originais para a história
contendo o problema.

44. Outras Práticas Chave
9. Um caso de teste deve ser criado ao se
encontrar um defeito.
10.Espaço aberto: a equipe trabalha em baias
em uma sala única
11.Regras adaptáveis: regras podem ser
alteradas desde que se consiga avaliar os
efeitos da avaliação

45. Contribuição do XP
• Reafirmar a importância dos princípios
racionais da Engenharia e da Gestão de
Software.

46. Técnicas Inovadoras
• Desenvolvimento dirigido a teste
• Refatoramento.
• Integração contínua.
• Propriedade coletiva.
• Usar ferramentas de automação adequadas
para cada uma dessas técnicas.

47. Outras considerações
• Existe uma sinergia entre as práticas D.D.T,
integração contínua, desenho simples e
refatoramento.
• Se uma delas não for executada, as outras
práticas ficam comprometidas.
• Muitas vezes a metodologia XP não é aplicada
de forma completa e consistente.

48. Industrial XP (IXP)
• É uma evolução orgânica da XP
• Semalhanças:
• Imbuída do mesmo espirito minimalista
• Centrado no cliente
• Orientado a testes

49. Industrial XP (IXP)
• Diferenças:
• Maior inclusão de gerenciamento
• Papel expandido para os clientes
• Práticas técnicas atualizadas

50. Industrial XP (IXP)
• Modifica várias práticas existentes
• Redefine algumas funções e
responsabilidades para serem mais
receptivas a projetos importantes de
grandes empresas

51. Industrial XP (IXP)
• Incorpora seis novas práticas:
• Ajudam a garantir que um PROJETO XP
funcione com êxito em empreendimentos
significativos em uma grande organização.

52. Industrial XP (IXP)
1. Avaliação imediata
• A equipe IXP verifica se todos os membros
da comunidade de projeto:
• Estão a bordo
• Tem o ambiente correto estabelecido
• Entendem os níveis de habilidades
envolvidos

53. Industrial XP (IXP)
2. Comunidade de projeto:
• A equipe IXP determina se as pessoas estão
prontas para o projeto.
• Pessoas certas.
• Com as habilidades corretas.
• Com os treinamento corretos.
• Comunidade: tecnólogos e outros envolvidos.

54. Industrial XP (IXP)
3. Mapeamento do projeto:
• A equipe IXP avalia o projeto para
determinar:
• Se ele se justifica em termos de
negócios.
• Se vai ultrapassar as metas e objetivos
globais da organização.

55. Industrial XP (IXP)
4. Gerenciamento orientado a testes:
• A equipe IXP estabelece:
• Uma série de destinos mensuráveis que
avaliam o progresso até a data.
• Define mecanismos para determinar se
estes foram atingidos ou não.

56. Industrial XP (IXP)
5. Retrospectivas:
• Uma equipe IXP conduz uma revisão
técnica especializada após a entrega de u
incremento de software.
• A revisão examina problemas, eventos e
lições aprendidas ao longo do processo de
incremento ou versão completa.

57. Industrial XP (IXP)
6. Aprendizagem contínua:
• A equipe IXP é estimulada a aprender
novos métodos e técnicas que possam levar
a uma produto de qualidade mais alta

58. REFERÊNCIAS
1. TSUI, Frank; KARAM, Orlando. Fundamentos
da Engenharia de Software. Tradução e
Revisão Técnica de Edson Tanaka. 2.ª Edição.
Rio de Janeiro: LTC, 2013.
2. WAZLAWICK, Raul Sidnei. Engenharia de
Software: Conceitos e Práticas. 1.ª edição.
Rio de Janeiro: Elsevier, 2013.

59. REFERÊNCIAS
3. PRESSMAN, R. S.; MAXIM, B. R. Engenharia de
Software: Uma Abordagem Profissional. Tradução:
João Eduardo Nóbrega Tortello. Revisão Técnica:
Reginaldo Arakaki, Julio Arakaki, Renato Manzan de
Andrade. 8.ª Edição. Porto Alegre: AMGH, 2016.
4.FILHO, W. P. P. Engenharia de Software:
Fundamentos, Métodos e Padrões. 3.ª Edição.Rio
de Janeiro: LTC, 2015