Carlos Henrique M. da Silva
carloshenrique.85@globo.com
eXtreme
Programming

Extreme Programming (XP) é uma metodologia de desenvolvimento
de software, nascida nos Estados Unidos ao final da década de 90.
Vem fazendo sucesso em diversos países, por ajudar a criar
sistemas de melhor qualidade, que são produzidos em menos
tempo e de forma mais econômica que o habitual. Tais objetivos
são alcançados através de um pequeno conjunto de valores e
práticas, que diferem substancialmente da forma tradicional de se
desenvolver software.
Estudos demonstram que a maioria dos projetos de software falha,
seja porque não cumprem o orçamento, ou não cumprem o
cronograma, ou as funcionalidades não atendem às necessidades
dos usuários ou porque todos estes fatores estão presentes em
conjunto.
VINÍCIUS MANHÃES TELES
eXtreme Programming - Conceito

eXtreme Programming - Introdução
Por que cerca de
80% a 90% dos
projetos de Software
fracassam?

eXtreme Programming - Introdução
Desenvolver software é uma atividade arriscada. Segundo as
estatísticas, os principais problemas são:
 Gastos que superam o orçamento;
 Consumo de tempo que supera o cronograma;
 Funcionalidades que não resolvem os problemas
dos usuários;
 Mudanças constantes podendo estar relacionadas
a requisitos, cronograma, equipe...
 Baixa qualidade dos sistemas desenvolvidos.

eXtreme Programming - Introdução
Há algumas décadas a indústria de software vem buscando técnicas
de desenvolvimento que possam reduzir os riscos dos projetos de
software e tornar essa atividade mais produtiva. Um marco neste
sentido é a criação da disciplina de Engenharia de Software em
1968. De lá para cá, inúmeras propostas foram feitas para melhorar
o desempenho dos projetos, começando pelo processo de
desenvolvimento linear e seqüencial (em cascata) até chegar aos
atuais processos ágeis de desenvolvimento.
O XP é um dos representantes destes processos e foi criado por Kent
Beck em 1997 em um projeto para a Chrysler (fabricante de veículos
norte-americana). O XP é composto por um conjunto reduzido de
práticas de desenvolvimento que se organizam em torno de valores
básicos. Essas práticas possuem fortes inter-relacionamentos
formando um conjunto de elevada sinergia.

eXtreme Programming - Introdução
Desenvolvimento de SW no passado
 Processos Tradicionais
Analisar, projetar e só depois iniciar codificação
 Prever o futuro
Ter certeza do que se sabe hoje será exatamente o que se quer
amanhã
 Temores
Mudança de requisitos depois de concluída a fase de análise e
projeto
Custo
Análise Projeto Codificação Testes
Tempo

eXtreme Programming - Introdução
Desenvolvimento de SW hoje
 Processos modernos incentivam pequenas iterações
Mudanças em etapas posteriores se tornam mais baratas
 Adotar a mudança
- A Engenharia de SW é diferente das outras engenharias
- Componentes, frameworks, BDs podem absorver o alto custo da
mudança

eXtreme Programming - Introdução
A crise do software
 Em média, os atrasos representaram 63% mais tempo do que o estimado;
 Os projetos que não cumpriram o orçamento custaram em média 45% mais;
 No geral, apenas 67% das funcionalidades prometidas foram efetivamente
entregues.
Resultado final de projetos de software (Standish Group,2000)

eXtreme Programming - Introdução
Utilização de Funcionalidades

eXtreme Programming - Introdução
Utilização de Funcionalidades

eXtreme Programming - Introdução
Desperdício Falha na comunicação
Falta de tempo

eXtreme Programming - Introdução
Manifesto Ágil
Estamos evidenciando maneiras melhores de desenvolver software fazendo-
o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho,
passamos a valorizar:
 Interação entre pessoas 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 tendo valor os itens à direita, valorizamos
mais os itens à esquerda.”
Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn,
Ward Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie
van Bennekum, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland, Dave
Thomas

Referência
eXtreme Programming

eXtreme Programming
Extreme Programming ou XP, é um processo de desenvolvimento de software voltado para:
 Projetos cujos requisitos são vagos e mudam com frequência;
 Desenvolvimento de sistemas orientados a objetos;
 Equipes pequenas, preferencialmente até 12 desenvolvedores;
 Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser
implementado logo no início do projeto e vai ganhando novas funcionalidades ao
longo do tempo.
VISÃO GERAL
O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo
de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno
de um conjunto de valores e prática que atuam de forma harmônica e coesa para assegurar
que o cliente sempre receba um alto retorno do investimento em software.

Valores do XP
 Comunicação
 Simplicidade
 Feedback
 Coragem
 Respeito
Práticas do XP
 Cliente Presente
 Jogo do Planejamento
 Stand Up Meeting
 Programação em Par
 Desenvolvimento Guiado pelos Testes
 Refactoring
 Código Coletivo
 Código Padronizado
 Design Simples
 Metáfora
 Ritmo Sustentável
 Integração Contínua
 Releases Curtos
eXtreme Programming

Valores do XP
eXtreme Programming

Comunicação
A comunicação entre o cliente e a equipe permite que todos os
detalhes do projeto sejam tratados com a atenção e a agilidade
que merecem.
O XP procura assegurar que a comunicação ocorra da forma
mais direta e eficaz possível. Sendo assim, ele busca aproximar
todos os envolvidos do projeto de modo que todos possam se
comunicar face-a-face ou da forma mais rica que for viável.
eXtreme Programming

