I_Teorico

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Projetos Ágeis 
com Extreme 
Programming (XP)
Introdução ao Extreme Programming
Responsável pelo Conteúdo:
Prof. Me. Artur Ubaldo Marques Junior
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Nesta unidade, trabalharemos os seguintes tópicos:
• XP – Extreme Programming;
• Histórias dos Usuários;
• Planning Game (Jogo do Planejamento);
• Pequenos Lançamentos.
Fonte: iStock/Getty Im
ages
Objetivos
• Familiarizar o estudante com o método XP de desenvolvimento de software.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Introdução ao Extreme Programming
UNIDADE 
Introdução ao Extreme Programming
Contextualização 
Extreme Programming – XP tem sido o alicerce de desenvolvimento dos times ágeis, 
juntamente com SCRUM, principalmente, nos últimos anos. Isso se deve à simplificação 
e às práticas utilizadas pelos times ágeis que se valem de XP para o desenvolvimento eficaz 
de software. XP, como toda metodologia, é baseada em práticas. 
Teles (2006) nos elucida que as “Práticas em XP representam aquilo que você verá 
as equipes XP fazendo diariamente. Práticas por si só são estéreis. A menos que você 
dê algum propósito, dado por um conjunto de valores, elas não fazem muito sentido”.
Além disso, ele nos lembra de que as práticas dependem da situação e do contexto 
para o seu uso. Dessa forma, com as inevitáveis mudanças de situação, outras práticas 
devem ser utilizadas para resolver a situação problema e XP possui muitas práticas; 
você poderá usar à vontade.
Por fim, dentro do XP, as práticas podem ser outras, de acordo com a situação en-
frentada; porém, os valores não têm de mudar para se adaptar a uma nova situação. 
Alguns novos princípios podem vir a ser necessários quando se muda de domínio.
A síntese de XP é tornar você melhor e podemos resumir isso na frase do mesmo au-
tor: “As práticas aplicadas são direcionadores para você saber onde está e aonde poderá 
chegar. Portanto, você progride em direção ao estado ideal de desenvolvimento eficaz”.
6
7
XP – Extreme Programming
Extreme Programming – XP, em português, Programação Extrema, é uma meto-
dologia para desenvolvimento de software ágil, cujos primeiros conceitos apareceram 
no final da década de 80, do século XX. Porém, a partir de um trabalho escrito por 
Kent Beck (um dos 17 participantes do manifesto ágil, em 2001) nessa mesma época, 
o XP foi efetivamente criado e dado o seu corpo de práticas. 
Beck, em extensão, além de ser reconhecido como criado do XP, também criou o 
TDD – Test Driven Development ou Desenvolvimento Guiado por Testes, metodo-
logia muito eficaz utilizada atualmente por grandes Empresas como a Microsoft.
Como grande parte das metodologias ágeis, XP utiliza como base de seu desenvolvi-
mento um ciclo de vida de software, baseado em 4 etapas distintas:
• Planejamento;
• Projeto;
• Codificação;
• Testes.
Planejam
ento
Projeto
Codi�caç
ão
Teste
Incremento de software
 Velocidade de projeto calculada
Versão
Teste de aceitação
Teste de unidades
 integração contínua
Soluções pontuais
 protótipos
Projeto simples
 cartões CRCHistórias de usuários
 valores
 critérios de teste de aceitação
