MÉTODO ÁGIL XP (EXTREME PROGRAMMING)

Prévia do material em texto

ESTADO DE MATO GROSSO 
SECRETARIA DE ESTADO DE CIÊNCIA E TECNOLOGIA 
UNIVERSIDADE DO ESTADO DE MATO GROSSO 
CAMPUS UNIVERSITÁRIO DE BARRA DO BUGRES 
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO 
Acadêmicos: 
Anderson Mendes 
Renato R. dos Santos; 
Igor 
Frank 
MÉTODO ÁGIL XP (EXTREME PROGRAMMING) 
Barra do Bugres, MT 
2015 
VISÃO GERAL 
É considerada uma metodologia “leve” de 
desenvolvimento de software. classificada 
com “sistema de práticas que a 
comunidade de desenvolvedores de 
software 
3 
VISÃO GERAL 
vem evoluindo para resolver os problemas 
de entregar software de qualidade 
rapidamente, e então alcançar as 
necessidades de negócio que sempre 
mudam”. 
 
4 
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. 
5 
INTRODUÇÃO 
Para isso, muito capital tem sido 
empregado no desenvolvimento de 
soluções informatizadas que deem 
agilidade a seu processo de produção e, 
consequentemente, gerem um saldo 
positivo dentro do mercado. 
6 
INTRODUÇÃO 
Porém, o processo de produção de 
desenvolvimento de software 
normalmente envolve riscos. (Fatores 
ambientais, externos e internos (partes 
interessadas)). 
7 
Porém, 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 à ocorrência desses fatores 
de risco, dentre outros. 
8 
Diante deste cenário, os métodos 
utilizados para o desenvolvimento de 
software vêm ganhando importância e 
gerando interesse tanto na comunidade de 
desenvolvedores quanto na área 
acadêmica. 
 
9 
METODOLOGIAS ÁGEIS 
Segundo Sommerville (2007), um método de 
desenvolvimento de software é um conjunto de 
atividades que auxiliam a produção de software. 
O resultado dessas atividades é um produto que 
reflete a forma como todo processo foi 
conduzido. 
10 
Na década de 1990, problemas com projetos e a 
insatisfação com as abordagens pesadas de 
desenvolvimento de software levaram alguns 
desenvolvedores a propor novos métodos. 
 
11 
O termo “Metodologias Ágeis” tornou-se 
popular quando dezessete especialistas em 
desenvolvimento de software, representando os 
métodos Extreme Programming (XP), Scrum, 
Feature Driven Development FDD, entre outros, 
12 
estabeleceram princípios comuns compartilhados por 
todos. O resultado foi a criação da Aliança Ágil (Agile 
Alliance) {Aliança Ágil é uma organização sem fins 
lucrativos que procura promover o conhecimento e 
discussão sobre todas as metodologias ágeis (FOWLER, 
2003).} e o estabelecimento do “Manifesto Ágil” (Agile 
Manifesto), no ano de 2004. 
13 
METODOLOGIAS ÁGEIS 
As metodologias ágeis variam em práticas e 
ênfases, porém, compartilham de algumas 
características, tais como: desenvolvimento 
iterativo e incremental, comunicação e redução 
de produtos intermediários, documentação 
extensiva (KOSCIANSKI E SOARES, 2006). 
 
14 
PRINCÍPIOS DOS MÉTODOS ÁGEIS 
15 
PRINCÍPIO DESCRIÇÃO 
Envolvimento 
do Cliente 
Clientes devem ser profundamente 
envolvidos no processo de 
desenvolvimento. Seu papel é fornecer e 
priorizar novos requisitos do sistema e 
avaliar as iterações do sistema. 
Entrega 
Incremental 
O software é desenvolvido em incrementos 
e o cliente especifica os requisitos a serem 
incluídos em cada incremento. 
PRINCÍPIOS DOS MÉTODOS ÁGEIS 
Foco nas pessoas 
Não em processos 
As habilidades da equipe de 
desenvolvimento devem ser 
reconhecidas e exploradas. Os 
membros da equipe devem devolver 
suas próprias maneiras de trabalhar. 
Aceitar Mudanças Ter em mente que os requisitos do 
sistema vão mudar, por isso projete o 
sistema para acomodar essas 
mudanças. 
16 
PRINCÍPIOS DOS MÉTODOS ÁGEIS 
Manter a 
simplicidade 
Concentrar-se na simplicidade do 
software que está sendo 
desenvolvido e no processo de 
desenvolvimento. Sempre que 
possível, eliminar a complexidade do 
sistema. 
17 
Fonte: Sommerville (2007) 
Koscianski e Soares (2006) descrevem os conceitos-chave do “Manifesto Ágil” da 
seguinte forma: (1) Indivíduos e interações ao invés de processos e ferramentas; (2) 
Software executável ao invés de documentação; (3) Colaboração do cliente ao invés de 
negociação de contratos; (4) Respostas rápidas a mudanças ao invés de seguir planos. 
Segundo os autores, o “Manifesto Ágil” não rejeita os processos e ferramentas, a 
documentação, a negociação de contratos ou o planejamento, mas simplesmente 
mostra que eles têm importância secundária quando comparados com os elementos 
humanos do projeto (desenvolvedores e clientes) e a rápida disponibilização de um 
software executável, de acordo com a necessidade do cliente. 
18 
Segundo Sommerville (2007), ao utilizar uma metodologia ágil, um representante dos 
stakeholders deve estar disponível quase o tempo todo. Isto se torna um problema 
principalmente se houver muitos stakeholders com prioridades distintas. A motivação 
para a agilidade reside nos seguintes tópicos: (1) Clientes ou usuários não têm certeza 
do que querem; (2) Eles têm dificuldade de dizer que querem e o que sabem; (3) 
Detalhes do que eles precisam serão revelados durante o desenvolvimento; (4) Os 
detalhes são complexos para os usuários; (5) Como eles veem o desenvolvimento do 
produto, eles mudam seus pensamentos; e (6) Forças externas (competidor, produto, 
serviço, entre outros) podem levar a modificações. 
19 
METODOLOGIAS ÁGEIS 
Pressman (2006) relata que a “Agilidade” 
tornou-se uma palavra mágica quando se 
descreve um processo moderno de 
software, tudo deve ser ágil. 
20 
METODOLOGIAS ÁGEIS 
 