Simplicidade
A comunicação, embora seja essencial, não é suficiente para
garantir que o cliente possa aprender durante o projeto e gerar
feedback rapidamente. Também é necessário que a equipe
compreenda e utilize o valor da simplicidade, que nos ensina a
implementar apenas aquilo que é suficiente para atender a
cada necessidade do cliente. Ou seja, ao codificar uma
funcionalidade devemos nos preocupar apenas com os
problemas de hoje e deixar os problemas do futuro para o
futuro (NÃO DEVEMOS TENTAR PREVER O FUTURO), pois
raramente acertamos as previsões.
eXtreme Programming

Feedback
Quando o cliente aprende com o sistema que utiliza e re-avalia
as suas necessidades, ele gera feedback para a equipe de
desenvolvimento.
O feedback é o mecanismo fundamental que permite que o
cliente conduza o desenvolvimento diariamente e garanta que
a equipe direcione as suas atenções para aquilo que irá gerar
mais valor.
eXtreme Programming

Coragem
Existem temores que costumam assombrar os participantes de um projeto de software. Beck e
Fowler (2001) destacam alguns destes medos que exercem influência significativa nos
processos de desenvolvimento.
Desenvolvedores, por sua vez, temem:
 Ser solicitados a fazer mais do que sabem fazer;
 Ser ordenados a fazer coisas que não façam
sentido;
 Ficar defasados tecnicamente;
 Receber responsabilidades, sem autoridade;
 Não receber definições claras sobre o que precisa
ser feito;
 Sacrificar a qualidade em função de prazo;
 Ter que resolver problemas complicados sem
ajuda e
 Não ter tempo suficiente para fazer um bom
trabalho.
Clientes temem:
 Não obter o que pediram;
 Pedir a coisa errada;
 Pagar demais por muito pouco;
 Jamais ver um plano relevante;
 Não saber o que está acontecendo e
 Fixarem-se em suas primeiras
decisões e não serem capazes de reagir
a mudanças nos negócios.
eXtreme Programming

Respeito
eXtreme Programming
Todo mundo dá e se sente o respeito que merecem como um membro da equipe
valorizada. Todos contribuem valor mesmo que seja simplesmente entusiasmo.
Desenvolvedores respeitam a experiência dos clientes e vice-versa. Gestores
respeitam o direito de aceitar a responsabilidade e receber autoridade sobre nosso
próprio trabalho.
Respeito é um valor que dá sustentação a todos os demais. Membros de uma
equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se
importarem uns com os outros. Respeito é o mais básico de todos os valores. Se ele
não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber
compreender e respeitar o ponto de vista do outro é essencial para que um projeto
de software seja bem sucedido.

eXtreme Programming

eXtreme Programming
Equipe (Whole Team)
Equipe XP = Cliente + Time de Desenvolvimento
Os papéis do time de desenvolvimento
englobam:
• Desenvolvedores
• Testadores
(ajudam o cliente com os testes de aceitação)
• Analistas/projetistas
(ajudam o cliente a definir requisitos)
• Gerente (garante os recursos necessários)
• Coach
(orienta a equipe, controlando a aplicação do XP)
• Tracker (coleta as métricas do projeto)
As funções do cliente englobam:
• Definição dos requisitos do
projeto
• Definição de prioridades
• Controle do rumo do projeto
• Definir os testes de aceitação
do Software

eXtreme Programming
Jogo de Planejamento
(Planning Game)
 Principais definições
• Estimativas de cada tarefa
• Prioridades (tarefas + importantes)
 Próximos passos
• Planejamento de release
(cliente propõe as funcionalidades e desenvolvedores avaliam)
• Planejamento da iteração
(define as funcionalidades da iteração e os desenvolvedores estimam)
 Ótimo feedback para o cliente, que dirige o projeto
• Ideia clara do avanço do projeto
• Clareza: Redução de Riscos, aumentando a chance de sucesso

eXtreme Programming
Pequenos Lançamentos
(Small Releases)
 Disponibiliza a cada iteração Software 100% funcional
• Versão
• Redução (se o projeto terminar, parte existe e funciona)
• Detecção prévia de problemas
• Comunicação entre cliente e desenvolvedor
 Cada lançamento possui funcionalidades prioritárias para a iteração
 Lançamento pode ser destinado a
• Usuário/cliente (testa, avalia e oferece feedback)
• Usuário/final (sempre que possível)
 Design simples e integração contínua são práticas essenciais

eXtreme Programming
Testes de Aceitação
(Customer Tests)
 São elaborados pelo cliente em conjunto com analistas e testadores
• São automatizados
• Quando rodarem com sucesso, funcionalidade foi implementada
• Devem ser rodados a cada iteração
 Ótimo feedback para o cliente
• Pode se saber, a qualquer momento, o percentual de implementação do
Software e quanto falta

eXtreme Programming
Projetos Simples (Simple Design)
 Projeto está presente em todas as etapas XP
• Projeto começa simples e se mantém assim através de testes de
refinamento de código (refactoring)
 Em XP, é levado ao extremo
• Não é Permitido qualquer funcionalidade adicional que não será usada na
iteração atual
 Implementação ideal é aquela que
• Passa por todos os testes
• Expressa as ideias definidas no planejamento
• Não contém código duplicado ou que “cheire”
 Prever o futuro é impossível e é “anti-XP”

eXtreme Programming
Programação em Pares
(Pair Programming)
 Software é desenvolvido em pares
• “2 cabeças juntas são melhores que 2 cabeças separadas”
• 1 piloto e 1 copiloto
• Papéis são alternados frequentemente
 Benefícios
•Melhor qualidade de código (refactoring e testes)
•Revisão constante do código
•Nivelamento da equipe
•Maior comunicação
 “Um” pelo preço de “Dois”
Pesquisas demonstram que duplas produzem código de melhor qualidade em
aproximadamente o mesmo tempo que programadores que trabalham
sozinhos

eXtreme Programming
Desenvolvimento Dirigido por
Testes (Test-driven Development)

