BEATRIZ SAITO GOBIRA

JOSÉ AUGUSTO ROZA

PEDRO HENRIQUE GEANINI DICATI

DESENVOLVIMENTO ÁGIL: EXTREME PROGRAMMING

TRÊS LAGOAS
2022
 BEATRIZ SAITO GOBIRA
JOSÉ AUGUSTO ROZA
PEDRO HENRIQUE GEANINI DICATI

DESENVOLVIMENTO ÁGIL: EXTREME PROGRAMMING

Relatório submetido ao Instituto Federal de

Educação, Ciência e Tecnologia de Mato Grosso do
Sul (IFMS) – Campus Três Lagoas, como parte de
requisitos necessários para a obtenção da
aprovação na unidade curricular de Engenharia de
Software II.

Orientador: Prof. Me. Elisangela Citro Turci

TRÊS LAGOAS
2022
1 INTRODUÇÃO

De acordo com Fowler (2005), metodologias ágeis tentam um compromisso

útil entre nenhum processo e muitos processos, fornecendo apenas o processo
suficiente para obter um retorno razoável. Simplificadamente, essa metodologia
busca agilizar o processo de entrega do software, simplificando, principalmente, a
documentação, no qual se reduz grande parte, focando mais nas partes principais.
Deste modo, as metodologias ágeis, como diz Fowler (2005), seguem a rota de que
a parte principal da documentação é o código-fonte.
A abordagem ampla de “metodologias ágeis” pode ser dividida em vários
ramos mais específicos, como Extreme Programming, Scrum, Lean Development,
dentre outros que foram sendo desenvolvidos ao longo do tempo. Este relatório
discorrerá sobre o Extreme Programming (XP), abordando seus valores, métodos,
práticas e princípios.

2 EXTREME PROGRAMMING (XP)

A metodologia ágil XP foi uma das primeiras a ser criadas e até hoje possui
adeptos. O XP foi criado na década de 90 por Kent Beck, Ward Cunningham e Ron
Jeffries, e ainda é um método bastante utilizado, um dos quais foca na satisfação do
cliente e na entrega incremental, possuindo os objetivos de desenvolver sistemas
rápidos e corretos, priorizando principalmente o desenvolvimento do software sobre
a análise e o projeto do sistema. Resumidamente, o XP é uma metodologia ágil para
equipes que desenvolvem softwares com os requisitos não tão bem definidos e que
podem se modificar rapidamente ao longo do tempo.

2.1 COMO FUNCIONA?

Além das práticas de engenharia, a XP é desenvolvida baseada em valores e

princípios. Os valores são abstratos, porém trazem propósito para as equipes,
atuando como um “norte”. Por outra via, as práticas são concretas e objetivas,
definindo concretamente o que deve-se fazer.

2.1.1 VALORES
 São cinco valores que fazem parte da XP:
• Comunicação: todos fazem parte da equipe e vão desenvolver a solução para
os requisitos juntos, além de que a comunicação contribui para a
disseminação de conhecimento dentro da equipe, diminuindo o tempo gasto
com solução de problemas;
• Simplicidade: adotar soluções mais fáceis e promissoras, diminuindo o custo
de manutenções e possíveis mudanças futuras;
• Feedback: ajuda na correções de erros e contribui para melhorias no sistema.
Deixa todos da equipe em constante comunicação com o cliente, sempre
possuindo um feedback do que pode ser alterado e mantido;
• Respeito: todos dão e sentem o respeito que merecem como membros
valiosos da equipe. Quando você e os membros de sua equipe respeitam e
se preocupam uns com os outros, o cliente, o projeto e seus futuros usuários,
todos ganham;
• Coragem: errar é natural e quebrar o que vinha funcionando pode acontecer
eventualmente. É necessário ter coragem para lidar com esse risco, o que em
XP se traduz em confiança nos seus mecanismos de proteção. Coragem é
necessária para melhorias no projeto.

2.1.2 PRINCÍPIOS

A partir dos valores, existem cinco princípios básicos, listados a seguir.

• Feedback rápido: sempre manter a comunicação total dos membros
participantes do projeto, assim irá gerar um alerta mais eficaz de dúvidas,
riscos, erros e problemas;
• Assumir simplicidade: resolva os problemas de hoje e confie na sua
habilidade de adicionar complexidades futuras, tendo em vista a resolução de
formas mais fáceis e simples possível;
• Mudança incremental: fazer mudanças básicas, pois programadores tem
liberdade para estarem sempre ativos em determinados códigos;
• Abraçando mudanças: usadas quando o cliente não sabe o que quer, logo
você poderá incluir alterações através do uso de princípios e praticas, como
mencionado;
 • Trabalho de qualidade: o XP trata de qualidade quando se diz em requezitos
