INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
Programação Ágil – Extreme Programming (XP)

2
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
Sumário
Introdução .................................................................................................................................... 3
1. Programação Ágil – Extreme Programming [XP]................................................................. 4
1.1 Criação .......................................................................................................................... 4
1.2 Metodologia ................................................................................................................. 5
1.3 Princípios básicos.......................................................................................................... 6
2. Práticas de programação...................................................................................................... 6
3. Ciclo de Vida ......................................................................................................................... 9
Conclusão.................................................................................................................................... 10
Referências: ................................................................................................................................ 11

3
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
Introdução
A constante necessidade de se obter resultados favoráveis na economia mundial tem
obrigado a indústria a reunir esforços para dinamizar o seu processo produtivo. A
evolução de softwares de computadores precisa superar metas para poder atingir o
objetivo deste mercado globalizado. Muito capital tem sido investido para esta
evolução, o processo de produção de desenvolvimento de software normalmente
envolve riscos, como o atraso no cronograma, mudanças nos requisitos, saída de um
importante membro da equipe de desenvolvimento, alta taxa de defeitos, sistemas
tornando-se obsoletos, projetos cancelados, devido à concorrência, dentre outros.
Indo de encontro a este cenário que surgiu o Extreme Programming – uma
metodologia ágil, que visa um rápido desenvolvimento, atende às reais necessidades
do cliente e, ainda, permite modificações, à medida que novas necessidades
apareçam. A seguir, iremos abordar noções de programação ágil, através de métodos
que simplificam e regulamentam o desenvolvimento de softwares para computadores.
Nosso foco será o Extreme Programming (XP), que se trata de uma metodologia de
desenvolvimento de software que se destina a melhorar a qualidade do software e a
capacidade de resposta à evolução das necessidades dos clientes. Como um tipo de
desenvolvimento ágil de software, defende "releases" frequentes em ciclos curtos de
desenvolvimento, que se destina a melhorar a produtividade e introduzir pontos de
verificação onde novos requisitos do cliente podem ser adotados.

4
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
1. Programação Ágil
Com a evolução da tecnologia e a transformação da engenharia de software, nasce um
grande problema nos projetos de sistemas: as coisas mudam. E com essa mudança,
viu-se a necessidade de um processo que evolua junto com os requisitos do sistema, e
desta ideia nasceram os Métodos Ágeis.
Muitos acham que ser ÁGIL é ser rápido, mas a busca por uma solução em softwares
não busca necessariamente rapidez, e sim um sistema ADAPTATIVO, que permita
mudanças ao longo do processo de desenvolvimento. Como todo método,
encontramos vantagens e desvantagens em seu processo. Os adeptos a este tipo de
programação apontam como vantagem o fato de não ter que testar tanto um
programa antes de disponibiliza-lo para utilização do usuário final. Com XP, um projeto
de desenvolvimento de aplicativo é realizado em pequenos incrementos. Cada etapa,
abordada separadamente em um período de tempo muito curto, complementa o
aplicativo e representa uma parte completa da funcionalidade. Você pode
implementar o aplicativo parcial, que deverá permitir que as pessoas executem algum
nível de trabalho, mesmo que o aplicativo ainda não faça tudo que você pretende
para ele no fim.
Críticos observaram várias desvantagens potenciais, incluindo problemas com
requisitos instáveis, sem compromissos documentados de conflitos de usuários, e a
falta de uma especificação de projeto total ou documentação.
1.1 - Criação
O Extreme Programming é um modelo de desenvolvimento de software, criado entre
1996-1997, por Kent Bech, no Departamento de Computação da montadora de carros
Chrysler. Ele possui muitas diferenças em relação a outros modelos, podendo ser
aplicado a projetos de alto risco e com requisitos dinâmicos. O XP é um conjunto bem
definido de regras, que vem ganhando um grande número de adeptos por oferecer
condições para que os desenvolvedores respondam com eficiência a mudanças no
projeto, mesmo nos estágios finais do ciclo de vida do processo, devido a quatro lemas
adotados por seus seguidores, que correspondem a cinco valores a partir das quais os
projetos podem ser melhorados. São eles: Comunicação, Simplicidade, FeedBack,
Coragem e Respeito.

