Este artigo apresenta uma visão abrangente das metodologias ágeis, focando nos princípios e práticas do Extreme Programming (XP). Discute a evolução da engenharia de software e a necessidade de adaptação frente a mudanças, enfatizando a importância da comunicação e feedback constante. O XP é caracterizado por ciclos de desenvolvimento curtos, permitindo entregas frequentes e maior colaboração com o cliente.

1. Conhecendo o eXtreme Programming (XP)
Daniel de Freitas Wildt, Guilherme Silva de Lacerda
{dwildt,guilhermeslacerda}@gmail.com
Abstract. The main goal of this work is to show a comprehensive view of Agile
Methods, with emphasis in principles, values, and practices of eXtreme
Programming.
Resumo. O principal objetivo deste artigo é apresentar uma visão abrangente
das metodologias ágeis, com ênfase em princípios, valores e práticas do
eXtreme Programming.
1. Introdução
No final da década de 60, duas conferências organizadas pelo Comitê de Ciências da
OTAN1 foram responsáveis por um marco na história da computação: o nascimento do
termo “Engenharia de Software”. Um dos objetivos destas conferências era discutir os
problemas da indústria de software. O termo engenharia de software foi escolhido para
evidenciar a preocupação com a produção de software e a necessidade de basear a
produção em fundamentos teóricos e práticas conhecidas dos diversos ramos da
engenharia [Naur e Randell 1968].
A engenharia de software tem como objetivo viabilizar maior produtividade na
construção de aplicações e qualidade dos artefatos de software [Ghezzi, Jazayeri e
Madrioli 1991; Pressman 1995].
Diversos foram os modelos e processos que surgiram com tais perspectivas,
fornecendo descrições de como o software deveria ser criado e mantido [Ortigosa 1995].
De uma forma geral, estas descrições envolvem uma contínua produção e transformação
de notações, desde a especificação de requisitos até o código do software produzido.
O primeiro deles, conhecido como modelo Waterfall [Royce 1970], tinha como
premissa a grande ênfase em planejamento, assumindo que os requisitos não sofreriam
mudanças ao longo do projeto. Era baseado em ciclos seqüenciais onde cada etapa
dependia totalmente do término da etapa anterior, acarretando, dentre outros problemas,
o desânimo e impaciência do cliente. A figura 1 apresenta um gráfico sobre custo da
modificação em relação ao tempo de projeto [Beck 2004]. À medida que se avança nas
etapas de desenvolvimento e, caso sejam solicitadas mudanças, deve-se voltar para
etapas anteriores de planejamento para ajustar as atividades, tornando-a caras para
incluí-las e adaptá-las.
1
OTAN: Organização do Tratado do Atlântico Norte

2. Figura 1. Custos da modificação em relação às etapas do ciclo de vida [Beck
2004]
Outras abordagens também surgiram, dando ênfase em aspectos diversos da
construção de software, como construção de modelos formais, modelos evolucionários,
modelo espiral e incrementais/iterativos [Balzer 1981; Gilb 1981; Boehm 1986;
Jacobson, Rumbaugh e Booch 1999]. Embora exista cada vez mais a preocupação e
esforços para definir processos, métodos, técnicas e ferramentas para desenvolvimento
de software, não existe uma única solução ou “bala de prata” para todos os problemas
[Brooks 1987].
Mesmo assim, as estatísticas de falha em projetos de software ainda estão
presentes. No último Chaos Report2 [Standish Group 2009], somente 32% dos projetos
de software são considerados como entregues com sucesso, 24% falharam integralmente
e 44% não tiveram seus objetivos plenamente satisfeitos.
Estes dados comprovam que a atividade desenvolver software é complexa e que
envolve uma série de fatores técnicos e humanos, desde planejamento do projeto,
entendimento dos requisitos, construção e evolução do software até relacionamento e
comunicação do time e com clientes.
A ênfase em planejamento pleno do projeto, logo de início, tentando prever tudo
que poderá acontecer também é dos fatores que levam a aumentar estas estatísticas.
Tenta-se prever todas as atividades para poder definir as estimativas a priori. O maior
problema é que não se sabe exatamente o que será desenvolvido. À medida que se
aproxima da construção do software, a realidade do trabalho emerge, ficando mais claro
para se definir as estimativas [McConnell 1998]. A figura 2, denominada cone da
incerteza, apresenta esta relação, desde o planejamento até a conclusão do software. O
cone da incerteza mostra que a fase de viabilidade (visão do produto) e estimativas
iniciais pode variar de 25% a 400%. Isto representa que, caso o projeto tenha uma
previsão de 10 semanas de trabalho, esta estimativa pode variar de 2,5 semanas a 40
semanas.
2
Relatório publicado periodicamente pelo Standish Group International, sobre pesquisas relacionadas a
sucessos e fracassos de projetos de software.

3. Figura 2. Cone da Incerteza [McConnell 1998]
Nas abordagens mais tradicionais, como Waterfall (figura 3, a), as etapas de
desenvolvimento podem variar de meses chegando a anos, quando o software é entregue
ao cliente, em função de postergar ao máximo o desenvolvimento, dando ênfase maior
no planejamento. Desta forma, demora-se a obter o software e, nos casos atuais, o ROI3.
O lead time4 é gigantesco.
Figura X. Ciclos de vida Waterfall e Iterativo [Shore e Warden 2008]
No ciclo de vida iterativo (figura 3, b), o lead time é reduzido e assume-se que as
entregas ocorrerão de forma incremental. O cliente tem condições de fornecer feedback
mais freqüente. Com isso, o custo da mudança durante a construção é reduzido em
relação ao modelo Waterfall [Beck 2004].
3
ROI (Return on Investiment). Os softwares hoje são estratégicos para os negócios das empresas.
4
Tempo considerado entre o início de uma atividade e o seu término.

4. Figura 4. Custo da mudança em função do tempo em Processos Incrementais e
Iterativos [Beck 2004]
Em XP, principal assunto abordado neste trabalho, o objetivo é dividir as
iterações em menor escala, onde o planejamento é constantemente revisto e repriorizado
com o cliente, objetivando sempre entregar maior valor no software, aumentando o ROI.
Figura 5. Ciclo de vida do XP [Shore e Warden 2008]
Este artigo está organizado da seguinte forma: na seção 2 é apresentada uma
visão geral sobre as metodologias ágeis, seus valores, princípios e exemplos destas
abordagens; na seção 3, é apresentado o XP, sua origem, principais papéis e práticas; Ã
seguir, na seção 4, são apresentadas características de implementação do XP, com foco
em planejamento de releases, iterações e trabalho diário; Na seção 5, são apresentadas
algumas ferramentas que apóiam as práticas de XP e, finalmente na seção 6, é
apresentada dicas de adaptação das práticas em contextos difíceis para a adoção de
metodologias ágeis.
2. Metodologias Ágeis
Na década de 90, alguns profissionais da indústria de software propuseram novos
processos e metodologias para desenvolvimento de software, adequados para lidar com
aspectos humanos dos projetos de software.
Em fevereiro de 2001, em Utah, 17 profissionais experientes (consultores,
desenvolvedores e líderes) da comunidade de software se reuniram para discutir
alternativas aos processos e práticas burocráticas utilizadas nas abordagens tradicionais
de Engenharia de Software e Gerência de Projetos. Assim nasceu o Manifesto Ágil
[Beck et al 2001], que destaca as diferenças em relação as abordagens tradicionais. No
quadro 1, é apresentado um trecho do manifesto ágil, que define os seus principais
valores.