21 
METODOLOGIAS ÁGEIS 
Uma equipe ágil é uma equipe capaz de 
responder adequadamente a modificações 
que podem ser aplicadas a tudo que envolve o 
desenvolvimento de software, tais como: 
regras de negócios, membros da equipe, 
tecnologias; entre outras. 
 
22 
24 
METODOLOGIAS ÁGEIS 
“Não existe solução mágica para 
problemas complexos.” 
“A questão não é documentar, é 
entender.” 
25 
METODOLOGIAS ÁGEIS 
“Não existem melhores práticas. Existem 
boas práticas para determinadas 
situações.” 
“Entregue hoje. Adapte amanhã.“ 
O QUE MUDA? 
• MÉTODOS TRADICIONAIS 
I. O planejamento deve propiciar a prevenção 
de mudanças 
• MÉTODOS ÁGEIS 
I. A mudança é incorporada ao escopo 
26 
O QUE MUDA? 
• RAZÕES 
I. Necessidades de negócio 
II. Novas oportunidades 
III. Mudanças de legislação 
IV. Requisitos incompletos 
27 
MUDANÇA DE POSTURA 
 
28 
MUDANÇA DE POSTURA 
• Adaptação é uma resposta à mudança. 
• Equipes auto gerenciáveis não são 
equipes sem liderança, são equipes com 
outro estilo de liderança. 
 
29 
PROCESSO UNIFICADO 
O Processo Unificado (PU) surgiu para realizar o 
desenvolvimento de software visando a 
construção de sistemas orientados a objetos. 
30 
PROCESSO UNIFICADO 
Este modelo de desenvolvimento de software é 
iterativo e adaptativo, desta forma consegue 
produzir um sistema de grande porte como se 
fossem vários pequenos sistemas, o que diminui 
o risco do projeto. 
 
31 
 
32 
FUNCIONAMENTO 
Ele é baseado em componentes,o que significa o 
sistema ser construído a partir de componentes de 
software interconectados via interfaces muito bem 
definidas. O processo unificado utiliza a Linguagem 
de Modelagem Unificada (Unified Modeling 
Language – UML) no preparo de todos os artefatos 
do sistema. 
33 
DO PONTO DE VISTA FUNCIONAL 
A verdadeira preocupação que devemos ter ao 
lidar com metodologia/processo de 
desenvolvimento de software que é o pilar 
Pessoas/Boas Práticas/Ferramentas, ou seja, ao 
invés de ficarmos dizendo que uma é melhor que a 
outra, devemos nos 
34 
DO PONTO DE VISTA FUNCIONAL 
atentar que sem pessoas treinadas para conhecer, 
praticar e respirar o processo, sem pessoas que 
utilizam de boas práticas de desenvolvimento de 
software e sem uma equipe com ferramentas 
disponíveis que apoie o processo, não adiantará de 
nada e continuaremos 
35 
DO PONTO DE VISTA FUNCIONAL 
a bater cabeça contra a parede em cada projeto. E 
com isso todos nós nos veremos fazendo a mesma 
pergunta de sempre: Processo Unificado ou 
Processo Ágil, RUP ou XP, fazer análise ou não, 
modelar ou não, ser ou não ser. Essa com certeza é 
a grande questão dos dias de hoje para nós 
desenvolvedores de software. 
 
36 
DO PONTO DE VISTA FUNCIONAL 
Pilar do Desenvolvimento de Software 
37 
DO PONTO DE VISTA FUNCIONAL 
conclusão que o melhor dos mundos não está 
em seguir somente um processo unificado ou 
somente um processo ágil, até mesmo porque 
podemos ser ágil sem usar XP ou Scrum e 
usando um RUP. Podemos tanto usar um RUP 
38 
DO PONTO DE VISTA FUNCIONAL 
e customizá-lo para a necessidade de um 
projeto, podemos usar um XP/Scrum 
dependendo da situação, como também 
podemos usar um pouco de cada, utilizando as 
partes onde cada um é mais forte em 
determinadas situações. 
39 
DO PONTO DE VISTA FUNCIONAL 
No final das contas o mais importante são as 
pessoas dentro do processo e as práticas 
utilizadas para chegar ao objetivo que é o 
software funcionando e o cliente feliz da vida. 
 
40 
DO PONTO DE VISTA FUNCIONAL 
 
41 
CENÁRIO DO EXTREME 
PROGRAMMING (XP) 
Contudo, além de os métodos tradicionais de 
desenvolvimento de software terem o foco 
voltado para a documentação, necessitam de 
requerimentos completos e fixos, o que os 
torna uma metodologia pesada e não flexível. 
42 
CENÁRIO DO EXTREME 
PROGRAMMING (XP) 
Foi contrapondo 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. 
 
43 
EXTREME PROGRAMMING 
(Aplicabilidade) 
O Extreme Programming é um modelo de 
desenvolvimento de software, criado em 1996, 
Ela surgiu a partir de ideias de Kent Bech e 
Ward Cunningham, no Departamento de 
Computação da montadora de carros Daimler 
Crysler. 
44 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Foi um dos primeiros a sugerir iterações curtas 
com participação intensa do usuário durante 
elas. Beck explica sua posição “extrema”, 
dizendo que se as técnicas de engenharias de 
software são boas, realiza-las todo o tempo é 
ainda melhor. 
 
45 
ENTRE AS PRÁTICAS, O XP DIZ QUE: 
• Já que testar é bom, que todos testem o 
tempo todo; 
• Já que revisão é bom, que se revise o tempo 
todo; 
• Se projetar é bom, então refatorar o tempo 
todo; 46 
• Se teste de integração é bom, então que se 
integre o tempo todo; 
• Se simplicidade é bom, desenvolva uma 
solução não apenas que funcione, mas que 
seja a mais simples possível; 
47 
• Se iterações curtas é bom, então mantenha-as 
realmente curtas; 
• Portanto, como podemos notar todas as 
coisas boas são levadas ao extremo no XP. 
48 
EXTREME PROGRAMMING 
(Aplicabilidade) 
O Extreming Programming (XP) tem muita 
semelhança com SCRUM em termos de valores 
e modelo de desenvolvimento de projetos, ou 
seja, como desenvolver projetos que possam 
abraçar as incertezas de forma mais seguras. 
49 
EXTREME PROGRAMMING 
(Aplicabilidade) 
No entanto, esses dois métodos também são 
complementares, visto que SCRUM é mais 
como um framework gerencial. O XP 
desenvolve menos esses aspectos e foca mais 
em práticas de engenharia. 
 