5
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
1.2 – Metodologia
Mesmo com todos seus prós, o XP não deve ser aplicado a qualquer tipo de projeto. O
grupo de desenvolvedores deve formar uma equipe de 2 a 10 integrantes, que devem
estar por dentro de todas as fases do desenvolvimento. É necessário realizar vários
testes, às vezes, alterar o projeto em decorrência destes. A equipe tem de ser bastante
interessada e pró-ativa, para assegurar a alta produtividade, e o cliente deve estar
sempre disponível para tirar dúvidas e tomar decisões em relação ao projeto.
Seguindo os requisitos básicos, o XP poderá trazer inúmeros benefícios ao mercado, de
forma que o processo de desenvolvimento se torne mais ágil e flexível. Um desses
benefícios é a agilidade no Planejamento (Planning Games) de não definir uma
especificação completa e formal dos requisitos, ao contrário das metodologias
tradicionais. Outro é a produção de sistemas simples que atendam aos atuais
requisitos, não tentando antecipar o futuro e permitindo atualizações frequentes em
ciclos bastante curtos. Dentre as
variáveis de controle em projetos
(Custo, Tempo, Escopo e
Qualidade) há um foco explicito
em escopo. Para isto recomenda-
se a priorização de
funcionalidades que representam
maior valor possível para o
negócio. Desta forma, caso seja
necessário a diminuição do escopo, as funcionalidades menos valiosos serão adiadas
ou canceladas do projeto.
A comunicação com o cliente, no XP, mostra-se mais intensa que nos métodos
tradicionais, devendo o cliente estar sempre disponível para tirar as dúvidas, rever
requisitos e atribuir prioridades, utilizando-se de sistemas de nomes, em vez de termos
técnicos para facilitar a comunicação. Nesse jogo, todos devem ter seus papéis bem
definidos. O código deve estar padronizado, para que todos na equipe possam
entender o que está sendo escrito e possa ser validado durante todo o

6
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
desenvolvimento, tanto pelos desenvolvedores quanto pelos clientes, a fim de se
saber se os requisitos estão ou não sendo atendidos.
1.3 – Princípios básicos
Com o modelo XP sendo utilizado amplamente no mercado, cabe às universidades a
tarefa de propagar este conhecimento entre os envolvidos. A inclusão de metodologias
de desenvolvimento ágil nos currículos de referência das universidades é de grande
valia para a indústria, que busca maior produtividade com a utilização do XP, mas que
esbarra na falta de desenvolvedores qualificados para aplicar tais metodologias.
E para que isto se torne realidade, além de abraçar a causa, nossas escolas de nível
superior precisam ensinar desde já os conceitos elementares da Programação Extrema
e Ágil. Veremos a seguir os principais conceitos da XP:
- Feedback rápido: Quanto mais demorado o retorno, menor o aprendizado produzido
por ele.
- Simplicidade assumida: Desenvolver a solução mais simples que possa funcionar.
Não construir complexidade desnecessária.
- Mudança incremental: Grandes mudanças tendem a não funcionar: os problemas
são normalmente resolvidos com uma série de pequenas mudanças naquilo que faz
diferença.
- Aceitar mudanças: A mudança é inevitável. Ao invés de combater a mudança, aceita-
la como normal e saudável para o projeto.
- Trabalho de qualidade: Se as pessoas que estão no projeto não gostam da qualidade
do trabalho que estão fazendo, a tendência do projeto e fracassar.
2. – Práticas de Programação Extrema
Em suma, o projeto deve seguir passos bem definidos para não haver perda de
nenhum principio elementar, seja tempo, custo, desgaste da equipe ou a perda total
do projeto. Para seguir a linha de forma cronológica, deve-se adotar as seguintes
práticas:

