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

Code and Fix

3 Amigos
Ivar Jacobson James Rumbaugh Grady Booch

Agora Temos Processo

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.

Nuvem de mudanças

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

3 Amigos
Ward Cunningham Ron Jeffries Kent Beck

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

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.

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

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

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 ? ? ?

Real Customer Involvement

Ubiquitous Language
Linguagem Ubíqua

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."

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.

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

Linguagem Ubíqua

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

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

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

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

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

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

Behaviour Driven Development
Story Card

Behaviour Driven Development
Story Card

Behaviour Driven Development
Story Card

Planning Poker

Informative Workspace

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

Stand Up Meeting
Thoughworks india

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

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é

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

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

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

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.

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

Integração Contínua

Extreme Programming
Princípios

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)

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)

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)

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)

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

http://www.xpce.org