aula06

Prévia do material em texto

6ºAula
Programação extrema - XP
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
entender os conceitos da Metodologia XP
saber os papéis e as principais práticas da metodologia XP
entender o ciclo de vida do XP
Olá, pessoal, tudo bem? 
Vamos agora abordar uma das Metodologias Ágeis mais 
populares. A Programação Extrema, que trabalha com uma série 
de práticas de Engenharia de Software, como a programação em 
pares, integração contínua, etc. Será a primeira de três metodologias 
que veremos nesta reta final do nosso curso.
Vamos lá?
Bons estudos!
185
42Met. para de Desenvolvimento de Software
Seções de estudo
1 - Introdução à Programação 
1. Introdução à Programação Extrema (XP)
2. Papéis da Programação Extrema
3. Principais Práticas do XP
4. O processo XP
A Programação Extrema, também conhecida pela sua 
sigla XP (do inglês: Extreme Programming), é uma metodologia 
ágil que define uma série de boas práticas de desenvolvimento 
de software que devem ser seguidas. Bassi (2014) define XP 
como:
A Programação Extrema é a combinação 
de uma abordagem colaborativa, livre 
boas práticas de engenharia de software 
independentemente do contexto. Cada uma 
dessas práticas contribui para o aumento da 
qualidade do software e ajuda a garantir que 
necessidades do negócio. Alguns exemplos 
dessas práticas são: revisão de código, 
integração rápida, testes automatizados, 
O XP surgiu na década de 1990, quando Kent Beck 
entrou em um projeto que já estava fadado ao fracasso na 
Chrysler. Diante dessa situação, Beck adotou uma abordagem 
totalmente diferente, usando várias boas práticas da 
engenharia de software (sendo que algumas dessas práticas 
já haviam sido documentadas na década de 1980). No final, 
um projeto que estava sendo considerado um desperdício de 
dinheiro, passou a ser um case da indústria de software. Em 
2001, o próprio Kent Beck representou a metodologia XP na 
reunião que criou o manifesto ágil.
1.1 - Valores
A proposta da metodologia XP é sintetizada em cinco 
valores, que são:
Comunicação: Bassi (2014) afirma que o 
processo de desenvolvimento de um software requer que 
desenvolvedores e clientes se entendam mutuamente, para 
que a confiança da equipe seja sempre elevada. Além disso, 
uma boa comunicação torna a difusão do conhecimento e a 
implicidade: Esse valor prega em desenvolver 
somente o que é necessário no momento. No jargão da 
Keep 
It Simple, Stupid! - Mantenha isso simples!). Evitar o excesso de 
classes, excesso de complexidade, não desenvolver requisitos 
 Como já sabemos, quando mais tempo 
o cliente se manifestar por uma mudança em um software 
já pronto, mais custos acarretará no desenvolvimento e 
na manutenção desse software. Assim, a metodologia XP 
prega que o cliente sempre manifeste suas opiniões sobre o 
andamento do software, para que seja verificado se o software 
Coragem: Esse valor está relacionado ao fato de 
nos processos tradicionais, os envolvidos se escondem nos 
processos, omitindo informações e comprometimento. 
No XP, as pessoas envolvidas precisam ter coragem para se 
comprometer com o andamento do software e coragem para 
informar ao cliente o que está acontecendo.
Respeito: O processo de desenvolvimento de 
software é colaborativo. Assim o respeito mútuo entre as 
partes da equipe é fundamental para o que o processo ande. 
Portanto, são enfocadas atividades colaborativas durante todo 
o processo, para que seja criado um ambiente de sinergia entre 
os participantes.
Perceba que os valores da Programação Extrema se 
interligam aos valores e aos princípios do manifesto ágil, que 
você viu na aula anterior. 
1.2 - Princípios
Além dos valores, a Programação Extrema define 
14 princípios, que servem para definir as práticas dessa 
metodologia. Esses princípios também ajudam a validar se uma 
nova prática ou adaptação a ser agregada à metodologia está 
válida com os propósitos da metodologia XP. Veremos esses 
valores a seguir:
 A produção do software depende dos desenvolvedores. 
É importante levar em conta que suas necessidades individuais devem 
ser respeitadas e balanceadas com os interesses do negócio e as 
necessidades da equipe.
 A equipe deve conhecer as necessidades de negócio 
intervalo de tempo. Flexibilidade para reagir a mudanças com rapidez 
é importante para acompanhar revisões nas prioridades de negócio.
 Melhorias devem ser implementadas constantemente. 