eXtreme Programming
Refinamento de código
(Refactoring)
http://www.refactoring.com/catalog/

eXtreme Programming
Integração Contínua
(Continuous Integration)

eXtreme Programming
Posse Coletiva
(Collective Ownership)

eXtremme Programming
Padrões de Codificação
(Coding Standards)

eXtremme Programming
Ritmo Saudável (Sustainable Pace)

eXtremme Programming
Metáfora (Metaphor)

eXtremme Programming
Reuniões em Pé (Stand-up Meeting)

eXtremme Programming
Spikes de Planejamento
(Spike Solution)

eXtremme Programming
Como Implantar?
 Uma prática de cada vez
• Enfatize o problema mais importante
 Dificuldades culturais
• Deixar alguém mexer no seu código
• Trabalhar em pares
 Dificuldades devido a mudança de hábitos
• Manter as coisas simples (e não tentar prever o futuro escrevendo "design
flexível")
• Jogar fora código desnecessário
• Escrever testes antes de codificar
• Refatorar com frequência (vencer o medo)

eXtremme Programming
Quando Não Usar XP
 Equipes grandes e espalhadas geograficamente
• Comunicação é um valor fundamental do XP
• Não é fácil garantir o nível de comunicação requerido em projetos XP em
grandes equipes
 Situações onde não se tem controle sobre o código
• Código legado que não pode ser modificado
 Situações onde o feedback é demorado
• Compile-link-build-test que leva 24 horas
• Testes muito difíceis, arriscados e que levam tempo
• Programadores espalhados em ambientes físicos distantes e sem
comunicação eficiente

eXtreme Programming
Características da Equipe
Uma equipe que utilize o XP normalmente é composta por pessoas
que representam os seguintes papéis:
 Gerente de Projeto
 Coach
 Analista de Teste
 Redator Técnico
 Desenvolvedor

eXtreme Programming
Gerente de Projeto
O gerente de projeto é responsável
pelos assuntos administrativos do
projeto. Ele procura liberar a equipe de
questões que não estejam diretamente
ligadas à atividade diária de
desenvolvimento. Além disso, administra
o relacionamento com o cliente
assegurando que o mesmo participe
ativamente do desenvolvimento e
forneça as informações essenciais para
que a equipe possa implementar o
sistema desejado.

eXtreme Programming
Coach
O coach é o profissional técnico do
projeto. O XP recomenda que um
profissional tecnicamente bem
preparado seja destacado para orientar a
equipe de modo que ela siga as boas
práticas recomendadas pelo XP. Embora
também possa atuar na implementação
do sistema, sua tarefa principal é
assegurar o bom funcionamento do
processo e buscar formas de melhorá-lo
continuamente.

eXtreme Programming
Analista de Testes
O analista de teste é responsável por
ajudar o cliente a escrever os testes de
aceitação. Quando estes testes não são
automatizados, o analista de teste deve
fazer com que eles sejam executados
diversas vezes ao longo das iterações do
projeto. Ele procura fazer com que os
eventuais defeitos do sistema sejam
identificados tão logo apareçam. Desta
forma, fornece feedback para a equipe
rapidamente, de modo que ela possa
fazer as correções com rapidez e evitar
que os problemas se propaguem.

eXtreme Programming
Redator Técnico
O redator técnico ajuda a equipe
de desenvolvimento a
documentar o sistema. A sua
presença permite que os
desenvolvedores se concentrem
prioritariamente na
implementação do software.
Embora eles possam continuar
fazendo algumas documentações,
o redator técnico é quem faz a
maior parte do trabalho de
documentação.

eXtreme Programming
Desenvolvedor
O desenvolvedor é a pessoa que analisa,
projeta e codifica o sistema. Em suma, é
a pessoa que efetivamente constrói o
software. Dentro do XP, não existem
divisões entre analista, projetista,
programador, etc. Cada desenvolvedor
exerce estes diferentes papéis em
diversos momentos do projeto.

eXtreme Programming
Desafios de Desenvolvimento de
Software
Modelo em Cascata

eXtreme Programming
 Análise: a equipe faz o levantamento de requisitos e busca compreendê-lo
detalhadamente
 Design: com base na análise a equipe projeta a arquitetura do sistema
 Implementação: a equipe se baseia na arquitetura e na análise para
implementar as diversas partes do software
 Teste: para verificar se o sistema atende às necessidades especificadas
pelo usuário, a equipe testa o software e faz as correções necessárias
 Implantação: o sistema é colocado em produção e os usuários finais
passam a utilizá-lo
 Manutenção: até o fim da sua vida, o software poderá sofrer alterações
por diversas razões, tais como correção e inclusão de novas funcionalidades
Desafios de Desenvolvimento de
Software

eXtreme Programming
Desenvolvimento Ágil
O termo “desenvolvimento ágil”, faz
referência ao desenvolvimento
iterativo, em espiral. Ele recomenda
que todas as fases descritas no
modelo em cascata sejam executadas
diversas vezes ao longo do projeto,
produzindo ciclos que se repetem ao
longo de todo o desenvolvimento.
Cada ciclo (da análise à
implementação) recebe o nome de
iteração. No desenvolvimento iterativo,
o software cresce a cada iteração, isto
é, o resultado de cada iteração é um
software pronto, testado e aprovado,
sendo que a primeira contém poucas
funcionalidades, enquanto a última
contém todas as funcionalidades do
sistema.

eXtreme Programming
Cliente Presente
Introdução
Tradicionalmente, quando pensamos no desenvolvimento de
software, delegamos ao cliente a tarefa de manifestar as suas
necessidades e à equipe de desenvolvimento a de implementar. Ou
seja, há uma divisão implícita entre as responsabilidades de cada
parte e um certo distanciamento entre elas.

eXtreme Programming
O XP trabalha com uma visão diferente
O XP sugere que o cliente esteja
presente durante o dia-a-dia do
projeto. A sua participação
contribui para o sucesso do
projeto, enquanto sua a sua
ausência é um sério fator de
risco.
A participação do cliente viabiliza
a simplicidade do processo. Além
disso, ela permite que o projeto
seja conduzido através de uma
série de pequenos ajustes e não
através de mudanças bruscas ao
longo do caminho.

eXtreme Programming
Estórias
As funcionalidades do sistemas são descritas brevemente em
cartões e recebem o nome de estórias. Estas estórias nada mais são
do que um convite ao diálogo. Sendo assim, quando os
desenvolvedores decidem começar a implementar uma determinada
estória, eles precisam dialogar com o cliente para entendê-las
melhor. Essa é uma das razões pelas quais é essencial que o cliente
esteja presente no dia-a-dia do desenvolvimento.

eXtreme Programming
Dúvidas Durante a Implementação
Enquanto os desenvolvedores se aprofundam na
modelagem da nova funcionalidade e começam a
implementá-la, dúvidas podem surgir. Mais uma vez, a
presença do cliente permite que as dúvidas sejam
respondidas rapidamente. Isso contribui com a agilidade
do processo e evita o trabalho especulativo.

eXtreme Programming
O Trabalho Especulativo
O trabalho especulativo, que ocorre quando a equipe não consegue
ter as dúvidas respondidas e assume premissas, representa um
enorme risco de retrabalho negativo. Assumindo premissas, a
equipe pode vir a construir partes da funcionalidades de forma
completamente incorreta, o que poderia ter sido evitado se o cliente
estivesse presente para responder às dúvidas.

eXtreme Programming
Confiança: um sub-produto da presença do
cliente
Além do feedback entre cliente e equipe de desenvolvimento, a
participação do cliente no desenvolvimento também contribui para
melhorar o relacionamento de ambas as partes. A aproximação
aumenta a confiança de todos os envolvidos.
É preciso notar que serviço é um produto intangível, como o próprio
software. Normalmente, temos mais facilidade em medir o valor de
algo que é concreto, que podemos ver, tocar, manipular. Ou seja,
normalmente, é mais fácil medir o valor de um carro, por exemplo,
que o valor de um serviço.

eXtreme Programming
Para a equipe de desenvolvimento, a aproximação do
cliente permite que muitas dúvidas sejam respondidas.
Além disso, com o cliente próximo, a equipe pode
apontar questões que tenham passados desapercebidas
aos olhos dele. Desta forma, a equipe pode preveni-lo de
situações incorretas.
Aproximação da equipe com o cliente

eXtreme Programming
 Por que é difícil ter o cliente presente?
 A sala de guerra (war room) com o cliente presente
 A sala de guerra com o cliente ausente
 A sala de guerra em outro prédio
 O que acontece com os projetos quando o cliente não está
presente?
Questionamentos importantes Equipe X Cliente

eXtreme Programming
O Jogo do Planejamento
O XP utiliza o planejamento para assegurar que a equipe de
desenvolvimento esteja sempre trabalhando naquilo que irá gerar
mais valor para o cliente a cada dia de trabalho. Este planejamento é
feito diversas vezes ao longo do projeto, para que todos tenham a
oportunidade de revisar as prioridades (Beck e Fowler, 2001).
 Dividindo as Responsabilidades
 Escrevendo Estórias
 Estimando Estórias
 Planejando os Releases
 Planejando as Iterações
 Encerrando uma Iteração
 Encerrando um Release

eXtreme Programming
Dividindo as Responsabilidades
A chave para gestão de um projeto de software é o equilíbrio de
poderes entre o cliente e a equipe de desenvolvimento. Por esta
razão, o XP procura separar claramente o papel de cada um, para
assegurar que o cliente tome todas as decisões de negócio, enquanto
a equipe de desenvolvimento cuida das decisões técnicas. (Beck e
Fowler, 2001). Isso dá origem a declaração de direitos do cliente e do
desenvolvedor (Jeffries et al., 2001).

eXtreme Programming
Direitos do Cliente
 Receber um plano geral para que saiba o que poderá ser feito, quando e
com que custo;
 Receber o máximo de valor de cada semana de trabalho da equipe de
desenvolvimento;
 Acompanhar o progresso do projeto através de um sistema executável,
que demonstra estar correto por passar nos testes que você especifica;
 Mudar de ideia, substituir funcionalidades e alterar prioridades sem ter
que pagar um preço exorbitante;
 Ser informado sobre mudanças no cronograma a tempo de decidir como
reduzir o escopo para ser capaz de manter a data original;
 Cancelar o projeto a qualquer momento e receber um sistema executável
que reflete todo o investimento que foi feito até a data do cancelamento.

eXtreme Programming
Direitos do Desenvolvedor
 Saber quais são as necessidades, bem como suas prioridades;
 Produzir um trabalho de alta qualidade permanentemente;
 Pedir e receber ajuda de seus colegas e do cliente;
 Gerar e atualizar as suas estimativas;
 Escolher as suas responsabilidades, ao invés delas serem determinadas
para você.

eXtreme Programming
Escrevendo Estórias
Todas as funcionalidades do sistema são levantadas através de estórias que
são registradas em pequenos cartões. Estas estórias devem ser escritas pelo
cliente, com suas próprias palavras.

eXtreme Programming
Escrevendo Estórias
Embora possa parecer estranho pedir ao cliente para escrever as
estórias, existem fortes razões para isso:
 O cliente é forçado a pensar melhor na funcionalidade;
 O cliente se torna responsável sobre aquilo que está sendo
solicitado;
 Fazer o cliente perceber que está gastando ao pedir uma
funcionalidade.

eXtreme Programming
Tarefas
A equipe de desenvolvimento utiliza os cartões para saber quais são
as funcionalidades desejadas pelo cliente. Os desenvolvedores
escolhem as estórias que irão implementar a cada dia de trabalho.
Entretanto, em projeto muito grande, os cartões podem acabar
representando estórias que consomem muito esforço para
implementar. Nestes casos, é comum a equipe dividir os cartões em
tarefas. Elas são registradas em novos cartões de modo que possam
ser distribuídas facilmente entre a equipe de desenvolvedores.
Exemplos:
1. Apresente ao cliente 10 tarifas mais
baratas para uma determinada rota;
2. O usuário deve poder alterar o seu perfil
(email, senha, primeiro nome, ultimo nome
e filiação). Dois campos de senha para
confirmação.

eXtreme Programming
Estimando Estórias
Para estimar a equipe de desenvolvimento precisa adotar uma
unidade de medida que será usada para todas as estórias.
Os desenvolvedores costumam estimar indicando a quantidade de
tempo (horas) que uma funcionalidade irá consumir.
O XP utiliza o conceito de dia ideal de desenvolvimento, que
representa um dia no qual o desenvolvedor trabalha na
implementação de funcionalidades, sem ter que se preocupar com
nenhuma atividade extra.
Usando pontos para estimar
Estimando por comparação
Estimando em equipe

eXtreme Programming
Planejando os Releases
O XP trabalha com o objetivo de gerar valor para o cliente ao longo
de todo o projeto. Para fazer isso, é importante que o software seja
entregue de forma incremental, de modo que após cada entrega o
cliente possa começar a utilizar o sistema e obter os benefícios que
ele oferece. Estas entregas recebem o nome de release em XP.
Os projetos em XP costumas ser divididos em releases, de modo que
cada release implementa um conjunto de funcionalidades que possui
um valor bem definido para o cliente. Por exemplo, imagine que o
projeto de oito meses seja dividido em quatro releases, como
ilustrado na figura abaixo.
8 sem.
Projeto dividido em releases

eXtreme Programming
Projeto Dividido em Releases
Suponha que este seja o projeto de um site de vendas on-line de
uma grande loja de departamentos. Poderíamos imaginar a seguinte
distribuição para os releases:
 R1: Consulta dos produtos em estoque;
 R2: Processamento de compras on-line;
 R3: Acompanhamento de pedidos;
 R4: Campanha de marketing de relacionamento.
Projetos XP procuram trabalhar com o conceito de releases
pequenos, isto é, os releases têm curta duração. Preferencialmente,
devem ter em torno de dois meses. Com isso, o cliente pode
começar a usufruir os benefícios do software e a equipe de
desenvolvimento passa a ter a oportunidade de receber feedback dos
usuários finais do sistema, o que permite que ela faça ajustes, de
modo a aprimorar a qualidade dos releases subsequentes.

eXtreme Programming
Priorizando as Estórias de Cada
Release
 As releases devem ter tamanhos fixos e pequenos
 Estabelecer a ordem (necessidades do cliente)
 Verificar a NECESSIDADE X ASPECTOS TÉCNICOS. Observar as
dependências técnicas
 Distribuir as estórias nos seus respectivos releases
 Não é necessário escrever todas as estórias do sistema no início
do projeto
 O cliente deve se concentrar nas estórias da primeira release (as
outras, deixar para o futuro para evitar trabalho especulativo)
 Dedicação nas estórias do release corrente e criar estórias para os
releases futuros

eXtreme Programming
Planejando as Iterações
Uma iteração é basicamente um pequeno espaço de tempo dedicado
para a implementação de um conjunto de estórias. Em sua maioria,
os projetos XP utilizam iterações de duas semanas.
O início de cada iteração é caracterizado por uma reunião que recebe
o nome de reunião de planejamento da iteração.
Tamanho da iteração = 2 semanas = 10 dias úteis
Deve-se descontar:
 1 dia útil para a reunião de planejamento de iteração
 1 dia útil para o encerramento da iteração
Dias úteis para desenvolvimento = 10 – 2 = 8
 Número de desenvolvedores = 4 = 2 x 2 = 2 pares
 1 par/dia = 1 ponto
 1 par em 8 dias = 1 x 8 = 8 pontos
 2 pares em 8 dias = 2 x 8 = 16 pontos

eXtreme Programming
Dependências Técnicas
A ordem em que o cliente deseja que as estórias sejam
implementadas é afetada por dependências técnicas que a equipe
deve identificar e lhe apresentar.
O XP recomenda que a equipe procure sempre respeitar a ordem
indicada pelo cliente. Na maioria dos casos isso é perfeitamente
possível, desde que a equipe implemente algumas simplificações.
As dependências técnicas costumam ser bem menos criticas do que
aparentam. Para contorná-las a equipe deve ser criativa e buscar
soluções que permitam ao cliente acesso às estórias tal como ele as
ordena.
Iterações são diferentes de releases: O XP apresenta um meio termo
que permite que o cliente tenha flexibilidade e a equipe trabalhe com
estabilidade. Durante todo o projeto, o cliente pode fazer alterações
nas estórias. Já dentro de uma iteração, e apenas neste caso, o
cliente tem que respeitar o acordo da reunião de planejamento.

eXtreme Programming
Encerrando uma Iteração
O último dia da iteração é reservado para uma reunião de
encerramento. Nela, o cliente executa todos os teste de aceitação
que foram escritos para as estórias da iteração.
O objetivo é que ele valide todo sistema e verifique se o resultado da
iteração está satisfatório.
Utilizando o sistema ele poderá detectar eventuais erros, bem como
aprender mais sobre os requisitos e, se houver necessidade, fazer
mudanças nos mesmos.

eXtreme Programming
Encerrando um Release
Um release se encerra ao final da ultima iteração prevista pra ele. Ao
final do release, a equipe coloca o sistema em produção para que
todos os usuários passem a ter acesso a ele.
Quanto mais entradas em produção o projeto tiver, melhor será o
seu resultado para os usuários, visto que a cada release eles terão a
oportunidade de fornecer feedback para a equipe de
desenvolvimento. Isso ajudará a equipe a direcionar seus esforços
pata fazer com que o sistema fique cada vez mais adequado às
necessidades de seus usuários.

eXtreme Programming
Stand up Meeting
Um dia de trabalho de uma equipe XP sempre começa com um stand up meeting. Este
nome significa “reunião em pé” em inglês. Esta reunião não tem apenas o objetivo de
avaliar o passado. Ela também é utilizada para decidir o que será feito no dia que se inicia.
Ela serve para priorizar as atividades dos membros da equipe ao longo do dia.

eXtreme Programming
Diariamente, no stand up meeting, a equipe decide em conjunto que
cartões serão tratados naquele dia e quem cuidará de cada cartão.
No fim do stand up meeting, cada membro da equipe sabe o que
deverá fazer ao longo do dia. É importante notar que a decisão sobre
o que fazer ao longo do dia não é tomada por uma única pessoa. Essa
decisão é tomada em equipe.
Stand up Meeting

eXtreme Programming
Programação em Par
Os desenvolvedores não trabalham sozinhos em um projeto que
utilize XP. Eles sempre trabalham em pares. Trata-se da programação
em par ou pair programming, como é conhecido em inglês.

eXtreme Programming
Os efeitos sobre a produtividade da equipe
A ideia da programação em par parece estranha a princípio porque
“enquanto um desenvolvedor o outro fica parado”. Isto é, “um
trabalha enquanto o outro não faz nada”. Obviamente não é isso o
que ocorre, mas é isso o que muita gente acaba interpretando
erroneamente.
Na verdade, um desenvolvedor digita enquanto o outro não digita.
Mas, ambos estão programando juntos. A programação em par
pressupõe uma comunicação contínua entre os desenvolvedores que
formam o par. Através da conversa, eles discutem as melhores
alternativas, corrigem erros, analisam cenários, enfim, discutem as
melhores ideias para a resolução de cada problema. Portanto, é
absolutamente incorreto acreditar que um trabalha enquanto o outro
fica parado. Ambos estão trabalhando o tempo todo.

eXtreme Programming
A pressão do Par
O ato de programar demanda grande concentração e produz um
gasto de energia considerável. Entretanto, no dia-a-dia de um
programador, ele se depara com diversas fontes de distração: email,
bate-papo com colegas, cansaço. Isto diminui seu ritmo de trabalho
no código.
A programação em par corrige estes desvios através da pressão em
par. O programador quando está acompanhado de outra pessoa, ele
deixa de ter um compromisso apenas consigo mesmo. O seu
compromisso se expande e passa a englobar também o seu colega.
Ou seja, sua responsabilidade aumenta já que passa a envolver mais
alguém. O efeito disso é que diversos focos de distração são
eliminados.

eXtreme Programming
Revezamento
A condução da programação é uma atividade que deve ser realizada
sempre por ambos os programadores que formam um par. Um de
cada vez, naturalmente. Para isso, é fundamental que eles se revezem
diversas vezes ao longo de um dia de trabalho.
O revezamento não se aplica apenas à questão de quem conduz o
teclado. Ele também nos leva à questão de quem será o nosso par.
Em um projeto, devemos trocar de par com frequência. Esta troca de
par é importante para a disseminação do conhecimento.

eXtreme Programming
Desafios
 A organização do escritório
 A visão gerencial
 O relacionamento humano
 Competição

eXtreme Programming
Refactoring
Desenvolvimento Guiado por
Testes (TDD)

eXtreme Programming
Refactoring – Conceitos básicos
Refactoring é o processo de modificar um software para melhorar a
estrutura interna do código.
Esse processo não repara erros e nem adiciona novas
funcionalidades.
Outra consequência é a melhora no entendimento do código, o que
facilita a manutenção e evita a inclusão de bugs. Esta melhora no
entendimento vem da constante alteração do código com objetivo de
facilitar a comunicação de motivações, intenções e objetivos por
parte do programador.

eXtreme Programming
 Obter um código-fonte claro e de fácil manutenção
 Reduzir a complexidade da aplicação
 Remover redundâncias desnecessárias
 Reutilizar código
 Otimizar o desempenho do software.
Objetivos Básicos

eXtreme Programming
Desenvolvimento Guiado pelos Testes (TDD)
Teste é parte do desenvolvimento de software que todo mundo sabe
que precisa ser feita, mas ninguem quer fazer.
Testar costuma ser considerado uma atividade chata, que consome
tempo e só é valorizada depois que o sistema entra em produção e
diversos problemas começam a surgir.
Grande parte dos projetos deixam os testes para serem feitos no final
(isso quando são feitos!)

eXtreme Programming
Por que Devemos Testar?
Se o desenvolvedor escreve um código incorreto e descobre isso dois
meses depois, a sua capacidade de aprendizado é muito baixa. Por
outro lado, se ele descobre alguns segundos após introduzir o erro,
ele aprende rapidamente que tipo de coisa ele fez que gera erro.
Sendo assim, ele provavelmente não errará de novo no futuro.
Quando os testes fazem parte do desenvolvimento, os
programadores recebem feedback rapidamente sobre aquilo que
estão fazendo. Com isso aprendem mais, resolvem os defeitos e tem
mais tempo para desenvolver funcionalidades e gerar valor para o
cliente.

eXtreme Programming
Testar é Investir
Quando testamos, estamos fazendo um investimento e esperamos
que ele gere um retorno no futuro. No caso de testes, este retorno
acontece quando:
• O desenvolvedor testa alguma coisa que deveria falhar e ela
simplesmente funciona.
• O teste falha quando já vinha funcionando normalmente, ou
seja, surgiu um defeito no sistema e o teste detectou.

eXtreme Programming
Testando o XP
O XP trabalha com dois tipos de testes: testes de unidade e testes de
aceitação.
Testes de unidade: é aquele realizado em cada classe do sistema para
verificar se os resultados gerados são corretos.
Testes de aceitação: São efetuados sobre cada funcionalidade, ou
estória do sistema.

eXtreme Programming
Testes de Unidade
 Devem ser automatizados
 100% deles devem rodar corretamente ao longo de todo o
desenvolvimento
Desafios
 Visto como aumento de trabalho pela equipe
 A programação em par
 Início difícil de trabalhar e automatizar
Fatores essenciais
 Conhecimento
 Ferramentas
 Programação em par
 Persistência

eXtreme Programming
Questões sobre os Testes de Unidade
 Testes com acesso a um BD?
 Testes rodando muito lentamente?
 E quando não consigo imaginar como testar uma classe?
 Como saber se testei tudo que podera quebrar?
 Código já escrito e não existem testes pra ele?
 Erros que aparecem da colaboração entre diferentes classes?
 GUIs?
 Meu código não pode ser testado porque…
 Testar a entrega

eXtreme Programming
Testes de Aceitação
Além de verificar se cada classe está funcionando corretamente, é
importante verificar se as classes englobadas por uma estória estão se
relacionando corretamente.
Quem cria e executa estes testes?
Cliente? Analista de testes? Os dois?
Testando em cada iteração
 Descrever os testes em cartões, depois juntem estes aos cartões
da estória.
 Um cartão só pode ser considerado finalizado quando o teste de
aceitação do mesmo for executado com sucesso.
Automatizando
HTML  HttpUnit
Java  Jbehave, Selenium WebDriver, …

Exemplo de Teste de Aceitação
Estória Visualizar os itens do carrinho de compras
Número Ação Resultado esperado
1
 Entrar no site
 Visualizar os itens do carrinho de compras
Mostra a mensagem: “Seu carrinho de
compras está vazio”
2
 Adicionar ao carrinho o produto: “Geladeira 380L”
 Visualizar os itens do carrinho de compras
Mostra uma linha contendo a
informação:
Geladeira 380L – 1 unidade – R$1500,00
3
 Adicionar ao carrinho o produto: “Fogão 4 bocas”
 Visualizar os itens do carrinho de compras
Mostra uma linha contendo a
informação:
Geladeira 380L – 1 unidade – R$1500,00
Fogão 4 bocas – 1 unidade – R$750,00
4
 Visualizar os itens do carrinho de compras
 Clicar em “Excluir” ao lado da linha que contém a
geladeira
Mostra uma linha contendo a
informação:
Fogão 4 bocas – 1 unidade – R$750,00
5
 Visualizar os itens do carrinho de compras
 Clicar em “Excluir” ao lado da linha que contém o fogão
Mostra a mensagem: “Seu carrinho de
compras está vazio”

eXtreme Programming

eXtreme Programming
Código Coletivo Padrões de
Codificação

eXtreme Programming
Código Coletivo
Quando um projeto é implementado por uma equipe, é comum
dividi-lo em partes, de modo que cada membro da equipe fique
responsável por uma ou mais partes. Desta forma, cada pessoa é
responsável por um subconjunto do código que forma o projeto.
A divisão do trabalho é uma prática comum em diversa áreas
profissionais. A forma como esta divisão é feita afeta diretamente o
resultado final de um projeto.
É bastante comum encontrarmos “ilhas de conhecimento” nos
projetos de software. Uma “ilha de conhecimento” pode ser
compreendida como sendo uma pessoa que possui um domínio
sobre uma área do projeto. Somente ela conhece aquela parte ou
aquele código. Se outra pessoa precisar mexer naquela parte, deverá
solicitar à ilha de conhecimento que entre em ação.

eXtreme Programming
A programação em par, por si só, já colabora para evitar a formação
de “ilhas de conhecimento”. Porém, o código coletivo vai além. Ele dá
a todas as pessoas a chance de mexer em qualquer parte do sistema.
É importante que ele seja sempre escrito da maneira mais legível
possível. Pois isto é o que garantirá que a equipe conseguirá
continuar a implementar o sistema.
Vale notar também que o código coletivo leva a equipe a ser mais
ágil no desenvolvimento. Como não existe um responsável por certa
parte do código, qualquer pessoa pode mexer nela tão logo sinta a
necessidade de fazê-lo. Não é necessário esperar por ninguém, não
é necessário esperar pelo especialista.
Código Coletivo

eXtreme Programming
Padrões de Codificação
Se você analisar o código de diferentes programadores,
provavelmente irá notar que existem diferenças de estilo. Por
exemplo, um programador prefere colocar { no final da declaração de
um método, enquanto outro prefere colocar na linha posterior.
O XP recomenda que a equipe adote um padrão no início do projeto.
Ela pode construir este padrão em conjunto ou pode adotar um que já
exista e esteja documentado em algum lugar, como por exemplo:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html

eXtreme Programming
Padrões de Codificação
Procure adotar um padrão que seja fácil e simples. Isso evita
resistência e facilita a compreensão do código, ou seja, melhora a
comunicação.
Jeffries et al. (2001, p.79) apresenta alguns tópicos a considerar:
 Identação
 Letras maiúsculas e minúsculas
 Comentários (evitá-los tanto quanto possível)
 Nomes

eXtreme Programming
Design Simples
Metáfora

eXtreme Programming
Design Tradicional
“O custo de se corrigir um
problema em um software
cresce exponencialmente ao
longo do tempo. Um problema
que poderia ter custado um
dólar para ser corrigido se
tivesse sido encontrado durante
a análise pode custar milhares
de dólares para ser resolvido
depois que o software já estiver
em produção.”

eXtreme Programming
O custo de uma alteração no XP
A comunidade de desenvolvimento de software investiu uma enorme
quantidade de recursos nas últimas décadas no sentido de reduzir os
custos de uma alteração em um software. Estes investimentos gerou
diversos avanços:
 Melhores linguagens de programação
 Avanços na tecnologia de banco de dados
 Melhores práticas de programação
 Novos ambientes e ferramentas de desenvolvimento
 Computadores mais rápidos e mais baratos
 Orientação a objetos

eXtreme Programming
Infelizmente a única constante em um projeto de software é a
mudança:
 Os requisitos mudam
 O design muda
 A tecnologia muda
 A equipe muda
 Os membros da equipe mudam
O problema não está na mudança em si, porque ela vai acontecer de
qualquer jeito. O problema é a incapacidade de lidar com ela quando
ela chegar.
Design Tradicional

eXtreme Programming
Estratégia
Para alcançar um design simples, o XP recomenda que você utilize a
seguinte estratégia:
1. Comece escrevendo um teste.
2. Faça o design e implemente apenas o suficiente para passar
nos testes.
3. Execute os passos 1 e 2 novamente tanto quanto necessário.
4. Se você identificar a oportunidade de tornar o design mais
simples, faça isso.
No XP, o design é criado de forma incremental. Sendo assim, ao final
da primeira iteração, o seu software terá um design bastante simples,
suficiente para as funcionalidades daquela iteração. Na segunda, terá
que fazer alguns refactorings e fará alterações no design, de modo a
incorporar novas funcionalidades.

eXtreme Programming
Simplicidade
Exemplo de quatro regras básicas para definir simplicidade:
1. O sistema (código e testes em conjunto) deve expressar tudo
aquilo que você deseja comunicar
2. O sistema não deve conter nenhum código duplicado
3. O sistema deve ter o menor número de classes possível
4. O sistema deve ter o menor número de métodos possível
Atualmente, existe uma verdadeira febre pela utilização de
frameworks que possam facilitar o desenvolvimento de sistemas.
Tais frameworks contêm uma série de funcionalidades genéricas que
podem poupar esforço da equipe ao longo do desenvolvimento.
Entretanto, existem custos associados à utilização de frameworks:
curva de aprendizado e são abrangentes demais.

eXtreme Programming
Metáfora
Metáforas são usadas frequentemente durante o desenvolvimento de
sistemas, na medida em que os desenvolvedores criam elementos
dentro do computador para simular outros que existem
regularmente fora dele, no mundo físico.

eXtreme Programming
XP procura explorar ao máximo a utilização de metáforas, para que
clientes e desenvolvedores sejam capazes de estabelecer uma
vocabulário apropriado para o projeto, repleto de nomes
representando elementos físicos com os quais os clientes estejam
habituados em seu dia-a-dia, de modo a elevar a compreensão
mútua.
Metáfora

eXtreme Programming
Ritmo Sustentável
Integração Contínua
Releases Curtos

eXtreme Programming
Ritmo Sustentável
O XP PROÍBE que os desenvolvedores trabalhem até mais
tarde. O XP sugere um ritmo sustentável de 40 HORAS
SEMANAIS, respeitando assim a individualidade e o físico
de cada desenvolvedor. Desta forma a equipe estará
sempre concentrada e muito menos propensa a pequenas
falhas na implementação.

eXtreme Programming
Integração Contínua
O XP propõe uma integração contínua, se possível deve
ser efetuada diversas vezes ao dia para que toda a equipe
tenha conhecimento do código recém-desenvolvido. Com
esta prática o feedback sobre a alteração efetuada será
obtido em um menor espaço de tempo.
Dificuldades em integrar diversas vezes ao dia:
 Tempo de build
 Código Coletivo
 Programação em Par

eXtreme Programming
Integração Contínua
Segundo Jeffries et al. (2001), em XP o código avança em
3 fases:
 Local: As mudanças que o par executou no código
ainda não estão disponíveis para os demais.
 Candidato à Liberação: O par terminou a tarefa e está
tudo pornto para a disponibilização.
 Disponibilizado: Código pronto. Testes 100%.

eXtreme Programming
Integração Contínua
Ferramentas: Para que seja feita a integração contínua,
são necessárias ao menos duas categorias de
ferramentas para auxiliá-lo:
 Ferramenta de build – Ant ou Maven
 Sistema de controle de versão (Repositório) – CVS,
Git, ClearCase, SourceSafe (Team Foundation Server)
etc.

eXtreme Programming
Releases Curtos
O XP recomenda que pequenos investimentos sejam
efetuados de forma gradual e que busquem grandes
recompensas o mais rapidamente possível. Com a prática
de releases curtos, o XP pretende dar o máximo de valor
econômico ao cliente em um curto espaço de tempo.
Release é um conjunto de funcionalidades bem definidas
e que representam algum valor para o cliente.

eXtreme Programming
Releases Curtos

 Formado em Análise de Sistemas
 Pós-Graduado em Auditoria em T.I.
 Gerente de TI da CLIOC – Coleção de Leishmania do
Instituto Oswaldo Cruz – Fiocruz
 Certificado em Gestão de Segurança da Informação e
Gerenciamento de T.I. pela Academia Latino-Americana
(Microsoft TechNet / Módulo Security)
Carlos Henrique M. da Silva
carloshenrique.85@globo.com