INSTITUTO FEDERAL DO PARANÁ

CAIO WENDRECHOSKI

Extreme Programming (XP)

IRATI-PR
2023
 Extreme Programming (XP)

A Extreme Programming (XP), considerada uma metodologia ágil, é bem

aproveitada por equipes de pequeno e médio porte de desenvolvedores de software,
de maneira que os projetos são direcionados a partir de requisitos vagos que se
modificam de maneira acelerada. (SOMMERVILLE, TEIXEIRA. 2011, 2012)
Esta metodologia possui características marcantes, tendo como destaque o
feedback do cliente que se torna constante, a abordagem incremental e o
encorajamento de comunicação entre os envolvidos no projeto. O feedback provém
de três fontes: do próprio software implementado, do cliente e de outros membros da
equipe, visando um desempenho ágil (SOMMERVILLE, PRESSMAN. 2011, 2000)
As regras básicas do XP, de maneira antecipada, podem ser
incompreendidas ou parecerem confusas, todavia seu conceito revolucionou o
desenvolvimento de software. A ideia é enfatizar o desenvolvimento rápido, ao
mesmo tempo que procura garantir a satisfação do cliente, favorecendo o
cumprimento das demandas estimadas. Vale salientar que as regras e práticas desta
metodologia estimulam sua utilização, podendo proporcionar um ambiente de
desenvolvimento agradável. (SOMMERVILLE, I. 2011)
A XP foi criada no ano de 1996, e foi apresentada na Object-Oriented
Programming, Systems, Languages & Applications (OOPSLA) por Kent Beck, no ano
de 2000, em uma conferência voltada a orientação a objetos reconhecida
internacionalmente, que hoje faz parte da System, Programming, Languages and
Applications: Softwares for Humanity (SPLASH). Um tempo depois, foi proposta uma
variação da XP, denominada Industrial XP (IXP), a IXP refina a XP e visa o processo
ágil especificamente para uso em grandes organizações (TEIXEIRA, PRESSMAN,
2012, 2000).

Figura 1 -Etapas da Metodologia XP.

 Fonte: PRESSMAN, 2000.

Tendo como metas principais atender as necessidades dos clientes da

maneira mais simples possível e desenvolver com prática orientada a objetos, a
equipe desta modalidade está permitida a trabalhar com até 12 integrantes.
Na medida que o software é criado, novas melhorias são implementadas, a
fim de que o cliente sempre terá um produto a ser testado e que possa receber um
feedback. Desse modo, os programadores podem conhecer melhor os processos e
construir o projeto de forma mais dinâmica possível para o trabalho do cliente
(TEIXEIRA, J. H. 2012).
É uma metodologia flexível, que pode ser moldada em cada tipo de projeto.
Todavia, se acaso se perceba que está resultando em um processo de retrabalho
exagerado, deve se ter em vista a reavaliação da utilização desta modalidade para a
execução do projeto, o XP segue rigorosamente o princípio keep it single (KIS), ou
seja, preserve a simplicidade. (SOMMERVILLE, PRESSMAN. 2011, 2000)
A comunicação, o feedback, a simplicidade, a coragem e o respeito, são os
cinco valores primordiais que são destacados na utilização dessa metodologia. A
comunicação entre os desenvolvedores e os clientes é mútua, buscando evitar ter
maus entendidos ou erros de projeto e reduzindo o percentual de chance de haver
pendências no projeto. No entanto, os processos são atendidos com agilidade e as
dúvidas são sanadas constantemente pelos clientes (TEIXEIRA, J. H. 2012).
O feedback possibilita a chance ao programador de melhor compreender as
necessidades do produto e rapidamente implementar as funções básicas, além de
formar uma opinião do cliente.
Acompanhado da simplicidade, durante a elaboração do projeto os envolvidos
são orientados a não fazer uso de recursos desnecessários, visando ter um
desempenho na formação estrutural maior, que em seguida será avaliada pelo
cliente, e se acaso não seja aprovada, poderá ser repensada de uma maneira
melhor para solucionar o problema em questão. (TEIXEIRA, J. H. 2012)
 A coragem faz os desenvolvedores adotarem medidas que às vezes se