da economia e ajudará a equipe a melhorar seu entendimento do 
problema. Depois, busque uma solução elegante e, por último, se isso 
ainda for prioritário, busque a solução ótima. Começar tentando a 
solução ótima vai custar mais tempo, e nem sempre será necessária.
As atividades devem sempre trazer benefícios 
para os envolvidos. Testes, refatorações e metáforas são exemplos de 
atividades que trazem ganhos imediatos, pois aumentam a compreensão 
e planejamentos detalhados de longo prazo não trazem benefício 
imediato e estão altamente sujeitos a mudanças no futuro.
 Boas soluções devem poder ser aplicadas novamente, 
inclusive em outros contextos e escalas. Devemos estar atentos para 
processo de desenvolvimento.
 A equipe deve reunir muitas habilidades, opiniões e 
perspectivas que ajudarão a encontrar a melhor abordagem para 
cada situação. É importante que a equipe possua o valor do respeito 
186
43
para garantir que as diferenças criem um ambiente colaborativo que 
favoreça o crescimento de todos.
 A integração do código, o desenvolvimento dirigido 
por testes e a entrega de novas versões devem manter um tamanho 
trabalho, assim poderá avaliar suas decisões e aprender com o passado, 
ser repetidas.
 O ritmo de trabalho deve ser sustentável ao longo do tempo, e 
a quantidade de software entregue também deve se manter estável. 
código em períodos os mais curtos possíveis para minimizar o risco e o 
tamanho de prováveis defeitos.
atenta às oportunidades que surgem. Mudanças e problemas são vistos 
como meios para aprendizado e melhoria.
 Devemos acrescentar maneiras de assegurar a 
qualidade do software e reduzir os riscos do projeto como um todo. 
Aumentar as oportunidades de aprendizado diminui a concentração de 
conhecimento. Testar frequentemente reduz a chance de que defeitos 
sejam entregues ao cliente.
 A equipe deve ter coragem para experimentar alternativas 
quando o seu caminho não estiver claro, mesmo sabendo que 
algumas dessas opções falharão. O mais importante é aproveitar essas 
oportunidades para adquirir aprendizado e estar disposto a abandoná-
las para investir seus esforços na melhor opção.
 A qualidade não é um fator negociável. O escopo e o 
tempo devem ser ajustados para entregar software de alta qualidade. 
O investimento na qualidade do código é importante para estabelecer o 
 As responsabilidades são aceitas, 
e não impostas. Cada membro deve estar comprometido e disposto a 
colaborar da melhor forma possível com a equipe. 
Veremos a seguir, quais são os papéis que participam em 
um processo XP.
2 - Papéis da Programação Extrema
Uma equipe na metodologia XP possui vários papéis de 
diferentes objetivos, mas que suas funções são essenciais para a 
sua execução. Não há um limite de pessoas na metodologia, e 
uma pessoa pode ocupar dois papéis diferentes em um projeto. 
Porém, essa prática é desaconselhável.
A metodologia XP tem como principais papéis:
Desenvolvedor: É o papel mais crucial na 
metodologia, pois são os desenvolvedores que 
fazem as tarefas mais vitais em um projeto XP. 
Escrita de história de usuário, estimativa do tempo 
de desenvolvimento, quebra histórias em tarefas, 
escreve os testes e os códigos referentes a essa tarefa, 
automatiza processos de desenvolvimento e melhora 
- aos poucos - o design dessa tarefa. Assim, um 
desenvolvedor multidisciplinar é ideal para o projeto. 
Além disso, habilidades sociais e de relacionamento 
são também recomendadas, visto que a programação 
é realizada em pares.
Cliente: Ele faz a priorização do que será 
desenvolvido ea verificação se o software 
corresponde aos seus anseios. Vale lembrar que o 
cliente sempre deve estar o mais próximo possível 
da equipe para que sejam resolvidas dúvidas com os 
desenvolvedores. Um cliente (que financia o sistema) 
pode não ser um dos usuários efetivos do sistema. 
Nesse caso, deve-se sempre aproximar daqueles 
que usarão o sistema. Se o cliente não pode estar 
presente o tempo todo, podem ser usadas formas de 
que saiba das necessidades dos usuários.
Coach: Deve manter o time engajado no projeto, 
orientando a todos sobre a disciplina nas práticas 
a seguir). Um coach deve ser representado por uma 
pessoa que não exerça o papel de gerente, para que 
em uma situação de dificuldade, o processo seja 
respeitado.
Testador: Ele chefia as operações de teste do 
sistema de diversas formas. Ajuda o cliente a escrever 
os testes de aceitação, ajuda outros programadores a 
escrever seus testes e na resolução de problemas do 
sistema.
Cleaner: É um profissional de excelência técnica, 
que “limpa” o código, promove refatorações, reduz 
a complexidade do sistema, aumentar a coesão 
do código e transforma o código no mais enxuto 
possível.
 Ele coleta as métricas do time de 