5. A principal diferença das metodologias ágeis em relação às metodologias
tradicionais é o enfoque na adaptação, visando ter o mínimo necessário5 para a
realização do trabalho. Com esta estratégia, busca-se aceitar e trabalhar a mudança,
reduzindo custos de implementação [Highsmith e Cockburn 2001].
Quadro 1. Trecho do Manifesto Ágil (tradução livre de [Beck et al 2001])
“Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a
fazê-lo. Através desse trabalho, passamos a valorizar:
1. Indivíduos e interação MAIS QUE processos e ferramentas;
2. Software em funcionamento MAIS QUE documentação abrangente;
3. Colaboração com o cliente MAIS QUE negociação de contratos;
4. Responder a mudanças MAIS QUE seguir um plano.
Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.”
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve
Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Além dos valores, o Manifesto Ágil também apresenta 12 princípios que ajudam
na promoção de suas idéias [Beck et al 2001]. Estes princípios são descritos a seguir:
1. A maior prioridade é a satisfação do cliente por meio da entrega rápida e
contínua de software que agregue valor;
2. Mudanças nos requisitos são aceitas, mesmo em estágios avançados de
desenvolvimento. Processos ágeis aceitam mudanças que trarão vantagens
competitivas para o cliente;
3. Entregue software em funcionamento frequentemente, em períodos de poucas
semanas a poucos meses, com preferência para a menor escala de tempo;
4. As pessoas relacionadas ao negócio e os desenvolvedores devem trabalhar
juntos no dia a dia do projeto;
5. Desenvolva projetos com indivíduos motivados, fornecendo ambiente e o
suporte necessário e confiando que realizarão o trabalho;
6. A forma mais eficiente e eficaz de transmitir informações dentro e fora do
time de desenvolvimento é a comunicação face a face;
7. A principal medida de progresso é software funcionando;
8. Processos ágeis promovem o desenvolvimento em ritmo sustentável. Os
investidores, desenvolvedores e usuários devem ser capazes de manter este
ritmo constante;
9. Cuidar continuamente da excelência técnica e do bom design ajuda a
aprimorar a agilidade;
5
barelly suficient

6. 10. Simplicidade – a arte de maximizar a quantidade de trabalho não necessário -
é essencial;
11. Os melhores requisitos, arquiteturas e design surgem de equipes auto-
organizadas, e;
12. Em intervalos regulares, o time reflete sobre como se tornar mais eficiente,
refinando e ajustando seu comportamento.
Esses princípios, se entendidos pelo cliente e pelo time, promovem uma
mudança de atitude [Smith e Sidky 2009]. O cliente consegue enxergar valor mais
rapidamente nas entregas freqüentes do software e, à medida que visualiza a solução,
consegue refletir sobre alternativas e prioridades. O time trabalha mais motivado,
porque consegue enxergar valor no seu trabalho que, através de feedback constante,
evolui continuamente. Essa relação aumenta para ambos, pois a confiança se faz cada
vez mais presente. Na figura 6, é mostrado o fluxo de valor das abordagens ágeis,
partindo da visão do produto, construção até a entrega implantação incremental deste
produto. Uma das práticas presentes neste fluxo é o constante aprendizado e a troca de
conhecimento do time com o cliente.
Figura 6. Fluxo de Valor (adaptado de [Shalloway e Trott 2009])
Com base nestes valores e princípios, aparecem abordagens mais específicas,
algumas com focos diferentes, mas com o mesmo núcleo. A seguir, são apresentados
exemplos destas abordagens.
2.1. Lean Software Development
O Sistema Toyota de Produção (STP) revolucionou a indústria da manufatura, desde
geração de valor para o cliente quanto à satisfação de trabalho para o time [Ohno 1998;
Liker 2004]. Estes princípios serviram de base para Mary e Tom Poppendieck identificar
semelhanças entre estes princípios e valores com o desenvolvimento de software. Com
base nestes pensamentos, foram identificados sete princípios para o desenvolvimento de
software. Estes princípios são: 1) eliminar desperdícios; 2) incluir qualidade no
processo; 3) criar conhecimento; 4) adiar comprometimentos; 5) entregar rápido; 6)
respeitar as pessoas e, 7) otimizar o todo [Poppendieck e Poppendieck 2003;
Poppendieck e Poppendieck 2005].

7. 2.2. Scrum
O Scrum surgiu na década de 90, criado por Ken Schwaber, Jeff Shuterland e Mike
Beedle [Schwaber 2004; Schwaber e Beedle 2001]. Seu principal objetivo é prover um
framework para gerenciamento de projetos, onde, a partir de um backlog inicial,
prioriza-se o trabalho que será realizado na iteração (denominado sprint), gerando um
potencial produto no final de cada ciclo. Este trabalho é desenvolvido com
acompanhamento diários (daily scrum meetings) e de final de sprint (sprint
retrospective), com o objetivo de reduzir riscos e promover a melhoria contínua. Por
mais dar ênfase no gerenciamento de atividades e tarefas, o Scrum pode ser utilizado em
conjunto com outros métodos e processos, que dão ênfase na engenharia, como XP. Na
figura 7, é apresentado o fluxo do Scrum.
Figura 7. Fluxo do Scrum [Hunt 2006]
2.3. Familia Crystal
A família Crystal é um conjunto de metodologias criadas por Alistair Cockburn para
equipes de tamanhos diferentes [Cockburn 2004]. Os primeiros trabalhos e estudos
sobre esta metodologia foi cunhado na IBM, em meados de 1990. A partir das
características dos projetos, se escolhe a mais apropriada. No Crystal, as metodologias
compartilham alguns princípios como entrega incremental em períodos de tempo, testes
funcionais e de regressão, revisões e workshops de produto. Um outro ponto forte que se
deve ter em mente, abordado por Cockburn, é a utilização do mínimo necessário para
alcançar o sucesso no projeto.
2.4. Adaptive Software Development (ASD)
Segundo [Highsmith 1997], o principal objetivo do ASD é identificar a natureza
adaptativa dos projetos de software, tratando as incertezas que são inerentes a esta
natureza. Para isso, Jim Highsmith baseou seus estudos na teoria de Sistemas
Adaptativos Complexos e na Teoria do Caos. O ASD é dividido em fases que se

8. sobrepõem: especulação, colaboração e aprendizado. Na figura 8, é apresentado o ciclo
de fases do ASD.
Figura 8. Fases do ASD [Highsmith 2000]
Através de iterações curtas, a equipe cria o conhecimento através do uso de
prototipações. No final de cada ciclo, ocorrem reuniões e revisões em grupo.
2.5. Dynamic System Development Method (DSDM)
O DSDM foi criado em 1994, desenvolvido por um consórcio de empresas britânicas. É
baseado nas melhores práticas do RAD6 [Martin 1991] e no modelo incremental e
iterativo. O DSDM inicia com fases de análise de viabilidade de descrição do negócio.
Nas fases de construção (modelagem/design/implementação) são realizados ciclos
iterativos de desenvolvimento. O DSDM tem como princípios a participação ativa do
cliente, entregas freqüentes, times com poder de decisão e testes durante o ciclo de vida
do produto [Stapleton 1997].
A figura 9 apresenta o fluxo do DSDM.
Figura 9. Fases e Processos do DSDM [Hunt 2006]
6
Rapid Application Development

9. 2.6. Feature Driven Development (FDD)
A FDD foi criada por Jeff De Luca e Peter Coad [Palmer e Felsing 2002]. É um
processo de software baseado em curtas iterações, definindo duas fases:
Concepção/Planejamento e Construção. Dentro da fase de Concepção/Planejamento,
existem os processos de criação de um modelo abrangente, que serve de base para a
criação da lista de features. Com base nesta lista, é que é realizado o planejamento.
Na fase de construção, estas features serão detalhadas e construídas. A figura 10
representa as fases e os processos da FDD.
Figura 10. Fases e Processos do FDD [Hunt 2006]
Neste projeto é que surgiu a idéia de utilizar modelos UML em cores, para
representar classes com diferentes responsabilidades, denominados arquétipos [Coad,
Luca e Lefebvre 1999].
O eXtreme Programming, principal objeto de estudo deste trabalho, será
apresentado com mais detalhes nas próximas seções.
3. eXtreme Programming (XP)
Segundo [Beck 2004; Cunningham 2002], eXtreme Programming (XP) é uma disciplina
de desenvolvimento de software voltada para pequenas e médias equipes, onde os
requisitos são vagos e mudam freqüentemente. Desenvolvido por Kent Beck, Ward
Cunningham e Ron Jeffries, o XP tem como principal tarefa a codificação, com ênfase