50 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Possui adeptos e outros que duvidam da 
sua real utilidade; 
No entanto, histórias de sucesso como a da 
grande empresa chamada Chrysler. 
53 
EXTREME PROGRAMMING 
(Aplicabilidade) 
A Chrysler possuía um sistema de folha de 
pagamento global que envolvia seus 90 mil 
empregados ao redor de todo o mundo. 
54 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Existia um sistema COBOL e converteu-se em 
Smalltalk na época. Seu planejamento inicial era 
de quatro anos (1995-1999) e isso não ocorreu. 
 
55 
Em 1996 Kent Beck e Jeffries foram contratados 
e começaram a aplicar práticas que auxiliaram a 
consolidar o que hoje é o XP. Esse projeto tem 
2.000 classes e 30.000 métodos, foi para 
produção após um ano depois da contratação de 
Beck e Jeffries. 
 
56 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Outro exemplo foi o sistema Ford Motors 
Company VCAPS System que utilizava 
métodos tradicionais e enfrentava diversos 
problemas. 
57 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Os desenvolvedores ficavam mais tempo 
consertando problemas encontrados do 
que desenvolvendo ou evoluindo o 
sistema. 
 
58 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Após isso o projeto começou a adotar 
testes automatizados, integração contínua 
e outros valores do XP. 
59 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Em menos de um ano, algo que não se 
conseguia há quatro anos, o sistema foi 
desenvolvido e evoluído constantemente 
sem maiores problemas. 
 
60 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Em grandes projetos, deve ser divididos em 
subprojetos independentes. Projetos 
longos devem ser quebrados em uma 
sequência de mini projetos auto contidos, 
com duração de uma a três semanas (BECK 
et al. 1999). 
 
61 
EXTREME PROGRAMMING 
(Aplicabilidade) 
Segundo Teles (2004), a XP é um processo de 
desenvolvimento de software apropriado para 
os seguintes projetos: (1) com requisitos vagos 
que e mudam com frequência; (2) 
Desenvolvimento de sistemas orientados a 
objeto; 
63 
EXTREME PROGRAMMING 
(Aplicabilidade) 
(3) Equipes pequenas; e (4) Desenvolvimento 
incremental. Para o autor a XP é organizada para 
assegurar que o cliente sempre receba um alto 
retorno do investimento em software. 
 
64 
• 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. 
65 
EXTREME PROGRAMMING 
(Paradigma) 
O XP muda o paradigma, onde não temos o 
medo da mudança, pois o errar é feito com um 
baixo custo. Diferente do tradicional em que se 
diz que quanto mais tarde a mudança, maiores 
são os custos, 
67 
EXTREME PROGRAMMING 
(Paradigma) 
e assim sendo nunca devemos fazer mudanças o 
XP diz que devemos sim estar constantemente 
fazendo mudanças e não devemos teme-las, 
principalmente quando seguimos os seus 
valores e assuas práticas. 
 
68 
EXTREME PROGRAMMING 
(Paradigma) 
Para conseguirmos se adaptar as mudanças o XP 
preconiza ciclos curtos que nos dá previsibilidade e 
redução de incertezas/riscos, Simplicidade e 
melhorias constantes de código (refactoring) para 
facilitar a mudança e Testes Automatizados e 
Integração Contínua para aumentar a confiança. 
69 
EXTREME PROGRAMMING: 
CONCEITOS 
XP é uma técnica revolucionária de 
desenvolvimento de software. Tais objetivos são 
alcançados através de um pequeno conjunto 
de VALORES, PRINCIPIOS E PRATICAS 
 
71 
EXTREME PROGRAMMING: 
CONCEITOS - VALORES 
Comunicação: segundo Beck “Os problemas nos 
projetos invariavelmente recaem sobre alguém 
não falando com alguém sobre algo 
importante”. 
72 
Assim, a comunicação enfatiza que devemos 
sempre estar se comunicando seja entre 
desenvolvedores ou com os clientes. 
A comunicação ajuda na eliminação de 
documentos e favorece a comunicação face a 
face. 
 
73 
XP é organizado em práticas que não podem ocorrer se não houver comunicação. De 
preferencia os clientes devem estar sempre presentes para criar Histórias de usuário e 
cliente on-site (CCC) ou ainda tirar dúvidas. Outra forma de comunicação no XP é a 
Programação em pares, onde os desenvolvedores programam num mesmo 
computador, nesse formato de programação ambos estão constantemente se 
comunicando e trocando ideias. O Jogo do planejamento (planning poker) também é 
outra forma de comunicação visto que a equipe de desenvolvimento está dando sua 
visão técnica, o cliente por sua vez está dando requisitos em pró do negocio e dando 
as prioridades. 
74 
EXTREME PROGRAMMING: 
CONCEITOS - VALORES 
Simplicidade: é tentar fazer o mais simples 
possível e caso seja necessário faremos algo 
mais complexo amanhã. 
75 
Muitas vezes algo é feito de forma completa e posteriormente não é mais 
sequer usado ou necessário. Portanto, entre os princípios temos: Qual é a 
coisa mais simples que funciona? Aqui também temos a importância do 
coach que deve estar sempre verificando se a simplicidade esta sempre sendo 
seguida nos projetos. Fazendo um paralelo entre a simplicidade e a 
comunicação conclui-se que a simplicidade faz com que temos menos a 
comunicar e de uma forma mais completa e por sua vez a comunicação faz 
com que transmitimos mais clareza e confiança para alimentar a 
simplicidade. 
 