desenvolvimento durante a iteração, gerando dados 
que podem ser usados para o aperfeiçoamento da 
equipe durante o projeto.
Gerente: Desempenha diversas tarefas no 
projeto, como a facilitação da comunicação entre 
desenvolvedores e clientes, auxilia o cliente na 
priorização de histórias, agenda reuniões com o 
cliente, auxilia no planejamento do projeto (no 
XP, o planejamento não é uma fase, mas sim uma 
fase contínua durante o projeto), gera relatórios 
de acompanhamento do projeto etc. Mas, vale 
lembrar que um Gerente não chefia a equipe de 
desenvolvimento.
Vimos, nesta seção, os principais papéis do XP. Vamos 
ver, a seguir, as principais práticas adotadas na metodologia 
XP.
3 - 
Para que a metodologia XP atenda seus objetivos, várias 
técnicas são empregadas, sendo que muitas delas vieram das 
aclamadas boas-práticas de desenvolvimento de software. 
Veremos algumas dessas principais práticas a seguir:
Testes automatizados: Nos projetos XP, é comum 
que os testes sejam automatizados e criados junto 
com o desenvolvimento do código. A razão para 
cedo os erros forem detectados, menos impactos 
187
44Met. para de Desenvolvimento de Software
eles causarão no software e mais barato será corrigi-
ser determinado como pronto, deve vir com os 
testes implementados e funcionando. Isto evita 
a sobrecarga de escrever todos os testes após o 
código ficar pronto. Para isso são usados frameworks 
de testes automatizados (JUnit, PHPUnit, Selenium 
etc.) junto a uma técnica chamada de TDD.
TDD é a sigla para “Desenvolvimento Dirigido a Testes”. É uma das 
práticas mais populares da engenharia de software. É uma técnica 
de desenvolvimento que, você pode usá-la em qualquer projeto, 
independentemente da metodologia que você segue para esse 
1. Essa etapa consiste em você escrever o teste 
antes de escrever a implementação da funcionalidade. Escrevendo 
funcionalidade. Como nenhuma funcionalidade foi implementada, 
obviamente o teste irá falhar;
2. Após escrever o teste, você implementa a 
funcionalidade da forma mais simples possível para que ele funcione;
3. Após terminar de escrever as funcionalidades, melhore o 
Refatorações: São mudanças no código, com 
o intuito de torná-lo mais flexível, mais fácil de 
fazer manutenções e mais fácil de entender. Essa 
técnica foi descrita por Martin Fowler, em seu 
livro “Refatoração - Aperfeiçoando o Projeto de 
Código Existente”. Nesse livro, Fowler mostra 
possíveis situações no código que podem ser 
melhoradas, as quais ele chama de “Mau cheiro” 
(bad smells). Os testes são importantes para que sejam 
feitas as refatorações, pois podem indicar se um 
aperfeiçoamento em um trecho pode causar efeitos 
Programação em Pares: No processo XP, 
cada dupla é responsável por analisar, projetar, 
implementar, testar e integrar a funcionalidade 
na qual estão trabalhando. Assim, cada passo é 
realizado por dois membros da equipe, que se 
revezam de tempos em tempos na condução do 
computador: enquanto um escreve, o outro revisa 
o código, pensa em outras situações de testes e 
sugere melhorias. Essa técnica diminui as chances 
de soluções inadequadas e aumenta o conhecimento 
 Para que o código seja 