10. menor nos processos formais de desenvolvimento, com uma maior disciplina de
codificação e testes. Tem como valores a comunicação, simplicidade, feedback e
coragem.
A comunicação é essencial em projetos de software. É a principal forma de se
transmitir e trocar informações e conhecimentos do projeto. Por esta razão, é importante
incentivar meios eficazes de comunicação. A comunicação está presente no Manifesto
Ágil [Beck et al 2001] e na maioria das práticas de XP [Beck 2004]. Na figura 11, é
apresentado um gráfico que representa ferramentas de comunicação e sua efetividade. À
medida que se aproxima dos membros do time (pessoas), mais rica é a comunicação. Da
mesma forma, quanto mais se afasta das pessoas, mais ruídos e barreiras surgem.
Figura 11. Riqueza dos Canais de Comunicação [Ambler 2005]
A comunicação incentiva diretamente outro valor, essencial em XP: o feedback.
Na adoção das práticas, o feedback é realizado a todo momento, seja em relação a
requisitos do cliente, seja em relação ao resultado da execução de testes unitários, seja
na compilação do código. A compreensão das necessidades dos usuários e do negócio
propriamente dito é um aprendizado contínuo. Segundo [Cockburn 2002], a razão de
adotar estratégias incrementais e iterativas é permitir que os inevitáveis erros das
pessoas sejam descobertos o mais cedo possível e reparados de forma metódica.
A simplicidade é outro valor presente nas práticas XP. É a diretriz de um projeto
ágil. A simplicidade visa manter o trabalho o mais simples e focado possível,
entregando o que realmente agrega valor [Poppendieck e Poppendieck 2003]. Conforme
[Boehm e Turner 2003], acrescentar suporte para futuras funcionalidades de forma
desnecessária complica o design e eleva o esforço de para desenvolver incrementos
subseqüentes.
A coragem também é incentivada através do uso das práticas. O desenvolvedor
só sentirá confiança em alterar o código de outro colega se conhecer o padrão de
codificação, por exemplo. Além desta prática, o uso de controle de versão e testes
unitários também encorajam tal investida. Segundo [Beck e Fowler 2000], além destes
medos naturais de alteração de código, tem-se uma série de medos que exercem
influência nos processos de desenvolvimento. Os clientes temem: a) não obter o que

11. pediram; b) pedir a coisa errada; c) pagar de mais por muito pouco; d) jamais ver um
plano relevante; e) não saber o que está acontecendo e, f) aterem-se nas primeiras
decisões de projeto e não serem capazes de reagir à mudança dos negócios. O time de
desenvolvimento teme: a) ser solicitados a fazer mais do que sabem fazer; b) ser
ordenados a fazer coisas que não façam sentido; c) ficar defasados tecnicamente; d)
receber responsabilidades, sem autoridade; e) não receber definições claras sobre o que
precisa ser feito; f) sacrificar a qualidade em função do prazo; g) resolver problemas
complexos sem ajuda e, h) não ter tempo suficiente para fazer um bom trabalho [Beck e
Fowler 2000].
O XP valoriza a criação e automação dos testes, sendo criados antes, durante e
depois da codificação. É flexível a mudanças de requisitos, valorizando o feedback com
o usuário e a qualidade do código fonte final [Astels, Miller e Novak 2002].
A idéia principal do XP é a criação de software de alta qualidade, abandonando
todo tipo de overhead de processo que não suporte diretamente esse objetivo. A XP é
orientada explicitamente a pessoas e vai contra o senso comum do gerenciamento de
que as pessoas são peças intercambiáveis dentro do processo de desenvolvimento.
3.1. Origens do XP
Os principais fundamentos de XP tiveram origem na década de 80, nas raízes do
desenvolvimento em Smalltalk [Cunningham 2008]. Nesta época, Kent Beck e Ward
Cunningham trabalhavam na Tektronixs. Os projetos realizados nesta época serviram de
laboratório para que fossem aperfeiçoadas práticas como refactoring, programação em
pares, mudanças rápidas, feedback constante do cliente, desenvolvimento iterativo,
testes frequentes. Neste período, também surgiram importantes contribuições, como a
tese de doutorado de Bill Opdyke [Opdyke 1992], sobre técnicas de refactoring que
Beck e Cunningham já usavam na indústria.
Em 1996, todas as práticas criadas e experimentadas ao longo de anos realmente
se fundiram [Anderson et al 1998]. Foi em um projeto da Daimler Chrysler,
denominado Chrysler Comprehensive Compensation (C3). O C3 era o projeto de folha
de pagamento da Companhia. Na época, Beck trabalhava como consultor para
problemas de desempenho em Smalltalk. Neste mesmo ano, Beck publicou um livro
com relevantes contribuições, que apresentava excelentes técnicas de desenvolvimento
nesta tecnologia [Beck 1996]. Sue Unger, CIO da Chrysler, entrou em contato com Beck
para fazer uma análise do projeto.
Após um período trabalhando com a equipe, Beck apresentou um relatório para a
diretora com a descrição dos problemas, desde problemas contratuais até problemas de
ambiente. As alternativas eram: a) deixar as coisas como estavam; b) cancelar o projeto
e, c) dar folga para a equipe e começar do zero. Unger escolheu a última opção e
colocou Beck a frente do time. A primeira medida do Beck perante o time foi dar folga
para o pessoal. Assim, o time pode recuperar o ânimo para começar uma nova etapa.
Beck realizou entrevistou os 20 membros do time individualmente, explicando
como funcionaria o processo de trabalho. Para cada um dos membros, ele explicava uma
prática. Nasceu, desta forma, as práticas de XP [Anderson et al 1998].

12. 3.2. Papéis
Os papéis de um time XP são formados por uma variedade de pessoas, com
características e habilidades necessárias para o sucesso do projeto. Em geral, os papéis
não variam muito em relação ao de outros processos e metodologias. A seguir, são
apresentados alguns destes papéis [Astels, Miller e Novak 2002]:
• Dono do Ouro: É o cliente que paga pelo desenvolvimento do projeto;
• Usuário/Cliente: Define os requisitos do software e utiliza o produto final e
executam os testes de aceitação;
• Gerente: Gerencia e acompanha o planejamento do projeto;
• Coach: É o técnico do time. Orienta o time, mantendo a disciplina na aplicação
das práticas que são padrões da equipe;
• Testadores: Ajudam os clientes com a definição dos testes. Realizam os testes do
sistema;
• Desenvolvedores: Definem a arquitetura, realizam estimativas e implementa o
código;
• Tracker: Responsável por coletar as métricas de projeto. O tracker é capaz de
contar uma história da iteração ao final da mesma, através dos apontamentos que
realizou e das informações que foram coletadas;
• Analistas: Ajudam o cliente na definição dos requisitos.
Existem variações e diferentes referências sobre os papéis em XP. Estes papéis
até podem ser acumulados por mais de uma pessoa dentro do time, porém deve tomar
certos cuidados [Cunningham 2006].
3.3. Práticas
O funcionamento do XP é baseado em um conjunto de valores e práticas. As práticas do
XP são divididas organizacionais (círculo vermelho), equipe (círculo verde) e
individuais (círculo azul), conforme figura 12.
Figura 12. Práticas XP [Jeffries 2000]