76 
EXTREME PROGRAMMING: 
CONCEITOS - VALORES 
Feedback: é muito presente no SCRUM através 
das reuniões diárias, retrospectiva, reuniões de 
revisão do produto, etc. Feedback é o valor 
primordial dentro do desenvolvimento ágil. 
77 
O XP foi o precursor a falar em feedback e afirma que ele possibilita que o software 
evolua. O XP, como algo mais técnico que o SCRUM, diz que devemos sempre 
“Perguntar ao software, e não a um documento", uma forma de alcançar isso é 
através dos testes automatizados que permitem feedback rápido. Os teste 
automatizados respondem de forma imediata se aquilo que foi introduzido ainda esta 
funcionando. O Feedback precisa ser cedo para sabermos se estamos fazendo a coisa 
correta, precisa ser concreto perguntando diretamente ao código e precisa ser 
constante através de iterações curtas, incrementos, e releases. Aqui garantimos 
constantemente junto ao cliente se estamos fazendo certo e o prazo esta seguindo 
bem o planejado. 
 
78 
EXTREME PROGRAMMING: 
CONCEITOS - VALORES 
Coragem: muitas vezes não fazemos as coisas 
porque não temos coragem de fazer as 
mudanças. XP diz que devemos ter coragem de 
sempre colocar o cliente a par do que está 
acontecendo. 
79 
Entre aquilo que o XP considera que devemos ter coragem de fazer destacam-se: 
– Acreditar na capacidade de reagir a mudanças; 
– Trocar de paradigma; 
– Aprender com os erros; 
– Dar e receber feedback sem medo das consequências; 
– Acreditar no feedback concreto (não na “teoria”); 
– Fazer o que precisa ser feito; 
– Jogar fora código ruim; 
– Jogar fora protótipos criados para testar ideias. 
 
80 
EXTREME PROGRAMMING: 
CONCEITOS - VALORES 
Coach: é uma pessoa responsável por garantir a 
aderência a estes valores nas práticas. O Coach 
normalmente é uma pessoa experiente que 
também ajuda as equipes a implementarem o 
XP e monitorar se as coisas estão sendo bem 
seguidas. 
 
81 
Por fim, XP preconiza que Codificação é a atividade central do projeto, que os Testes 
(que também são código) servem de especificação de requisitos, e a Comunicação oral 
entre desenvolvedores é fundamental. Isto não quer dizer que a equipe XP não 
constrói documentos e não faz modelagem, ela só não considera que um modelo é 
um documento. Modelos são feitos o tempo todo seja como quadro branco, sessões 
de design, etc, mas servem como um suporte para o concreto que realmente importa. 
Os valores devem sustentar as práticas que serão vistas no próximo artigo como já foi 
solicitado pelos nossos leitores. Por fim a próxima sessão falará um pouco sobre a 
adoção do XP nas organizações. 
 
82 
EXTREME PROGRAMMING: 
CONCEITOS - VALORES 
Respeito é um valor que dá sustentação aos 
demais. Se ele não existir em um projeto, não há 
nada que possa salvá-lo. Ouvir, compreender e 
respeitar o ponto de vista dos demais 
integrantes da equipe é essencial. 
83 
Todos os valores apresentados são alicerces da 
XP, pois eles que oferecem sustentação às boas 
práticas adotadas na metodologia (TELES, 2004). 
 
84 
EXTREME PROGRAMMING: 
CONCEITOS - PRINCÍPIOS BÁSICOS 
Feedback rápido: Quanto mais demorado o 
retorno, menor o aprendizado produzido por 
ele. 
EXTREME PROGRAMMING: 
CONCEITOS - PRINCÍPIOS BÁSICOS 
Simplicidade assumida: Desenvolver a solução 
mais simples que possa funcionar. Não construir 
complexidade desnecessária. 
 
86 
EXTREME PROGRAMMING: 
CONCEITOS - PRINCÍPIOS BÁSICOS 
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. 
87 
EXTREME PROGRAMMING: 
CONCEITOS - PRINCÍPIOS BÁSICOS 
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. 
 
88 
EXTREME PROGRAMMING: 
CONCEITOS - PRINCÍPIOS BÁSICOS 
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. 
 