Plano de iteração
Programação em pares
Refatoração
Figura 1 – Ciclo de Vida do Processo XP
Fonte: Adaptado de Pressman, 2006
7
UNIDADE 
Introdução ao Extreme Programming
Em linhas gerais, o projeto inicia com a fase de planejamento, ou seja, uma descrição 
baseada em histórias do usuário que gera um entendimento do domínio do problema 
utilizando cartões índices feitos pelos usuários, nos quais estão os requisitos de enten-
dimento do negócio. É feito um jogo de planejamento usando técnicas de estimativa 
ágeis, em que o que interessa é a complexidade envolvida na funcionalidade. Na fase 
de projeto, são oferecidas soluções e alguns protótipos para que a equipe e os usuários 
se sintam confiantes em desenvolver. A codificação leva em consideração pequenas ite-
rações com entregas constantes, sempre levando em conta a refatoração (melhoria do 
código deixando-o limpo; porém, sem mudar suas características de funcionamento). 
Os testes são obrigatórios em XP, normalmente feitos para cada unidade de software, de 
tal forma que, antes mesmo da codificação, esses testes, uma vez passados, geram ver-
sões que após verificação e correção são validadas, e integradas ao código em execução 
ou, se preferir, uma nova versão do software. Isso se repete até que o software final seja 
entregue em funcionamento. 
Resumo funcional baseado em: PRESSMAN, 2006, p. 72
XP não é um framework baseado em processos enfadonhos, como pudemos obser-
var no curtíssimo resumo do ciclo de vida XP, na Figura 1.
Ele pode ser considerado o primeiro método ágil funcional; além disso, promove a 
iteração de forma circular, levando em consideração ao menos 12 práticas de projeto e 
codificação levadas pelo time de forma extrema; daí o nome XP.
Temos de conhecer as práticas de maneira introdutória, e para isso Kent Beck (cria-
dor do XP) desenvolveu um processo que permite o uso dessas práticas a qualquer 
tempo, conforme descrito por Hutagalung (2006), que versa resumidamente sobre as 
práticas, definindo-as:
1. Histórias de usuários: as histórias do usuário podem ser visualizadas 
como uma versão menor do caso de uso. Desta forma, o cliente define 
o mais breve possível a especificação da nova aplicação (características, 
valor, prioridade). Essas histórias serão a base para a equipe de projeto 
fazer estimativa de custos e gerenciamento do projeto;
2. Pequenos lançamentos: enfatiza atualizações de versões pequenas, 
simples, mas frequentes do aplicativo. Cada requisito recém-adiciona-
do será imediatamente incorporado e o sistema será relançado;
3. Metáfora (esquemas de nomeação padronizados): desenvolvedo-
res e programadores devem aderir aos padrões de nomes, nomes de 
classes e métodos;
4. Propriedade coletiva: todo o código é considerado de propriedade 
de toda a equipe e não de um indivíduo. Portanto, todo o código é 
revisado e atualizado por todos;
5. Padrão de codificação: estilos e formatos de codificação devem ser os 
mesmos para permitir a compatibilidade entre os membros da equipe. 
Essa abordagem resulta em uma colaboração mais rápida;
6. Design simples: sempre procure a implementação do sistema que seja 
tão fácil quanto possível;
8
9
7. Refatoração: o aplicativo deve ser continuamente ajustado e aprimora-
do por todos os membros da equipe. Isso requer uma comunicação ex-
tremamente boa entre os membros para evitar a duplicação de trabalho;
8. Teste: toda pequena liberação (chamada de bloco de construção) deve 
passar nos testes antes de ser liberada. A singularidade do XP nesse 
aspecto é que os testes são criados primeiro e, em seguida, o código 
do aplicativo é desenvolvido para atender e passar nos desafios dos 
testes pré-escritos;
9. Programação em par: os programadores XP trabalham em pares. 
Todo o código é desenvolvido por dois programadores que trabalham 
juntos em uma única máquina.A expectativa é que a programação 
em pares produza códigos de maior qualidade com o mesmo custo ou 
com menor custo;
10. Integração contínua: as compilações de software são concluídas vá-
rias vezes ao dia. Dessa forma, todos os desenvolvedores podem evitar 
fragmentações de trabalho, pois eles liberam e integram continuamente 
o código juntos;
11. Semana de trabalho de 40 horas: Mantenha as condições men-
tais e físicas de estar funcionando sem trabalhar mais do que o 
corpo pode suportar;
12. Cliente no local: o cliente deve ser visto como parte integrante do pro-
jeto. O cliente deve estar disposto a estar sempre disponível para ga-
rantir que o projeto esteja no caminho certo. (HUTAGALUNG, 2006)
Extreme Programming
Valores
Práticas
Jogos do Planejamento
Pequenas Liberações
Metáforas
Desenho Simples
Teste
Refaturação
Programação em Pares
Donos Coletivos do Código
Integração Contínua
Semana de 40h
Cliente on-site
Usar Padrões de Codi�cação
Comunicação
Simplicidade
Coragem
Feedback
Figura 2 – XP Valores e Práticas
Os valores pelos quais XP se guia são o que norteia as equipes que programam nesse 
framework. Esses valores lastreiam as 12 práticas nomeadas na parte à direita do mapa 
mental, de tal maneira que são as atividades diárias realizadas pelas equipes durante o 
ciclo de vida. Disponível em: https://goo.gl/xWSEN4.
Fonte: Adaptado pelo autor
Para entendermos a forma como essas 12 práticas funcionam, precisamos enten-
der, inicialmente, suas 2 divisões.
As práticas, conforme Telles (2006), capacitam os desenvolvedores a responder com 
confiança às mudanças nos requisitos do cliente, mesmo no final do ciclo de vida do de-
senvolvimento do projeto. 
9
UNIDADE 
Introdução ao Extreme Programming
A filosofia do XP preza pelo trabalho em equipe; em outras palavras, gerentes, clien-
tes e desenvolvedores são parceiros iguais numa equipe colaborativa.
Fundamentam-se, como vimos na Figura 2, em 4 valores.
Vamos conhecer suas definições com maior profundidade nas outras unidades, mas 
agora é importante defini-las minimamente:
• Simplicidade: manter o design do software simples e limpo;
• Feedback: obter feedback do que se está fazendo mediante emprego de testes, e 
fazer isso desde o primeiro dia do projeto;
• Coragem e Respeito: entregar o Sistema aos clientes o mais cedo possível e im-
plementar as mudanças conforme sugerido. Cada pequeno sucesso aprofunda o 
respeito pelas contribuições únicas de cada membro da equipe.
Muita gente boa de desenvolvimento de software, porém com visão um pouco mío-
pe, acaba por entender que se há um framework, ele deve ser ultra estruturado, docu-
mental e com palavras solenes sobre comportamentos etc. etc. ... etc. ... 
Nada mais errado!
XP está mais para filosofia, ideologia, e é tenazmente seguido pelos times ágeis, 
pois fundamenta a forma de comportamento de um time de altíssima eficiência, exigido 
pelos tempos modernos, não é mesmo?
Você precisa entender isso e começar a adotar em sua vida, na área de TIC – Tec-
nologia da Informação e Comunicação, tanto para desenvolver softwares, como em 
qualquer projeto que exija desenvolvimento.
Essas práticas são necessárias e muito queridas para que uma Empresa ou equipe se 
destaquem pelo que produzem.
Para que você possa entender esse turbilhão de valores e práticas e suas aplicações, 
é necessário conhecer a história por trás do XP, incluindo seus autores e fases, bem 
como saber de seus avanços e de que forma eles influenciaram as metodologias ágeis e 
lean usadas e festejadas nos dias atuais.
Vamos lá!
A história do XP é bastante interessante e é apresentada por Cunningham (2008) 
com alguns eventos impactantes no tempo, que servem de balizamento para entender-
mos desde a crise do software, da década de 70 do século XX, e a sequência de ações 
que proporcionaram o ambiente propício para o surgimento dos métodos ágeis e, em 
particular, do XP:
• Tudo começou quando em meados dos anos de 1970, Christopher 
Alexander recomenda um processo incremental para o design de 
software;
• Nessa mesma época, Seymour Papert, conecta o ato de programar 
com a aprendizagem e Alan Kay inclui modelagem orientada a objetos 
para apoiar os processos desenvolvidos por Christopher Alexander;
10
11
• Outros eventos ocorreram nesse tempo, como programação aos pa-
res, na verdade uma pratica da década de 60, que foi redescoberta 
por Ward e Kent Beck, que mais tarde criaria o XP, desenvolveram 
15 frameworks diferentes para testes ágeis durante vários meses;
• Ward usou parte desses 15 frameworks ágeis criados por eles, no de-
senvolvimento de um software comercial chamado WyCash. Além disso, 
ele introduz práticas específicas para preservar a flexibilidade do projeto 
em face das demandas do cliente e dos horários fluídos. XP começava a 
se desenhar;
• O Hillside Group um grupo de desenvolvedores defende durante a 
crise de software da década de 70 que quando se trata de desenvolvi-
mento de software usando metodologias inovadoras, o alto risco que 
se corre desenvolvendo por iterações pode gerar uma alta recompen-
sa. Esse grupo nutre um conjunto de valores que se tornam essenciais 
para o XP que ainda não foi gerado;
• Kent Beck escreve novos padrões de programação para um cliente 
durante uma consultoria. Apesar de esses métodos serem bem rece-
bidos, seu efeito não foi o que se esperava. Porém a evolução desses 
novos padrões cresce e se torna para a linguagem Smalltalk os seus 
padrões e melhores práticas;
• Em 1999, Kent Beck foi contratado e trabalha no projeto WellFleet 
para a Hewitt Associates. Aqui ele primeiro ensina consistentemente 
uma equipe como mentor e consultor. Acaba difundindo uma das gran-
des práticas que se tornarão um fundamento e distinção tanto do XP 
e TDD, estamos falando dos Testes de Unidade, enfim o projeto entra 
em produção com muito pouco problemas em 1999;
• Kent Beck é novamente contratado como consultor para executar o 
projeto de folha de pagamento da Chrysler. Ele encontra proble-
mas mais profundos, diz à alta administração para começar de novo 
o projeto. Este é o ponto em que Kent “gira os botões”, aproveitando 
sua experiência com Smalltalk, Patterns e Hillside e cria o XP e o 
apresenta para o mundo. (CUNNINGHAM, 2008)
XP é uma metodologia tão importante nos dias atuais, que grande parte das Em-
presas de software a colocam com uso obrigatório em times ágeis em conjunto com 
SCRUM, para uma complementar a outra e potencializar o efeito desejado para um 
software excelente e rápido. 
Nas palavras de Martin Fowler, um dos signatários do Manifesto Ágil e colaborador 
de Kent Beck no XP:
XP foi um dos primeiros métodos ágeis, na verdade, ele foi o método 
ágil dominante no final dos anos 90 e início dos anos 00, antes de 
Scrum se tornar dominante. Muitas pessoas o consideram como o 
principal catalisador que chamou a atenção para métodos ágeis, e 
superior ao Scrum como base para iniciar um desenvolvimento ágil.
Como todos sabem, é muito difícil um sistema ser desenvolvido num ambiente calmo, 
tranquilo e sem mudança de requisitos.
11
UNIDADE 
Introdução ao Extreme Programming
Na realidade, é muito difícil que os projetos sigam o fluxo sequencial do modelo 
em cascata, por exemplo, bem como se percebe a dificuldade em se identificar todos 
os requisitos e metas no início dos projetos, pois os requisitos tendem a mudar com-
pletamente durante o tempo e, por fim, se seguirmos métodos tradicionais, como o 
cascata, uma versão funcional só pode ser obtida no final do processo, o que vale dizer 
que, muitas vezes, o negócio mudou completamente, ou pior, deixou de existir e o 
projeto, por consequência, foi cancelado.
A palavra que diferencia um método tradicional de um método ágil é ADAPTAÇÃO!
XP é tremendamente adaptativo em frente aos métodos tradicionais e isso é verda-
deiro, porque ele responde prontamente às mudanças.
A base disso são alguns princípios ágeis seguidos, como:
• Escrever o teste de maneira precoce, focado naautomação (uso de softwares de 
teste automatizados), já que é provável que esse teste esteja errado de alguma for-
ma até a entrega ocorrer;
• Design Incremental;
• Implantação diária;
• Alto nível de envolvimento do cliente;
• Integração contínua;
• Ciclos de desenvolvimento curtos;
• Planejamento incremental;
• Base de código único;
• Abraçar a mudança, no lugar de evitar a mudança.
Itens importantes sem dúvida, mesmo assim insuficientes na opinião de Kent que, 
quando trabalhou no projeto da Chrysler, percebeu 4 dimensões importantes que não 
podem ser deixadas ao lado em XP, pois definem rumos de sucesso ou fracasso. 
São elas:
• Você precisa melhorar a comunicação!
• Você precisa buscar simplicidade!
• Você precisa obter feedback sobre o quão bem você está fazendo as coisas!
• Você precisa sempre prosseguir com coragem!
Claro, para que você possa vivenciar isso, é necessário estar trabalhando num ambiente 
democrático de respeito às ideias e com gente de alto nível profissional e humano. 
Isso não existirá se você estiver imerso numa empresa autocrática ou baseada numa 
estrutura de cargos orientados a graus de parentesco ou amizade, e não em competên-
cia e mérito, como vemos fortemente ancorada nos países de origem anglo-saxônica, 
germânica, gaulesa ou asiática que, de uma forma ou de outra, também são os líderes 
em educação, desenvolvimento humano e engenharia de software. 
12
13
Creio que nós, latinos, ainda temos muito que aprender com eles, não é mesmo?
XP tem a fama que seu nome traz, que é levar todas as suas práticas ao extremo 
(são 12 lembra?). 
A seguir, na Tabela 1, você poderá ver algumas referências diretas dos extremos de XP.
Tabela 1 – Algumas práticas levadas ao extremo por XP
Boas práticas são Levadas ao extremo
Revisões de código Rever o código o tempo todo (programação em pares)
Testando Todo mundo vai testar o tempo todo (testes de unidade); até mesmo os clientes (teste funcional e de aceitação)
Desenhar Faça parte do negócio diário de todos (refatoração)
Simplicidade Sempre deixe o sistema com o design mais simples que suporta a funcionalidade atual (a coisa mais simples que possa funcionar)
Arquitetura Todo mundo vai trabalhar definindo e refinando a arquitetura o tempo todo (uso de metáforas)
Teste de integração Integrar e testar várias vezes ao dia (integração contínua)
Iterações curtas Faça iterações realmente curtas: horas, e não semanas, meses ou anos (o jogo de planejamento esclarece)
Fonte: https://goo.gl/7SgvfL
XP segue 4 atividades consideradas padrão para o processo de desenvolvimento de 
software, a saber, e isso não é ciclo de vida; não confunda – são apenas atividades; por-
tanto, o time de desenvolvimento XP ou está:
• Fazendo codificação: codificação é considerada o único produto importante do 
processo de desenvolvimento do Sistema. Começa a codificação no início do dia e 
se entrega algo que funcione no fim do dia; isso é impreterível. Isso também signi-
fica que os codificadores não podem ser juniores!
• Elaborando ou realizando testes: é muito enfático que se deve sempre verificar 
se uma função funciona por meio do teste. XP se vale dos Testes de Unidade, que 
são testes automatizados, e o programador trabalhará o maior número possível de 
vezes para tentar quebrar o código que ele está escrevendo;
• Ouvindo: a habilidade e o conhecimento nos aspectos técnicos devem ser acom-
panhados pela capacidade de sermos bons ouvintes. Essa capacidade permiti-
rá que os desenvolvedores entendam o que os clientes querem e desenvolvam 
soluções que correspondam às necessidades e aos desejos dos clientes, o mais 
próximo possível. Portanto, habilidades psicossociais e emocionais dos desenvol-
vedores não são mais somente porque foi feita uma escolha de sorte pelo pessoal 
do RH. São itens obrigatórios; um programador/analista sem essas habilidades, 
infelizmente, não é mais considerado para contratação, principalmente, para 
softwares comerciais. É importante desenvolver essas habilidades;
• Projetando: a simplicidade do XP não significa que ele possa excluir o processo de 
design. Sem um projeto adequado no longo prazo, o Sistema se torna muito complexo 
e os projetos podem parar. Importante criar uma estrutura de projeto que organize a 
lógica no Sistema, de modo que muitas dependências no Sistema possam ser evitadas.
13
UNIDADE 
Introdução ao Extreme Programming
Então, podemos enxergar graficamente os grandes eventos durante o desenvolvi-
mento XP, conforme mostrado pela figura a seguir:
Requisitos
do Projeto
Histórias
do Usuário
Casos
de Teste
Tarefas Conclusão
Usuário
Testando
Teste Unitários
Automatizados
Métricas das Histórias
Realizadas
Encontros de
planejamento
de liberação
Testes de
Aceitação
Entradas
do Usuário
Figura 3 – Visão simplifi cada dos grandes eventos no desenvolvimento XP
Fonte: Adaptado de umsl.edu
Histórias dos Usuários
Histórias do usuário é a pedra de toque dos métodos ágeis; elas foram iniciadas 
quando o XP foi criado e implantado para valer num projeto da Chrysler Motors; hoje 
uma empresa do grupo FCA. 
Sabemos que, normalmente, a primeira fase de um projeto e mesmo de um framework 
trata da elicitação de requisitos dos usuários que, de forma tradicional, trata de um levanta-
mento formal das necessidades de um projeto de software.
O problema é que esse documento formal feito por analistas obtido do pessoal de ne-
gócios e das áreas demandantes, apesar de relativamente minucioso e rico em detalhes, 
alicerça a estrutura inicial em que era feito o planejamento do Sistema para posterior 
codificação e entrega ao fim do projeto do software pronto.
Pois é, o problema começava exatamente aí. O negócio mudava no decorrer do pro-
jeto; já estávamos na década de 90, do século XX, próximo ao bug do milênio e outros 
momentos críticos para a indústria de software e também num evento especificamente 
cataclísmico, batizado um pouco mais tarde de Globalização.
Esse evento foi possível graças às Tecnologias de Comunicação que estavam evo-
luindo de forma voraz, principalmente, os protocolos de comunicação como os ISO e 
TCP-IP, que começaram a se solidificar durante a década de 1990. 
A Globalização e as novas TICs, incluindo Internet, browser e a recém-criada 
WWW colaboraram decisivamente para destruir as fronteiras físicas dos negócios, 
colocando tudo num cenário digital. Portanto, a velocidade da competição entre em-
presas antes transnacionais, agora globais, começou a acelerar de forma vertiginosa 
e a mudar as regras do jogo de forma geral e o comportamento e processamento 
dos dados em particular.
14
15
Isso sem dúvida criou mudanças nos negócios, regras e formas de ver as próprias orga-
nizações que refletiram de forma indubitável, no software e na forma de se fazer software. 
E ela aconteceu da pior forma possível, na forma de reclamações sobre fracassos 
na entrega, escopos totalmente desfocados da necessidade dos negócios e uma acele-
ração e custos somente comparável à quantidade de atraso gerado e posterior cance-
lamento, o que colocou a área de TI em xeque-mate.
Para enfrentar esses tempos difíceis, foi necessário entender que não se podia mais 
manter o usuário ou cliente longe do desenvolvimento do software, e que a primeira 
coisa que mudava num projeto de software eram os próprios requisitos, principalmen-
te, da forma com que eram feitos em documentos extensos e burocráticos.
É aí que a maré muda, e se percebeu que, para fazer frente a requisitos que muda-
vam, era necessário manter o que se chamou de histórias dos usuários sempre atuali-
zadas e a melhor forma de se fazer isso é mantendo os usuários e os clientes presentes 
durante o desenvolvimento e facilitar a vida de todas por meio de cartões índices (nada 
mais é do que uma ficha de catalogação bibliográfica)... ok, não se usa mais isso... 
quem disse?
Hoje, serve para escrever as famosas histórias do usuário, que nada mais são do que 
pequenas versões, bem curtas mesmo, com uma narrativa coesa sobreum comporta-
mento ou até uma funcionalidade do software que, em XP e nos métodos ágeis em 
geral, ajudam as equipes a manterem o norte, rumo ao sucesso.
Agora que já introduzimos você a esse importante artefato, vamos conhecer mais 
detalhadamente sua história.
As histórias dos usuários nas metodologias ágeis, em geral, e notadamente no XP, 
são a unidade fundamental das atividades dos times de desenvolvimento, como disse-
mos logo acima.
Release planning
As a ____, I
want to be able
to ____so that
____
Might have a initial
estimate (perhaps for
both analysis and
development), and an
expression of technical
and business and
con�dence that this is
real and achievable
Initial Story List
Iteration planning
As a ____, I
want to be able
to ____so that
____
Release Story List
As a ____, I
want to be able
to ____so that
____
I will know this
is done when
______
I will know this
is done when
______
To do this I must:
1 - ________
2 - ________
Iteration Story List
Development team breaks
out the detail of work
needed to pass test
Possible automation of
the acceptance test
More detaleid
estimate, and a
speci�c acceptance
test - low con�dence
stories might be
“spiked” or prototyped
Figura 4 – Histórias e seu fluxo pelo XP
Fonte: https://goo.gl/RohTas
15
UNIDADE 
Introdução ao Extreme Programming
As histórias de usuários são pequenas, muito menores do que outros artefatos de re-
quisitos, como casos de uso ou cenários de uso. É importante reconhecer que todas as 
declarações feitas num Index Card (Cartões de Índice) representam uma única história de 
usuário, por vez.
Mas, como escrevemos histórias de usuários? 
Vejamos a Figura 5:
• Os estudantes podem comprar passes de estacionamento mensais on-line;
• Os passes de estacionamento podem ser pagos por cartões de crédito;
• Os passes de estacionamento podem ser pagos via PayPal;
• Professores podem inserir as notas dos alunos;
• Os estudantes podem obter o cronograma atual do seminário;
• Os alunos podem solicitar transcrições oficiais;
• Os alunos só podem se inscrever em seminários para os quais tenham pré-requisitos;
• Transcrições estarão disponíveis on-line por meio de um navegador padrão.
Figura 5 – Exemplo de História Inicial do Usuário e Exemplo de Ficha de História de Usuário formal, 
digitalizada de sua fonte original. Ambas por Scott W. Ambler, 2009, criador do framework XP
Fonte: Adaptado de Scott W. Ambler
16
17
Vamos deixar uma coisa clara. 
Quem escreve história de usuários são... os usuários. 
É claro!
A equipe de desenvolvimento recebe, entende, analisa e pensa, sim, sabemos que isso 
é difícil, mas sim, eles pensam na arquitetura para atender aquelas histórias, na forma 
com que a interação humano computador será feita pelos designers, e demais aspectos 
do projeto do software.
Veja o que Ambler (2009) escreve a respeito disso, já que as partes interessadas – 
os clientes e usuários são “partes interessadas” – nesse projeto de software e para que 
as coisas aconteçam de forma correta devem ser estimuladas a escrever as “histórias 
de usuários”. 
Ele escreveu passo a passo o que você deve fazer para ser bem sucedido com as 
histórias de usuários:
• As partes interessadas escrevem histórias de usuários: um concei-
to importante é que os envolvidos no projeto escrevem as histórias do 
usuário, não os desenvolvedores. As histórias de usuários são simples 
o suficiente para que as pessoas aprendam a escrevê-las em poucos 
minutos, por isso faz sentido que os especialistas do domínio (as partes 
interessadas) as escrevam;
• Use a ferramenta mais simples: as histórias de usuários geralmente 
são escritas em fichas de índice. Os cartões de índice são muito fáceis 
de trabalhar e, portanto, são uma técnica de modelagem inclusiva;
• Lembre-se dos requisitos não funcionais: as histórias podem ser 
usadas para descrever uma ampla variedade de tipos de requisitos;
• Indique o tamanho estimado: inclua uma estimativa para o esforço 
de implementar a história do usuário. Uma maneira de estimar é atri-
buir pontos de história do usuário (planning poker) a cada cartão, uma 
indicação relativa de quanto esforço levará um par de programadores 
para implementar a história. A equipe sabe então que, se atualmente, 
leva em média 2,5 horas por ponto da carta; portanto, a história do 
usuário fica muito mais fácil de estimar. Então 2,5h x uma carta com 
5 pontos, teremos uma atividade cuja duração seria de aproximada-
mente 12,5h;
• Indique a prioridade: os requisitos, incluindo os defeitos identificados 
como parte de suas atividades de testes paralelos independentes ou por 
suas operações e esforços de suporte, são priorizados pelos envolvidos 
no projeto e adicionado à pilha no local apropriado. Você pode facil-
mente manter uma pilha de requisitos priorizados movendo as cartas 
na pilha conforme apropriado. O cartão de história do usuário inclui 
uma indicação da prioridade. Podemos usar uma escala de um a dez, 
sendo 1 a prioridade mais alta e 10 a mais baixa;
• Inclua um identificador exclusivo: o cartão também deverá possuir 
um identificador exclusivo para a história do usuário. A única razão 
para isso é manter a rastreabilidade entre a história do usuário e ou-
tros artefatos, em particular testes de aceitação. (AMBLER, 2009)
17
UNIDADE 
Introdução ao Extreme Programming
Bom, histórias de usuários são legais e muito úteis para o projeto. Mas como já vi-
venciamos, há usuário que se empolga e escreve mais um pouco. Claro que isso nem 
sempre é “non sense” ou “blá, blá, blá”. 
Podemos realmente ter histórias de usuários muito grandes, que chamamos de EPO-
PEIAS, ou grupos de histórias, que chamamos de TEMAS.
Vejamos como são estruturadas.
• Epopeias: são grandes histórias de usuário, normalmente, aquelas que são gran-
des demais para serem implementadas em uma única iteração e, portanto, pre-
cisam ser desagregadas em histórias de usuário menores, em algum momento 
(mais cartões índices). Normalmente, possuem prioridade mais baixa. Observa-
ção: não faz sentido desagregar uma epopeia de baixa prioridade, porque você 
estaria investindo tempo em algo que nunca poderá abordar, a menos que uma 
parte da epopeia seja de alta prioridade e precise ser abordada imediatamente 
pelo time de desenvolvimento;
• Tema: é uma coleção de histórias de usuários relacionadas. Por exemplo, para um 
Sistema de registro universitário, pode haver temas em torno dos alunos, gerencia-
mento de Cursos, geração de transcrição, administração de notas, processamen-
to financeiro. São usados para organizar histórias em lançamentos (iterações) ou 
organizá-las para que várias subequipes possam trabalhar nelas.
Você deve ter percebido que as histórias de usuários são o alfa e o ômega do XP.
A partir dessas histórias, os desenvolvedores costumam escrever os testes unitários 
baseados nelas. 
As histórias possuem as noções básicas da funcionalidade e são perfeitas para testes, 
porque são breves e caracterizam os recursos mais importantes do produto acabado. 
Os testes em XP, como já frisamos diversas vezes anteriormente neste texto, são 
escritos antes de começar a criação do código do próprio produto de software. 
Essa abordagem do pessoal de desenvolvimento visa a economizar tempo e a aten-
der aos termos do projeto.
Planning Game (Jogo do Planejamento)
O Jogo do Planejamento permite-nos encontrar rapidamente um plano aproxima-
do de projeto do software, e depois refiná-lo à medida que o projeto avança. 
Poderíamos dizer que o Jogo do Planejamento é uma reunião; é um ponto vital de 
interação entre cliente e desenvolvedor.
Uma reunião acontece com a equipe trabalhando em uma pilha de cartões de índice 
que contêm as histórias do usuário e são tratados durante o Jogo de Planejamento. 
18
19
Cartões de índice são uma ferramenta altamente eficaz. A função dos cartões é 
conectar os clientes e os desenvolvedores para atingirem seu objetivo comum, ou 
seja, o Sistema. 
Figura 6 – Exemplo de Cartão de Índice.“O cartão de índice não menciona uma programação declarativa. 
Ele também não especifica qual linguagem, sistema operacional ou hardware deve ser usado. 
O cliente simplesmente escreve em linguagem natural o que precisa. Ele não 
se importa como o desenvolvimento fará isso ou resolverá o problema.”
Fonte: extremeperl.org
Há uma clara separação de responsabilidades durante o Jogo de Planejamento. Vejamos 
quem são os atores que entram nesse jogo em XP.
Tabela 2 – Responsabilidades durante o Jogo de Planejamento
O negócio Técnico
Definir o escopo 
do lançamento
Estimar quanto tempo cada 
história do usuário levará
Definir a ordem de entrega (quais 
histórias são feitas primeiro)
Comunicar os impactos técnicos da 
implementação de requisitos
Definir datas e horários 
de lançamento
Divide as histórias do usuário em 
tarefas e aloque o trabalho
Fonte: https://goo.gl/XCPAaR
Podemos realizar as estimativas em cima desses cartões de histórias utilizando o 
Planning Poker, muito útil para as equipes ágeis. 
O Jogo de Planejamento é feito levando-se em consideração a expectativa de mu-
danças no projeto. Lembra-se dos problemas com os requisitos?
O planejamento do XP aborda duas questões-chave no desenvolvimento de software: 
• Prever o que será realizado até a data de vencimento; 
• Determinar o que fazer a seguir. 
A ênfase, como você poderá notar, está em direcionar, dar rumo ao projeto.
19
UNIDADE 
Introdução ao Extreme Programming
Duas etapas importantes em XP trabalham com esses conceitos. Lacey (2018) as 
descreve como:
• O Planejamento de Liberação é uma prática em que o Cliente apre-
senta os recursos desejados aos programadores e os programadores 
estimam sua dificuldade. Com as estimativas de custos em mãos e com 
o conhecimento da importância dos recursos, o Cliente estabelece um 
plano para o projeto. Os planos de lançamento inicial são necessaria-
mente imprecisos: nem as prioridades nem as estimativas são verdadei-
ramente sólidas e, até que a equipe comece a trabalhar, não saberemos 
com que rapidez elas serão. Até mesmo o primeiro plano de lançamen-
to é preciso o suficiente para a tomada de decisões, no entanto, e as 
equipes de XP revisam o plano de lançamento regularmente;
• Planejamento de Iteração é a prática pela qual a equipe recebe orien-
tação a cada duas semanas. As equipes de XP criam softwares em “ite-
rações” de duas semanas, entregando softwares úteis ao final de cada 
iteração. Durante o planejamento de iteração, o cliente apresenta os 
recursos desejados para as próximas duas semanas. Os programadores 
dividem-nas em tarefas e estimam seu custo (em um nível mais refinado 
de detalhes do que no Planejamento da Liberação). Com base na quan-
tidade de trabalho realizado na iteração anterior, a equipe se inscreve 
para o que será realizado na iteração atual. (LACEY, 2018)
Beck (1999) escreveu que: “O jogo de planejamento XP tem dois participantes no 
processo de planejamento: Negócios e Desenvolvimento”.
• Desenvolvedores: são as pessoas que irão realizar a implementação do que foi 
definido no cartão;
• Negócio (Cliente): são as pessoas que vão dizer aos desenvolvedores o que eles 
querem que seja implementado. O cliente decide a prioridade do trabalho a ser feito 
e o que está dentro e fora do escopo. 
Ainda, Kent Beck, criador do XP, coloca um peso muito grande no jogo de plane-
jamento. Ele é o que determina o grau de complexidade de cada história de usuário e, 
como num jogo, ele tem diversas fases. 
Vamos pegar o texto original de Beck (1999) e estudá-lo. Existem 3 fases do jogo do 
planejamento em XP:
1. Exploração: esta é uma maneira de tentar descobrir coisas novas que 
o sistema é capaz de fazer. O propósito da fase de exploração é dar aos 
jogadores uma apreciação do que todo o sistema deve eventualmente 
fazer. Exploração tem três movimentos:
a. Escreva uma história: negócios escreve uma história descrevendo 
algo que o sistema precisa fazer. As histórias são escritas em car-
tões de índice, com um nome e um parágrafo curto descrevendo o 
propósito da história;
b. Estimar uma história: desenvolvimento estima quanto tempo a 
história levará para implementar. Se o desenvolvimento não puder 
estimar a história, ela pode pedir aos negócios que esclareçam ou 
dividam a história;
20
21
c. Uma história é contada: se Desenvolvimento não puder estimar 
uma história completa ou se os negócios perceberem que parte 
de uma história é mais importante do que o restante, os negócios 
podem transformar uma história em duas ou mais histórias.
2. Compromisso: será tomada a decisão quanto aos passos a serem 
seguidos na realização dos requisitos.O propósito da fase de com-
promisso é que as empresas escolham o escopo e a data da próxima 
versão e que o desenvolvimento se comprometa com a entrega. 
Possui 4 movimentos a saber:
a. Classificar por Valor: negócios classifica as histórias em 3 pilhas:
I. Aquelas sem as quais o sistema não funcionará; 
II. Aquelas que são menos essenciais, mas fornecem valor comer-
cial significativo;
III. Aquelas que seria bom ter.
b. Classificar por risco: desenvolvedores classificam as histórias em 
3 pilhas:
I. Aquelas que podem estimar com precisão;
II. Aquelas que podem ser razoavelmente estimadas;
III. Aquelas que não podem estimar. 
c. Definir velocidade: desenvolvedores informam a rapidez com que 
a equipe pode programar em tempo de engenharia ideal por mês;
d. Escolher o escopo: a empresa escolhe o conjunto de cartões na li-
beração, seja definindo uma data para a engenharia estar completa 
e escolhendo cartões com base em sua estimativa e velocidade do 
projeto, seja escolhendo os cartões e calculando a data;
e. Direção: esta é a orientação dos desenvolvedores para o requisito 
do projeto. O propósito da fase de direção é a atualização do plano 
com base no que é aprendido pelo desenvolvimento e pelos negó-
cios durante o tempo. A fase de direção tem quatro movimentos:
I. Iteração: no início de cada iteração (de 1 até 3 semanas), Negó-
cios selecionam uma iteração das histórias mais valiosas a serem 
implementadas. As histórias da primeira iteração devem resultar 
em um sistema que é executado de ponta a ponta;
II. Recuperação: se o desenvolvimento perceber que ele superesti-
mou sua velocidade, ele poderá solicitar a Negócios que é o con-
junto de histórias mais valioso a ser retido no release atual com 
base na nova velocidade e nas estimativas;
III. Nova história: se os negócios perceberem que precisa de uma 
nova história durante o meio do desenvolvimento de um lança-
mento, ele poderá escrever a história. O desenvolvimento estima 
a história, depois o negócio remove as histórias com a estimativa 
equivalente do plano restante e insere a nova história;
IV. Reestimativa: se o desenvolvimento achar que o plano não 
fornece mais um mapa preciso do que fazer, ele pode reestimar 
todas as histórias restantes e definir a velocidade novamente. 
(BECK, 1999)
21
UNIDADE 
Introdução ao Extreme Programming
Como você percebe, o jogo possui uma dinâmica própria e eficaz; o time de desenvol-
vimento consegue determinar o grau de complexidade das histórias e o time de negócios 
as prioridades, e juntos conseguem determinar a ordem das entregas em geral.
Pequenos Lançamentos
O importante numa metodologia ágil como XP é garantir um fluxo contínuo de en-
tregas de software operacional e para isso nos valemos de iterações curtas. 
Os usuários ficam felizes, pois podem perceber os avanços e que o produto que uti-
lizam em seu dia a dia tem exatamente o efeito funcional que desejam.
Vejamos o que Baird (2002) nos diz:
[...] a única maneira de garantir que se esteja desenvolvendo o software 
que o cliente espera é manter os ciclos de lançamento os mais curtos pos-
síveis. Mesmo que o lançamento seja pequeno (se preferir pode chamar 
de Iteração), em XP ele ainda deve agregar valor comercial ao cliente. 
Como o cliente faz parte do planejamento de lançamentos, ele trabalha com a 
equipe de desenvolvimentopara definir as histórias do usuário e a ordem de imple-
mentação, como já vimos; além disso, a equipe de desenvolvimento pode usar cada 
lançamento como um ponto de verificação, em que ambos podem medir com a 
precisão das estimativas. 
Durante o estágio de planejamento, os desenvolvedores estimaram as histórias do 
usuário com base em sua taxa de transferência e dificuldade esperadas. Agora podemos 
comparar o planejado Xreal, usando essas lições aprendidas para a próxima iteração.
Os ciclos de lançamento pequenos são viáveis, porque estamos construindo as his-
tórias de usuários mais importantes primeiros, e nosso ambiente automatizado (ne-
cessidade de software de automação de testes e deployment como o JUnit e o JAVA 
Deployment Toolkit), facilitam a integração frequente de software.
As equipes XP praticam pequenos lançamentos (iterações) de 2 maneiras importantes:
• Primeiro: a equipe de desenvolvimento libera software testado e pronto para 
execução, entregando o valor comercial escolhido pelo Cliente, a cada iteração. 
O Cliente pode usar este software para qualquer finalidade, seja avaliação ou até 
mesmo liberação para usuários finais, o que é altamente recomendado;
• Segundo: a equipe libera direto para os usuários finais; a ideia é que testem e va-
lidem com frequência. Se houver algo ainda imperfeito, é prontamente ajustado. 
Dessa forma, quando estão seguros, liberam seguindo a primeira maneira narrada 
logo acima. Os projetos XP têm atualizações diárias, e isso é importante estar claro 
em sua mente.
22
23
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
3 Formas de Quebrar Histórias de Usuário – Rodrigo Vieira (2016)
https://youtu.be/OAVR9Zc5DeI
Gerenciamento de Requisitos sem Mistério – Fabício Laguna (2016)
https://youtu.be/jajQyzOpLaE
Histórias de Usuário – Fatto Consultoria e Sistemas (2015)
https://youtu.be/sEtiCJfXTE8
Métodos Ágeis e Documentação de Software
https://youtu.be/3Smbhnmue7Y
O que é Requisito – Fatto Consultoria e Sistemas (2015)
https://youtu.be/ooO6hyLuFNU
23
UNIDADE 
Introdução ao Extreme Programming
Referências
BAIRD, S. Extreme Programming Practices in Action, p. 3. 2002. Disponível em: 
<http://www.informit.com/articles/article.aspx?p=30187&seqNum=4>. Acesso em: 
8 maio 2018.
BECK, K. Extreme Programming Explained: Embracing Change. Boston: Addison-
Wesley, USA, 1999.
CUNNINGHAM, W. History of Extreme Programming, 2008. Disponível em: 
<http://wiki.c2.com/?HistoryOfExtremeProgramming>. Acesso em: 2 maio 2018.
HUTAGALUNG, W. Extreme Programming. 2006. Disponível em: <http://www.
umsl.edu/~sauterv/analysis/f06Papers/Hutagalung/>. Acesso em: 7 maio 2018.
LACEY, M. Planning Game. 2018. EUA: Mitch Lacey & Associates INC. Disponí-
vel em: <https://www.mitchlacey.com/intro-to-agile/extreme-programming/planning-
-game>. Acesso em: 5 maio 2018.
PRESMAN, R.; MAXIM, B. R. Engenharia de Software: Uma Abordagem Profissio-
nal. 8.ed. McGraw Hill, 2016. p. 72-85.
TELES, V. M. Práticas do XP. 2006. Disponível em: <http://www.desenvolvimentoa-
gil .com.br/xp/praticas/>. Acesso em: 5 maio 2018.
24