13. As práticas são descritas a seguir:
• Equipe (Whole Team): todos em um projeto XP são partes da equipe, integrando
os clientes à equipe de desenvolvimento. É importante salientar que um membro
da equipe pode assumir mais de um papel. Os papéis foram abordados com mais
detalhes na seção 3.1;
• Clientes no Local (Client on Site): Para total funcionamento do XP, é necessário
que o cliente se integre à equipe de desenvolvimento;
• Jogo do Planejamento (Planning Game): São definidas estimativas e prioridades.
Ótimo feedback para que cliente possa dirigir o projeto, podendo-se ter uma
idéia clara do avanço do projeto minimizando os riscos. Nesta prática é onde são
definidas as histórias que descrevem as funcionalidades a serem implementadas;
• Testes de Aceitação (Customer Tests): São testes elaborados pelo cliente, sendo
os critérios de aceitação do software. Devem ser rodados a cada interação futura.
Oferecem feedback do desenvolvimento da aplicação;
• Pequenas entregas (Small Releases): Disponibiliza a cada interação o software
100% funcional. Desta forma, é disponibilizado pequenas versões para que o
cliente possa obter o seu ganho o mais cedo possível, minimizando os riscos;
• Posse Coletiva (Collective Ownership): Em um projeto XP, qualquer dupla de
programadores pode melhorar o software a qualquer momento. O código tem um
único dono: a equipe. Todos compartilham a responsabilidade pelas alterações;
• Integração Contínua (Continuous Integration): XP mantém o projeto integrado
continuamente, expondo o estado atual de desenvolvimento (viabiliza
lançamentos pequenos e frequentes), oferencendo um feedback sobre todo o
sistema, em qualquer etapa do processo;
• Metáfora (Metaphor): A equipe mantém uma visão compartilhada do
funcionamento do software. Serve de base para estabelecimento dos padrões de
codificação e da forma de comunicação com o cliente. Uma metáfora deve
funcionar como uma forma de comunicação comum entre equipe e cliente. Em
se tratando da metáfora do software, é entender o que precisa ser desenvolvido,
entender a visão do produto que está sendo construindo;
• Ritmo Saudável (Sustainable Pace): Os projetos XP procuram obter a maior
produtividade dos programadores e entregar o software na melhor qualidade
possível, obtendo a satisfação do cliente. Para isso há uma grande preocupação
com o cronograma. Definir um número de horas de trabalho, que gerem um
ritmo sustentável na equipe, exemplo de uma semana de 40 horas, é fundamental
para o maior rendimento da equipe;
• Padrões de Codificação (Coding Standards): Todo o código escrito segue o
padrão definido pela equipe, facilitando a comunicação e refinamento do design;
• Testes (Test-Driven Development): Todo o desenvolvimento XP é guiado por
testes. Os testes dão segurança necessária para garantir a qualidade de forma
contínua, dão coragem para mudar. Os testes são a base do feedback do código

14. para o programador. Os testes dão ritmo ao desenvolvimento, porque o código a
ser desenvolvido é o código para fazer um determinado teste passar;
• Programação em Pares (Pair Programming): Todo o desenvolvimento é feito em
pares, obtendo uma melhor qualidade do design, código e testes, uma revisão
constante do código e uma maior comunicação;
• Design Simples (Simple Design): O código está, a qualquer momento, na forma
mais simples para a realização dos testes. Esta prática está presente em todas as
outras etapas do XP.
• Refinamento (Refactoring): O design é melhorado continuamente através do
refinamento. Em XP, o código é o próprio design. O refinamento é um processo
formal realizado através de etapas reversíveis, melhorando a estrutura do código
sem alterar sua função [Fowler 1999]. O refinamento do código deve ser feito
sempre após um teste que passa. Isto dá liberdade ao desenvolvedor de modificar
o código fonte, pois sabe que os testes devem continuar passando. Se um teste
passa a falhar, alguma coisa na lógica da aplicação foi alterada e precisa ser
revista;
• Reuniões em Pé (Stand Up Meetings): Além das cerimônias de planejamento de
release e iterações, XP possuem uma prática que ajuda a expor para o time como
está o desenvolvimento das tarefas. Nestas reuniões, é exposto o andamento do
trabalho (o que se fez ontem, o que está sendo feito, quais são os problemas), de
forma que o time possa avaliar as dificuldades e analisar possíveis soluções.
• Spikes de Planejamento (Spikes Solution): Muitas vezes, nos projetos, é
necessário fazer investigações e avaliações de tecnologias que serão
incorporados no desenvolvimento [Wells 2001a]. Estas investigações são
chamadas de spikes. Os spikes forçam que, em um momento apropriado e
necessário, seja realizada uma análise de recursos tecnológicos (em geral,
ferramentas, frameworks, APIs7) para inclusão nas tecnologias usadas no
projeto. Os spikes de planejamento ajudam o time a gerar o conhecimento
necessário para que possam estimar novas funcionalidades a serem
desenvolvidas no projeto.
4. Implementando eXtreme Programming
Nesta seção, é descrito o uso de práticas XP para definição de planejamento do projeto,
releases, iterações. Também é apresentado como funciona o trabalho diário em um time
XP.
4.1. Ciclo de Trabalho
O ciclo de trabalho em XP é dividido em fases, conforme mostrado na figura 13.
7
Application Programming Interface

15. Figura 13. Ciclo de vida de um Projeto XP [Wells 2001a]
Na fase de exploração, são definidos as user stories iniciais e o rascunho da
arquitetura. Do ponto de vista de requisitos, é interessante detalhá-los de forma que se
tenha uma visão suficiente para começar o projeto, com uma definição básica para as
estimativas [Beck 2004]. À medida que se avança em etapas posteriores de
planejamento, as user stories são priorizadas e mais detalhadas. Outro ponto tratado
nesta fase é o spike de arquitetura. A arquitetura é tratada em XP como algo primordial e
que evolui naturalmente com as iterações. Para que esta evolução seja tranqüila, é
importante o conhecimento e uso de patterns. Em [Ambler 2004a], o assunto de
modelagem de arquitetura é explorado com mais detalhes, como propósitos, diagramas
para modelagem, ferramentas e estatísticas de adoção desta abordagem. O principal
objetivo desta fase é a redução de riscos, tanto de planejamento, quanto de
desenvolvimento.
Na fase de planejamento, os requisitos são detalhados para compor o plano de
release. Este trabalho é realizado durante a reunião de planejamento de release. Neste
plano, são definidos com maiores detalhes os requisitos do software. Os requisitos
técnicos também são explorados, de forma que, caso se tenha alguma dúvida de
implementação, é possível fazer uso de spikes [Wells 2001a]. O principal objetivo desta
fase é definir o plano do produto de software e a definição das entregas, ocorrendo o
mais cedo possível [Beck e Fowler 2000]. Esta é a base para o planejamento das
iterações. Na figura 14, é apresentada uma lista de requisitos (potenciais user stories),
onde são analisados diferentes aspectos como prioridade, volatilidade técnica e de
requisitos, acesso e dependências. Ela servirá de base para a elaboração dos planos de
iterações.
Figura 14. Exemplo de uma lista de requisitos, com atributos classificatórios
A fase de iterações é onde o trabalho será realmente realizado. O tamanho das
iterações são diferentes de time para time, podendo variar de 1 a 3 semanas [Wells
2001a]. Nesta fase, o plano de release serve de base para o trabalho e as user stories
planejadas para a iteração atual são exploradas e detalhadas [Beck e Fowler 2000]. Caso
não seja a primeira iteração, além do plano de release, informações como problemas

