Extreme Programming (XP) é uma metodologia ágil para desenvolvimento de software que valoriza indivíduos, software funcionando, e resposta à mudança. XP utiliza práticas como programação em pares, integração contínua, testes automatizados e planejamento baseado em histórias de usuário para entregar valor ao cliente rapidamente. Apesar de algumas controvérsias, XP tem sido bem-sucedida em muitos projetos.

1. Extreme Programming
Programação Extrema
Christiano Milfont
Juazeiro do Norte 2009
Copyright 2009 Milfont.org

2. Code and Fix

3. 3 Amigos
Ivar Jacobson James Rumbaugh Grady Booch

4. Agora Temos Processo

5. Ainda Temos Problemas
Código complexo.
Manutenção difícil.
Baixa produtividade.
Cronograma sempre atrasado.
Insatisfação de todos.
Design degradado.
Documentação defasada,
excessiva e ilegível.
Fracasso em grande parte dos
projetos.

6. Nuvem de mudanças

7. Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
2001
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham
Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern
Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland
Dave Thomas

8. 3 Amigos
Ward Cunningham Ron Jeffries Kent Beck

9. Extreme Programming
Os princípios conectam os valores
(crenças fundamentais dos processos)
às práticas (atividades concretas do
cotidiano).

10. Extreme Programming
Valores
Courage (Coragem)
Para tomar as decisões certas e dizer o que precisa ser dito para os interessados.
Communication (Comunicação)
Para dar as informações certas e serem usadas com máxima vantagem pelas pessoas
certas.
Simplicity (Simplicidade)
Para descartarmos as coisas que queremos mas que não precisamos agora.
Feedback (Parecer)
Para aprendermos as lições adequadas a cada oportunidade.
Respect (Respeito)
Para nos tratar com dignidade e reconhecermos o conhecimento e nosso mútuo
desejo de sucesso.

11. Release Plan
“A good plan violently executed now is
better than a perfect plan executed next
week.”
“Um bom plano executado violentamente
agora é melhor que um plano perfeito
executado na próxima semana.
General George S. Patton

12. Release e Iteration Planning
Release
Condições de satisfação
(user stories, budget,
schedule)
Release
Planning
Iteração
Condições de satisfação
(user stories +
Acceptance Tests)
Iteration Incremento
Desenvolvimento
Planning no produto

13. Master Story List
ID Criticidade Item Iteração Estimativa Restando
1 Alto Informar problema 1 10 0
2 Baixo Listar problemas ? ? ?
3 Baixo Cadastrar tipos de bug ? ? ?
4 Médio Aprovar problema 2 ? ?
5 Altíssimo Controle de acesso 1 100 0
6 Baixo Cadastrar status ? ? ?
7 Baixo Cadastrar membros ? ? ?
8 baixo Cadastrar projeto ? ? ?

14. Real Customer Involvement

15. Ubiquitous Language
Linguagem Ubíqua

17. Linguagem Ubíqua
"A language structured around
the domain model and used by
all team members to connect
all the activities of the team
with the software."

18. Linguagem Ubíqua
Contexto
• Especialistas em negócio não entendem
termos de desenvolvedores.
• Desenvolvedores não entendem termos do
negócio.
• Uma palavra ou sentença tem vários
significados e modelos dependendo do
cenário.

19. Linguagem Ubíqua
“The Blind Men and the Elephant”,
By John Godfrey Saxe
(1813- 1887)

20. Linguagem Ubíqua

21. Linguagem Ubíqua
Um Membro do projeto cadastra uma “Issue” no
sistema.
Um Gerente de projetos aceita ou rejeita a
entrada de Issues para serem trabalhadas.
Um Funcionário do hospital dar entrada do
Paciente na Emergência.
O Cenário de entrada por pacientes depende do
Login do usuário com ROLE Admin na Action
antes do forward.
Um funcionário atende uma solicitação de saída
de medicamento pelo prontuário do paciente
com limite do cardápio do médico.
A Tabela TB_ITEMS tem ligação com a Tabela
TB_NOTAS

22. Linguagem Ubíqua
Um Membro do projeto cadastra uma “Issue” no
sistema.
Um Gerente de projetos aceita ou rejeita a
entrada de Issues para serem trabalhadas.
Um Funcionário do hospital dar entrada do
Paciente na Emergência.
O Cenário de entrada por pacientes depende do
Login do usuário com ROLE Admin na Action
antes do forward.
Um funcionário atende uma solicitação de saída
de medicamento pelo prontuário do paciente
com limite do cardápio do médico.
A Tabela TB_ITEMS tem ligação com a Tabela
TB_NOTAS

23. Linguagem Ubíqua
Um Membro do projeto cadastra uma “Issue” no
sistema.
Um Gerente de projetos aceita ou rejeita a
entrada de Issues para serem trabalhadas.
Um Funcionário do hospital dar entrada do
Paciente na Emergência.
O Cenário de entrada por pacientes depende do
Login do usuário com ROLE Admin na Action
antes do forward.
Um funcionário atende uma solicitação de saída
de medicamento pelo prontuário do paciente
com limite do cardápio do médico.
A Tabela TB_ITEMS tem ligação com a Tabela
TB_NOTAS