mais legível e mais compreensível por toda a equipe, 
são estabelecidos padrões que os programadores 
devem respeitar para programar seu código (por 
exemplo, número de espaços de indentação nomes 
Propriedade Coletiva: O código não possui 
como dono uma única pessoa, é de propriedade de 
toda a equipe. Assim, qualquer um pode realizar 
modificações, se achar necessário. Vale lembrar que 
os testes garantem se uma modificação é segura ou 
Para que a propriedade 
coletiva seja colocada em prática, o código é 
disponibilizado em um repositório único, onde 
controla as alterações que foram feitas. São exemplos 
de programas que fornecem esse serviço o Git, 
Subversion e Mercurial. Além disso, pode ser usada 
para a integração contínua, onde a cada nova 
atualização do código, um programa roda todos os 
testes automatizados para verificar se tem algum erro 
ou não. São exemplos de programas (ou serviços) de 
integração contínua: Jenkins e Travis-CI.
User Stories: Representa 
de forma conceitual a necessidade do usuário, sem 
entrar em detalhes complexos. Uma User Story é 
um cartão onde o usuário escreve sua necessidade da 
seguinte forma: 
Como um (tipo de usuário - gerente, cliente, funcionário), eu 
gostaria de (funcionalidade - ex.: cadastrar um produto, emitir um 
relatório) para (benefício - ex.: controlar o estoque, disponibilizar para 
venda, etc.).
Como veremos a seguir, um cartão pode vir também 
com a estimativa de trabalho para a sua implementação e a 
prioridade especificada pelo cliente. Ainda, no verso do cartão 
podem conter testes que indicam se uma funcionalidade está 
dentro dos padrões ou não.
188
45
Vimos aqui as principais práticas da Programação 
Extrema. A seguir, entraremos no estudo dos processos da 
metodologia XP.
4 - 
O processo XP inicia-se na fase de exploração, onde o 
cliente expõe as suas necessidades aos desenvolvedores que 
participarão do projeto. Diante do entendimento inicial, a equipe 
pesquisa e discute quais tecnologias podem ser empregadas para 
desenvolver o software. Pode demorar de alguns dias a algumas 
semanas, dependendo da situação do projeto proposto.
Depois que os desenvolvedores entenderem o problema, 
o(s) cliente(s) descreve(m) suas necessidades. Diante das 
necessidades expostas, os clientes e desenvolvedores discutem 
sugestões de mudança e tiram dúvidas sobre pontos não 
entendidos a respeito desses requisitos. Após todos entenderem 
suas necessidades (o que é fundamental nessa etapa), o(s) 
cliente(s) escreve(m) seus requisitos em um cartão, chamado 
de User Story, que é a base dos requisitos nessa metodologia. 
Depois que as User Stories estiverem definidas, os 
desenvolvedores estimam qual será o volume de trabalho 
exigido para programar uma User Story. Técnicas diversas podem 
ser usadas, como o Planning Poker ou qualquer outra técnica que 
considere o valor de todo o grupo de desenvolvedores. Após 
essa definição, a estimativa é anotada no cartão, junto com a 
prioridade especificada pelo cliente.
Uma vez as user stories definidas e estimadas, os 
programadores separam essas estórias em conjuntos, com valor 
de mercado, para entrarem em produção juntas. Esse conjunto 
de estórias constitui em um release. Depois de selecionado 
um conjunto de cartões para ser programado em um release, 
os programadores dividem esse conjunto em grupos menores. 
As funcionalidades que compõem esses grupos menores são 
desenvolvidas em uma iteração. 
Em um release, é entregue um software executável com 
as estórias que foram definidas nesse período de tempo. Cada 
release é composto por uma ou mais iterações. Essa maneirade organizar o desenvolvimento em iterações e releases serve 
para tornar mais facilitada a medição do progresso de software 
e para que o cliente tenha o mais rapidamente possível um 
software pronto, que seja útil de alguma forma ao cliente. Vale 
lembrar que o critério que seleciona quais user stories serão 
implementadas é a prioridade estabelecida pelo cliente. 
Em cada dia da iteração, é realizada uma reunião em 
pé. É uma reunião rápida, com duração de 15 minutos, onde 
cada participante mostra o que foi feito no dia anterior, o que 
pretende fazer no dia, que problemas foram encontrados 
e se ele precisa de ajuda. Isso serve para sincronizar toda a 
equipe sobre o andamento do projeto. Se for detectado um 
problema, os interessados em resolvê-lo se identificam para 
encontrar uma solução após a reunião.
Após isso, os desenvolvedores se organizam em 
pares para realizar suas tarefas. Se uma dupla não estiver 
trabalhando em algum cartão previamente, eles escolhem um 
cartão que seja de maior prioridade e compatível com o nível 
técnico. Posteriormente, a dupla escolhe um computador, faz 
o download da última versão do projeto e executa todos os 
testes para ver se está funcionando.
Depois, a dupla se organiza para definir qual será a 
forma de implementar o que foi descrito na história do 
cartão selecionado. Se houver dúvidas de interpretação, 
elas consultam o cliente para saná-las. Com a implantação 
definida, os programadores utilizam a abordagem TDD para 
escrever o código e os testes, revezando-se no controle do 
computador. Feita a implementação, com todos os testes 
aprovados, o cliente é chamado para emitir um parecer sobre 
a funcionalidade definida.
Após a aprovação do cliente, o código escrito pela dupla 
é integrado ao código do restante da equipe. Porém, devem 
ser feitos testes para confirmar se a integração do novo código 
não afetará o dos demais. Em outros momentos, podem ser 
realizadas refatorações para melhorar o design do código, para 
que sua manutenção seja mais fácil.
Ao final de cada iteração, o cliente avalia e inspeciona o 
que foi feito e a equipe avalia o que deu certo e o que pode 
melhorar na próxima iteração. E o ciclo se reinicia.
No transcorrer de um projeto, podem ocorrer mudanças 
durante o processo de desenvolvimento. Nesse caso, o cliente 
pode alterar, criar e excluir user stories. Caso isso aconteça, um 
novo processo de estimativa ocorre e as divisões dos grupos 
de user stories são refeitas para refletir as alterações realizadas 
na lista de requisitos.
Com isso, finalizamos o nosso estudo sobre a metodologia 
Programação Extrema (XP). Na próxima oportunidade, 
estudaremos a consagrada metodologia Rational Unified Process 
(RUP).
Retomando a aula
abordamos as práticas da metodologia Extreme 
1. Introdução à Programação Extrema (XP)
A Programação Extrema é uma metodologia que prega 
o uso de várias boas práticas de desenvolvimento de software. 
Suas diretrizes são especificadas em cinco valores: Comunicação, 
Simplicidade, Coragem, Feedback e Respeito.
189
46Met. para de Desenvolvimento de Software
2. Papéis da Programação Extrema
A Programação Extrema utiliza diversos papéis, como 
Testador, Coach, Cleaner, Desenvolvedor, Tracker, Gerente e 
Cliente, sendo que cada papel exerce diferentes obrigações no 
processo.
3. Principais Práticas do XP
A metodologia XP prega o uso de diversas boas práticas 
de engenharia de software, como testes automatizados, 
integração contínua, programação em pares, cartões de história 
e propriedade coletiva do código.
4. O processo XP
O processo XP, em poucas palavras, é baseado em 
iterações e releases, onde, em cada release, um software deve 
ser entregue funcionando com as funcionalidades acertadas. 
Cada release é composto por uma ou mais iterações.
ANICHE, Mauricio. Test-Driven Development: Teste e 
Design no Mundo Real. São Paulo: Casa do Código, 2014a.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São 
Paulo: Pearson Addison Wesley, 2014.
PRESSMAN, Roger S. Engenharia de software: uma 
BASSI, Dairton. Programação Extrema (XP). In: 
Métodos 
Ágeis para Desenvolvimento de Software. Porto Alegre: Bookman, 
2014. p. 37–57. Cap. 4
TELES, Vinícius Manhães. Extreme Programming: 
Aprenda como encantar seus usuários desenvolvendo software com 
agilidade e alta qualidade. São Paulo: Novatec Editora, 2014.
WILDT, Daniel et. al. eXtreme Programming: Práticas para 
o dia a dia no desenvolvimento ágil de software. São Paulo: Casa do 
Código, s.d..
Vale a pena
Vale a pena ler
ANICHE, Maurício. TDD. [S.l.:] Caelum, 2014b. 
Disponível em: <http://tdd.caelum.com.br/>. Acesso em: 
06 out. 2017.
GOMES, André Faria. Programação em Par. [S.l.:] 
André Faria Gomes, 2008. Disponível em: 
<http://blog.andrefaria.com/programacao-em-par>. 
Acesso em: 06 out. 2017.
MEDEIROS, Higor. Introdução ao Extreme Programming 
(XP). [S.l.:] Devmedia, 2013. Disponível em: <http://www.
Vale a pena acessar
devmedia.com.br/introducao-ao-extreme-programming-
xp/29249>. Acesso em 06 out. 2017.
FONSECA, Daniel. Conceitos básicos sobre Metodologias 
Ágeis para Desenvolvimento de Software (Metodologias Clássicas x 
Extreme Programming) [S.l.:]. DevMedia, s.d. Disponível em:
<http://www.devmedia.com.br/conceitos-basicos-
sobre-metodologias-ageis-para-desenvolvimento-
de-sof tware-metodolog ias-c lass icas-x-extreme-
programming/10596>. Acesso em: 06 out. 2017.
TELES, Vinícius Manhães. Programação em Par | 
XP. [S.l.:] DesenvolvimentoAgil.com.br, 2006. Disponível em: 
<http://www.desenvolvimentoagil.com.br/xp/praticas/
programacao_par>. Acesso em: 06 out. 2017.
Minhas anotações
190