16. reportados e project velocity8 da iteração anterior também são considerados para o
planejamento atual. Com base neste plano de iteração, é que o time realiza o trabalho
diário de construção. A cada dia, é realizado o stand up meeting para que o trabalho
realizado seja exposto para o time. O tracker coleta métricas diárias e as expõe para o
time. No final da iteração, o time realiza uma avaliação da iteração, promovendo a
melhoria para a iteração posterior. O principal objetivo desta fase é a construção do
software, baseado em um planejamento incremental. Uma versão do produto é
disponibilizada. A figura 15 apresenta o fluxo de uma iteração em XP.
Figura 15. Ciclo de Iteração XP [Wells 2001a]
A fase de produção é caracterizada pela realização dos testes de aceitação e o
lançamento do produto para produção. Esta é a principal característica desta fase, o
pequeno incremento do produto, com objetivo de colocá-lo mais cedo possível em
produção [Beck 2004]. Assim, o cliente terá a real noção da evolução do produto e
poderá dar também um feedback mais fidedigno sobre o trabalho realizado.
Nas metodologias ágeis e, em especial o XP, as fases de planejamento de
release, iterações e produção estão inseridas em uma fase maior, a fase de manutenção
[Beck 2004]. O [SWEBoK 2004] aborda diferentes categorias de manutenção, de
origem reativa (correção) e pró-ativa (aprimoramento). Essa abordagem de não separar o
desenvolvimento da manutenção e entender que o software evolui continuamente é uma
característica de XP. Esta evolução é tratada de forma natural, através das práticas em
promover pequenos planejamentos (release, iterações), implementando poucas
funcionalidades e entregando software mais rapidamente. Com isso, o cliente consegue
dar um feedback mais rápido, pois são menos funcionalidades a testar e validar. Como o
feedback é mais rápido, se consegue rever o planejamento do trabalho a ponto de
realizar mudanças, se necessário.
4.2. Planejamento de Projeto
Em XP, o planejamento de projeto é encarado como um jogo, onde o adversário é
entregar software de qualidade, dentro do prazo e custo estimados [Beck 2004]. O
cliente é parte primordial do planejamento, participando da priorização dos requisitos,
detalhando-os junto com os analistas em formato de user stories e tarefas. O principal
foco do planejamento é a priorização, baseados em risco e maior valor para o negócio.
Na figura 16, é apresentada esta relação de risco e valor.
8
Project Velocity é uma métrica utilizada para representar o esforço de trabalho realizado na iteração
(planejado X construído). Está métrica é usada para planejar futuras iterações.

17. Figura 16. Priorização com base em risco e valor (adaptado de [Cohn 2005])
Existem requisitos que são de alto risco de implementação e baixo valor de
negócio9. Estes devem ser evitados. O time se concentra no que realmente é importante
(maior valor) e maior risco para o negócio e de implementação. Assim, o problema é
tratado sempre com maior prioridade [Wake 2000]. A principal intenção é, além de
agregar mais valor rapidamente para o software, evitar desperdícios. Na figura 17, é
apresentada a ordem de implementação dos requisitos. Com base nestas premissas, a
implementação dos requisitos de maior prioridade são essenciais para agregar valor ao
produto. Este exercício de repriorização é realizado no inicio de cada iteração. Para a
priorização, usa-se o feedback da iteração anterior juntamente com o planejamento
definido para a iteração atual.
Figura 17. Ordem de implementação dos requisitos (adaptado de [Cohn 2005])
Na figura 18, apresenta-se a forma de priorização, onde sempre tem-se os
requisitos mais importantes para negócio no topo da pilha. Este é um exercício comum
do time com o cliente, avaliando a importância do será implementado.
9
Algo que não agrega valor, que não foi planejado e que foi implementado é chamado de Gold Plating.
Mais informações podem ser obtidas em [Wiegers 2003]

18. Figura 18. Troca de prioridade dos itens planejados [Ambler 2007]
4.3. Escrevendo User Stories
Os requisitos são registrados no formato de user stories. As user stories tem o mesmo
propósito dos casos de uso, porém escritos de forma mais curta e enxuta, levando em
consideração a perspectiva do usuário [Cohn 2004]. Segundo [Jeffries 2001], as user
stories devem ser escritas, com base nas propriedades 3Cs (Card, Conversation e
Confirmation). No quadro 2, é apresentado as propriedades 3Cs.
Quadro 2. Propriedades de uma User Story [Jeffries 2001]
Propriedade Significado
Card As user stories são registradas em cartões. Existe um fator
psicológico em relação ao tamanho do é passado para o usuário
registrar a user story. Se o tamanho do cartão for pequeno, o
usuário tem que se concentrar no que realmente é importante na
user story.
Conversation Assim como os casos de uso, as user stories são escritas em
formato de narrativa, sob a perspectiva da persona, levando em
consideração a descrição da funcionalidade e o
propósito/benefício.
Confirmation Para as user stories, é necessário definir os critérios de aceitação.
Estes critérios servirão de base para a descrição dos testes de
aceitação.
Nas user stories, são registradas funcionalidades de valor para o cliente, podendo
ser escritas informalmente ou mais estruturadas seguindo um template. Segundo [Wake
2003], uma boa prática para o time na escrita de user stories é levar em consideração
das características desejáveis INVEST. No quadro 3, é apresentado especificamente
cada uma das características desejáveis.

19. Quadro 3. Características desejáveis para User Story [Wake 2003]
Característica Significado
Independent Deve ser independente, para facilitar negociação, priorização e
implementação
Negotiable Deve ser negociável, para facilitar a priorização. Deve capturar a
essência e não os detalhes
Valueable Deve agregar valor
Estimable Uma boa user story é que pode se definir uma estimativa. Não
precisa ser exata, mas boa o bastante para se levar em conta no
planejamento
Small Deve ser pequena. User stories pequenas facilitam a
implementação e o processo de estimativas
Testable Deve permitir a realização de testes. Se não foi possível definir
um teste para esta user story, deve-se rever seu propósito e escrita
Na figura 19, são apresentadas dois exemplos de user stories escritas sem o uso
do template.
Figura 19. Exemplos de User Stories [Cohn 2004]
No quadro 4, é apresentado um exemplo de template onde é identificado os
componentes de uma user story. A persona representa um tipo de usuário que interage
com o sistema [Cooper 2003]. A principal diferença entre atores e personas é que as
personas são instâncias de um tipo de usuário/papel (ator), tentando analisar seu
contexto no mundo real. Para as personas, são definidas as funcionalidades e seu
propósito.
Quadro 4. Template de User Story [Cohn 2004]
As (Como) <persona>
I can (Posso) <funcionalidade>
So that (Pois assim) <benefício>
Dentro destes elementos das user stories, é possível reconhecer questões chaves
como: “Quem é afetado pelo requisito? O que deve ser implementado? Por quê?” Estes
questionamentos estão atrelados aos critérios de aceitação, algo fundamental na escrita
da user story. Quando um requisito é definido, os critérios de aceitação devem estar
presentes. É uma forma de comprovação da user story.

20. No quadro 5, é apresentado um exemplo prático da escrita de user story,
incluindo os testes de aceitação, baseadas no Behavior Driven Development (BDD)10.
Quadro 5. Exemplo de User Story com BDD
Sendo uma pessoa que precisa de crédito
Posso acessar o simulador de crédito ACME
Pois assim saberei das opções que tenho para requisitar.
Dado que sou um usuário do site de simulação de crédito
Quando peço uma simulação de crédito abaixo de R$500
Então o máximo de parcelas que poderei parcelar serão de 5
Dado que sou um estagiário
Quando peço R$500 e tenho renda de R$800 e indico parcelamento em 4 vezes
Então o Sistema vai negar o empréstimo indicando que tenho acesso apenas a 60% da minha renda, ou seja,
R$480
4.4. Dia a dia em um time XP
O trabalho diário de um time XP é baseado no plano de iteração [Wells 2001a]. Todo o
dia é realizado o stand up meeting, com o objetivo de expor o trabalho individual para o
time, suas dificuldades e como estão sendo resolvidos os problemas. Nestas atividades,
estão previstas atividades de programação em pares e integração contínua por parte do
time. Esta última dita a junção dos componentes de software produzidos pelos pares,
sendo realizada várias vezes ao dia. Na figura 20, é apresentado o ciclo de
desenvolvimento diário em XP.
Figura 20. Ciclo de Desenvolvimento diário [Wells 2001a]
Em [Wake 2000], é apresentado uma visão alternativa do trabalho diário. Nesta
outra visão, o design inicial é algo explorado, que servirá de base para a implementação.
Todo o trabalho é realizado em pares, desde análise, projeto, codificação e testes. Dentro
deste contexto, o uso de práticas de modelagem ágil [Ambler 2004b] se torna
primordial. A figura 21 descreve as atividades diárias de um desenvolvedor XP.
10
Mais informações sobre BDD em http://blog.dannorth.net/introducing-bdd/