tornam complexas e de alto risco, sendo premissas que contrariam os moldes
tradicionais de desenvolvimento. Aqui podemos citar o ritmo sustentável, assumir
atrasos, refactoring contínuo, permitir que o cliente opine, pair programing, sendo um
programador e um responsável pela correção imediata, tendo em vista a aceleração
do processo. Testes automatizados e expor o código-fonte.
Vale salientar que grandes quantidades de horas extras não são bem vistas
no XP, pois o resultado final pode resultar na perda de qualidade final do programa,
o que vai totalmente contra os moldes do XP. (SOMMERVILLE, TEIXEIRA. 2011,
2012)
O respeito também é um valor muito importante adotado pelo XP, pois
estimula os desenvolvedores a respeitarem seus clientes e vice-versa. Aceitando
críticas e dando ouvidos aos membros envolvidos. (TEIXEIRA, J. H. 2012)
Assim como os valores, existem no XP as boas práticas a serem seguidas
com a intenção de garantir um ciclo de desenvolvimento fortemente dependente,
sendo os padrões de projeto que a equipe deve seguir um design pattern conhecido.
De modo que todos consigam entender mais rapidamente os códigos uns dos
outros, sendo que cabe a eles escolherem a melhor linguagem de programação para
a elaboração do projeto. (TEIXEIRA, J. H. 2012)
A adoção de um design simples é essencial se levar em consideração que
todo sistema pode sofrer alterações o tempo todo de seu desenvolvimento,
buscando dessa forma evitar programações desnecessárias a fim de eliminar a
perda de tempo. A possibilidade do projeto ser orientado a objetos facilita esse
design, bem como suas alterações desnecessárias. (TEIXEIRA, J. H. 2012)
O fato do cliente sempre estar presente, acompanhar o desenvolvimento e
participar do processo é algo crucial para um resultado pleno, na medida que o
software é implementado o cliente tem a visão de como vai ficar além de poder
sugerir mudanças e participar da criação dos testes conceituais que serão os
indicadores de uma boa codificação. (TEIXEIRA, J. H. 2012)
Quando a equipe recebe os requisitos do cliente, também nomeados de
estórias, é realizado o jogo de planejamento, onde se realiza uma divisão por
funcionalidades, em seguida o cliente recebe uma lista delas e faz a catalogação
das prioridades para somente depois organizar em ordem numérica para a
implementação, com a lista também podemos estimar o custo de cada uma delas e
planejar a sua execução assim como as iterações necessárias. (SOMMERVILLE,
TEIXEIRA. 2011, 2012)
Toda a equipe participa das reuniões diárias, que se trata de uma reunião
rápida onde será discutida as dificuldades e experiências de implementação de cada
funcionalidade, discutindo o que foi feito no dia anterior e formulando o que será feito
no dia, definindo as duplas e seus objetivos, por se tratar de uma reunião rápida, os
participantes geralmente ficam de pé (stand-up). (SOMMERVILLE, TEIXEIRA. 2011,
2012)
A Programação em pares é uma característica muito interessante no XP,
também disponível em outras metodologias, o pair programming visa a aceleração
de correções e diminuição do tempo, sendo comprovado que programar em dupla
faz o serviço render duas vezes mais. Outra razão seria a constante troca de
experiências da dupla possibilitando dividir os problemas em dois, e na ausência de
um dos integrantes a outra pode suprir uma eventual demanda pois conhece o
código da mesma forma. Assim também, a dupla pode interagir em todas as áreas
do sistema, a fim de não se desenvolver ilhas de expertise. (SOMMERVILLE,
TEIXEIRA. 2011, 2012)
Durante os testes do cliente, um feedback é recebido sobre o resultado do
trabalho, com base nisso o programador pode modificar alguma coisa do código a
fim de atendê-lo. O objetivo não é sair refazendo tudo mas sim reutilizar ao máximo
em busca de melhores performances, estes testes também são chamados de testes
de aceitação, ou testes de cliente, sendo que são obtidos de histórias de usuários
implementadas como parte de uma versão de software. (TEIXEIRA, PRESSMAN.
2012, 2000)
Para facilitar o entendimento do cliente é adotado um artifício para criar
analogias com os processos utilizados, desta maneira o cliente não se sente
constrangido por não entender os termos técnicos utilizados pelos desenvolvedores.
(TEIXEIRA, J. H. 2012)
XP se desfia em uma equipe muito bem embasada cujas as partes são
definidas pelo Gerente de projeto que tem o dever de acreditar nos ideais e nos
valores e bem como cobrá-los dos outros membros. Cabe a ele ser o maior elo de
contato com o cliente apresentando o cenário da metodologia e explicando como
cada parte funciona. Além de cuidar das negociações de prazos e custos.
(TEIXEIRA, J. H. 2012)
O Coach é o profissional com maior nível de conhecimento sobre XP,
cabendo a ele monitorar a equipe para que siga com os valores e as práticas da
metodologia. Sendo ele uma espécie de mentor, toda dúvida deve ser sanada por
ele. (TEIXEIRA, J. H. 2012)
O Desenvolvedor não tem diferença alguma do analista, podendo exercer
diversos papéis durante a elaboração de um projeto, facilitando o desenvolvimento
com a troca de experiências. (TEIXEIRA, J. H. 2012)
A qualidade dos sistemas e comandada pelo analista de testes juntamente
com o cliente que retorna os feedbacks aplicados no final de cada iteração, não
deve acumular funções com os desenvolvedores a fim de evitar uma visão
tendenciosa do que foi desenvolvido. (TEIXEIRA, J. H. 2012)
Propondo o mínimo de documentação, o Redator técnico é a pessoa
responsável por documentar as funções do sistema paralelamente com a sua
produção no XP, sendo uma peça crucial para o meio jurídico do processo.
(TEIXEIRA, J. H. 2012)

REFERÊNCIAS:

SOMMERVILLE, I. Engenharia de Software 9°Edição. Editora Pearson.

TEIXEIRA, J. H. Metodologias Ágeis Engenharia de software sob medida Editora
Érica, 2012.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.[s.l.]

Grupo A - AMGH, 2000.