89 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Para aplicar os valores e princípios durante o 
desenvolvimento de software, o XP propõe uma 
série de práticas. Há uma confiança muito 
grande nas inergia entre elas, os pontos fracos 
de cada uma são superados pelos pontos fortes 
de outras. 
90 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Jogo de Planeamento (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 
Planeamento. 
91 
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 paraserem colocadas em produção. 
92 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Pequenas Versões (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. 
93 
As versões chegam a ser ainda menores que as 
produzidas por outras metodologias 
incrementais, como o RUP. 
 
94 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Metáfora (Metaphor): Procurar facilitar a 
comunicação com o cliente, entendendo a 
realidade dele. 
95 
O conceito de rápido para um cliente de um sistema 
jurídico é diferente para um programador 
experiente em controlar comunicação em sistemas 
de tempo real, como controle de tráfego aéreo. É 
preciso traduzir as palavras do cliente para o 
significado que ele espera dentro do projeto. 
96 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Projeto Simples (Simple Design): Simplicidade é 
um princípio do XP. Projeto simples significa 
dizer que caso o cliente tenha pedido que na 
primeira versão. 
97 
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. 
98 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Time Coeso (Whole Team): A equipe de 
desenvolvimento é formada pelo cliente e pela 
equipe de desenvolvimento. 
99 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Testes de Aceitação (Customer Tests): São testes 
construídos pelo cliente em conjunto com 
analistas e testadores, para aceitar um 
determinado requisito do sistema. 
100 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Ritmo Sustentável (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. 
101 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Reuniões em pé (Stand-up Meeting): Reuniões 
em pé para não se perder o foco nos assuntos 
de modo a efetuar reuniões rápidas, apenas 
abordando tarefas realizadas e tarefas a realizar 
pela equipe. 
102 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Posse Coletiva (Collective Ownership): O código 
fonte não tem dono e ninguém precisa ter 
permissão concedida para poder modificar o 
mesmo. O objetivo com isto é fazer a equipe 
conhecer todas as partes do sistema. 
103 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Programação em Pares (Pair Programming): é a 
programação em par/dupla num único 
computador. Geralmente a dupla é criada com 
alguém sendo iniciado na linguagem e a outra 
pessoa funcionando como um instrutor. 
104 
Como é apenas um computador, o novato é que fica à 
frente fazendo a codificação, e o instrutor acompanha 
ajudando a desenvolver suas habilidades. Dessa forma o 
programa sempre é revisto por duas pessoas, evitando e 
diminuindo assim a possibilidade de erros (bugs).Com 
isto, procura-se sempre a evolução da equipe, 
melhorando a qualidade do código fonte gerado. 
 
105 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Padrões de Codificação (Coding Standards): A 
equipe de desenvolvimento precisa estabelecer 
regras para programar e todos devem seguir 
estas regras. Dessa forma parecerá que todo o 
código fonte foi editado pela mesma pessoa, 
mesmo quando a equipe possui 10 ou 100 
membros. 106 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
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. 
107 
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. 
 
108 
EXTREME PROGRAMMING: 
CONCEITOS – PRÁTICAS 
Refatoração (Refactoring): É um processo que 
permite a melhoria contínua da programação, 
com o mínimo de introdução de erros e 
mantendo a compatibilidade com o código já 
existente. 
109 
Refactorizar melhora a clareza (leitura) do 
código, dividido em módulos mais coesos e de 
maior reaproveitamento, evitando a duplicação 
de código-fonte. 
 
110 
Integração Contínua (Continuous Integration): 
Sempre que realizar uma nova funcionalidade, 
nunca esperar uma semana para integrar na 
versão actual do sistema. 
111 
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. 
 
112 
113 
114 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
O ciclo de vida de um projeto XP consiste em 
pôr as práticas e estratégias da XP em 
funcionamento de maneira ordenada. 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
O projeto ideal em XP é aquele que inicia 
por uma curta fase de desenvolvimento, 
seguida de anos de produção e 
refinamentos simultâneos e finalmente 
encerra quando o projeto não faz mais 
sentido. 
 
116 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
O ciclo de vida e as fases do processo XP são 
abordagens muito discutidas por diversos 
autores que adotam essa metodologia. O ciclo 
de vida XP é bastante curto e, à primeira vista, 
difere dos padrões dos modelos de processo 
convencionais. 
117 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Entretanto, esta abordagem faz 
sentido somente em um ambiente 
onde as mudanças de requisitos do 
sistema são fatores dominantes. 
118 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
No caso extremo, os requisitos podem 
mudar no meio da versão, para atender 
funcionalidades mais importantes do que 
as definidas no planejamento original. 
 
119 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Ele consiste de uma pequena fase inicial de 
desenvolvimento seguida por um longo período 
de refinamento e suporte à produção. O ciclo de 
vida pode ser dividido nas seguintes fases: 
 
120 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
• Exploração; 
• Planejamento; 
• Interações; 
• Produção; 
• Manutenção; 
• Morte (Fim do projeto); 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Exploração: O objetivo da fase de Exploração é 
entender o que o sistema deve fazer, bem o 
suficiente para que possa ser estimado. Sendo que, 
o cliente escreve e administra histórias {story cards) 
e o programador estima as histórias. 
122 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Encerra quando todas as histórias necessárias 
para a próxima fase - fase de planejamento - 
tenham sido estimadas. 
123 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
A fase de Exploração começa com as regras de negócio. O 
cliente escrevendo cartões de história que descrevem o 
que o sistema precisa fazer. Em paralelo as histórias dos 
clientes os programadores estão experimentando 
ativamente as diferentes tecnologias e as possíveis 
configurações, explorando as possibilidades para a 
arquitetura do sistema. 
124 
EXTREME PROGRAMMING:CICLO DE VIDA 
Leva-se de uma a duas semanas testando a 
arquitetura, mas deve-se testar de três a quatro 
maneiras, ou seja, diferentes pares podem testar 
diferentes tecnologias e comparar ou, dois pares 
podem testar a mesma tecnologia e comparar as 
diferenças emergentes; 
125 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Planejamento: O objetivo da fase de Planejamento 
é definir a menor data e o maior conjunto histórias 
que serão realizadas na primeira versão. Esta 
definição é feita de acordo com estimativas entre 
cliente e programadores. Assim que as histórias são 
coletadas, o Jogo de Planejamento é conduzido. 
 
126 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
O cliente decide quais histórias são vitais e que 
devem fazer parte da primeira versão. Desta forma, 
pode-se elaborar uma lista priorizada das histórias. 
Se houver uma boa preparação durante a fase de 
exploração é necessário apenas alguns dias para a 
fase de planejamento; 
 
127 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Iteração para primeira versão: Os compromissos 
são divididos para serem executados em iterações 
que duram de uma a quatro semanas. Para cada 
história executada naquela iteração é produzido um 
conjunto de testes ficcionais. 
128 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
A primeira iteração, mostra como a arquitetura do 
sistema irá se comportar. Então, as histórias devem 
ser escolhidas de forma que representem força para 
criar todo o sistema. A pergunta chave para ser 
trabalhada nesta fase é: Qual a coisa de maior valor 
para o time para ser trabalhada nesta iteração. 
129 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Conforme Reis (2000), uma sequência de ciclos 
iterativos conduzem o desenvolvimento, que 
concentra o projeto, a codificação, os testes e as 
versões do produto. Normalmente, há alguns 
ciclos iterativos antes da fase de produção. 
130 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
No final de cada iteração o cliente terá 
completado a execução de todos os testes 
flincionais e, no final da última iteração, o 
sistema estará pronto para entrar em produção; 
131 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Produção: Existem alguns processos para avaliar se 
o software realmente está pronto para entrar em 
produção. Pode-se implementar novos testes para 
provar se o sistema está estável o suficiente para 
entrar em produção. Testes são frequentemente 
aplicados nesta fase. 
132 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Pode ser necessário apenas ajustar o desempenho. E o 
melhor momento para realizar estes ajustes é no final da 
versão. Pois, se tem mais conhecimento do projeto, assim 
como existe a possibilidade de realizar estimativas reais 
de sobrecarga de produção do sistema. E provavelmente, 
este teste poderá ser realizado na máquina de produção; 
133 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Manutenção: A fase de manutenção é o estado 
normal de um projeto XP. Deve-se simultaneamente 
produzir novas funcionalidades, manter o sistema 
existente rodando, substituir membros do time que 
partem e incorporar novos membros ao time. 
134 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Nesta fase, pode-se tentar fazer refactorings 
maiores, os quais, nas versões anteriores, causaram 
certo receio. Pode-se testar novas tecnologias que 
se pretende incorporar nas próximas versões, ou 
migrar a tecnologia que está em uso para versões 
mais atualizadas. 
135 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
O cliente pode escrever novas histórias que tragam 
para o seu negócio grandes conquistas. A estrutura 
do time provavelmente será alterada, ou seja, 
voltada para a produção. Talvez seja necessário um 
help-desk, e já não se tenha á necessidade de uma 
grande quantidade de programadores. 
136 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Entretanto, se deve ter cuidado com a rotação da posição 
de todos os programadores, o time pode ser mudado 
gradualmente. Isto é importante, tanto para comunicar a 
estrutura de todo o projeto, quanto os detalhes de 
planejamento e implementação, e que somente pode ser 
feito através do contato diário entre o time; 
137 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Fim do projeto: Beck (2000) considera que "Morrer bem 
é tão importante quanto viver bem. Isto é uma verdade 
para o XP como para as pessoas". Quando não mais 
existir novas histórias, é o momento de finalizar o 
projeto. E o momento de escrever algumas páginas (de 5 
a 10 páginas) sobre a funcionalidade do sistema, um 
documento que auxilie no futuro a saber como realizar 
alguma alteração no sistema. 
138 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Uma boa razão para finalizar o projeto é o 
cliente estar satisfeito com o sistema e não ter 
mais nada que consiga prever para o futuro. 
Toda a equipe que trabalhou no sistema deve 
ser reunida para reavaliação. 
139 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
Aproveite a oportunidade de analisar o que 
pode ter causado queda no sistema e o que fez 
o projeto avançar. Assim, o time saberá melhor 
o que fazer no futuro, o time executará tarefas 
de formas diferentes da próxima vez. 
 
140 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
 
141 
EXTREME PROGRAMMING: 
CICLO DE VIDA 
O XP busca a excelência técnica obrigatória para 
melhoria contínua do processo e esta faz com 
que a equipe torne-se perita nas melhores 
práticas de desenvolvimento, ou seja, torne-se 
extrema. 
 
142 
COMPONENTES/PAPÉIS NO 
PROCESSO 
Programador: segundo Back, ele é o coração do XP, pois o 
principal foco é a implementação. A diferença entre um 
programador em outras metodologias e no XP é que aqui 
ele precisa se preocupar com a comunicação, com o design 
do sistema, com os testes unitários, com ser eXtremo. 
 
 
 
143 
COMPONENTES/PAPÉIS NO 
PROCESSO 
Cliente: Responsável por escrever “histórias”; 
muitas vezes é um programador ou é 
representado por um programador do grupo; 
trabalha no mesmo espaço físico do grupo; 
feedback do cliente é essencial. 
Se o programador é quem implementa, o cliente é 
quem sabe o que deve ser implementado, ou seja, é 
quem conhece o produto. O titulo de cliente é dado 
a pessoa responsável por escrever as histórias de 
usuário, por defender os interesses do cliente, por 
saber dar valor as histórias (valor do ponto de vista 
de importância ao negócio). 
 
145 
COMPONENTES/PAPÉIS NO 
PROCESSO 
Testador: Como o programador já fez os testes 
unitários, a tarefa do testador está relacionada 
aos testes funcionais e por sua execução 
frequente. 
 
146 
COMPONENTES/PAPÉIS NO 
PROCESSO 
Rastreador: Back afirma que o rastreador é a 
consciência da equipe, sendo o responsável por 
finalizar a iteração, por uma visão global do 
andamento do sistema, etc. Este papel necessita 
de habilidade de coleta de informação e boa 
comunicação interpessoal. 
147 
COMPONENTES/PAPÉIS NO 
PROCESSO 
Treinador: O mais experiente do grupo; 
identifica quem é bom no que; lembra a todos 
as regras do XP; faz programação pareada; 
chama a atenção para oportunidades de 
melhorias; seu papel diminui à medida em que o 
time fica mais maduro. 
 
148 
treinador que é o responsável pelo processo 
como um todo e por manter o XP funcionando. 
149 
COMPONENTES/PAPÉIS NO 
PROCESSO 
• Acompanhador: A “consciência” do time; 
mantém histórico do progresso; faz 
estimativas para o futuro e coleta estatísticas 
sobre o andamento do projeto, como: 
150 
• Número de histórias definidas e implementadas.• Número de unit tests. 
• Número de testes funcionais definidos e 
funcionando. 
• Número de classes, métodos, linhas de código. 
151 
COMPONENTES/PAPÉIS NO 
PROCESSO 
Consultor: Não é obrigatório, mas quando há 
necessidade, equipes XP pode chamar um 
consultor ad hoc. 
152 
COMPONENTES/PAPÉIS NO 
PROCESSO 
• O Chefão: este é o manda chuva, quem 
manda em tudo. 
153 
COMPONENTES/PAPÉIS NO 
PROCESSO 
Ninguém tem maior importância no grupo, mas 
todos tem suas atribuições e devem buscar a 
qualidade total dos seus processos. O 
programador deve especializar-se na sua tarefa 
e deve ainda cultivar as boas práticas 
154 
COMPONENTES/PAPÉIS NO 
PROCESSO 
A equipe XP mantém o sistema integrado e funcionando 
o tempo todo. Programadores escrevem todo o código de 
produção em pares, todos trabalham em conjunto para a 
excelência do produto. Eles codificam em um estilo 
consistente para que todos possam entender e melhorar 
todo o código conforme necessidade da equipe. 
155 
COMPONENTES/PAPÉIS NO 
PROCESSO 
O cliente mantém os programadores informados 
sobre suas necessidades, o treinador mantém a 
equipe coesa e o testador valida as 
funcionalidade. Tudo para que o resultado seja 
de alta qualidade. 
156 
EXTREME PROGRAMMING: ADOÇÃO 
DO XP NA ORGANIZAÇÃO 
Não existe uma regra geral de como devemos adotar o 
XP na nossa organização. Nunca utilizou XP antes e 
quer começar a utilizar com um cliente que já está há 
algum tempo trabalhando com você e a sua equipe o 
ideal é que esse processo seja gradual, tanto com o 
cliente quando com a equipe. 
157 
EXTREME PROGRAMMING: ADOÇÃO 
DO XP NA ORGANIZAÇÃO 
Ou seja, começa-se a utilizar os valores e as práticas 
do XP aos poucos criando testes automatizados aos 
poucos com as partes mais importantes, chamando 
o cliente para participar das reuniões e mostrando a 
importância disso para o próprio cliente, para a 
equipe e para o bem do projeto. 
158 
EXTREME PROGRAMMING: ADOÇÃO 
DO XP NA ORGANIZAÇÃO 
Se você quer utilizar XP desde o início é mais 
simples, basta começar a utilizar e envolver o 
cliente no processo, seguindo sempre os valores 
e práticas do XP. 
 
159 
EXTREME PROGRAMMING: ADOÇÃO 
DO XP NA ORGANIZAÇÃO 
Segundo Beck, pode-se utilizar três passos para a 
implementação do XP: 
1. Escolha o pior dos problemas; 
2. Resolva-o da maneira XP; 
3. Quando ele não for mais seu problema, repita os 
passos 1 e 2 para o próximo problema. 
160 
EXTREME PROGRAMMING: ADOÇÃO 
DO XP NA ORGANIZAÇÃO 
Desta forma, utilize uma prática XP por vez, mas 
tenha em mente os seus valores, assim, é 
possível se adaptar ao XP, até ter sua 
implementação por completo no seu projeto. 
 
161 
EXTREME PROGRAMMING: ADOÇÃO 
DO XP NA ORGANIZAÇÃO 
O uso do XP é uma mudança no paradigma 
tradicional, o que pode implicar em confusão no 
início da sua implementação. 
 
162 
EXTREME PROGRAMMING: ADOÇÃO 
DO XP NA ORGANIZAÇÃO 
A vontade de mudar é uma virtude, mesmo que 
confunda parte da empresa durante um tempo 
(Mike Cohn, 2011). Esta mudança exige 
conhecer os valores, princípios e técnicas que 
fazem parte das bases do XP. 
163 
EXTREME PROGRAMMING: NÃO 
ADOÇÃO DO XP NA ORGANIZAÇÃO 
A metodologia XP propõe uma forma simplificada e eficaz 
de desenvolvimento de software. Contudo, aplicá-la em 
equipes de desenvolvimento que fazem uso de outros 
processos não é fácil, e muitas vezes impossível. A grande 
dificuldade não diz respeito a problemas técnicos, mas 
sim, culturais dentro das equipes de desenvolvimento 
(BECK, 2004). 
164 
EXTREME PROGRAMMING: NÃO 
ADOÇÃO DO XP NA ORGANIZAÇÃO 
Outro ponto importante a considerar é a política da 
empresa que desenvolve software. Caso a empresa 
produza software em massa, a XP não é aconselhável. 
Esse conceito não se aplica a XP, visto que se aproxima do 
modelo em cascata, com uma série de etapas executadas 
umas após as outras, planejando no início e recebendo o 
feedback apenas no fim do processo (TELES, 2005). 
165 
EXTREME PROGRAMMING: NÃO 
ADOÇÃO DO XP NA ORGANIZAÇÃO 
Segundo Borborema (2007), o uso da XP deve 
ser feito em empresas que primam por 
processos dinâmicos de desenvolvimento, 
baseados na resposta do cliente e no 
aprendizado contínuo de todos os integrantes 
da equipe. 
166 
EXTREME PROGRAMMING: NÃO 
ADOÇÃO DO XP NA ORGANIZAÇÃO 
167 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
Os dados relatados nesta seção foram coletados 
por meio de entrevistas com dois gestores da 
empresa: o Presidente e seu Diretor de TI. 
• Fonte: Metodologias Ágeis: Um Exemplo de 
Aplicação da Extreme Programming (XP). 
168 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
EMPRESA ACCESSPRO 
A AccessPro se originou da empresa Ideológica 
Informática, fundada no ano de 1994. Desde sua 
fundação a Ideológica atuou com o 
desenvolvimento e consultoria em Microsoft Access 
(MS Access), entre outras atividades. 
169 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
No ano de 2009, se transformou em uma empresa 
independente e completamente focada na 
ferramenta MS Access. Os números da empresa 
são: 54 clientes ativos; 16 funcionários; 120 
projetos executados; 7 projetos em andamentos e 4 
em Stand by (Maio/2010); 1 equipe de XP com 10 
pessoas. 
 
170 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
A Missão da empresa é desenvolver ferramentas 
e prestar serviços de alta qualidade que 
proporcionem ganhos reais de produtividade, 
controle e informação aos seus clientes. 
171 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
A sua visão é tornar-se uma empresa que seja 
referência nacional em desenvolvimento em MS 
Access e VBA1. 
 
172 
1. Visual Basic for Application (VBA) é uma linguagem baseada no Visual Basic, 
que está integrada a todos os produtos da família Microsoft (CARMONA, 2006). 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
A empresa possui uma carteira de mais de 50 
clientes, de diversos portes, setores e graus de 
informatização. Seguem alguns de seus principais 
cliente: Knorr Bremse, Atlas Copco, Banco Safra, 
Universidade São Camilo, Honda Trading, Carrefour, 
Medial Saúde, Itaú Seguros, Kopenhagen, Contem 
1g. 
173 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
O portfólio de produtos desenvolvidos pela 
AccessPro possui desde software para controle de 
uma simples portaria até sistemas complexos com 
de importação e exportação de dados diversos. Do 
ponto de vista hierárquico, a empresa mantém uma 
estrutura simples. O organograma representado na 
figura 1 ilustra essa estrutura. 
174 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
O grande diferencial da empresa está na 
utilização de uma metodologia prática e 
descomplicada. A atividade de planejamento é 
suficiente para evitar erros de interpretação e 
de comunicação, mas não em excesso a ponto 
de tornar o projeto uma atividade burocrática. 
175 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
Os gestores da empresa afirmam que sua prioridade é o 
cliente, e todas as decisões que são tomadas visam 
agregar valor para ele. Por isso, buscam compreender 
profundamente os processos de trabalho e necessidades 
dos clientes, buscando novas oportunidades de melhoria 
por meio da aplicação inteligente da tecnologia. 
176 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
VALORES DA XP NA ACCESSPRO 
177 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
 
178 
EXEMPLO DE APLICAÇÃO DA 
EXTREMEPROGRAMMING 
AS DOZE PRÁTICAS DA XP NA ACCESSPRO 
179 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
 
180 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
 
181 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
 
182 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
Com os desafios que a empresa enfrenta a cada 
projeto, o Diretor de TI concorda que, a coragem 
é essencial para acreditar que, utilizando os 
valores, práticas e princípios da XP, será capaz de 
fazer o software evoluir com segurança e 
agilidade. 
183 
EXEMPLO DE APLICAÇÃO DA 
EXTREME PROGRAMMING 
Para ele o valor mais importante da XP é o 
respeito, enfatizando que o respeito com seus 
colaboradores e clientes é essencial para o 
sucesso na adoção da metodologia. 
184 
CONCLUSÃO 
E 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 
garantindo dinamismo na economia atual. 
 
185 
REFERENCIAS 
MEDEIROS, Higor. Introdução ao Extreme Programming (XP). Disponível em 
<http://www.devmedia.com.br/introducao-ao-extreme-programming-xp/29249>. 
Acessado em ‎23‎ de ‎mar.‎ de ‎2015. 
 
Sueli Aparecida Loddi, Samáris Ramiro Pereira, Camila Casadei, Mariana Vieira 
Apolinário de Souza. Metodologias Ágeis: um exemplo de aplicação da eXtreme 
Programming (XP). Disponível em 
<http://www.fatecsaocaetano.edu.br/fascitech/index.php/fascitech/article/view/34>. 
Acessado em ‎23‎ de ‎mar.‎ de ‎2015. 
 
BECK. K. Extreme Programming Explained: enbrance change. Boston : Addison Wesley 
/Longman, 1999. 
 
JORGE, Fernandes. XP: eXtreme Programming Introdução. Disponível em 
<http://www.cic.unb.br/~jhcf/MyBooks/iess/XP/eXtremeProgrammingIntro.pdf>. 
Acessado em ‎23‎ de ‎mar.‎ de ‎2015. 
186 
REFERENCIAS 
JORGE, Fernandes. Programação em Pares. Disponível em 
<http://www.cic.unb.br/~jhcf/MyBooks/iess/PairProg/pai
rprogramming.pdf>. Acessado em ‎23‎ de ‎mar.‎ de ‎2015. 
 
JORGE H. C. FERNANDES. Diretório. Disponível em 
<http://www.cic.unb.br/~jhcf/>. Acessado em ‎23‎ de ‎mar.‎ 
de ‎2015. 
 
ASTELS, David; MILLER, Granville; NOVAK, Miroslav. 
Extreme Programming – Guia prático. Rio de Janeiro, Ed. 
Campos, 2002. 
187 
REFERENCIAS 
BECK, Kent. Programação Extrema (XP) Explicada. Porto 
Alegre:Bookman, 2004. 
 
BECK, Kent Exteme Programming Explained:Embrace change. Addison-
Wesley, 1999. 
 
SOMMERVILLE, Ian. Engenharia de software. 8ªed. São Paulo: Pearson, 
2007. 
 
Metodologia XP ( eXtreme Programming ) – Desenvolvimento Ágil 
Disponível em <http://hiperbytes.com.br/artigos/metodologia-xp-
extreme-programming-desenvolvimento-agil/>. Acessado em ‎23‎ 
de ‎mar.‎ de ‎2015. 
188 
REFERENCIAS 
SOUSA, Vinicius Lourenço de. Processo Unificado vs Ágil: Ser ou não ser, eis 
a questão. Disponível em 
<https://viniciuslourenco.wordpress.com/2008/08/06/processo-unificado-vs-
agil-ser-ou-nao-ser-eis-a-questao/>. Acessado em ‎23‎ de ‎mar.‎ de ‎2015. 
 
PRABHAKARAN, Prasad. Attempt to Compare Agile Methods. Mahindra 
Satyam. 2009. 
 
Extreme Programming (XP).Disponível em 
<http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de%20sistemas
/XP.pdf>. Acesso em 23 mar. 2014. 
189 
REFERENCIAS 
Daniel Ferreira. Comparativo entre Processos Ágeis - Seminário 
apresentado na disciplina de Gestão, Qualidade e Processos – 
CIn UFPE – Novembro/2012. 
 
Wikipédia. Processo unificado. Disponível em < 
http://pt.wikipedia.org/wiki/Processo_unificado>. Acessado 
em ‎23‎ de ‎mar.‎ de ‎2015. 
 
PROCESSO DE SOFTWARE: UM ESTUDO DE CASO EM XP 
.Disponível em < 
http://sedici.unlp.edu.ar/bitstream/handle/10915/22583/Docu
mento_completo.pdf?sequence=1>. Acesso em 23 mar. 2014. 
 
190 
REFERENCIAS 
LARA, Diego Trevisan. Michael Caiuta. Processo Unificado. Disponível em 
<http://www.inf.ufpr.br/lmperes/ciclos_vida/processo_unificado.pdf>. 
Acessado em ‎23‎ de ‎mar.‎ de ‎2015. 
 
ROCHA, Fabio Gomes. Integrando XP as principais metodologias agéis. 
Disponível em <http://www.devmedia.com.br/integrando-xp-as-principais-
metodologias-ageis/30989>. Acessado em ‎23‎ de ‎mar.‎ de ‎2015. 
 
BECK, Kent. et. al. MANIFESTO ÁGIL. 2001. Disponível em: 
<http://www.manifestoagil.com.br/>. Acesso em 23 mar. 2014. 
 
 
 
 
191 
REFERENCIAS 
TELES, Vinícius M. Um estudo de caso da adoção das 
práticas e valores do Extreme Programming. 181 p. 
Dissertação (Mestrado em Informática) – Universidade 
Federal do Rio de Janeiro, UFRJ, 2005. 
 
TELES, Vinícius M. Extreme Programming. São Paulo: 
Novatec Editora, 2004. 
192