7
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
• Planejamento (Jogo de Planejamento - Planning Game): O desenvolvimento é feito em
iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para
priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento. Nela,
o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial
neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no
projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de
escopo negociável, que difere significativamente das formas tradicionais de contratação de
projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades,
completamente testadas e prontas para serem postas em produção.
• Fases pequenas (Small Releases): A liberação de pequenas versões funcionais do projeto
auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte
do sistema que está comprando. As versões chegam a ser ainda menores que as
produzidas por outras metodologias incrementais, como o RUP.
• Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de
analistas e testadores, para aceitar um determinado requisito do sistema.
• Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos
assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a
realizar pela equipe.
• Padronização do Codigo (Coding Standards): A equipe de desenvolvimento precisa
estabelecer regras para programar e todos devem seguir estas regras. Desta forma
parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe
possui 10 ou 100 membros;
• Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes
unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem
é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só
que os testes unitários são essenciais para que a qualidade do projeto seja mantida;

8
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
• Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a
realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente
para um programador experiente em controlar comunicação em sistemas em tempo real,
como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado
que ele espera dentro do projeto.
• Design Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples
significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário
"teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema,
você vai fazer o código exato para que esta funcionalidade seja implementada, sem se
preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao
adotar essa prática é a confusão por parte dos programadores de código simples e
código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais
simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do
XP. Código fácil deve ser identificado e substituído por código simples.
• Time Coeso (Whole Team): A equipe de desenvolvimento é formada por pessoas
engajadas e de forma multidisciplinar (no sentido de incluir pessoas com cada uma das
habilidades necessárias para o projeto).
• Semana de 40 horas (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de
trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são
permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que
se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho
motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar
sempre em harmonia.
• Propriedade Coletiva (Collective Ownership): O código fonte não tem dono e ninguém
precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a
equipe conhecer todas as partes do sistema.
• Programação Pareada (Pair Programming): é a programação em par/dupla num
único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra
pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que
fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas
habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e
diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da
equipe, melhorando a qualidade do código fonte gerado;
• Refatoração (Refactoring): É um processo que permite a melhoria continua da
programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o
código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos
mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte;
• Integração Contínua (Continuous Integration): Sempre que produzir uma nova
funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só
aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de
forma contínua permite saber o status real da programação.

9
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
3. Ciclo de Vida

10
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
Conclusão
Estando ciente de que este tema tratado é amplo, pode-se concluir que a inclusão do
Extreme Programming no dia a dia do desenvolvimento de software enriquece a
comunidade de programação, independente do segmento das empresas nos quais os
profissionais desempenham suas atividades, garantindo a evolução dos negócios e
dinamismo na economia atual. Constatamos também que o que garante o sucesso de
um projeto não é somente a adoção de uma metodologia comprovadamente eficaz, a
adaptação ou a mesclagem de várias delas, mas sim a incorporação integral nas rotinas
de desenvolvimento por parte da equipe e a crença de que tais princípios, valores e
práticas terão o resultado esperado no final do projeto.

11
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE RONDÔNIA – IFRO
PROFESSOR: DANIEL BRANDÃO
Referências:
KUHN, Giovane Roslindo; PAMPLONA, Vitor Fernando. Apresentando XP. Encante seus
clientes com Extreme Programming.
BECK, K. – Extreme Programming Explained: enbrance change. Boston : Addison
Wesley /Longman, 1999.
TELES, Vinicius Manhães. UM ESTUDO DE CASO DA ADOÇÃO DAS PRÁTICAS E VALORES
DO EXTREME PROGRAMMING. (Dissertação de Mestrado). Disponível em:
http://www.improveit.com.br/xp/dissertacaoXP.pdf
SANTOS, Rildo. Engenharia de Software Ágil. www.extremeprogramming.org