para satisfazer o cliente, ou sejam o sistema tem que roda 100% no teste,
pois aqui não se trata de opção e sim de obrigação.

2.1.3 PRÁTICAS

São 12 listadas na imagem a seguir.

Explicando cada uma delas:

• Equipe(Técnicos e clientes): o cliente deve estar no local para fazer parte do
desenvolvimento, realizando testes e auxiliando no lançamento de pequenas
versões atualizadas e de acordo com o gosto do cliente;
• Teste de aceitação: especificado pelo cliente para testar que o sistema
funciona conforme especificado por ele. Quando todos os seus testes de
aceitação passam, a história é considerada completa;
• Pequenas versões: Release é algo que é implantado no cliente, ou seja, está
pronto para ser utilizado. As Releases normalmente são pequenas e
frequentes (a cada 2-3 meses) sendo que funcionalidades prioritárias são
desenvolvidas mais cedo para serem entregues mais rapidamente ao cliente,
pois prioriza-se o que ele mais precisa no momento;
• Jogo de planejamento: Seu objetivo é determinar rapidamente o escopo da
próxima Release, combinando prioridades do negócio e estimativas técnicas.
Portanto no XP planejamos o tempo todo, diferente do que alguns pensam.
Com um cliente presente ele define o escopo para a próxima Release;
• Propriedade coletiva: Todos podem modificar o código a qualquer momento.
Códigos não pertencem a apenas uma pessoa. A melhor forma de evitarmos
problemas como trocas de pessoas da equipe e com isso a perda de
conhecimento é a propriedade coletiva, onde todos mexem em todas as
partes do programa e conhecem de tudo um pouco;
• Integração contínua: Todo código deve ser integrado diariamente e todos
testes devem passar antes e depois da integração. Se algum problema é
encontra do ele deve ser corrigido imediatamente;
• Metáforas: é uma linguagem comum que todos devem possuir. Por exemplo,
ao invés de descrevermos como uma certa arquitetura funciona apenas
comunicamos o seu nome e todos entendem o que um programador quis
dizer;
• Ritmo sustentável: o XP preconiza que não se pode trabalhar horas extras por
mais de uma semana, pois trabalho extra é sintoma de que algo está errado.
Devemos manter um ritmo sustentável;
• Padrão de código: todos mexem em todos os códigos, todos refatoram e
todos trabalham em pares. Assim é interessante mantermos um padrão para
termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão
de codificação sempre no inicio dos projetos;
• Testes unitários: automatiza o teste da funcionalidade e tipicamente testa uma
classe, ou pequeno grupo de classes. Se um bug é descoberto, acrescenta-
se imediatamente um caso de teste para ele. Assim garantimos que ele não
se repetirá;
• Programação em par: Trata-se de duas pessoas trabalhando com UMA
máquina onde um codifica, e o outro critica ou dá sugestões;
• Design simples: Projetos flexíveis são considerados uma defesa contra
mudanças imprevistas no software. O XP preconiza que a mudança é barata,
pois ele utiliza ciclos curtos, projetos simples, refatorações, por isso mantém-
se o projeto o mais simples possível, modificando-o quando for necessário
suportar mais funcionalidade.
• Refatoração: A refatoração significa melhorar o código sem alterar sua
funcionalidade. Antes de uma mudança sempre refatoramos o código para
facilitar a realização de mudanças. Ou seja, se após a refatoração o código
continua funcionando como anteriormente, incluímos as novas mudanças.
3 CICLO DE VIDA DE UM PROJETO XP

Um projeto XP possui algumas fases durante o seu ciclo de vida. Essas fases
são compostas por várias atividades que são executadas durante a vida útil do
projeto:
• Fase de exploração: é onde a equipe tem o primeiro contato com o cliente e o
que será desenvolvido. É a fase onde o programador/Equipe tira todas as
informações possíveis para a criação do produto para suprir a necessidade do
seu cliente.
• Planejamento Inicial: tem como propósito definir entre o cliente e os
programadores a data para a primeira release (tempo de desenvolvimento) do
produto. Onde os programadores junto com o cliente é desenvolvido o
planejamento da iteração e a estimativas do sistema, o tempo de cada
iteração deve ter em média de uma a três semanas e para cada release de
dois a quatro meses.
• Interações do release: tem como objetivo definir a arquitetura, onde é
importante que a equipe tire principais informações para a criação do
esqueleto do sistema como um todo na primeira iteração. Depois da primeira
iteração concluída terá uma base melhor para o desenvolvimento das
iterações de maior valor para o cliente.
• Fase de produção vem logo depois das iteração estejam concluídas, é o
momento onde a equipe de programadores coloca cada iteração para rodar
em um ambiente que simula o seu comportamento e o seu desempenho ao
decorrer do código. Utilizando práticas como TDD, iteração continua, teste de
aceitação, entre outros métodos.
• Manutenção: é a fase que é considerada inerente ao projeto, onde o
programador sempre estará mantendo o programa rodando, incorporando o
código e melhorando o código. Mecanismos como: refatoramento, introdução
de novas tecnologias entre outros.
• Fase da morte: é a finalização do projeto, podendo obter duas razões uma
boa e uma ruim, onde a boa é quando o cliente está satisfeito com o seu
produto e não vê nenhuma funcionalidade que possa adicionar no futuro. A
má razão é quando o seu produto é totalmente inviável para o cliente, devido
à dificuldade de adicionar funcionalidades e a alta taxa de erros.
4 GERÊNCIA DE PROJETOS E PAPÉIS ENVOLVIDOS EM XP