24. Behaviour Driven Development
Use Case User Story
Um caso de uso captura Uma estoria descreve
um contrato entre os funcionalmente o que será
interessados de um valioso para os usuários e
sistema sobre seus aos compradores de um
comportamentos. software.
Writing Effective Use Cases User Stories Applied
Alistair Cockburn Mike Cohn

25. Behaviour Driven Development
User Story
• Card [cartão]
• Conversation [conversação]
• Confirmation [confirmação]
“Ron Jeffries, 2001”

26. Behaviour Driven Development
User Story
• Independente
• Negociável
• Valioso ao comprador
• Estimável
• Small [Pequena]
• Testável
User Stories Applied
Mike Cohn

27. Behaviour Driven Development
Story Card

28. Behaviour Driven Development
Story Card

29. Behaviour Driven Development
Story Card

30. Planning Poker

31. Informative Workspace

32. Nossa Rotina Diária
Standup Meeting @ 9h
Pair Up
Test First [Prática]
Code Refactor
Integrar ou Disponibilizar
Ir para casa @ 17h

33. Stand Up Meeting
Thoughworks india

34. Pair Up
• Sit Together (sentam-se juntos)
• Shared Code (código compartilhado)
• Energized Work ( Trabalho energizado)
• Move People Around (Move as pessoas em volta)
• Pair Programming
• (Programação em Par)
– Navegador e Condutor
– Trabalho energizado

35. Move People Around
Dia Turno Historia
1 2 3
Seg Manhã Paulo/José Pedro/Carlos
Tarde Paulo/Carlos Pedro/José
Ter Manhã Carlos/Pedro José/Paulo
Tarde Carlos/Paulo José/Pedro
Qua Manhã Carlos/José Pedro/Paulo
Tarde Carlos/Paulo Pedro/José
Qui Manhã Paulo/Pedro José/Carlos
Tarde Paulo/Carlos José/Pedro
Sex Manhã Carlos/José Pedro/Paulo
Tarde Carlos/Paulo Pedro/José

36. Pair Programming
“E depois disto designou o
Senhor ainda outros setenta,
e mandou-os adiante da sua
face, de dois em dois, a todas
as cidades e lugares aonde
ele havia de ir.”
Lucas 10:1
http://www.bibliaonline.com.br/acf/lc/10

37. Pair Programming
• Pros • Contras
Força boas práticas [Coding Standards] Preferência de trabalho
Revisão de trabalho Desperdício em partes triviais
Redução de custos Conflito de Egos
Disseminação/nivelamento Habitos pessoais irritantes
Menos interrupção e dispersão

38. Test Driven Development
“Desenvolvimento guiado por testes
é um caminho de gerenciamento
do medo durante a programação.”
Kent Beck - Test Driven
Development by Example

39. Test Driven Development
RED-GREEN-REFACTOR
1. Escreva um teste que não funciona.
2. Escreva o código e faço-o funcionar.
3. Refatore e elimine o código
repetitivo.

40. Test Driven Development
O ritmo em 3 A’s
• Arrange [Criar um objeto]
• Act [Invocar um método]
• Assert [Verificar o resultado]
Refactoring Workbook, Bill Wake

41. Integração Contínua

42. Extreme Programming
Princípios

43. Extreme Programming
Práticas primárias
Sit Together (Sentem-se juntos)
Whole Team (Equipe completa)
Energized Work (Trabalho energizado)
Pair Programming (Programação em par)
Move People Around (Mova as equipes)
Stories (Histórias)
Weekly Cycle (Ciclo semanal)
Quarterly Cycle (Ciclo trimestral)
Slack (Folga)
Ten-Minute Build (Construir em 10 minutos)

44. Extreme Programming
Práticas primárias [cont.]
Continuous Integration (Integração contínua)
Test-First Integration (Teste primeiro)
Incremental Design (Design incremental)
Informative Workspace (Ambiente informatizado)

45. Extreme Programming
Práticas secundárias
Real Customer Involvement (Envolvimento real do cliente)
Incremental Deployment (Disponibilização incremental)
Team Continuity (Continuidade da equipe)
Shrinking Teams (Diminuição de equipes)
Root-Cause Analysis (Análise da causa-origem)
Daily Deployment (Disponibilização (entrega) diária)
Negotiated Scope Contract (Contrato com escopo negociável)
Shared Code (Código compartilhado)
Code and Tests (Código e testes)
Single Code Base (Código único)

46. Extreme Programming
Práticas secundárias (Cont.)
Metaphor (Metáforas)
Refactoring (Refatoração)
Pay-per-Use (Pague-por-uso)
Design Patterns (Padrões de projeto)
40 Hour Week (40 horas semanais)
Planning Game (Jogo do planejamento)
Stand Up Meetings (Reuniões em pé)
Coding Standards (Padrões de codificação)

47. Extreme Programming
Papéis
1.Programmer
2.Customer
3.Tester
4.Tracker
5.Coach
6.Consultant
7.Big Boss

48. http://www.xpce.org