21. Figura 21. Atividades diárias de um desenvolvedor XP [Wake 2000]
No trabalho diário vale destacar que a prática de programação em pares pode ser
utilizada no formato de sessões. Desta forma, user stories mais complexas e que exijam
mais revisões pode ser candidatas para a prática em sessão. Mais importante que adotar
a prática de programação em pares é promover a rotação entre estes pares11. Além de
disseminar o conhecimento do projeto para o time, mantém a simplicidade nas
atividades, maximizando o valor entregue no software.
5. Ferramentas de Apoio
Para apoiar a adoção dos princípios, valores e práticas do XP, existem uma série de
ferramentas que podem ser utilizadas nos projetos de software. Nesta seção, apresenta-
se duas categorias: hard tools, que são as ferramentas mais simples, relacionadas com o
ambiente e as soft tools, que são as ferramentas de software que apóiam as práticas.
Além das ferramentas, as métricas são outro recurso muito utilizado para acompanhar o
desenvolvimento do trabalho em XP.
5.1. Ambiente e Hard Tools
O ambiente é essencial para apoiar as práticas, tanto de gerenciamento quando de
construção. Para isso, é necessário adequá-lo para as necessidades de um time ágil. Para
adequá-lo, pode-se utilizar uma série de gráficos de acompanhamento, murais e quadros
tornando o ambiente informativo12 [Shore e Warden 2008]. A figura 22 apresenta um
layout de sala para um time ágil.
11
Prática que não está presente no círculo de práticas de XP, mas que tem enorme valor. Também
conhecida como Move People Around. Mais informações em [Wells 2001b]
12
Existem dois termos utilizados para representar o ambiente informativo em times ágeis: Big Visible
Charts (Ron Jeffries) e Information Radiator (Alistair Cockburn).

22. Figura 22. Ambiente de trabalho para um time XP [Shore e Warden 2008]
Este ambiente é propício para postar informações de andamento do projeto,
fazendo com o que o time visualize estes resultados de forma mais simples e rápida. O
ambiente fornece mecanismos para que a comunicação, um dos valores do XP, esteja
sempre presente.
Os quadros e murais expostos para time são melhores que sites na Web ou
planilhas eletrônicas dentro das estações de trabalho [Jeffries 2004a]. Nestas
ferramentas, a informação não está exposta para o time, os membros do time têm que
buscá-las. Com quadros e murais, estão sempre disponíveis para o time, sempre visíveis.
Segundo [Jeffries 2004a], é interessante usar planilhas e wikis como forma de registro,
porém é necessário criar mecanismos para que a informação fique sempre disponível
para o time. Por exemplo, um dos gráficos utilizados, é a quantidade de testes de
aceitação existentes, para cada período de tempo (dia, semana, iteração), apresentados
na figura 23.
É possível ver a evolução e verificar se algo não está indo não está bem [Jeffries
2004a]. Utilizando gráficos como ferramentas de acompanhamento, é possível
identificar certos padrões. Estes padrões podem indicar informações relevantes para o
time, entre elas como descobrir sua própria velocidade de produção. Outros gráficos
muito usados por times ágeis são os gráficos de burndown e burnup [Cockburn 2005]. O
primeiro (burndown chart) é relacionado com a queima de horas da iteração, onde em
cada período de trabalho marca-se quanto já foi realizado. Assim, é possível projetar as
próximas iterações com base no trabalho feito, fazendo-se uma projeção se será possível
entregar no prazo. O segundo, é relacionado com a implementação das tarefas e em
relação ao que foi planejado. Também é possível analisar neste gráfico o valor agregado
para o produto (figura 24).

23. Figura 23. Gráficos do uso de testes de aceitação (o da esquerda, evoluindo
naturalmente e o da direita com testes que não estão passando) [Jeffries 2004a]
Figura 24. Gráficos de Burndown e Burnup [Silver 2008]
Além dos gráficos, um time ágil utiliza quadros para execução e
acompanhamento do trabalho do time. Nestes quadros, é possível verificar o trabalho
que está planejado, os que estão em andamento e os que já estão prontos. Estes quadros
são também conhecidos como quadros de Kanban13 [Kniberg e Skarin 2009]. Existem
variações de quadros, que podem estar relacionados ao time ou natureza do projeto.
Estas variações é que vão indicar os tipos de quadros que serão utilizados e que seções
serão criadas. O quadro pode conter seções para exposição de marcos de entrega de
releases, mural de recados, mural de lembretes, classificação de requisitos, exposição de
gráficos de acompanhamento, métricas sobre o andamento do trabalho, entre outros.
O objetivo do ambiente visual é que não é somente o time que visualiza o
quadro, mas o quadro também faz esta tarefa para o time. Por exemplo, um quadro onde
se tem as seguintes seções: tarefas planejadas, em execução e testes. No momento que
tarefas são colocadas em planejamento e, esta seção ficar lotada, é hora de começar a
execução. Da mesma forma que, quando a execução já está lotada, é necessário passar
tarefas para a seção de testes. Este tipo de fluxo é chamado de Just in Time14. Caso
aconteça algum problema na execução das tarefas, é possível sinalizar com o quadro
13
Termo japonês utilizado que significa semáforo. Os kanbans surgiram na Toyota, na década de 50
[Ohno 1998].
14
Fluxo puxado.

24. para o time. Outra questão interessante na adoção destes quadros é que, só será possível
planejar novas tarefas para desenvolvimento, somente quando liberar espaço nas seções.
Pode-se ampliar as seções destes quadros para registrar potenciais melhorias,
identificar problemas e, na retrospectiva da iteração, discutir as soluções com o time.
Figura 24. Exemplo de quadro de acompanhamento
5.2. Soft Tools
Existem inúmeros softwares utilizados para apoiar as práticas do XP. No quadro 6, é
apresentado uma lista de ferramentas para as tecnologias Java, PHP e .NET15, práticas
que são apoiadas, a licença disponível e endereço web do fornecedor.
Quadro 6. Lista de ferramentas por tecnologia
Práticas/ Ferramenta Suporte a Licença URL
Tecnologia
Intenções
Planejamento XPlanner Java LGPL http://www.xplanner.org/
de Releases e
Iterações ExtremePlanner Java Comercial http://www.extremeplanner.com/
AgileTrack Java Comercial http://agiletrack.net/
RallyDev Não Free e http://www.rallydev.com/
informado Comercial
XPWeb PHP GPL http://xpweb.sourceforge.net/
Testes de FIT Várias GPL http://fit.c2.com/
Aceitação,
Integrados FITNesse Várias L http://fitnesse.org/
Selenium Várias GPL http://seleniumhq.org
15
A escolha das tecnologias foi baseada em sua adoção na indústria de software para aplicações
comerciais. Mais informações sobre linguagens de programação em
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