A gerência é dividida através de dois papéis: o treinador (Coach) e o

rastreador (Tracker), podendo ou não ser gerenciado pela mesma pessoa.
Treinador se ocupa com a execução técnica e a evolução do processo. O
objetivo do rastreador é coletar métricas estimadas verificando possíveis
divergências. Além dos papéis apresentados, existem outras funções compostas na
equipe:
• Programador: como o próprio nome já diz, ele analisa, projeta, testa, codifica,
e integra o sistema.
• Cliente: escolhe o que vai agregar valor ao seu negócio.
• Testador: irá ajudar o cliente na definição e escrita dos testes funcionais.
• Consultor: é necessário apenas em algumas situações onde se precisa de
alguém com um elevado nível de conhecimento.

5 QUANDO NÃO SE DEVE USAR XP

Os limites do XP ainda não são todos reconhecidos, mas existem fatores

principais que são fortes indicadores para não usar o XP são equipes grandes,
clientes desconfiados e a falta de suporte tecnológico. Os possíveis tópicos para ter
um projeto bem sucedido são:
• Cultura: a equipe deve ser organizada, de forma que todos possam trabalhar
em um espaço receptivo e eficiente. Um espaço mal organizado e distribuído
pode atrapalhar o desenvolvime nto do projeto;
• Tamanho da Equipe: Um projeto XP deve possuir uma equipe pequena,
normalmente com no máximo 12 programadores, onde facilita a organização
e a comunicação.
• Tecnologia: Não se usa XP quando a tecnologia é complicada, quando se
demora para obter um feedback ou não se adapta facilmente as mudanças.
• Espaço Físico: Quanto mais próximos os programadores ficarem um do outro
melhor a comunicação entre eles, ou seja, um espaço não muito pequeno,
mas também não muito grande.
• Cliente: O XP tem exige o tipo de cliente que seja ativo no projeto, que faça
participação, onde esteja a disposição na maioria do tempo para esclarecer a
 dúvidas. Caso o cliente não esteja disponível, tem que ser alguém de
confiança que entenda do negócio ou que seja capacitado para exercer tal
função.

6 REFERÊNCIAS BIBLIOGRÁFICAS

FOWLER, Martin. The new metodology. 2005. Disponível em:

https://www.martinfowler.com/articles/newMethodology.html. Acesso em: 9 ago.
2022.
TEBET, Isabella. Extreme Programming (XP): o que é, valores e benefícios.
2021. Disponível em: https://www.objective.com.br/insights/extreme-programming-
xp-o-que-e-e-beneficios/. Acesso em: 9 ago. 2022.
WELLS, Don. Extreme Programming: A gentle introduction. 2009. Disponível em:
http://www.extremeprogramming.org/. Acesso em: 9 ago. 2022.
TELES, Vinícius Manhães. Extreme Programming. 2006. Disponível em:
http://www.desenvolvimentoagil.com.br/xp. Acesso em: 9 ago. 2022.
AFONSO, Higor. Introdução ao Extreme Programming (XP). 2013. Disponível em:
https://www.devmedia.com.br/introducao-ao-extreme-programming-xp/29249.
Acesso em: 9 ago. 2022.
DIGITÉ. Introdução a Programação Extrema (XP). Disponível em:
https://www.digite.com/pt-br/agile/programacao-extrema-xp/. Acesso em: 8 ago.
2022.
BASSI, Dairton. Desenvolvendo Software Livre com Programação eXtrema.
Disponível em: https://www.ime.usp.br/~dairton/files/FISL7-210406v3.pdf. Acesso
em: 9 ago. 2022.
AFONSO, Higor. Práticas em XP: Extreme Programming. 2013. Disponível em:
https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330. Acesso
em: 9 ago. 2022.