25. Práticas/ Ferramenta Suporte a Licença URL
Tecnologia
Intenções
Testes JUnit Java GPL http://www.junit.org
Unitários,
Cobertura NUnit .NET (C#) GPL http;//www.nunit.org
CsUnit .NET (C#) GPL http://www.csunit.org/tutorials/tutorial7/
Cobertura Java GPL http://cobertura.sourceforge.net/
Emma Java GPL http://emma.sourceforge.net/
NCover .NET Comercial http://www.ncover.com/
PHPUnit PHP GPL http://www.phpunit.de/
Integração Apache ANT Java Apache http://ant.apache.org/
Contínua
CruiseControl Várias BSD http://cruisecontrol.sourceforge.net/
Hudson Java GPL https://hudson.dev.java.net/
Apache Maven Java Apache http://maven.apache.org/
PHPUnderControl PHP GPL http://www.phpundercontrol.org/
Phing PHP GPL http://phing.info/
Padrões de NDepend .NET Comercial http://www.ndepend.com/
Codificação,
Auditoria, NDoc .NET GPL http://ndoc.sourceforge.net/
Controle de PMD/CPD Java GPL http://pmd.sourceforge.net/
Versões,
IDEs Javadoc Java Gratuito http://java.sun.com/j2se/javadoc/
PHPCodeSniffer PHP GPL http://pear.php.net/package/PHP_CodeSniffer/redirected
PHPDoc PHP GPL http://www.phpdoc.org/
CheckStyle Java GPL http://checkstyle.sourceforge.net/
Eclipse Várias Eclipse http://www.eclipse.org
NetBeans Várias GPL http://www.netbeans.org
Visual Studio .NET Comercial http://www.microsoft.com/exPress/
e Gratuito
5.4. Métricas
Para controlar o andamento do trabalho, as equipes de desenvolvimento definem
métricas. Nas metodologias ágeis, as métricas não são diferentes. Segundo [Hartmann e
Dymond 2006], uma boa métrica ágil deve:
• Reforçar princípios ágeis: entregar valor e colaborar com o cliente são
princípios fundamentais das metodologias ágeis;
• Seguir tendências e não números: a tendência é mais importante que os valores
representados pela métrica;
• Medir resultados e não saídas: medir os resultados obtidos é mais importante
que medir saídas de atividades de processos;
• Foco no necessário: é impossível medir tudo. Muita informação pode esconder
o que realmente é importante;

26. • Ser facilmente coletada: as métricas devem ser facilmente identificadas e
coletadas, para facilitar o trabalho do tracker;
• Revelar contextos e variáveis: métricas devem expor influências e contextos,
facilitando a melhoria;
• Apoiar os valores ágeis: as métricas devem apoiar a comunicação e feedback,
promovendo o aprendizado e a melhoria contínua.
Existem inúmeras métricas, como as aplicadas a código, planejamento,
automação e valor de negócio [Mittal 2008]. As métricas mais utilizadas em XP são
Running Tested Features (RTF), Project Velocity e Load Factor [Jeffries 2004b; Beck
2004; Cunningham 2007; Cunningham 2009].
A métrica Running Tested Features (RTF) é referente à taxa de valor de negócio
entregue por funcionalidade testada e implantada. Desta forma, o cliente define quando
uma funcionalidade está pronta, através de testes de aceitação [Jeffries 2004b].
A métrica Project Velocity está relacionada a quanto de software o time
consegue entregar por iteração, em relação às atividades planejadas [Cunningham
2007]. A base para medição são as story points ou dias ideais de desenvolvimento. Esta
métrica é extremamente importante para o time, pois é através dela que se consegue
fazer um nivelamento de produção e encontrar o takt time16. Aí está a importância de ter
uma iteração time-boxed17. Esta métrica pode ser afetada por inúmeros fatores, como
impedimentos, mudanças no time, conhecimento do negócio e tecnologia.
A métrica Load Factor está relacionada com o trabalho individual do time,
levando em consideração o que foi planejado e o que foi efetivamente realizado em um
dia de trabalho ideal [Cunningham 2009]. Este fator é utilizado, juntamente com o
Project Velocity para o planejamento das iterações. Além destas métricas, é
extremamente importante o time levar em conta seu histórico de desenvolvimento.
6. Adotando e Escalando XP
O XP é uma disciplina ágil, que requer total integração da equipe. Por isso, os valores
de comunicação, simplicidade, coragem e feedback são sempre levados em consideração
antes da aplicação da disciplina. Como o XP é voltado para testes, é muito importante a
projeção dos testes antes da codificação. Isto permite o refactoring sem qualquer temor,
dando mais segurança ao time.
Entretanto, é mais complexo aplicar XP em projetos onde a comunicação é uma
barreira. Outra situação onde se torna complicado aplicar o XP é quando não se tem
controle sobre o código e quando o feedback é demorado, sem uma comunicação
eficiente [Astels, Miller e Novak 2002].
Outras questões que dificultam o uso de XP são barreiras culturais, como
alteração de código de terceiros e relevância de hábitos antigos, procurando manter as
coisas simples. O XP também não pode ser aplicado quando o cliente quer uma
especificação detalhada do sistema antes de começar o desenvolvimento.
16
Termo utilizado no Lean para representar o compasso de trabalho do time
17
Períodos de tempo distintos e fixos, sem variações.

27. O XP tem obtido um crescimento contínuo como disciplina de desenvolvimento
dentro da indústria do software, sendo discutida pelos principais engenheiros de
software do mercado. Existem vários trabalhos relacionando XP com processos
incrementais e iterativos, como [Martin 2002; Smith 2003], abordando características
em termos de tempo e alocação de recursos, artefatos, disciplinas e atividades.
As práticas do XP podem ser abordadas dentro de diferentes ciclos de
desenvolvimento e metodologias. Ao trabalhar com modelos de maturidade como SW-
CMM/CMMI, as práticas de metodologias ágeis podem ajudar nos processos
relacionados à engenharia, nos processos de qualidade do produto, métricas, e melhoria
contínua [Paulk 2001; Sutherland, Jakobsen e Johnson 2007; Glazer 2008]. As
metodologias ágeis também são relacionadas a sistemas de gestão da qualidade como
ISO 9001, pois os princípios de qualidade da ISO são muito próximos dos princípios
ágeis, como foco no cliente, liderança, envolvimento das pessoas, melhoria contínua e o
trabalho de melhoria dos fornecedores [ISO 2010].
Referências
Ambler, Scott (2004a) “Architecture Envisioning: An Agile Best Practice”,
http://www.agilemodeling.com/essays/initialArchitectureModeling.htm, Última
Visita: Abril de 2010.
Ambler, Scott (2004b) “Modelagem Ágil: Práticas Eficazes para Programação Extrema
e o Processo Unificado”, Bookman.
Ambler, Scott (2005) “Communication on Agile Software Projects”,
http://www.agilemodeling.com/essays/communication.htm, Última Visita: Abril de
2010.
Ambler, Scott (2007) “Introduction to User Stories”,
http://www.agilemodeling.com/artifacts/userStory.htm, Última Visita: Abril de 2010.
Anderson, Ann et al (1998) “Chrysler goes to Extremes”, Computing Distributed,
October.
Astels, David; Miller, Granville e Novak, Miroslav (2002) “Extreme Programming:
Guia Prático”, Campus.
Balzer, Robert (1981) “Transformational Implementation: an example”, In: IEEE
Transactions of Software Engineering, volume 7.
Beck, Kent (1996) “Smalltalk Best Practices Paterns”, Prentice Hall.
Beck, Kent e Fowler, Martin (2000) “Planning Extreme Programming”, Addison-
Wesley.
Beck, Kent et al (2001) “Agile Manifesto”, http://www.agilemanifesto.org, Última
Visita: Abril de 2010.
Beck, Kent (2004) “Programação eXtrema Explicada”, Bookman.
Boehm, Barry (1986) “A Spiral Model of Software Development and Enhancement”,
ACM SIGSOFT Software Engineering Notes, volume 11.

28. Boehm, Barry e Turner, Richard (2003) “Balancing Agility and Discipline: a guide for
the perplexed”, Addison-Wesley.
Brooks, Frederic (1987) “No Silver Bullet: Essence and Accidents of Software
Enginnering”, IEEE Computer, volume 20.
Coad, Peter; Luca, Jeff e Lefebvre (1999) “Java Modeling Color with UML: Enterprise
Components and Process with CDRom”, Prentice Hall.
Cockburn, Alistair (2002) “Agile Software Development”, Addison-Wesley.
Cockburn, Alistair (2004) “Crystal Clear: A human-powered methodology for small
teams”, Addison-Wesley.
Cockburn, Alistair (2005) “Earned-values and Burn Charts”,
http://alistair.cockburn.us/Earned-value+and+burn+charts, Última Visita: Abril de
2010.
Cohn, Mike (2004) “User Stories Applied”, Addison-Wesley.
Cohn, Mike (2005) “Agile Estimating and Planning”, Prentice Hall.
Cooper, Alan (2003) “Cooper Journal: The Origin of Personas”,
http://www.cooper.com/journal/2003/08/the_origin_of_personas.html, Última Visita:
Abril de 2010.
Cunningham, Ward (2002) “Extreme Programming”, http://www.c2.com/cgi/wiki?
ExtremeProgramming, Última Visita: Abril de 2010.
Cunningham, Ward (2006) “Extreme Roles”, http://www.c2.com/cgi/wiki?
ExtremeRoles, Última Visita: Abril de 2010.
Cunningham, Ward (2007) “Project Velocity”, http://c2.com/cgi/wiki?ProjectVelocity,
Última Visita: Abril de 2010.
Cunningham, Ward (2008) “History of Extreme Programming”,
http://www.c2.com/cgi/wiki? HistoryOfExtremeProgramming, Última Visita: Abril
de 2010.
Cunningham, Ward (2009) “Load Factor”, http://c2.com/cgi/wiki?LoadFactor, Última
Visita: Abril de 2010.
Fowler, Martin (1999) “Refactoring: Improving the Design of Existing Code”, Addison-
Wesley.
Ghezzi, Carlo; Jazayeri, Mehdi e Mandrioli, Dino (1991) “Fundamentals of Software
Enginnering”, Prentice Hall.
Gilb, Tom (1981) “Evolutionary Development”, ACM SIGSOFT Software Engineering
Notes, volume 6.
Glazer, Hillel et al (2008) “CMMI or Agile: Why not embrace both!”, Technical Note,
SEI/CMU.
Hartmann, Deborah e Dymond, Robin (2006) “Appropriate Agile Measurements: Using
metrics and diagnostics to deliver business value”, In: Agile 2006 Conference.

29. Highsmith, Jim (1997) “Messy, exciting, and anxiety-ridden: Adaptive software
development”, In: American Programmer, volume 10.
Highsmith, Jim (2000) “Retiring lifecycle dinosaurs: Using adaptive software
development to meet the challenges of a high-speed, high-change environment”, In:
Software Testing & Quality Engineering, July/August.
Highsmith, Jim e Cockburn, Alistair (2001) “Agile Software Development: The
business of innovation”, Prepared by the IEEE Computer Society/ACM Joint Task
Force.
Hunt, John (2006) “Agile Software Construction”, Springer-Verlag London.
ISO (2010) “ISO Quality Management Principles”, http://www.iso.org/iso/qmp, Última
Visita: Abril de 2010.
Jacobson, Ivar; Rumbaugh, James e Booch, Grady (1999) “The Unified Software
Development Process”, Addison-Wesley.
Jeffries, Ron (2000) “Extreme Programming”, http://www.xprogramming.com, Última
Visita: Abril de 2010.
Jeffries, Ron (2001) “Essencial XP: Card, Conversation and Confirmation”, XP
Magazine.
Jeffries, Ron (2004a) “Big Visible Charts”,
http://xprogramming.com/xpmag/BigVisibleCharts, Última Visita: Abril de 2010.
Jeffries, Ron (2004b) “A Metric leading Agility”,
http://xprogramming.com/xpmag/jatRtsMetric, Última Visita: Abril de 2010.
Kniberg, Henrik e Skarin, Mattias (2009) “Kanban and Scrum: making the most of
both”, C4 Media Inc., Published by InfoQ.
Liker, Jeffrey (2004) “The Toyota Way: 14 Management Principles from the World´s
Greatest Manufacturer”, McGraw-Hill.
Martin, James (1991) “Rapid Application Development”, Macmillan Publishing Co.
Martin, Robert (2002) “RUP vs XP”,
http://www.objectmentor.com/resources/articles/RUPvsXP.pdf, Última Visita: Abril
de 2010.
McConnell, Steve (1998) “Software Project Survival Guide”, Microsoft Press.
Mittal, Deepak (2008) “Metrics for Agile Projects”, In: Agile NCR 2008 Conference.
Naur, Peter e Randell, Brian (1968) “Software Engineering: report of a conference
sponsored by the NATO Science Committee”, Scientific Affairs Division.
Ohno, Taiichi (1998) “Toyota Production System: Beyond Large-Scale Production”,
Productivity Press.
Opdyke, William (1992) “Refactoring Object-Oriented Frameworks”, PhD Thesis,
University of Illinois.
Ortigosa, Alvaro (1995) “Proposta de um Ambiente Adaptavel de Apoio ao Processo de
Desenvolvimento de Software”, Dissertacao de Mestrado, UFRGS.

30. Palmer, Stephen e Felsing, John (2002) “A practical Guide to Feature Driven
Development”, Prentice Hall.
Paulk, Mark (2001) “Extreme Programming from a CMM Perspective”, In: IEEE
Software, volume 18.
Pressman, Roger (1995) “Engenharia de Software”, Makron Books.
Poppendieck, Mary e Poppendieck, Tom (2003) “Lean Software Development: An agile
toolkit”, Addison-Wesley.
Poppendieck, Mary e Poppendieck, Tom (2005) “Implementing Lean Software
Development: from concept to cash”, Addison-Wesley.
Royce, Winston (1970) “Managing the development of large software systems”, In:
Proceedings of IEEE WESCON.
Schwaber, Ken e Beedle, Mike (2001) “Agile Software Development with Scrum”,
Prentice Hall.
Schwaber, Ken (2004) “Agile Project Management with Scrum”, Microsoft Press.
Shalloway, Alan e Trott, James (2009) “Lean-Agile Pocket Guide for Scrum Teams”,
Net Objectives Press.
Shore, Jim e Warden, James (2008) “The Art of Agile Development”, O’Reilly.
Silver, Nik (2008) “Burndown and Burnup Charts”,
http://niksilver.com/2008/01/19/burn-up-and-burn-down-charts/, Última Visita: Abril
de 2010.
Smith, John (2003) “A Comparison of the IBM Rational Unified Process and eXtreme
Programming”,
ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP167.pdf,
Última Visita: Abril de 2010.
Smith, Greg e Sidky, Ahmed (2009) “Becoming Agile: in an imperfect world”, Manning
Publications Co.
Standish Group (2009) “The Chaos Report”, Technical Report.
Stapleton, Jennifer (1997) “DSDM: A framework for business centered development”,
Addison-Wesley.
Sutherland, Jeff; Jakobsen, Carsten e Johnson, Kent (2007) “Scrum and CMMI Level 5:
The Magic Potion for Code Warriors”, In: Agile 2007 Conference.
SWEBoK (2004) “Guide to the Software Engineering Body of Knowledge”, IEEE
Computer Society.
Wake, William (2000) “Extreme Programming Explored”, Addison-Wesley.
Wake, William (2003) “INVEST in Stories / SMART Tasks”,
http://xp123.com/xplor/xp0308/, Última Visita: Abril de 2010.
Wells, Donovan (2001a) “Extreme Programming: A Gentle Introdution”,
http://www.extremeprogramming.org/. Última Visita: Abril de 2010.

31. Wells, Donovan (2001b) “Move People Around”,
http://www.extremeprogramming.org/rules/movepeople.html. Última Visita: Abril de
2010.
Wiegers, Karl (2003) “Software Requirements”, Microsoft Press, 2º. Edição.