Programação Extrema (XP) Explicada - Acolha As Mudanças

Kent Beck é dono e presidente da First Class Software, Inc.
, onde ele con-

centra-se em seus dois maiores interesses, padrões (patterns) e Programação
eXtrema. É um dos pioneiros em temas como padrões para desenvolvimen-
to de software, cartões CRC, o framework do editor gráfico HotDraw, o frame-
work de testes de unidade xUnit e na “redescoberta” da programação prece-
dida por testes. É autor de mais de 50 artigos sobre programação e dos
livros The Smalltalk Best Practice (Prentice-Hall) e Kent Beck’s Guide to Better
Smalltalk: A Sorted Collection (Cambridge University Press).
B126p Beck, Kent.

Programação extrema explicada [recurso eletrônico] : acolha
as mudanças / Kent Beck ; tradução Adriana Picoral Sarandy
Machado e Natália Nunes Pinto Lopes. – Dados eletrônicos.–
Porto Alegre : Bookman, 2008.
Editado também como livro impresso em 2004.

ISBN 978-85-7780-306-4
1. Computação – Programação de software – XP. I. Título.
CDU 004.457XP
Catalogação na publicação: Mônica Ballejo Canto – CRB 10/1023

Kent Beck
Programação
e trema
(XP)
e plicada
Acolha as mudanças
Tradução:
Adriana Picoral Sarandy Machado
Natália Nunes Pinto Lopes
Consultoria, supervisão e revisão técnica desta edição:

Marcelo Soares Pimenta
Doutor em Informática pela Université Toulouse 1, França
Professor do Instituto de Informática da UFRGS
Versão impressa
desta obra: 2004
2008
Obra originalmente publicada sob o título
Extreme programing explained: embrace change, 1/e
Kent Beck
© 2000, Addison-Wesley
ISBN: 0-201-61641-6
Tradução autorizada a partir do original em idioma inglês, publicado por Pearson

Education, Inc., sob o selo Addison-Wesley Professional.
Capa: Amarílis Barcelos
Leitura final: Carla Krohn
Supervisão editorial: Denise Weber Nowaczyk
Editoração eletrônica: Laser House
Muitas das designações utilizadas por fabricantes ou vendedores para distinguir seus pro-
dutos são marcas registradas. Das que tínhamos ciência, foram impressas com letra inicial
maiúscula, ou com todas as letras maiúsculas.
O autor e a editora dedicaram-se na preparação deste documento, mas não oferecem
qualquer tipo de garantia expressa ou implícita e não assumem responsabilidade por
eventuais erros ou omissões. Nenhuma responsabilidade é assumida por danos aciden-
tais ou conseqüentes associados ou originados do uso das informações ou dos programas
aqui contidos.
Reservados todos os direitos de publicação, em língua portuguesa, à

ARTMED® EDITORA S.A.
(BOOKMAN® COMPANHIA EDITORA é uma divisão da ARTMED® EDITORA S.A.)
Av. Jerônimo de Ornelas, 670 - Santana
90040-340 Porto Alegre RS
Fone (51) 3027-7000 Fax (51) 3027-7070
É proibida a duplicação ou reprodução deste volume, no todo ou em parte, sob quaisquer

formas ou por quaisquer meios (eletrônico, mecânico, gravação, fotocópia, distribuição na
Web e outros), sem permissão expressa da Editora.
SÃO PAULO
Av. Angélica, 1091 - Higienópolis
01227-100 São Paulo SP
Fone (11) 3665-1100 Fax (11) 3667-1333
SAC 0800 703-3444
IMPRESSO NO BRASIL
PRINTED IN BRAZIL
Ao meu Pai
Obrigado a Cindee Andrews, minha mulher e companheira, por
insistir que eu a ignorasse e escrevesse. Obrigado a Bethany, Lin-
coln, Lindsey, Forrest e Joelle por abrirem mão de passar tempo co-
migo a fim de que eu pudesse digitar.
AGRADECIMENTOS
E
screvo em primeira pessoa aqui não porque estas sejam as minhas idéias, mas
porque esta é a minha perspectiva sobre essas idéias. A maioria das práticas da
XP são tão velhas quanto a programação.
Ward Cunningham é minha fonte imediata de muito do que você lerá aqui. De
muitas formas, eu passei os últimos 15 anos tentando explicar para outras pessoas o
que ele faz com naturalidade. Agradeço a Ron Jeffries por experimentar as práticas
(de XP) e torná-las muito melhores. Agradeço a Martin Fowler por explicá-las de ma-
neira não assustadora. Agradeço a Erich Gamma pelas longas conversas diante dos
cisnes no rio Limmat e por não me deixar pensar de forma medíocre. E ainda, nada
disto teria acontecido se eu não tivesse observado meu pai, Doug Beck, exercer seu
ofício de programador por todos esses anos.
Agradeço ao time C3 da Chrysler por me seguir pela montanha e então me ultra-
passar no caminho do topo. E agradeço especialmente aos nossos gerentes Sue Un-
ger e Ron Savage pela coragem de nos dar a chance de tentar.
Agradeço à Daedalos Consulting por apoiar a elaboração deste livro.
O prêmio de melhor revisor vai para Paul Chisholm por seus comentários ricos,
abrangentes, cuidadosos e muitas vezes simplesmente chatos. Este livro não seria
metade do que é sem o seu feedback.
Eu realmente gostei de interagir com todos os meus revisores. Bem, pelo menos
eles me ajudaram enormemente. Não há como agradecê-los o suficiente por revisar
a versão 1.0 da minha prosa, alguns deles em língua estrangeira. Agradeço (listados
na ordem aleatória em que li suas revisões) Greg Hutchinson, Massimo Arnoldi, Da-
ve Cleal, Sames Schuster, Don Wells, Joshua Kerievsky, Thorsten Dittmar, Moritz
Becker, Daniel Gubler, Christoph Henrici, Thomas Zang, Dierk Koenig, Miroslav No-
viii AGRADECIMENTOS
vak, Rodney Ryan, Frank Westphal, Paul Trunz, Steve Hayes, Kevin Bradtke, Jeani-
ne De Guzman, Tom Kubit, Falk Bruegmann, Hasko Heinecke, Peter Merel, Rob
Mee, Pete McBreen, Thomas Ernst, Guido Haechler, Dieter Holz, Martin Knecht,
Dierk König, Dirk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio
Moreno, Rolf Pfenninger e Matthias Ressel.
A P R E S E N TA Ç Ã O
A
Programação eXtrema (XP) define a codificação como a principal atividade de
um projeto de software. É impossível que isso funcione!
Deixe-me refletir um pouco sobre meu próprio trabalho com desenvolvimento.

Trabalho em uma cultura de software just-in-time, com ciclos de entrega comprimidos
e temperados com alto risco técnico. Ser capaz de transformar as mudanças em suas
aliadas é uma habilidade requerida para a sobrevivência. A comunicação entre mem-
bros do time e entre times às vezes separados geograficamente é feita através de có-
digo. Observamos o código para compreender APIs de subsistemas novas ou em
evolução. O ciclo de vida e o comportamento de objetos complexos são definidos em
casos de testes, também estes em código. Os relatórios de problemas são acompanha-
dos por casos de teste que demonstram o problema, mais uma vez, em código. Por
fim, melhoramos continuamente o código existente com a refatoração. Obviamente
nosso desenvolvimento é centrado no código, e, no entanto, somos capazes de entre-
gar o software a tempo. Então essa idéia pode funcionar, afinal.
Seria errado concluir que tudo o que é preciso para desenvolver software é progra-
mação desenfreada. Desenvolver software é difícil, e desenvolver software de qualida-
de no prazo combinado é ainda mais difícil. Para funcionar, é preciso o uso discipli-
nado de práticas-modelo (best practices*) adicionais. É deste ponto que Kent inicia seu
provocativo livro sobre XP.
*N. de T. Best practices, traduzido neste livro por práticas-modelo, tem o significado de práticas confiáveis que foram
validadas e consolidadas por experimentos.
x PREFÁCIO
Kent estava entre os líderes da Tektronix que reconheceram a potencialidade da

programação em pares em Smalltalk para aplicações complexas de desenvolvimen-
to. Juntamente com Ward Cunningham, ele inspirou grande parte do movimento dos
padrões, que tanto impacto teve em minha carreira. A XP descreve uma abordagem
para o desenvolvimento que combina práticas usadas por muitos desenvolvedores
de sucesso que acabaram enterradas sob a massiva literatura sobre métodos e pro-
cessos de software. Como os padrões, a XP baseia-se em práticas-modelo tais como
testes de unidade, programação em pares e refatoração. Na XP, essas práticas são
combinadas para que possam complementar e muitas vezes controlar umas às
outras. O foco está nas trocas mútuas entre as diferentes práticas, o que faz deste li-
vro uma contribuição importante. Existe um objetivo único que é desenvolver softwa-
re com as funcionalidades certas e dentro do prazo. Mesmo que o bem-sucedido pro-
cesso Just In Time da OTI não seja pura e simples XP, ele tem muitas características
em comum com ela.
Eu aproveitei bastante minha interação com Kent e a prática de episódios XP em
uma coisa chamada JUnit. Suas concepções e abordagens sempre desafiam a forma
como eu encaro o desenvolvimento de software. Não há dúvidas de que a XP desafia
algumas abordagens tradicionais; este livro permitirá que você decida se quer ado-
tar a XP ou não.
Erich Gamma
PREFÁCIO
E
ste livro é sobre Programação eXtrema (XP). A XP é uma metodologia leve para
times de tamanho pequeno a médio, que desenvolvem software em face a requi-
sitos vagos que se modificam rapidamente. Este livro pretende ajudá-lo a deci-
dir se a XP serve para você.
Para algumas pessoas, a XP parece ser apenas bom senso. Então por que o “eXtre-
ma” no nome? A XP leva princípios e práticas do senso comum a níveis extremos:
• se revisar o código é bom, revisaremos código o tempo inteiro (programação

em pares);
• se testar é bom, todos vão testar o tempo inteiro (testes de unidade), até mes-
mo os clientes (testes funcionais);
• se o projeto é bom, ele fará parte das funções diárias de todos (refatoração);
• se simplicidade é bom, sempre deixaremos o sistema com o projeto mais
simples que suporte a funcionalidade atual (a coisa mais simples que possa
funcionar);
• se arquitetura é importante, todos trabalharão para definir e refinar a arquite-
tura o tempo inteiro (metáfora);
• se testes de integração são importantes, então vamos integrar e testar várias
vezes ao dia (integração contínua);
• se iterações curtas são boas, faremos iterações muito, muito pequenas – se-
gundos, minutos e horas, não semanas, meses e anos (o Jogo do Planejamen-
to).
Na primeira vez em que eu articulei a XP, eu tinha uma imagem mental de botões em
uma mesa de controle. Cada botão representava uma prática que, por experiência, eu
xii PREFÁCIO
sabia que funcionava bem. Eu giraria todos os botões para o máximo e veria o que ia
acontecer. Fiquei um tanto surpreso ao descobrir que o conjunto das práticas era es-
tável, previsível e flexível.
A XP faz dois conjuntos de promessas:
• Aos programadores, a XP promete que eles poderão trabalhar naquilo que

realmente interessa, todos os dias. Eles não precisarão enfrentar situações as-
sustadoras sozinhos, poderão dar o melhor de si para que o sistema deles seja
bem-sucedido, tomarão as decisões para as quais estão bem preparados, e não
aquelas para as quais não são qualificados.
• Aos clientes e gerentes, a XP promete que eles obterão o maior valor possível
de cada semana de programação. Em intervalos de poucas semanas, eles po-
derão perceber progresso concreto nas metas que lhes importam e poderão
mudar a direção do projeto na metade do desenvolvimento sem incorrer em
custos exorbitantes.
Resumindo, a XP promete reduzir o risco do projeto, melhorar a resposta às mu-

danças nos negócios, melhorar a produtividade durante toda a vida do sistema e
acrescentar diversão à construção de software em times – tudo isso ao mesmo tempo.
É verdade. Pare de rir. Agora você precisa ler o resto do livro para descobrir se eu es-
tou maluco.
Este Livro
Este livro fala sobre o que está por detrás da XP – suas raízes, filosofia, histórias, mi-
tos. Ele pretende ajudá-lo a tomar uma decisão consciente quanto a usar ou não a XP
em seu projeto. Se você ler este livro e decidir corretamente não usar XP em seu pro-
jeto, eu terei atingido meu objetivo tanto quanto se você decidir corretamente usá-la.
Um segundo objetivo deste livro é ajudar aqueles entre vocês que já estão usando XP
a entendê-la melhor.
Este não é um livro sobre como precisamente aplicar a Programação eXtrema. Vo-
cê não encontrará aqui uma pilha de checklists, nem lerá muitos exemplos ou muitas
histórias de programação. Para isso, você precisará procurar na rede, conversar com
alguns dos treinadores aqui mencionados, esperar pelos livros mais detalhados, do
tipo “como fazer”, ou simplesmente inventar sua própria versão.
O próximo passo da aceitação da XP está nas mãos de um grupo de pessoas (vo-
cê pode ser uma delas) que estão insatisfeitas com o desenvolvimento de software co-
mo ele é praticado atualmente. Você quer uma maneira melhor de desenvolver soft-
ware, quer melhores relacionamentos com seus clientes, quer programadores mais fe-
lizes, estáveis e produtivos. Em resumo, você está procurando maior retorno e não
está com medo de experimentar novas idéias para obtê-lo. Mas se você vai correr o
risco, você prefere ser convencido de que não está simplesmente sendo estúpido.
A XP pede que você faça as coisas de forma diferente. Às vezes, a orientação da
XP é completamente contrária ao senso comum. Eu até espero que aqueles que esco-
lhem a XP exijam razões convincentes para fazer as coisas diferentemente, mas se as
razões existem, espero que eles simplesmente sigam em frente. Eu escrevi este livro
para lhe dar essas razões.
PREFÁCIO xiii
O que é a XP?
O que é a XP? A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível,
científica e divertida de desenvolver software. Ela se distingue das outras metodolo-
gias por:
• seu feedback antecipado, concreto e contínuo derivado dos ciclos curtos;

• sua abordagem incremental de planejamento, que gera rapidamente um pla-
no geral que vai evoluir com o decorrer do projeto;
• sua habilidade de agendar de forma flexível a implementação das funcionali-
dades, respondendo às mutáveis necessidades de negócios;
• sua confiança nos testes automatizados escritos por programadores e clientes
para monitorar o progresso do desenvolvimento, para permitir que o sistema
evolua e para detectar cedo os erros;
• sua confiança na comunicação oral, testes e código-fonte para comunicar a es-
trutura e o objetivo do sistema;
• sua confiança em um processo de projeto evolutivo que dura tanto quanto o
sistema em si;
• sua confiança na intensa colaboração de programadores com habilidades co-
muns;
• sua confiança nas práticas que combinam tanto com os instintos de curto pra-
zo dos programadores quanto com os interesses de longo prazo do projeto.
A XP é uma disciplina de desenvolvimento de software. É uma disciplina porque

há certas coisas que você precisa fazer para estar fazendo XP. Você não poderá esco-
lher se escreverá ou não os testes – se não escrever, você não é eXtremo e ponto final.
A XP foi desenvolvida para funcionar em projetos com times de dois a 10 progra-
madores, que não sejam severamente restringidos pelo ambiente computacional
existente e nos quais boa parte da execução de testes possa ser feita em uma fração
de dia.
A XP assusta ou irrita algumas pessoas que a encontram pela primeira vez. No
entanto, nenhuma das idéias da XP é nova. A maioria delas é tão velha quanto a pro-
gramação. De uma certa forma, a XP é conservadora – todas as suas técnicas foram
comprovadas por décadas (para a estratégia de implementação) ou séculos (para a
estratégia de gerenciamento).
A inovação da XP é:
• colocar todas essas práticas juntas, sob um só teto;

• garantir que elas sejam praticadas a fundo;
• garantir que as práticas apóiem umas às outras ao máximo.
O Suficiente
Nos livros The Forest People e The Mountain People, o antropólogo Colin Turnbull des-
creve duas sociedades contrastantes. Nas montanhas, os recursos eram escassos, e as
pessoas estavam sempre à beira da inanição. A cultura desenvolvida por eles era hor-
xiv PREFÁCIO
rível. Mães abandonavam seus bebês para bandos nômades de crianças selvagens
tão-logo tivessem uma pequena chance de sobreviver. Violência, brutalidade e trai-
ção eram a ordem do dia.
Por outro lado, a floresta tinha muitos recursos. Uma pessoa gastava apenas meia
hora por dia cuidando de suas necessidades básicas. A cultura da floresta era exata-
mente o oposto da cultura das montanhas. Adultos compartilhavam a criação das
crianças, que eram alimentadas e amadas até que fossem capazes de cuidar de si pró-
prias. Se uma pessoa matasse outra por acidente (homicídio intencional era desco-
nhecido), ela era exilada, mas precisava se afastar apenas um pouco no interior da
floresta e apenas por uns poucos meses, e mesmo assim outros integrantes da tribo
lhe levavam comida.
A XP é um experimento em resposta à pergunta: “Como você programaria se ti-
vesse tempo suficiente?”. Na verdade, você não pode ter tempo extra, porque, no fim
das contas, estamos tratando de negócios e certamente estamos jogando para ganhar.
Mas se você tivesse tempo suficiente, escreveria testes; você reestruturaria o sistema
quando aprendesse algo novo; conversaria muito com seus colegas programadores e
com o cliente.
Tal “mentalidade de suficiência” é humana, ao contrário do cruel e penoso traba-
lho de prazos impossíveis e impostos, que afastam muitos talentos do ramo da pro-
gramação. A mentalidade de suficiência é também um bom negócio. Ela cria suas pró-
prias eficiências, assim como a mentalidade de escassez cria seu próprio desperdício.
Resumo
O livro é escrito como se você e eu estivéssemos criando uma nova disciplina de de-
senvolvimento juntos. Começamos examinando nossos pressupostos básicos sobre
desenvolvimento de software. Então, criamos a disciplina em si. Concluímos exami-
nando as implicações do que criamos – como ela pode ser adotada, quando ela não
deveria ser adotada e que oportunidade ela cria para os negócios.
O livro é dividido em três seções:
• O Problema – Os capítulos que vão desde “Risco: O Problema Básico” até “De
Volta ao Básico” definem o problema que a Programação eXtrema está tentan-
do resolver e apresenta critérios para avaliar a solução. Esta seção lhe dará
uma idéia geral de como Programação eXtrema vê o mundo.
• A Solução – Os capítulos que vão desde “Uma Rápida Visão Geral” até “Estra-
tégia de Testes” transformam as idéias abstratas da primeira seção em práticas
de uma metodologia concreta. Esta seção não lhe dirá exatamente como exe-
cutar as práticas; em vez disto, apresentará sua forma geral. A discussão de ca-
da prática a relaciona com os problemas e princípios introduzidos na primei-
ra seção.
• Implementando a XP – Os capítulos que vão desde “Adotando a XP” até “A
XP em Ação” descrevem uma variedade de tópicos sobre a implementação da
XP – como adotá-la, o que é esperado das várias pessoas em um projeto eXtre-
mo, qual a aparência da XP para o pessoal de negócios.
SUMÁRIO
SEÇÃO I O Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Esta seção prepara o terreno para a Programação eXtrema por meio da discussão de
vários aspectos do problema a ser resolvido ao inventarmos uma nova disciplina de
desenvolvimento de software. A seção discute os pressupostos básicos que usaremos na
escolha de práticas que cubram os vários aspectos de desenvolvimento de software – a
metáfora da condução, os quatro valores, os princípios derivados desses valores e as
atividades a serem estruturadas por uma nova disciplina de desenvolvimento.
CAPÍTULO 1 Risco: O Problema Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

O desenvolvimento de software tem falhas na entrega e falhas nos valores entregues.
Essas falhas têm impactos econômicos e humanos enormes. Precisamos achar uma
nova maneira de desenvolver software.
CAPÍTULO 2 Um Episódio de Desenvolvimento . . . . . . . . . . . . . . . . . . . . .25

A programação quotidiana inicia-se com uma tarefa conectada de forma clara a uma
funcionalidade que o cliente deseja, segue com testes, passando pela implementação e
pelo projeto, terminando na integração. Um pouco de cada uma das atividades do
desenvolvimento de software está incluída em cada episódio.
CAPÍTULO 3 A Economia no Desenvolvimento de Software . . . . . . . . . . . .29

Precisamos desenvolver nosso software economicamente mais valioso gastando
dinheiro mais devagar, obtendo rendimento mais rapidamente e aumentando a
provável expectativa de vida produtiva do nosso projeto. Mas o mais importante de
tudo é aumentar as opções de decisões de negócios.
16 SUMÁRIO
CAPÍTULO 4 Quatro Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Vamos controlar quatro variáveis em nossos projetos – custo, tempo, qualidade e
escopo. Dentre estas, o escopo nos fornece a forma mais valiosa de controle.
CAPÍTULO 5 O Custo das Modificações . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Sob certas circunstâncias, o aumento exponencial do custo em modificar o software ao
longo do tempo pode ser “achatado”. Se pudermos achatar a curva, velhas suposições
sobre a melhor maneira de desenvolver software não mais existirão.
CAPÍTULO 6 Aprendendo a Dirigir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Precisamos controlar o desenvolvimento de software fazendo muitos pequenos ajustes e
não uns poucos grandes ajustes, tal qual como conduzimos um carro. Isso significa que
nós precisaremos de feedback para saber quando estamos saindo do caminho,
precisaremos de muitas oportunidades para fazer correções além de fazer essas
correções a um custo razoável.
CAPÍTULO 7 Quatro Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Nós teremos êxito quando tivermos um estilo que contempla um conjunto consistente
de valores que servem para necessidades tanto humanas quanto comerciais:
comunicação, simplicidade, feedback e coragem.
CAPÍTULO 8 Princípios Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

A partir dos quatro valores, nós derivamos aproximadamente uma dúzia de princípios
para guiar nosso novo estilo. Vamos conferir as práticas de desenvolvimento propostas
para ver se elas estão à altura desses princípios.
CAPÍTULO 9 De Volta ao Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Queremos fazer tudo que for necessário para ter um desenvolvimento de software
estável e previsível. Porém, não temos tempo para nada extra. As quatro atividades
básicas do desenvolvimento são codificar, testar, escutar e projetar.
SEÇÃO II A Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Agora nós já preparamos o terreno. Conhecemos o problema que precisamos resolver:
decidir como devem ser executadas as atividades básicas do desenvolvimento de
software – codificar, testar, ouvir e projetar. Temos um conjunto de valores e princípios
para nos guiar assim como escolhemos estratégias para cada uma dessas atividades. E
temos a curva de custos achatada como nossa carta na manga para simplificar as estra-
tégias que escolhermos.
CAPÍTULO 10 Uma Rápida Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

Nós nos basearemos na sinergia entre práticas simples, que muitas vezes foram
abandonadas décadas atrás por serem consideradas simplórias, simples demais ou
impraticáveis.
CAPÍTULO 11 Como Isso Poderia Dar Certo? . . . . . . . . . . . . . . . . . . . . . . . .73

As práticas apóiam umas às outras. O ponto fraco de uma é compensada pelos pontos
fortes das outras.
SUMÁRIO 17
CAPÍTULO 12 Estratégia de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . .79

Vamos gerenciar o projeto como um todo usando princípios básicos de negócios –
entrega em fases, feedback concreto e rápido, articulação clara das necessidades dos
negócios do sistema e o uso de especialistas para tarefas especiais.
CAPÍTULO 13 Estratégia de Ambiente de Trabalho . . . . . . . . . . . . . . . . . . . .85

Criaremos uma área de trabalho aberta para o nosso time, com pequenos espaços
privados nas áreas periféricas e uma área comum de programação no meio.
CAPÍTULO 14 Dividindo as Responsabilidades Técnicas e de Negócios . . .89

Outro ponto-chave da nossa estratégia é manter o pessoal técnico focado nos problemas
técnicos e as pessoas de negócios focadas nos problemas de negócios. O projeto precisa
ser dirigido pelas decisões de negócio, mas elas precisam ser informadas pelas decisões
técnicas sobre custo e risco.
CAPÍTULO 15 Estratégia de Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . .93

Planejaremos definindo rapidamente um plano geral, e então o refinaremos em
períodos cada vez mais curtos – anos, meses, semanas, dias. Faremos o plano de
maneira rápida e barata, de forma haverá pouca inércia quando precisarmos mudá-lo.
CAPÍTULO 16 Estratégia de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . .103

Ao contrário da estratégia de gerenciamento, a estratégia de desenvolvimento é um
desvio radical da sabedoria convencional – nós cuidadosamente criaremos hoje a
solução para os problemas de hoje, e acreditaremos que seremos capazes de resolver
amanhã os problemas de amanhã
CAPÍTULO 17 Estratégia de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109

Continuamente nós refinaremos o projeto do sistema, partindo de um começo muito
simples. Retiraremos todas as flexibilidades que não se provarem úteis.
CAPÍTULO 18 Estratégia de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Escreveremos os testes antes de codificar, minuto a minuto. Preservaremos estes
testes para sempre, e executaremos todos eles juntos freqüentemente. Também
derivaremos testes sob a perspectiva do cliente.
SEÇÃO III Implementando a XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

Nesta seção, discutiremos como colocar em prática as estratégias da última seção. Ao
escolher um conjunto de estratégias radicalmente simplificado, você repentinamente
terá muito mais flexibilidade para trabalhar. Você pode usar essa flexibilidade para
muitos propósitos, mas precisa estar ciente de sua existência e das possibilidades que
ela oferece.
CAPÍTULO 19 Adotando a XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125

Adote uma prática da XP a cada vez, sempre abordando o problema que mais preocupa
o seu time. Uma vez que ele não é mais o seu problema mais importante, passe para o
próximo.
18 SUMÁRIO
CAPÍTULO 20 Ajustando a XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127

Projetos que querem alterar sua cultura atual são muito mais comuns do que projetos
que podem criar uma cultura completamente nova. Adote a XP um pouco de cada vez
em projetos que já estão acontecendo, começando com testes ou planejamento.
CAPÍTULO 21 Ciclo de Vida de um Projeto XP Ideal . . . . . . . . . . . . . . . . .131

O projeto XP ideal passa por uma curta fase de desenvolvimento inicial, seguida por
anos de suporte à produção e refinamento simultâneos, e finalmente chega a uma
graciosa aposentadoria quando o projeto não faz mais sentido.
CAPÍTULO 22 Papéis para Pessoas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137

Certos papéis precisam ser preenchidos para que um time eXtremo funcione –
programador, cliente, treinador, rastreador.
CAPÍTULO 23 A Regra 20-80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145

O valor total da XP não virá até que todas as práticas estejam sendo efetuadas. Muitas
das práticas podem ser adotadas em pequenas porções, mas seus efeitos serão
multiplicados quando elas estiverem ocorrendo juntas.
CAPÍTULO 24 O que Torna a XP Difícil . . . . . . . . . . . . . . . . . . . . . . . . . . .147

Mesmo que as práticas individuais possam ser executadas pelos programadores, reunir
todas as peças e mantê-las unidas é difícil. São primeiramente as emoções –
principalmente o medo – que tornam a XP difícil.
CAPÍTULO 25 Quando Você não Deveria usar a XP . . . . . . . . . . . . . . . . .151

Os limites exatos da XP ainda não estão claros. Porém, existem alguns estraga-
prazeres que fazem a XP não funcionar – grandes times, clientes desconfiados,
tecnologias que não suportam elegantemente as modificações.
CAPÍTULO 26 A XP em Ação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

A XP pode ajustar-se às formas habituais de contrato, se bem que com pequenas
modificações. Em particular, os contratos de preço fixo/escopo fixo se transformam em
contratos de preço fixo/data fixa/escopo razoavelmente fixo quando desenvolvidos com
o Jogo do Planejamento.
CAPÍTULO 27 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
Bibliografia Comentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163

Glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
SEÇÃO I
O Problema
E
sta seção prepara o terreno para a Programação eXtrema por meio da discussão
de vários aspectos do problema a ser resolvido ao inventarmos uma nova disci-
plina de desenvolvimento de software. A seção discute os pressupostos básicos
que usaremos na escolha de práticas que cubram os vários aspectos de desenvolvi-
mento de software – a metáfora da condução, os quatro valores, os princípios deriva-
dos desses valores e as atividades a serem estruturadas por uma nova disciplina de
desenvolvimento.
CAPÍTULO 1
Risco: O Problema Básico
O desenvolvimento de software tem falhas na entrega e falhas nos va-

lores entregues. Essas falhas têm impactos econômicos e humanos enor-
mes. Precisamos achar uma nova maneira de desenvolver software.
O
problema básico no desenvolvimento de software é o risco. A seguir estão al-
guns exemplos de risco:
• Deslizes no cronograma – o dia de entrega chega e você tem de dizer ao clien-

te que o software não ficará pronto antes de seis meses.
• Projeto cancelado – depois de vários deslizes, o projeto é cancelado sem ter
chegado fase de produção.
• O sistema “azeda” – o software é colocado em fase de produção com sucesso,
mas, depois de uns dois anos, o custo de se fazer modificações ou a taxa de er-
ros cresce tanto que o sistema deve ser substituído.
• Taxa de erros – o software é colocado em fase de produção, mas a taxa de erros
é tão alta que ele não é usado.
• Negócio mal compreendido – o software é colocado em fase de produção, mas
não resolve o problema original;
• Modificações nos negócios – o software é colocado em fase de produção, mas o
problema de negócio cuja resolução para o software foi projetado foi substituí-
do seis meses atrás por um outro problema de negócios mais urgente.
• Falsa riqueza de funções – o software tem um grande número de funções po-
tencialmente interessantes, as quais foram muito divertidas de programar, po-
rém nenhuma delas gera dinheiro para o cliente.
22 PROGRAMAÇÃO EXTREMA EXPLICADA
• Rotatividade da equipe – após dois anos, todos os bons programadores no

projeto começam a odiar o programa e vão embora.
Nestas páginas, você lerá sobre Programação eXtrema (XP), uma disciplina de de-
senvolvimento de software que aborda o risco em todas as etapas do processo de de-
senvolvimento. A XP é também muito produtiva, gerando um software de alta quali-
dade, e é muito divertida de se colocar em prática.
Como a XP aborda os riscos listados acima?
• Deslizes no cronograma – a XP exige ciclos curtos de entrega, de no máximo

poucos meses, fazendo com que a extensão de qualquer deslize seja limitada.
Dentro de um release, a XP utiliza iterações de funções requeridas pelo cliente.
Essas iterações duram de uma a quatro semanas, a fim de obter feedback deta-
lhado sobre o progresso. Dentro de uma iteração, a XP planeja tarefas com du-
ração de um a três dias, para que o time possa resolver problemas até mesmo
no período de uma iteração. Finalmente, a XP exige que as funções com prio-
ridade mais alta sejam implementadas primeiramente. Assim, qualquer fun-
ção que não for contemplada na versão será de importância menor.
• Projeto cancelado – a XP pede ao cliente que escolha o menor release que faça
mais sentido considerando o negócio, para que haja menos coisas que possam
dar errado antes de se ir para a fase de produção e para que o valor do software
seja o maior possível.
• O sistema “azeda” – a XP cria e mantém um conjunto abrangente de testes, os
quais são executados e reexecutados após cada modificação (diversas vezes ao
dia) para assegurar o padrão de qualidade. A XP sempre mantém o sistema em
excelente condição. Não será permitido que código redundante seja acumulado.
• Taxa de erros – a XP faz testes sob a perspectiva tanto do programador – de-
senvolvendo testes a cada função – quanto do cliente – desenvolvendo testes
a cada funcionalidade do programa.
• Negócio mal compreendido – a XP convida o cliente para ser uma parte inte-
grante do time. A especificação do projeto é continuamente refinada durante o
desenvolvimento. Assim, o software pode refletir o aprendizado obtido com o
cliente e o time.
• Modificações no negócio – a XP encurta o ciclo de release, fazendo com que
existam menos modificações durante o desenvolvimento de um único release.
Durante um release, o cliente é bem-vindo a substituir uma nova funcionalida-
de por uma funcionalidade ainda não terminada. O time nem percebe se está
trabalhando em uma funcionalidade descoberta recentemente ou em caracte-
rísticas definidas anos atrás.
• Falsa riqueza de funções – a XP insiste que apenas as tarefas com maior prio-
ridade sejam abordadas.
• Rotatividade da equipe – a XP solicita aos programadores que aceitem a res-
ponsabilidade de estimar e completar seus próprios trabalhos dando a eles re-
torno sobre o tempo real efetivamente dispendido, para que as suas estimati-
vas possam melhorar e para que respeitem essas estimativas. As regras para
definir quem pode fazer e mudar estimativas são claras. Por este motivo, há
RISCO: O PROBLEMA BÁSICO 23
menos chance de um programador ficar frustrado por ser solicitado a fazer o

obviamente impossível. A XP também encoraja o contato entre as pessoas que
compõem o time, reduzindo o isolamento que freqüentemente é um ponto im-
portante da insatisfação no emprego. Por último, a XP incorpora um modelo
explícito de rotatividade da equipe. Novos membros do time são encorajados
a gradualmente aceitar mais e mais responsabilidades, e são assistidos ao lon-
go do caminho uns pelos outros e pelos programadores já existentes.
Nossa Missão
Se nós aceitarmos o risco do projeto como o problema a ser resolvido, onde vamos
procurar a solução? O que precisamos fazer é inventar um estilo de desenvolvimen-
to de software que trate desses riscos. Precisamos comunicar esta disciplina da manei-
ra mais clara possível para programadores, gerentes e clientes. Precisamos definir re-
comendações (guidelines) para adaptá-lo às condições locais (ou seja, comunicar o
que é fixo e o que é variável).
Isso é o que abordaremos nas Seções I e II deste livro. Nós seguiremos passo a
passo através dos aspectos do problema de criar um novo estilo ou método de desen-
volvimento, e então resolveremos o problema. De um conjunto de pressupostos bá-
sicos, iremos derivar soluções que ditam como as várias atividades no desenvolvi-
mento de software – planejamento, testes, desenvolvimento, projeto e implantação –
devem ocorrer.
CAPÍTULO 2
Um Episódio de Desenvolvimento
A programação quotidiana inicia-se com uma tarefa conectada de forma

clara a uma funcionalidade que o cliente deseja, segue com testes, pas-
sando pela implementação e pelo projeto, terminando na integração. Um
pouco de cada uma das atividades do desenvolvimento de software está
incluída em cada episódio.
A
ntes, porém, daremos uma pequena amostra de aonde estamos indo. Este ca-
pítulo é a história do pulso da XP – o episódio de desenvolvimento. Aqui o
programador implementa uma tarefa de engenharia (a menor unidade do cro-
nograma) e a integra com o resto do sistema.
Eu olho para a minha pilha de cartões de tarefas. O primeiro deles diz “Exportar
retenções deste trimestre”. Na reunião em pé desta manhã, lembro de você ter dito
que tinha terminado o cálculo do trimestre. Eu pergunto se você (meu colega hipoté-
tico) tem tempo para me ajudar a exportar. “Claro”, você responde. A regra diz que
se você recebe um pedido de ajuda, você precisa dizer “sim”. Nós acabamos de nos
tornar parceiros de programação.
Passamos alguns minutos discutindo o trabalho que você fez ontem. Você fala so-
bre os bins* que adicionou, sobre como são os testes, talvez um pouco sobre como vo-
cê notou ontem que a programação em pares funcionou melhor quando você afastou
o monitor em uns 30 centímetros.
Você pergunta: “Quais são os casos de teste para esta tarefa?”
Eu respondo: “Quando rodamos a estação de exportação, os valores no registro
de exportação devem bater com os valores nos bins”.
“Que campos precisam ser preenchidos?”, você pergunta.
“Não sei. Vamos perguntar ao Eddie.”
Nós interrompemos Eddie por 30 segundos. Ele explica quais os cinco campos
que ele sabe estarem relacionados com o trimestre.
*N. de R. T.
Bin, mantido como no original para preservar a informalidade do texto, é uma gíria para “código do pro-
grama” ou “código que se transfornará em código binário”.
Damos uma olhada na estrutura de alguns dos casos de teste de exportação que
existem. Encontramos um que é quase o de que precisamos. Abstraindo uma super-
classe, podemos implementar facilmente nosso caso de teste. Fazemos a refatoração.
Rodamos os testes já existentes. Todos rodam.
Nós notamos que diversos outros casos de teste de exportação poderiam tirar
vantagem da superclasse que acabamos de criar. Queremos ver alguns resultados na
tarefa, então apenas escrevemos “Retroalimentar Testes Superclasse Exportação” em
nossos cartões de coisas a fazer.
Agora, escrevemos nosso caso de teste. Como acabamos de fazer a superclasse do
caso de teste, escrever o novo caso de teste é fácil. Terminamos em alguns minutos.
Quando estamos na metade, eu digo: “Já posso até imaginar como vamos implemen-
tar isso. Nós podemos...”.
“Vamos terminar o caso de teste primeiro”, você interrompe. Enquanto estamos
escrevendo, surgem idéias para três variações. Você as escreve nos cartões de coisas
a fazer.
Terminamos o caso de teste e o rodamos. Ele falha. É claro. Nós não implementa-
mos nada ainda. “Espere um minuto”, você diz. “Ontem Ralph e eu estávamos tra-
balhando em uma calculadora pela manhã. Escrevemos cinco casos de teste que pen-
sávamos que não iam funcionar. Apenas um deles não rodou de cara.”
Nós utilizamos um depurador no caso de teste. Olhamos para os objetos com que
temos de computar.
Eu escrevo o código. (Ou você escreve, quem quer que tenha uma idéia mais clara.)
Enquanto estamos implementando, notamos alguns outros casos de teste que devería-
mos escrever. Nós os colocamos nos cartões de coisas a fazer. O caso de teste roda.
Vamos para um próximo caso de teste, e depois outro. Eu os implemento. Você re-
para que o código poderia ser mais simples. Você tenta me explicar como simplificar.
Eu fico frustrado ao tentar escutá-lo e implementar ao mesmo tempo, então eu pas-
so o teclado para você. Você refatora o código. Você roda os casos de teste. Tudo OK.
Você implementa os próximos casos de teste.
Depois de algum tempo, olhamos os cartões de coisas a fazer e o único item é
reestruturar os outros casos de teste. As coisas andaram bem, então nós continuamos
e os reestruturamos, verificando se eles rodam ao terminar cada um deles.
Agora nossa lista de coisas a fazer está vazia. Notamos que a máquina de integra-
ção está livre. Nós carregamos a última versão. Então carregamos nossas alterações.
Nós rodamos todos os casos de teste, tanto os novos como todos os testes que os ou-
tros já haviam criado. Um deles falha. “Isso é estranho. Faz quase um mês que os ca-
sos de teste não falham durante a integração”, você diz. Sem problemas. Depuramos
o caso de teste e corrigimos o código. Rodamos tudo novamente. Dessa vez eles pas-
sam. Nós liberamos nosso código.
Este é todo o ciclo de desenvolvimento da XP. Note que:
• Pares de programadores programam juntos.

• O desenvolvimento é voltado a testes. Você testa primeiro e então codifica. Até
que todos os testes rodem, você não terminou. Quando todos os testes rodam,
e você não consegue pensar em nenhum outro teste que poderia falhar, você
terminou de adicionar funcionalidade.
UM EPISÓDIO DE DESENVOLVIMENTO 27
• Os pares não fazem apenas os casos de teste rodarem. Eles também evoluem o
projeto do sistema. Alterações não são restritas a nenhuma área em particular.
Os pares acrescentam valor à análise, ao projeto, à implementação e ao teste do
sistema. Eles agregam esse valor onde quer que o sistema precise.
• A integração ocorre imediatamente após o desenvolvimento, incluindo teste
de integração.
CAPÍTULO 3
A Economia no
Desenvolvimento de Software
Precisamos desenvolver nosso software economicamente mais valioso

gastando dinheiro mais devagar, obtendo rendimento mais rapidamente
e aumentando a provável expectativa de vida produtiva do nosso proje-
to. Mas o mais importante de tudo é aumentar as opções de decisões de
negócios.1
S
omando as entradas e saídas do fluxo de caixa do projeto, podemos analisar de
forma simples o que torna o projeto de software valioso. Levando em considera-
ção o efeito das taxas de juros, podemos calcular o valor líquido atualizado dos
fluxos de caixa. Podemos refinar nossas análises multiplicando os fluxos de caixa
descontados pela probabilidade do projeto sobreviver para pagar ou ganhar aqueles
fluxos de caixa.
Com estes três fatores,
• entrada e saída do fluxo de caixa

• taxa de juros
• mortalidade do projeto
podemos criar uma estratégia para maximizar o valor econômico do projeto. Pode-
mos fazer isso:
• gastando menos, o que é difícil porque todo mundo começa com mais ou me-
nos as mesmas ferramentas e habilidades;
• ganhando mais, o que só é possível com uma organização de vendas e um
marketing superior, tópicos que não serão abordados neste livro (graças a Deus);
• gastando mais tarde e ganhando mais cedo, pagando, assim, menos juros so-
bre o dinheiro que gastamos e ganhando mais juros sobre o dinheiro que rece-
bemos;
1
Agradeço a John Favaro pela análise da XP com estimativa de valores das opções.
• aumentando a probabilidade de o projeto se manter vivo, fazendo com que se-

ja mais provável conseguir o pagamento mais substancial no término do pro-
jeto.
Opções
Existe uma outra maneira de ver a economia de um projeto de software – como uma
série de opções. O gerenciamento de um projeto de software pode ser visto como ten-
do quatro tipos de opção:
• Opção de abandonar – você pode obter algo do projeto mesmo se você o can-
celar. Quanto mais você conseguir obter do projeto sem realmente entregá-lo
na forma prevista, melhor.
• Opção de trocar – você pode mudar a direção de um projeto. Uma estratégia
de gerenciamento de projeto é mais valiosa se, no meio dele, os clientes pude-
rem mudar os requisitos. Quanto mais freqüente e drasticamente os requisitos
puderem mudar, melhor.
• Opção de adiar – você pode esperar até a situação se resolver antes de inves-
tir. Uma estratégia de gerenciamento de software é mais valiosa se você puder
esperar para gastar dinheiro sem perder completamente a oportunidade de in-
vestir. Quanto maior o adiamento e maior a quantidade de dinheiro que puder
ser retida, melhor.
• Opção de crescer – se o mercado parece estar decolando, você pode crescer ra-
pidamente para tirar vantagem dele. Uma estratégia de gerenciamento de pro-
jeto é mais valiosa se puder aumentar graciosamente para, com maiores inves-
timentos, produzir cada vez mais. Quanto mais rápido o projeto puder crescer,
melhor. Quanto mais tempo ele puder crescer, também.
Calculando o valor das opções, temos duas partes de arte, cinco partes de mate-
mática e uma parte da boa e velha intuição.
Existem cinco fatores envolvidos:
• a quantidade de investimento requerida para realizar a opção;

• o preço que você pagará pela recompensa se você exercer a opção;
• o valor atual da recompensa;
• a quantidade de tempo pelo qual você poder exercer a opção;
• a incerteza do eventual valor da recompensa.
Dentre esses, o valor das opções geralmente é controlado pelo último dos fatores:
a incerteza. A partir dela, podemos fazer uma previsão concreta. Suponha que criás-
A ECONOMIA NO DESENVOLVIMENTO DE SOFTWARE 31
semos uma estratégia de gerenciamento de projeto que maximizasse o valor do pro-

jeto analisado como opções oferecendo:
• feedback preciso e freqüente sobre o progresso;

• muitas oportunidades para mudar drasticamente os requisitos;
• um investimento inicial menor;
• a oportunidade de avançar mais rapidamente.
Quanto maior a incerteza, mais valiosa se torna a estratégia. Isso é verdadeiro se

a incerteza decorrer de risco técnico, de um ambiente de negócios instável ou de re-
quisitos que evoluem rapidamente. (O que fornece uma resposta teórica à questão,
“Quando eu devo usar XP?”. Use XP quando os requisitos forem vagos ou instáveis.)
Exemplo
Suponha que você esteja programando alegremente e percebe que poderia acrescen-
tar uma funcionalidade que lhe custaria $ 10. Você estima que o retorno para essa
funcionalidade (seu valor líquido atual) é de aproximadamente $ 15. Então o valor lí-
quido atual por se acrescentar essa funcionalidade é $ 5.
Suponha agora que na verdade não estivesse bem claro o quanto essa nova fun-
cionalidade valeria – você estava apenas adivinhando, não tinha certeza de que va-
leria $ 15 para o cliente. Na verdade, você estima que o valor dela para o cliente po-
deria variar em até 100% da sua estimativa. Além disso, suponha (veja o Capítulo 5,
O Custo das Modificações,) que ainda lhe custaria em torno de $ 10 acrescentar essa
funcionalidade daqui a um ano.
Qual seria o valor da estratégia de apenas esperar e não implementar a funciona-
lidade agora? Ora, com as taxas de juros normais de aproximadamente 5%*, a calcu-
ladora da teoria das opções devolve um valor de $7,87.
A opção de esperar vale mais do que investir agora para acrescentar a funcionali-
dade. Por quê? Com tanta incerteza, a funcionalidade certamente pode ser muito
mais valiosa para o cliente e, neste caso, você não está tendo mais prejuízo imple-
mentando-a agora do que estaria se esperasse. Ou ela poderia não valer nada – nes-
te caso, você eliminou o problema de um exercício inútil.
No jargão das negociações, opções “eliminam risco negativo”.
*N. de R. Tais juros são realidade nos EUA. É sabido que, no Brasil, os juros são maiores.
CAPÍTULO 4
Quatro Variáveis
Vamos controlar quatro variáveis em nossos projetos – custo, tempo,

qualidade e escopo. Dentre estas, o escopo nos fornece a forma mais va-
liosa de controle.
T
emos aqui um modelo de desenvolvimento de software através da perspectiva
de um sistema de variáveis de controle. Neste modelo, existem quatro variáveis
no desenvolvimento de software:
• custo
• tempo
• qualidade
• escopo
A forma como o jogo de desenvolvimento de software é jogado neste modelo é a

seguinte: forças externas (clientes, gerentes) ficam encarregadas de definir os valores
de três dessas variáveis. O time de desenvolvimento fica com o valor resultante da
quarta variável.
Alguns gerentes e clientes acreditam que podem definir o valor de todas as qua-
tro variáveis. “Você vai terminar estes requisitos até o primeiro dia do próximo mês
com exatamente esta equipe. E a qualidade é fator primordial aqui, então o produto
terá o nosso padrão habitual.” Quando isso acontece, a qualidade sempre desapare-
ce (o que, na verdade, é o padrão habitual), já que ninguém faz um bom trabalho sob
muito estresse. É provável também que o tempo fique fora de controle. Você obtém
um software de baixa qualidade, e atrasado.
A solução é tornar visíveis as quatro variáveis. Se todos – programadores, clientes
e gerentes – puderem enxergar as quatro variáveis, poderão escolher de forma cons-
ciente quais delas controlar. Se eles não gostarem do resultado obtido para a quarta
variável, poderão alterar os valores de entrada, ou escolher três variáveis diferentes
para controlar.
Interação entre as Variáveis

Custo – Mais dinheiro pode facilitar um pouco as coisas, mas dinheiro demais mui-
to cedo cria mais problemas do que resolve. Por outro lado, dê pouquíssimo dinheiro
a um projeto e ele não será capaz de resolver o problema de negócio do cliente.
Tempo – Mais tempo para a entrega do produto pode aumentar a qualidade e ex-
pandir o escopo. Já que o feedback dos sistemas em produção tem muito mais quali-
dade do que qualquer outro tipo de feedback, dar a um projeto tempo demais irá pre-
judicá-lo. Dê ao projeto muito pouco tempo e a qualidade se deteriora, bem como o
escopo, o tempo e o custo.
Qualidade – A qualidade é terrível como variável de controle. Você pode ter ga-
nhos a curto prazo (dias ou semanas) se deliberadamente sacrificar a qualidade, mas
o custo – humano, comercial e técnico – é enorme.
Escopo – Um escopo menor faz com que seja possível fornecer maior qualidade
(desde que o problema de negócio do cliente ainda seja resolvido). Também permite
que você entregue o produto mais cedo ou mais barato.
Não existe uma relação simples entre as quatro variáveis. Por exemplo, você não
pode obter mais rapidamente o software gastando mais dinheiro. O ditado diz: “No-
ve mulheres não podem gerar um bebê em um mês”. (E ao contrário do que eu ouvi
de alguns gerentes, 18 mulheres ainda não podem gerar um bebê em um mês.)
De muitas formas, o custo é a variável mais restrita. Você não pode apenas com-
prar qualidade, escopo ou curtos ciclos de entrega. Na verdade, no começo de um
projeto, você não pode gastar muito de forma alguma. O investimento precisa come-
çar pequeno e crescer com o tempo. Mais tarde, você poderá gastar cada vez mais di-
nheiro de maneira produtiva.
Eu tive um cliente que disse: “Nós prometemos entregar todas essas funcionali-
dades. Para fazer isso, vamos precisar de 40 programadores”.
Eu respondi: “Você não pode ter 40 programadores no primeiro dia. Você precisa
começar com um time. Então passar para dois. Então quatro. Em dois anos você po-
derá ter 40 programadores, mas não hoje”.
Eles disseram: “Você não entende. Nós precisamos de 40 programadores’. Eu res-
pondi: ‘Vocês não podem ter 40 programadores”. Eles disseram: “Nós podemos
sim!”.
Eles não podiam. Ou melhor, podiam. Eles contrataram os 40 programadores. As
coisas não foram muito bem. Os programadores abandonaram o projeto, eles contra-
taram outros 40. Quatro anos depois, eles estavam apenas começando a agregar
valor ao negócio, um pequeno subprojeto de cada vez, e antes disso o projeto quase
foi cancelado.
Todas as restrições nos custos podem levar os gerentes à loucura. Em especial se
eles estão focados no processo orçamentário anual, eles estão tão acostumados a con-
siderar apenas o custo que cometerão grandes erros ignorando as restrições que tan-
to controle de custos proporcionam.
QUATRO VARIÁVEIS 35
O outro problema com o custo é que maiores investimentos geralmente alimen-

tam objetivos secundários, como status ou prestígio. “É claro, eu tenho um projeto
com 150 pessoas.” Isso pode levar a projetos que falham porque o gerente queria im-
pressionar. No fim, que status existe em escalar 10 programadores para o mesmo pro-
jeto e entregá-lo na metade do tempo?
Por outro lado, o custo está profundamente relacionado com as outras variá-
veis. Dentro dos limites de investimento que podem ser feitos de forma sensata, ao
gastar mais dinheiro, você pode expandir o escopo, ou pode agir de forma mais
ponderada e aumentar a qualidade, ou você pode (até certo ponto) reduzir o tem-
po para entrega.
Gastar dinheiro pode também reduzir o atrito – máquinas mais rápidas, mais es-
pecialistas técnicos, escritórios melhores.
As limitações de controlar projetos ao controlar o tempo geralmente são decorren-
tes de forças externas – o ano 2000 é o exemplo mais recente. Final de ano, antes que
o trimestre comece; quando está agendado para que o sistema antigo seja desligado;
uma feira importante – estes são alguns exemplos de restrições de tempo externas.
Logo, a variável tempo geralmente não está nas mãos do gerente de projeto, e sim
nas mãos do cliente.
Qualidade é outra variável peculiar. Muitas vezes, ao insistir em maior qualida-
de, você termina o projeto mais cedo, ou você pode obter mais resultados em um
mesmo período. Isso aconteceu comigo quando comecei a escrever testes de unida-
de (como descrito no Capítulo 2, Um Episódio de Desenvolvimento). Tão-logo eu ti-
nha os meus testes, eu ganhava tanta confiança em meu código que eu programava
mais rapidamente, sem estresse. Eu podia organizar meu sistema com mais facilida-
de, o que tornava o desenvolvimento mais fácil. Eu também já vi isso acontecendo
com equipes. Logo que eles começam a testar, ou assim que eles estabelecem padrões
de codificação, eles começam a produzir mais rapidamente.
Existe uma relação estranha entre qualidade interna e externa. Qualidade exter-
na é aquela mensurada pelo cliente. Qualidade interna é aquela mensurada pelos
programadores. Sacrificar temporariamente a qualidade interna para reduzir o tem-
po de entrega, torcendo para que a qualidade externa não sofra muito, é uma joga-
da de curto prazo tentadora. E você pode evitar o caos por algumas semanas ou me-
ses. Mas, no final, os problemas de qualidade interna vão alcançá-lo e farão o seu
software extremamente caro de ser mantido, ou incapaz de alcançar um nível com-
petitivo de qualidade externa.
Por outro lado, de vez em quando, você pode terminar o projeto mais rapidamen-
te ao relaxar as restrições de qualidade. Uma vez eu estava trabalhando em um siste-
ma para substituir um sistema legado em Cobol. Nossa restrição de qualidade era
que nós reproduzíssemos exatamente as respostas produzidas pelo sistema antigo.
Quando estávamos chegando perto da nossa data de entrega, ficou claro que nós po-
deríamos reproduzir todos os erros do sistema antigo, mas apenas se atrasássemos
muito a entrega do produto. Fomos até os clientes e lhes mostramos que nossas res-
postas estavam mais corretas, e oferecemos a opção de receberem o produto sem
atrasos se eles se dispusessem a acreditar em nossas respostas em vez das respostas
do sistema antigo.
Existe um efeito humano gerado pela qualidade. Todos querem fazer um bom tra-
balho, e trabalham muito melhor se sentem que estão fazendo um bom serviço. Se
você deliberadamente baixar a qualidade, sua equipe pode ir mais rapidamente a
princípio, mas logo a desmoralização de produzir um produto ruim vai superar
qualquer ganho temporário decorrente de não testar, não revisar ou não seguir pa-
drões.
Foco no Escopo
Muitas pessoas conhecem custo, qualidade e tempo como variáveis de controle, mas
ignoram a quarta. Para desenvolvimento de software, a variável mais importante de
se estar ciente é o escopo. Nem os programadores nem os empresários têm mais do
que uma vaga noção do que é valioso no software em desenvolvimento. Uma das de-
cisões mais importantes do gerenciamento de projetos é eliminar o escopo. Se você
controlar ativamente o escopo, poderá fornecer aos gerentes e aos clientes o controle
sobre custo, qualidade e tempo.
Uma das melhores coisas sobre o escopo é que ele é uma variável de grande va-
riação. Durante décadas, os programadores reclamaram: “Os clientes não conse-
guem nos dizer o que eles querem. Quando nós lhes damos o que eles dizem que
querem, eles não gostam”. Essa é uma verdade absoluta do desenvolvimento de soft-
ware. Os requisitos nunca estão claros de início. Clientes nunca conseguem dizer a
você exatamente o que eles querem.
O desenvolvimento de um software qualquer altera seus próprios requisitos. As-
sim que os clientes vêem o primeiro protótipo, eles percebem o que querem na se-
gunda versão... ou o que eles realmente queriam na primeira. E é um aprendizado
valioso, porque não poderia ter ocorrido baseado simplesmente em especulação. É
um aprendizado que só pode vir da experiência. Mas os clientes não conseguem che-
gar lá sozinhos. Eles precisam de pessoas que saibam programar, e que sirvam não
como guias, mas como parceiros.
E se nós encarássemos a indefinição maleável dos requisitos como uma oportuni-
dade, e não um problema? Então nós podemos encarar o escopo como a mais fácil de
nossas quatro variáveis de controle. Por ele ser tão maleável, podemos moldá-lo – um
pouquinho aqui, um pouquinho lá. Se o tempo para a data de entrega for curto, sem-
pre existe algo que pode ser postergado para a próxima versão. Ao não tentar fazer
demais, preservamos nossa habilidade de produzir a qualidade desejada em tempo.
Se criássemos um método de desenvolvimento baseado neste modelo, fixaríamos
a data, a qualidade e o custo de um software qualquer. Nós encararíamos o escopo co-
mo resultado das três primeiras variáveis. Então, com o avanço do desenvolvimen-
to, nós continuamente ajustaríamos o escopo para ele se ajustar às condições que en-
contrássemos.
Esse deveria ser um processo que tolerasse modificações com facilidade, porque
o projeto mudaria de direção com freqüência. Você não iria querer gastar muito em
um software que depois não pudesse ser usado. Você não iria querer construir uma
nova estrada só porque errou o caminho. Além disso, você precisaria ter um proces-
so que mantivesse o custo das mudanças condizente com a vida do sistema.
QUATRO VARIÁVEIS 37
Se você abrisse mão de funcionalidades importantes ao fim de cada ciclo de release,

o cliente logo ficaria aborrecido. Para evitar isso, a XP usa duas estratégias:
1. Você ganha muita prática ao fazer estimativas e ao utilizar os resultados

reais como entrada para novas estimativas. Estimativas melhores diminuem
a probabilidade de que você precise desistir de funcionalidades.
2. Você implementa os requisitos mais importantes para o cliente primeiro; as-
sim, se alguma funcionalidade precisar ser eliminada, ela será menos impor-
tante do que as funcionalidades que já estão no sistema.
CAPÍTULO 5
O Custo das Modificações
Sob certas circunstâncias, o aumento exponencial do custo de modificar

o software ao longo do tempo pode ser “achatado”. Se pudermos acha-
tar a curva, velhas suposições sobre a melhor maneira de desenvolver
software não mais existirão.
U
m dos pressupostos universais sobre engenharia de software é que o custo de
modificar um programa aumenta exponencialmente ao longo do tempo. Eu
consigo me lembrar de estar sentado em uma grande sala de aula com piso de
linóleo na época da faculdade vendo o professor desenhar no quadro a curva encon-
trada na Figura 1.
“O custo de consertar um problema em um software qualquer aumenta exponen-
cialmente ao longo do tempo. Um problema que talvez custe um dólar para ser con-
sertado se você o encontrou durante a análise de requisitos pode custar milhares de
dólares quando o software estiver em produção.”
Custo das modificações
Requisitos Análise Projeto Implementação Testes Produção
Figura 1 O custo das modificações aumentando exponencialmente ao longo do tempo.

Eu decidi naquele momento que nunca deixaria um problema chegar até a fase de
produção. Não senhor, eu iria encontrar os problemas o mais cedo possível. Resolve-
ria cada possível problema antecipadamente. Eu iria ver e rever meu código. De jei-
to nenhum eu iria custar ao meu empregador U$ 100.000.
O problema é que essa curva não é mais válida. Ou melhor, com uma combinação
de tecnologia e práticas de programação, é possível obter uma curva que é bem o
contrário disso. Hoje em dia, as histórias são possivelmente como a seguinte, que
aconteceu comigo recentemente em um sistema de gerenciamento de contratos de
seguro de vida.
17:00 – Descubro que aparentemente a maravilhosa função do nosso sistema com
a qual uma única transação pode ter débitos de muitas contas e créditos para muitas
contas simplesmente não é usada. Cada transição vem de uma conta e vai para ou-
tra. É possível simplificar o sistema como mostra a Figura 2?
17:02 – Peço para Massimo sentar-se comigo para examinar a situação. Escreve-
mos uma consulta. Cada uma das 300 mil transações no sistema tem uma única con-
ta de débito e uma única conta de crédito.
17:05 – Se fôssemos consertar o erro, como poderíamos fazer isso? Poderíamos
mudar a interface da transação e mudar a implementação. Escrevemos os quatro mé-
todos necessários e começamos os testes.
17:15 – Os testes (mais de 1.000 testes de unidade e de função) ainda rodam 100%.
Não conseguimos pensar em nenhuma razão para as modificações não darem certo.
Começamos a trabalhar no código de migração do banco de dados.
17:20 – Os batches noturnos estão terminados, e fizemos o back-up do banco de da-
dos. Instalamos as novas versões do código e rodamos a migração.
17:30 – Rodamos alguns testes de sanidade. Tudo em que podíamos pensar fun-
ciona. Incapazes de pensar em alguma outra coisa para fazer, vamos para casa*.
O dia seguinte – O log de erros está limpo. Sem reclamações dos usuários. A mo-
dificação deu certo.
Durante as duas semanas seguintes, descobrimos uma série de outras simplifica-
ções que só foram possíveis pela nova estrutura, que nos permitia expandir a parte
de contabilidade do sistema para uma funcionalidade inteiramente nova, tudo isso
tornando o sistema mais simples, mais claro e menos redundante.
A comunidade de desenvolvimento de software gastou inúmeros recursos nas úl-
timas décadas tentando reduzir o custo das modificações – melhores linguagens, me-
lhores tecnologias de banco de dados, melhores práticas de programação, melhores
ambientes e ferramentas, novas notações.
débitos*
Transação créditos* Componente de Transação
débito 1
Transação crédito 1 Componente de Transação
Figura 2 Podemos ter um único componente para cada débito e crédito?
*N. de R. O expediente normal de trabalho nos EUA se encerra às 17 h.

O CUSTO DAS MODIFICAÇÕES 41
O que faríamos se todo aquele investimento tivesse valido a pena? E se todo

aquele trabalho em linguagens e banco de dados e outras coisas parecidas tivesse
realmente chegado em algum lugar? E se o custo das modificações não aumentasse
exponencialmente ao longo do tempo, mas aumentasse muito mais devagar, even-
tualmente alcançando uma assíntota? E se o professor de engenharia de software de
amanhã desenhar a Figura 3 no quadro?
Essa é uma das premissas da XP. É a grande premissa técnica da XP. Se o custo das
modificações aumentasse vagarosamente ao longo do tempo, você agiria de manei-
ra completamente diferente da qual você age sob o pressuposto de que custos au-
mentam exponencialmente. Você tomaria grandes decisões o mais tarde possível, du-
rante o processo, para adiar o custo de tomar as decisões e para ter a maior chance
possível de que elas estejam certas. Você implementaria apenas o que é preciso, na
esperança de que as necessidades do amanhã por você antecipadas não se tornassem
realidade. Você introduziria elementos no projeto apenas se eles simplificassem o có-
digo existente e fizessem com que a escrita do próximo trecho de código fosse mais
simples.
Se uma curva de custo de modificações achatada faz a XP possível, uma curva ín-
greme de custo de modificações torna a XP impossível. Se as modificações forem de-
sastrosamente caras, você seria louco de seguir em frente sem refletir com cuidado.
Mas se as modificações se mantiverem baratas, o valor adicional e o risco reduzido
pelo feedback concreto antecipado excedem o custo adicional de se fazer modificações
mais cedo.
Manter baixo o custo das modificações não é uma coisa que acontece magicamen-
te. Existem tecnologias e práticas que mantém o software flexível.
Pelo ponto de vista tecnológico, objetos são a tecnologia-chave. O envio de men-
sagens é um jeito barato de construir muitas oportunidades para modificações. Cada
mensagem se torna um ponto em potencial para modificação futura, uma modifica-
ção que pode acontecer sem que o código já existente seja tocado.
Os bancos de dados orientados a objetos transferem essa flexibilidade para o do-
mínio do armazenamento permanente. Com um banco de dados orientado a objetos,
é possível migrar facilmente objetos em um formato para objetos em outro formato,
pois o código é anexado aos dados, e não separado, como em tecnologias de banco
de dados anteriores. Mesmo se você não conseguir achar uma maneira de migrar os
objetos, você pode ter duas implementações alternativas coexistindo.
Custo das modificações
Tempo
Figura 3 O custo das modificações talvez não aumente drasticamente ao longo do tempo.
O que não quer dizer que você tenha de ter objetos para ter flexibilidade. Eu
aprendi os fundamentos da XP assistindo ao meu pai escrever código de controle de
processos em tempo real em assembler. Ele desenvolveu um estilo que lhe possibilita-
va refinar continuamente o projeto de seus programas. No entanto, pela minha expe-
riência, o custo de modificações cresce mais abruptamente sem objetos do que com
eles.
O que não quer dizer que objetos sejam suficientes. Eu já vi (e provavelmente es-
crevi, para dizer a verdade) muitos códigos orientados a objetos que ninguém queria
tocar.
Muitos fatores surgiram da história sobre o que tornou nosso código fácil de mo-
dificar, mesmo depois de anos de produção:
• um projeto simples, sem elementos extras – sem idéias que ainda não eram
usadas, mas que se esperava que fossem usadas no futuro;
• testes automatizados, para que pudéssemos ter a certeza de que saberíamos se
acidentalmente modificássemos o comportamento atual do sistema;
• muita prática em modificar o projeto, para que, quando fosse necessário mu-
dar o sistema, nós não tivéssemos medo de tentar.
Com esses elementos definidos – projeto simples, testes e uma atitude de constan-
te refinamento do projeto – nós experimentamos a curva achatada da Figura 3. Uma
modificação que teria levado poucos minutos antes que muito código tivesse sido es-
crito levou 30 minutos depois de ter estado em produção por dois anos. E eu vejo
projetos gastando dias ou semanas tomando o mesmo tipo de decisão, em vez de fa-
zer o que eles precisam fazer ainda hoje e confiar neles mesmos para consertar isso
amanhã se for preciso.
Com essa mudança de pressuposto sobre o custo das modificações, vem a opor-
tunidade de abordar o desenvolvimento de software de uma forma completamente
diferente. É uma abordagem tão disciplinada quanto qualquer outra, mas é discipli-
nada em outras dimensões. Em vez de se ter o cuidado de tomar grandes decisões
mais cedo e pequenas decisões mais tarde, nós podemos criar uma abordagem para
o desenvolvimento de software que toma cada decisão rapidamente, mas apóia cada
decisão com testes automatizados, e que prepara você para efetivamente melhorar o
projeto do software quando você aprende uma maneira melhor de fazê-lo.
Porém, criar tal abordagem não será fácil. Nós teremos de reexaminar nossos
pressupostos mais enraizados sobre o que faz o desenvolvimento de software ser
bom. Nós podemos fazer essa jornada em etapas. Começaremos com uma história,
uma história que irá ancorar tudo mais que fazemos.
CAPÍTULO 6
Aprendendo a Dirigir
Precisamos controlar o desenvolvimento de software fazendo muitos

pequenos ajustes, e não uns poucos grandes ajustes, tal qual como quan-
do conduzimos um carro. Isso significa que nós precisaremos de feed-
back para saber quando estamos saindo do caminho, precisaremos de
muitas oportunidades para fazer correções além de fazer essas correções
a um custo razoável.
A
gora nós já temos a forma geral do problema – o custo extremamente elevado
do risco e a oportunidade de gerenciar esse risco por meio de opções – e do re-
curso necessário para formar a solução: a liberdade para fazer modificações
mais tarde durante o ciclo sem aumentar o custo significativamente. Agora precisa-
mos nos focar na solução. A primeira coisa de que precisamos é uma metáfora, uma
história compartilhada, para a qual podemos voltar em períodos de estresse ou de
decisão nos ajudar a mantermos o caminho certo.
Lembro-me claramente do dia em que comecei a aprender a dirigir. Minha mãe e
eu estávamos na Rodovia Interestadual 5, perto de Chico, na Califórnia, um trecho
de estrada reto e nivelado que se perde no horizonte. Eu estava no assento do passa-
geiro e minha mãe fez com que eu segurasse o volante. Ela me deixou sentir como o
movimento do volante afetava a direção do carro. E então ela me disse: “É assim que
se dirige. Alinhe o carro no meio da pista, em direção ao horizonte”.
Eu segui cuidadosamente pela rodovia, mantendo o carro exatamente no meio da
pista. Estava me saindo bem. Comecei então a divagar um pouquinho...
De repente voltei a prestar atenção quando o carro entrou no acostamento. Minha
mãe (sua coragem hoje me surpreende) suavemente colocou o carro de novo na es-
trada. E então ela realmente me ensinou sobre dirigirir: “Dirigir não é fazer o carro
andar na direção certa. Dirigir é prestar atenção constantemente, fazendo uma pe-
quena correção para um lado, outra pequena correção para o outro.”
Esse é o paradigma da XP. Mesmo que as coisas pareçam andar perfeitamente
bem, você não tira os olhos da estrada. A mudança é a única constante. Esteja sempre
preparado para ir um pouco para um lado, um pouco para o outro e, às vezes, para
ir para uma direção completamente diferente. Essa é a vida do programador.
Tudo muda em um software . Os requisitos mudam. O projeto muda. Os negócios

mudam. A tecnologia muda. O time muda. Os membros do time mudam. O proble-
ma não é a mudança por si só, porque ela vai acontecer; o problema é, na verdade, a
falta de habilidade para se lidar com a mudança quando ela chega.
O motorista de um projeto de software é o cliente. Se o software não faz o que ele
quer, você falhou. Obviamente, eles não sabem exatamente o que o software deveria
fazer. É por isso que desenvolver software é como dirigir, e não apenas alinhar o car-
ro na estrada. Nosso trabalho como programadores é dar ao cliente um volante e for-
necer feedback quanto à nossa posição na estrada.
A história da condução também fornece uma moral para o processo da XP em si.
Os quatro valores – comunicação, simplicidade, feedback e coragem – descritos no
próximo capítulo, mostram-nos como o desenvolvimento de software deveria ser sen-
tido. No entanto, as práticas para se atingir essa sensação serão diferentes para cada
lugar, tempo e pessoa. Ao conduzir o seu processo de desenvolvimento, você adota
um conjunto simples de práticas que lhe fornecem a sensação que você deseja. Ao
longo do desenvolvimento, você está o tempo todo consciente das práticas que o
aproximam e das que o afastam do seu objetivo. Cada prática é um experimento a ser
seguido, até que se prove que ele é inadequado.
CAPÍTULO 7
Quatro Valores
Nós teremos êxito quando tivermos um estilo que contempla um conjun-

to consistente de valores que servem para necessidades tanto humanas
quanto comerciais: comunicação, simplicidade, feedback e coragem.
A
ntes que possamos transformar a história sobre aprender a dirigir em um con-
junto de práticas para desenvolvimento de software, precisamos de algum pa-
râmetro para saber se estamos no caminho certo. De nada adiantaria inventar
um novo estilo de desenvolvimento para, no final, descobrir que não gostamos dele
ou que ele não funciona.
Metas individuais de curto prazo freqüentemente entram em conflito com metas
sociais de longo prazo. As sociedades aprenderam a lidar com esse problema desen-
volvendo um conjunto de valores a serem compartilhados, apoiados por mitos, ri-
tuais, punições e recompensas. Sem esses valores, o homem tende a voltar-se para
seus próprios interesses de curto prazo.
Os quatro valores da XP são:
• comunicação
• simplicidade
• feedback
• coragem
Comunicação
O primeiro valor da XP é a comunicação. Quando analisamos os problemas que ocor-
reram nos projetos, vemos que muitos deles foram provocados por alguém que não
conversou com outro alguém sobre alguma coisa importante. Algumas vezes, o pro-
gramador não fala para os outros sobre uma mudança fundamental no projeto.
Outras vezes, o programador não faz a pergunta certa para o cliente, fazendo com
que uma importante decisão de domínio seja prejudicada. Às vezes um gerente não
faz a pergunta certa para o programador e o progresso de projeto é reportado de ma-

neira errada.
A má comunicação não acontece por acaso. Existem muitas circunstância que le-
vam a um colapso nas comunicações. Um programador dá más notícias ao gerente e
o gerente pune o programador. O cliente diz algo importante para o programador e
o programador parece ignorar a informação.
A XP procura manter as comunicações certas fluindo através do emprego de mui-
tas práticas que não podem ser feitas sem comunicação. São práticas que fazem sen-
tido a curto prazo, como teste de unidade, programação em pares e estimativa de ta-
refas. O efeito de testar, programar em pares e estimar é a comunicação entre progra-
madores, clientes e gerentes.
Isso não quer dizer que a comunicação não seja obstruída em um projeto XP. As
pessoas ficam com medo, erram e se distraem. A XP emprega um “treinador” cujo
trabalho é perceber quando as pessoas não estão se comunicando e restabelecer o
vínculo entre elas.
Simplicidade
O segundo valor da XP é a simplicidade. O treinador XP pergunta ao time: “Qual a
coisa mais simples que poderia funcionar?”.
Simplicidade não é fácil. É muito difícil não antecipar aquilo que você precisará
implementar amanhã ou na próxima semana ou no próximo mês. Mas antecipar as
coisas compulsivamente é ser influenciado pelo medo do custo exponencial da cur-
va das modificações. Algumas vezes o treinador precisa gentilmente lembrar o time
de que eles estão sendo influenciados pelos seus medos: “Talvez você seja tão mais
inteligente do que eu que possa fazer essa tal de árvore dinamicamente balanceada
funcionar. Eu iria ingenuamente assumir que uma buscar linear funcionaria”.
Greg Hutchinson escreveu:
Uma pessoa pra quem eu estava prestando consultoria decidiu que

precisávamos de um diálogo de exibição de texto para uso geral. (OK,
como se já não tivéssemos o suficiente, mas tudo bem.) Nós
conversamos sobre como seria a interface para esse diálogo e como ele
funcionaria. O programador decidiu que o diálogo deveria ser
ligeiramente inteligente, variando o seu tamanho e o número de
quebras de linhas no string baseado no tamanho da fonte e em outras
variáveis. Eu perguntei para ele quantas pessoas precisavam dessa
funcionalidade atualmente, e ele era o único. Eu sugeri ainda que não
fizéssemos um diálogo tão inteligente, mas apenas um que funcionasse
para o caso dele (20 minutos de trabalho). Poderíamos fazer a classe e a
interface conhecidas e, quando necessário, faríamos a interface mais
inteligente. Eu não consegui convencer o programador, e ele gastou
dois dias fazendo o código. No terceiro dia, até os requisitos dele
tinham mudado, e ele já não precisava mais daquela parte. Dois dias-
homem foram desperdiçados em um projeto que já estava apertado. No
entanto, por favor me avise se você puder utilizar esse código. (Fonte:
e-mail.)
QUATRO VALORES 47
A XP está fazendo uma aposta. Está apostando que é melhor fazer uma coisa sim-
ples hoje e pagar um pouco mais amanhã para fazer alguma modificação nela se for
necessário do que fazer uma coisa mais complicada hoje que talvez nunca será usada.
Simplicidade e comunicação têm uma maravilhosa relação de suporte mútuo.
Quando mais você se comunica, mais claramente você vê o que precisa ser feito e tem
mais certeza sobre o que não precisa. Quanto mais simples for o sistema, menos vo-
cê precisa comunicar sobre ele. O que nos leva a uma comunicação mais completa,
especialmente se você pode simplificar o sistema o suficiente para precisar de menos
programadores.
Feedback
O terceiro valor na XP é o feedback. Outras frases do treinador são: “Não pergunte pa-
ra mim, pergunte ao sistema” e “Você já escreveu um caso de teste para isso?”. Feed-
back concreto sobre o estado atual do sistema é absolutamente inestimável. Otimismo
é uma doença profissional da programação. Feedback é o tratamento.
O feedback funciona em diferentes escalas de tempo. Primeiramente, o feedback
funciona na escala de minutos e dias. Os programadores escrevem testes de unidade
para toda a lógica do sistema que poderia não funcionar. Os programadores têm feed-
back concreto de minuto a minuto sobre o estado do sistema. Quando os clientes es-
crevem novas “histórias” (descrições das características), os programadores as ava-
liam imediatamente. Assim os clientes têm feedback concreto sobre a qualidade de
suas histórias. A pessoa que rastreia o progresso observa o término das tarefas para
dar, a todo o time, feedback sobre a probabilidade de eles terminarem tudo o que foi
definido para um dado período de tempo.
O feedback também funciona na escala de semanas e meses. Os clientes e testado-
res escrevem testes de funcionalidade para todas as histórias (que na verdade são
“casos de uso simplificados”) implementadas pelo sistema. Eles têm feedback concre-
to sobre o estado atual do sistema. Os clientes revisam o cronograma a cada duas ou
três semanas para ver se a velocidade geral do time fecha com o plano e também pa-
ra reajustar o plano. O sistema é colocado em produção assim que ele fizer sentido,
para que os negócios possam começar a sentir como o sistema se comporta em ação
e a descobrir como ele pode ser melhor explorado.
Produções precoces precisam de uma pequena explicação. Uma das estratégias
no processo de planejamento é o time colocar em produção as histórias mais impor-
tantes assim que possível. Isso dá aos programadores feedback concreto sobre a quali-
dade de suas decisões e sobre o processo de desenvolvimento que só é possível quan-
do colocamos a mão na massa. Alguns programadores nunca experimentaram um
sistema em produção. Como eles podem aprender a melhorar seu trabalho?
A maioria dos projetos parece ter uma estratégia exatamente oposta. O pensa-
mento parece ser: “Quando o sistema entra em produção, você não pode fazer alte-
rações interessantes, então mantenha o sistema em desenvolvimento o maior tempo
possível”.
Na verdade, é o contrário. “Em desenvolvimento” é um estado temporário, em
que o projeto fica uma pequena parte de sua vida. É muito melhor dar ao sistema
uma vida independente, fazendo-o sobreviver por si mesmo. Você terá que simulta-
neamente gerenciar a produção e desenvolver novas funcionalidades. É melhor se
acostumar mais cedo a equilibrar a produção e o desenvolvimento do que fazê-lo tar-
de demais.
O feedback concreto trabalha juntamente com a comunicação e a simplicidade.

Quanto mais feedback você tiver, mas fácil será se comunicar. Muitas horas de discus-
são podem ser poupadas se, quando alguém tiver alguma objeção ao seu código, ele
lhe entregar um caso de teste que faz esse código falhar. Se você estiver se comuni-
cando claramente, você saberá o que é preciso testar e medir para aprender sobre o
sistema. Sistemas simples são mais fáceis de se testar. Escrever o teste faz você se con-
centrar na simplicidade do sistema – antes de os teste executarem, você não termi-
nou; e quando todos executarem, você terminou.
Coragem
Dentro do contexto dos três primeiros valores – comunicação, simplicidade e feedback
– é hora de acelerar o passo. Se você não correr na sua velocidade máxima, uma ou-
tra pessoa o fará e ganhará a corrida.
Aqui está uma história de coragem em ação. No meio da oitava iteração das 10
iterações agendadas (25 semanas das 30) da primeira versão do primeiro grande pro-
jeto XP, o time descobre uma falha em uma parte essencial da arquitetura. Os escores
do teste funcional vinham crescendo adequadamente, mas de repente pararam de
crescer de modo que ficavam bem abaixo de onde deveriam estar. O conserto de um
defeito causava um outro. O problema era uma falha na arquitetura.
(Para os curiosos, o sistema computava folhas de pagamento. “Vencimentos” re-
presentava aquilo que a companhia devia aos empregados. “Descontos” representa-
va o que os empregados deviam a outras pessoas. Algumas pessoas estavam usando
Vencimentos negativos quando elas deveriam estar usando Descontos positivos).
O time fez exatamente a coisa certa. Quando descobriram que não tinham mais
como seguir a diante, eles consertaram a falha. Isso imediatamente fez com que me-
tade dos testes que estavam executando falhassem. Alguns dias de muito esforço, no
entanto, fizeram com que os escores dos testes estivessem novamente seguindo para
a meta final. Foi preciso coragem para isso.
Outro ato corajoso é jogar o código fora. Você sabe quando algumas vezes você
trabalha todo o dia em cima de algo que não está indo muito bem e a máquina trava?
E na manhã seguinte você chega e em meia hora refaz todo o trabalho do dia ante-
rior, mas desta vez de maneira organizada e simples?
Faça assim: se o final do dia chega e o código está um pouco fora do controle, jo-
gue-o fora. Guarde talvez os casos de teste, se você gostou da interface que projetou,
mas talvez não. Você pode recomeçar tudo do nada.
Ou você pode ter três alternativas de projeto. Assim, trabalhe em cima de cada al-
ternativa por um dia, só para experimentá-las. Livre-se do código e recomece em ci-
ma do projeto mais promissor.
A estratégia de projeto da XP se parece com um algoritmo para escalar uma coli-
na (hill-climbling). Você começa com um projeto simples, então você o transforma em
algo um pouco mais complexo, e depois em um pouco mais simples, para então dei-
xá-lo um pouco mais complexo. O problema com algoritmos para escalar colinas é al-
cançar um local ótimo, onde uma pequena mudança não consegue melhorar a situa-
ção, mas uma grande mudança consegue.
O que garante que você nunca chegará a uma rua sem saída? Coragem. De vez
em quando, alguém no time irá ter uma idéia louca que talvez acabe com a comple-
xidade de todo o sistema. Se eles tiverem coragem, irão colocar essa idéia em produ-
ção. Agora você está escalando uma colina inteiramente nova.
QUATRO VALORES 49
Se você não tiver definido os três primeiro valores, coragem por si só é apenas fu-
çar em seu próprio sistema (hacking). No entanto, quando combinada com comuni-
cação, simplicidade e feedback concreto, a coragem se torna extremamente valiosa.
A comunicação dá suporte à coragem porque abre a possibilidade para mais ex-
periências de alto risco e alta recompensa. “Você não gosta disso? Eu odeio esse có-
digo. Vamos ver o quanto dele podemos substituir em uma tarde.” A simplicidade dá
suporte à coragem porque você pode se dar o luxo de ser muito mais corajoso com
um sistema simples. É muito menos provável que você estrague o sistema inadverti-
damente. Coragem dá suporte à simplicidade porque, assim que a oportunidade de
simplificar o sistema é percebida, você a experimenta. O feedback concreto dá supor-
te à coragem porque você se sente muito mais seguro experimentando algo extremo
no código se você puder pressionar um botão e ver resultados positivos nos testes
(ou não, no caso de você jogar o código fora).
Os Valores em Prática
Eu pedi ao time C3 (aquele primeiro grande projeto XP que eu mencionei anterior-
mente) para me contar histórias sobre o momento mais marcante durante o projeto.
Eu esperava ouvir histórias sobre grandes refatorações, ou sobre como testes salva-
ram o projeto, ou sobre um cliente satisfeito. Em vez disso eu recebi isto:
O momento que mais me marcou foi quando Eddie mudou-se para um

emprego mais perto de sua casa, evitando um deslocamento diário de
duas horas. Assim, ele pôde passar mais tempo com sua família. O time
mostrou a ele completo respeito. Ninguém disse nada contra a saída
dele. Todos perguntaram o que poderiam fazer para ajudar.
Isso nos leva a um valor muito mais profundo, aquele que se esconde por baixo
dos outros quatro – respeito. Se os membros do time não se importarem uns com os
outros e com o que eles estão fazendo, a XP estará condenada. Da mesma forma, a
maioria das outras abordagens de desenvolvimento de software (ou de qualquer ou-
tra coisa) também estará. Porém, a XP é muito mais sensível a isso. Com um pouco
de compaixão e interesse, a XP talvez dê alguma lubrificação para todas aquelas pe-
ças se movendo juntas. Se os membros de um time não se importarem com o projeto,
nada mais poderá salvá-lo. Com um mínimo de paixão, a XP já dá algum feedback po-
sitivo. Isso não é manipulação; isso é gostar de fazer parte de algo que dá certo, em
vez de fazer parte de algo que não funciona.
Toda essa filosofia é muito boa, mas se não há uma maneira de colocá-la em prá-
tica, de reforçá-la e de tornar seus valores um hábito natural, então não passará de
uma outra tentativa frustrada na história das boas intenções metodológicas. A seguir
precisaremos ter um guia mais concreto que nos levará a práticas que satisfazem e
reúnem os quatro valores – comunicação, simplicidade, feedback e coragem.
CAPÍTULO 8
Princípios Básicos
A partir dos quatro valores, nós derivamos aproximadamente uma dú-

zia de princípios para guiar nosso novo estilo. Vamos conferir as práti-
cas de desenvolvimento propostas para ver se elas estão à altura desses
princípios.
O
capítulo Aprendendo a Dirigir nos aconselha a fazer diversas pequenas mu-
danças e a nunca desviar os olhos da estrada. Os quatro valores – comunica-
ção, simplicidade, feedback e coragem – nos dão os critérios para uma solução
de sucesso. No entanto, os valores são muito vagos para nos ajudar a decidir quais
práticas usar. Precisamos transformar os valores em princípios concretos que possam
ser usados.
Esses princípios vão nos ajudar a escolher entre as alternativas. Daremos prefe-
rência às alternativas que melhor atendam aos princípios. Cada princípio incorpora
os valores. Um valor pode ser vago. O que é simples para uma pessoa pode ser com-
plexo para outra. Um princípio é mais concreto. Ou você tem feedback rápido ou não.
Aqui estão os princípios fundamentais:
• feedback rápido
• simplicidade presumida
• mudanças incrementais
• aceitação das mudanças
• alta qualidade
Feedback rápido – A psicologia do aprendizado ensina que o tempo decorrido entre

uma ação e seu feedback é fundamental para a aprendizagem. Experimentos com ani-
mais mostram que até pequenas diferenças no tempo de feedback resultam em gran-
des diferenças de aprendizagem. Bastam alguns segundos de atraso entre o estímu-
lo e a resposta para o rato não aprender que o botão vermelho significa comida. En-
tão, um dos princípios é obter o feedback, interpretá-lo e aplicar o que é aprendido no

sistema o mais rápido possível. O negócio aprende qual a melhor forma de o sistema
contribuir, e realimenta o que foi aprendido em dias ou semanas, em vez de meses ou
anos. Os programadores aprendem qual a melhor forma de se projetar, implementar
e testar o sistema, e realimentam o que foi aprendido em segundos ou minutos, em
vez de dias, semanas ou meses.
Simplicidade presumida – Trate cada problema como se pudesse ser resolvido de
maneira ridiculamente simples. O tempo que você economiza nos 98% dos proble-
mas para os quais isto será verdade lhe dará muitos recursos para aplicar nos outros
2%. De certa forma, este é o princípio que os programadores têm mais dificuldade
em aceitar. Tradicionalmente, nós somos orientados a planejar para o futuro, para
projetar para o reúso. Em vez disso, a XP recomenda que o trabalho de hoje (testes,
refatoração e comunicação) resolva os problemas de hoje. Recomenda também con-
fiar em sua habilidade de adicionar complexidade no futuro onde ela for necessária.
A economia de software como opções favorece essa abordagem.
Mudanças incrementais – Grandes modificações feitas de uma vez só simplesmen-
te não funcionam. Até mesmo na Suíça, o centro do planejamento meticuloso, onde
eu moro hoje em dia, eles não tentam fazer grandes modificações. Qualquer proble-
ma é resolvido com uma série das menores mudanças que fazem diferença.
Você descobrirá que a modificação incremental é aplicada de muitas formas na
XP. O projeto é modificado um pouco de cada vez. O planejamento muda um pouco
de cada vez. O time muda um pouco de cada vez. Até a adoção da XP precisa ser fei-
ta em pequenos passos.
Aceitação das mudanças – A melhor estratégia é aquela que preserva o maior núme-
ro de opções enquanto resolve o seu problema mais urgente.
Alta qualidade – Ninguém gosta de trabalhar de forma desleixada. Todos gostam
de fazer um bom trabalho. Das quatro variáveis de desenvolvimento de projetos – es-
copo, custo, tempo e qualidade – qualidade não é verdadeiramente uma variável li-
vre. Os únicos valores possíveis são “excelente” ou “insanamente excelente”, depen-
dendo se vidas estão em jogo ou não. Do contrário, você não aprecia o seu trabalho,
não trabalha bem e o projeto vai por água abaixo.
A seguir estão alguns princípios menos fundamentais. Eles também nos ajudarão
a decidir o que fazer em situações específicas.
• ensinar aprendendo;
• investimento inicial pequeno;
• jogar para ganhar;
• experimentação concreta;
• comunicação honesta e franca;
• trabalhar a favor dos instintos do pessoal, e não contra eles;
• aceitação de responsabilidades;
• adaptação local;
• viajar com pouca bagagem;
• métricas genuínas.
PRINCÍPIOS BÁSICOS 53
Ensinar aprendendo – Em vez de criar uma série de declarações doutrinárias como

“Farás testes da maneira XYZ”, nós nos focaremos em ensinar estratégias para apren-
der quantos testes são necessários. E também quanto projeto*, quanta refatoração e
quanto de todas as outras coisas deve ser feito. Algumas idéias vamos declarar com
convicção. Em outras, não teremos tanta confiança, e estas nós vamos declarar como
estratégias com as quais o leitor poderá aprender suas próprias respostas.
Investimento inicial pequeno – Recursos demasiados muito cedo em um projeto é
uma receita para o desastre. Orçamentos apertados forçam os programadores e os
clientes a cortar requisitos e reduzir propostas. A concentração gerada por um orça-
mento apertado leva você a fazer um bom trabalho em todas as áreas. No entanto, os
recursos podem ser apertados demais. Se você não tem os recursos para resolver
nem mesmo um único problema interessante, o sistema que você cria com certeza
não será interessante. Se existe alguém ditando o escopo, as datas, a qualidade e o
custo, você será incapaz de alcançar o sucesso. Entretanto, na maioria das vezes, to-
dos podem viver com menos recursos do que gostariam.
Jogar para ganhar – Era sempre maravilhoso ver os times de basquete da UCLA,
treinados por John Wooden. Na maioria das vezes, eles esmagavam os oponentes.
Mesmo se o jogo estivesse em seus minutos finais, o time da UCLA tinha certeza ab-
soluta de que iria ganhar. Afinal eles já tinham ganhado tantas outras vezes. Então
eles ficavam tranqüilos. Eles faziam o que precisava ser feito. E ganhavam de novo.
Lembro-me de um jogo de basquete do Oregon que apresentou um forte contras-
te. O time do Oregon estava jogando contra o time do Arizona, na época com uma
ótima escalação, que em breve mandaria quatro de seus jogadores para a NBA. No
intervalo, surpreendentemente, o Oregon estava com uma vantagem de 12 pontos. O
Arizona não conseguia acertar uma, e o ataque do Oregon mantinha os jogadores do
Arizona desorientados. Após o intervalo, no entanto, o Oregon voltou e tentou jogar
o mais devagar possível, para reduzir o número de pontos convertidos e garantir a
vitória. A estratégia não funcionou, é claro. O Arizona encontrou maneiras de utili-
zar sua superioridade em talentos para ganhar o jogo.
É a diferença entre jogar para ganhar e jogar para não perder. A maior parte do
desenvolvimento de software que eu vejo por aí é jogado para não perder. Muito pa-
pel escrito, muitas reuniões feitas. Todos estão tentando fazer o desenvolvimento
“pelo manual”, não porque ele faça algum sentido, mas porque eles querem poder
dizer no final que não foi culpa deles, eles estavam seguindo o procedimento e “pas-
se bem” **.
O desenvolvimento de software jogado para ganhar faz tudo aquilo que ajuda o ti-
me a ganhar e nada daquilo que não o ajuda a ganhar.
Experimentação concreta – Cada vez que você toma uma decisão e não a testa, exis-
te uma probabilidade de que a decisão esteja errada. Quanto mais decisões você to-
ma, mais esses riscos se acumulam. Assim, o resultado de uma sessão de projeto de-
*N. de R.T. O termo original design foi aqui traduzido por projeto quando seu significado é basicamente “um conjun-
to de atividades de concepção de um sistema que antecede (em verdade, prepara) a implementação”. Estas atividades
envolvem decisões do espaço- solução como uso de determinada arquitetura ou adoção de determinados padrões (pat-
terns). O termo “desenho” nos parece inapropriado para isto. Nas raras vezes em que o significado é diverso, adota-
mos traduções que julgamos adequadas caso a caso.
**N. de R. T. A expressão original CYA é uma forma abreviada difundida na Internet para See ya, ou mais completa-
mente, See you later cuja tradução: Vejo você depois, é o mundo dos negócios, a expressão costuma ser usada com um
significado adicional aproximado de “passe bem” ou “e eu com isso?”.
veria ser uma série de experimentos voltados às questões levantadas durante a ses-
são, e não um projeto pronto. O resultado de uma discussão sobre os requisitos tam-
bém deveria ser uma série de experimentos. Toda decisão abstrata deve ser testada.
Comunicação honesta e franca – Esta é uma afirmação tão básica que eu quase a dei-
xei de fora. Quem não ia querer se comunicar de maneira franca e honesta? Aparen-
temente, todos que eu visito. Os programadores precisam ter liberdade de explicar as
conseqüências das decisões que outros fazem: “Você violou o encapsulamento aqui
e isso gerou uma bagunça!”. Eles têm de poder indicar uns aos outros onde o código
está com problemas. Eles precisam ter liberdade para expressar seus receios e preci-
sam receber apoio. Eles devem poder dar más notícias aos clientes e à gerência, e fa-
zê-lo cedo, e não serem punidos.
Se eu percebo que alguém está olhando em volta para saber quem o está escutan-
do antes de responder uma pergunta, eu vejo isso como um sinal de sérios problemas
no projeto. Se assuntos pessoais precisam ser discutidos, eu entendo que seja neces-
sária privacidade. Mas decidir qual modelo de objetos usar não é assunto que mere-
ça um carimbo de “confidencial”.
Trabalhar a favor dos instintos do pessoal e não contra eles – As pessoas gostam de
ganhar. Elas gostam de aprender. Gostam de interagir com outras pessoas. Pessoas
gostam de fazer parte de um time. Gostam de estar no controle. Gostam que con-
fiem nelas. Gostam de fazer um bom trabalho. Gostam que seu software funcione.
Paul Chilsolm escreveu certa vez:
Eu estava em uma reunião, e o candidato a gerente de controle de

qualidade sugeriu que fossem adicionados cerca de 12 campos (a um
formulário on-line que já estava cheio de dados que ninguém usava),
não porque a informação seria útil no final, mas porque
presumivelmente o preenchimento desses campos adicionais
ECONOMIZARIA TEMPO. Minha reação foi bater a cabeça contra a
mesa da sala de reunião, como um personagem de desenho animado da
Warner Brothers que acaba de escutar algo inacreditável e dizer para
ele parar de mentir para mim. (Até hoje, eu não sei se essa foi a atitude
menos profissional que eu já tive, ou a mais profissional. Um oculista
me disse para parar de bater minha cabeça contra as coisas, isso pode
levar ao descolamento da retina.) (Fonte: e-mail.)
É complicado projetar um processo no qual seguir interesses pessoais de curto

prazo também favoreça os interesses de longo prazo do time. Você pode afirmar o
quanto quiser que algumas práticas são para o bem de todos a longo prazo, mas
quando a pressão aumenta, se a prática não resolve um problema imediato, ela será
descartada. Se a XP não trabalhar com os interesses de curto prazo do pessoal, ela es-
tará destinada ao buraco negro das metodologias.
Algumas pessoas adoram isto na XP, o fato de ela exaltar o que aparentemente os
programadores fazem quando deixados à vontade para fazer o que quiserem, apenas
com controle suficiente para manter o processo no caminho certo. Lembro-me de
uma citação que diz: “A XP é como a observação de programadores no seu habitat na-
tural (programmers in the wild)”.
Aceitação de responsabilidades – Nenhuma ação tira mais o ânimo de um time ou de
uma pessoa do que dizer o que ela deve fazer, especialmente se o trabalho é impos-
sível. Esse tipo de dominação funciona apenas para fazer as pessoas agirem como se
PRINCÍPIOS BÁSICOS 55
estivessem cooperando. Com o tempo, uma pessoa a quem mandaram fazer alguma
coisa encontrará muitas maneiras de expressar sua frustração, a maior parte em de-
trimento do time e muitas delas em detrimento pessoal.
A alternativa é que a responsabilidade seja aceita, e não dada. Isso não quer di-
zer que você fará apenas o que você quiser. Você faz parte de um time, e se o time
conclui que uma certa tarefa precisa ser feita, alguém escolherá fazê-la, por pior
que seja.
Adaptação local – Você precisa adaptar às suas condições locais tudo o que ler nes-
te livro. Isso é a aplicação do princípio da aceitação de responsabilidades ao proces-
so de desenvolvimento. Adotar a XP não significa que eu vá decidir como você vai
desenvolver software. Significa que você irá decidir como desenvolver. Eu posso lhe
contar o que eu descobri que funciona bem. Eu posso apontar as conseqüências de
você se desviar disso. Porém, no final das contas, este é o seu processo. Você precisa
tomar uma decisão hoje. Você precisa saber se ela ainda funcionará amanhã. Você
precisa modificar e adaptar. Não leia este livro pensando: “Até que enfim, agora eu
sei como desenvolver”. Você vai terminar dizendo: “Eu preciso decidir tudo isso e
ainda programar?”. Sim, você precisa. Mas vale a pena.
Viajar com pouca bagagem – Você não pode esperar que carregando muita bagagem
ainda possa andar rápido. Os artefatos que mantemos devem ser:
• poucos,
• simples,
• valiosos.
Os integrantes de um time XP tornam-se nômades intelectuais, sempre prepara-

dos para levantar acampamento e seguir o bando. O bando, neste caso, pode ser um
design que quer seguir uma direção diferente da antecipada, ou um cliente que quer
seguir uma direção diferente da antecipada, ou um membro do time que vai embo-
ra, ou uma tecnologia que repentinamente fica popular, ou um clima de negócios que
se altera.
Como os nômades, o time XP se acostuma a viajar com pouca bagagem. Eles não
carregam nada exceto aquilo que é preciso para continuar produzindo valor para o
cliente – testes e código.
Métricas genuínas – Nossa busca por controle sobre o desenvolvimento de software
levou-nos a adotar métricas, o que é bom, mas acabou nos levando a mensurar com
um nível de detalhamento que não é suportado pelos nossos instrumentos. É melhor
dizer “Isto vai demorar mais ou menos duas semanas” do que “14.176 horas”, se vo-
cê não conseguir realmente estimar com esse nível de detalhamento. Nós também
nos esforçaremos para escolher métricas que estejam correlacionadas ao modo como
queremos trabalhar. Linhas de código, por exemplo, são uma métrica inútil em face
de um código que encolhe quando aprendemos melhores formas de programar.
CAPÍTULO 9
De Volta ao Básico
Queremos fazer tudo que for necessário para ter um desenvolvimento de

software estável e previsível. Porém, não temos tempo para nada extra.
As quatro atividades básicas do desenvolvimento são codificar, testar, es-
cutar e projetar.
O
capítulo Aprendendo a Dirigir mais os quatro valores – comunicação, sim-
plicidade, feedback e coragem – nos fornecem diversos princípios. Agora es-
tamos prontos para começar a construir uma disciplina de desenvolvimento
de software. O primeiro passo é decidir sobre o escopo. O que tentaremos prescrever?
Que tipo de problemas iremos abordar e que tipo de problemas iremos ignorar?
Lembro-me de quando comecei a programar em BASIC. Eu tinha alguns livros de
exercícios que cobriam os fundamentos da programação. Quando eu terminei todos
os exercícios (o que não demorou muito) eu queria tentar resolver um problema mais
desafiador. Resolvi que tentaria escrever um jogo tipo Star Trek, parecido com o que
eu tinha jogado no Lawrence Hall of Science em Berkeley, mas mais divertido.
Meu processo de escrever programas para resolver os exercícios dos livros era
olhar para o problema por alguns minutos, digitar o código para resolvê-lo, e então
lidar com qualquer problema que aparecesse. Então eu sentei confiante para escrever
o meu jogo. Nada me ocorreu. Eu não tinha a mínima idéia de como escrever uma
aplicação com mais de 20 linhas. Decidi, então, escrever todo o programa no papel
antes de digitar o código. Escrevi três linhas e não consegui seguir a diante.
Eu precisava fazer algo além de programar. Mas eu não sabia o que mais poderia
fazer.
E se voltássemos a esse estado, mas sob a luz da experiência? O que poderíamos
fazer? Sabemos que não podemos simplesmente “codificar até terminar”. Que ativi-
dades devemos adicionar ao processo? O que extrairíamos de cada atividade se o ex-
perimentássemos novamente?
Codificar
No final do dia é preciso haver um programa. Por isso eu denominei “codificar”
aquela atividade que sabemos não poder contornar. Seja através de diagramas que
geram código ou pela entrada do código em um navegador, você está codificando.
O que é que queremos extrair do código? O mais importante é o aprendizado. A
maneira com que aprendo é ter uma idéia e depois testá-la para ver se ela é boa ou
não. Escrever código é a melhor maneira que eu conheço para fazer isso. O código
não é controlado pelo poder ou pela lógica da retórica. O código não se impressiona
por diplomas de graduação ou salários robustos. O código fica parado no seu lugar,
fazendo alegremente aquilo que você diz para ele fazer. Se ele não está fazendo o que
você achava que disse para ele fazer, isso é problema seu.
Quando você codifica alguma coisa, você também tem a oportunidade de com-
preender a melhor estrutura para o código. Existem certos sinais no código que lhe
dizem que você ainda não compreende a estrutura necessária.
O código também lhe dá a chance de se comunicar de forma clara e sucinta. Se vo-
cê explicar para mim uma idéia que você teve, eu posso não entendê-la. Porém, se
nós a codificarmos juntos, eu poderei ver na lógica em que você escreve o formato
preciso de suas idéias. Eu vejo o formato de suas idéias não como você o tem em sua
mente, mas sim como ele se expressa no mundo real.
Essa comunicação facilmente se transforma em aprendizado. Eu entendo a sua
idéia e acabo tendo uma outra. Eu não consigo explicá-la para você, então eu tam-
bém a transformo em código. Já que é uma idéia relacionada com a sua, nós usamos
código relacionado. Você vê a minha idéia e tem uma outra.
Por fim, o código é um artefato sem o qual o desenvolvimento não consegue vi-
ver. Eu já ouvi histórias sobre sistemas cujo código-fonte foi perdido, mas mesmo as-
sim eles continuaram em produção. No entanto, fenômenos desse tipo são cada vez
mais raros. Para um sistema viver, ele precisa manter o seu código-fonte.
Já que necessitamos de um código-fonte, devemos usá-lo para tantos propósitos
de engenharia de software quanto possível. Acontece que o código serve como meio
de comunicação – expressando intenções táticas, descrevendo algoritmos, apontan-
do para pontos que poderão ser expandidos ou reduzidos no futuro. O código tam-
bém pode ser usado para expressar testes, que não apenas testam objetivamente o
sistema mas também provêm uma valiosa especificação operacional do sistema em
todos os aspectos.
Testar
Os filósofos positivistas ingleses Locke, Berkeley e Hume disseram que tudo o que
não puder ser mensurado não existe. Quando se trata de código, eu concordo comple-
tamente com eles. As funções do software que não podem ser demonstradas por sim-
ples testes automatizados não existem. Eu tenho a tendência de acreditar que tudo o
que escrevi reflete exatamente o que eu queria dizer. Eu também tenho a tendência de
acreditar que tudo o que eu queria dizer é o que eu deveria querer dizer. Então eu não
confio em nada que escrevo até que eu teste o que eu fiz. Os testes me dão a chance de
pensar sobre o que eu quero independentemente da implementação. Assim, os testes
me dizem se eu implementei aquilo que eu pensei ter implementado.
Quando as pessoas pensam em testes automatizados, elas pensam em testar fun-
cionalidade – ou seja, quais números são computados. Quanto mais experiência ob-
DE VOLTA AO BÁSICO 59
tenho escrevendo testes, mais eu descubro que eu posso testar requisitos não-funcio-
nais – como performance ou fidelidade do código aos padrões.
Erich Gamma cunhou a expressão “infectado por testes” para descrever aquelas
pessoas que não escrevem código se elas ainda não têm um teste. Os testes lhe dizem
quando você terminou – quando os testes executam, você por enquanto terminou de
codificar. Quando você não consegue pensar em nenhum outro teste que talvez fa-
lhe, você terminou por completo.
Os testes são tanto um recurso quanto uma responsabilidade. Você não faz ape-
nas um teste, executa-o e declara que você terminou. Você é responsável por escrever
todo teste que se supõe não executam de imediato. Depois de um tempo, você ficará
bom em julgar o número de testes – se os dois primeiros testes funcionam, você po-
de seguramente concluir que o terceiro executará sem que você precise escrevê-lo.
Claro que esse é exatamente o tipo de julgamento que leva a erros nos programas, as-
sim é preciso ser cuidadoso ao julgar. Se mais tarde aparecerem problemas que pode-
riam ter sido evitados caso aquele terceiro teste tivesse sido escrito, você precisa es-
tar preparado para aprender a lição e escrevê-lo na próxima vez.
A maioria dos softwares é entregue sem ter sido desenvolvida com testes automa-
tizados abrangentes. Testes automatizados claramente não são essenciais. Então, por
que não deixá-los fora da minha lista de atividades essenciais? Eu tenho duas respos-
tas: uma a curto e outra a longo prazo.
A resposta a longo prazo é que testes mantêm o programa vivo por mais tempo
(se os testes são executados e mantidos). Se você tem testes, você pode fazer mais
modificações por mais tempo. Se você continua escrevendo os testes, sua confiança
no sistema aumenta ao longo do tempo.
Um de nossos princípios é trabalhar a favor da natureza humana, e não contra. Se
tudo o que você pôde fazer foi argumentar a longo prazo a favor dos testes, esqueça.
Algumas pessoas escreveriam testes por obrigação ou porque alguém está as obser-
vando. Tão-logo a sua atenção desviasse ou a pressão aumentasse, nenhum novo tes-
te seria escrito, os que foram escritos não executariam e tudo desabaria. Assim, se vo-
cê quiser ir a favor da natureza humana e se quisermos testes, então devemos achar
uma razão para testar que seja de curto prazo.
Felizmente, existe uma razão de curto prazo para escrever testes. Programar
quando você tem testes é mais divertido do que programar sem eles. Você codifica
com muito mais confiança. Você não precisa ignorar aqueles pensamentos inoportu-
nos como “Bem, esta é a coisa certa a fazer agora, mas será que estraguei algo?”.
Aperte o botão. Execute todos os testes. Se aparecer a luz verde, você está pronto pa-
ra continuar seu trabalho com confiança renovada.
Uma vez eu me vi fazendo isso em uma demonstração pública de programação.
Toda vez que eu me desviava da platéia para recomeçar a programar, eu pressiona-
va meu botão de testes. Eu não tinha modificado nada no código. Nada no ambiente
tinha mudado. Eu só queria um pequeno empurrão na minha confiança. Ver que os
testes ainda executavam me dava isso.
Programar e testar ao mesmo tempo é mais rápido do que só programar. Eu não
esperava esse efeito quando comecei a fazer isso, mas eu certamente notei a diferen-
ça e ouvi várias outras pessoas dizerem o mesmo. Você talvez ganhe produtividade
por meia hora sem usar testes. Mas uma vez que você se acostumou a testar, rapida-
mente notará a diferença na produtividade. O ganho em produtividade vem da re-
dução no tempo de depuração – você não precisa mais gastar uma hora inteira pro-
curando a causa de um bug – você a encontra em poucos minutos. Algumas vezes,
você simplesmente não consegue fazer um teste funcionar. Então você provavelmen-
te tem um problema muito maior e precisa repensar a situação. É preciso certificar-se
que seus testes estão certos ou se o projeto precisa de refinamento.
No entanto, existe um perigo ao se fazer isso. Testes malfeitos fazem você acredi-
tar erroneamente que tudo é um mar de rosas. Você ganha confiança em seu sistema
porque todos os testes executam. Porém, você segue adiante sem perceber que dei-
xou para trás uma armadilha, pronta para lhe capturar na próxima vez que você pas-
sar por ela.
O truque dos testes é achar um nível de erros que você esteja disposto a tolerar. Se
puder suportar apenas uma reclamação de cliente por mês, então invista em testes e
melhore seu processo de teste até que você obtenha este nível. Assim, usando esse
padrão, se todos os testes executaram, siga adiante como se o sistema estivesse bem.
Adiantando as coisas um pouco, teremos dois conjuntos de testes. Teremos testes
de unidade, escritos pelos programadores para convencer a si mesmos que seus pro-
gramas funcionam do jeito que eles esperavam. Também teremos testes funcionais
escritos (ou pelo menos especificados) por clientes para convencer a si próprios de
que o sistema como um todo funciona do jeito que eles acham que deveria funcionar.
Existem dois públicos-alvo para os testes: os programadores, que precisam con-
cretizar sua confiança na forma de testes para que todo mundo possa compartilhar
essa confiança; e os clientes, que precisam preparar um conjunto de testes que repre-
sentam a sua confiança, pensando “Bem, eu acho que se você consegue computar to-
dos esses casos, então o sistema deve funcionar”.
Ouvir
Programadores não sabem de nada. Na verdade, programadores não sabem nada
que as pessoas de negócios consideram interessante. Acredite, se aquelas pessoas de
negócios pudessem viver sem programadores, elas nos mandariam embora em um
segundo.
Aonde eu quero chegar com isso? Bem, se você resolveu testar, você tem de obter
as respostas de algum lugar. Já que você (como um programador) não sabe nada, vo-
cê precisa perguntar para alguém. Eles lhe dirão quais são as respostas esperadas e
quais são os casos incomuns sob a perspectiva dos negócios.
Se você fizer perguntas, então é melhor você estar preparado para ouvir as res-
postas. Assim, ouvir é a terceira atividade no desenvolvimento de software.
Os programadores também devem ouvir abertamente. Eles ouvem o que o clien-
te afirma ser o problema de negócios. Eles ajudam o cliente a entender o que é difícil
e o que é fácil, ouvindo-o ativamente. Assim, o feedback dado pelo programador aju-
da o cliente a entender melhor o seu problema.
Apenas dizer “Vocês deveriam ouvir uns aos outros e ao cliente” não ajuda muito.
As pessoas tentam fazer isso e não dá certo. Nós precisamos achar uma maneira de es-
truturar essa comunicação para que as coisas que precisam ser comunicadas o sejam
na quantidade de detalhes e no momento certos. De maneira parecida, as regras que
desenvolvemos também precisam desencorajar comunicação que não ajuda, ou que é
feita antes da compreensão real daquilo que será comunicado ou ainda que é feita em
tal grau de detalhamento que encobre a parte importante da comunicação.
DE VOLTA AO BÁSICO 61
Projetar
Por que não podemos apenas ouvir, escrever um caso de teste, executá-lo, ouvir no-
vamente, escrever um outro caso de teste, executá-lo e continuar repetindo esses pas-
sos eternamente? Porque sabemos que isso não funciona assim. Você pode fazer isso
por um tempo. Em uma linguagem generosa, você talvez possa fazer isso por algum
tempo. No entanto, algum dia, você não terá como prosseguir. A única maneira de fa-
zer o próximo caso de teste executar é fazer um outro falhar. Ou a única maneira de
fazer um caso de teste executar é complicada demais para valer a pena. A entropia
faz uma nova vítima.
A única maneira de evitar isso é projetar. Projetar é criar uma estrutura que orga-
niza a lógica do sistema. Um bom projeto organiza a lógica de maneira que uma mo-
dificação em uma parte do sistema nem sempre requeira uma modificação em uma
outra parte. Um bom projeto garante que todas as peças da lógica do sistema tenham
uma e apenas uma origem. Um bom projeto também coloca a lógica perto dos dados
com os quais ela opera. Um bom projeto permite a extensão do sistema modificando
apenas um local.
Um projeto ruim é exatamente o contrário. Uma modificação conceitual requer
modificações em muitas partes do sistema. A lógica precisa ser duplicada. Conse-
qüentemente, o custo de um projeto ruim se torna grande demais. Você não consegue
mais lembrar onde todas modificações implicitamente conectadas precisam estar.
Você não consegue adicionar uma nova função sem estragar uma outra já existente.
A complexidade é uma outra fonte de um projeto ruim. Se um projeto requer qua-
tro camadas de vias secundárias para descobrir o que realmente está acontecendo, e
se essas camadas não têm nenhum propósito funcional ou explanatório, então o pro-
jeto é ruim.
Assim, a última atividade que temos de estruturar em nossa nova disciplina é
projetar. Nós precisamos prover um contexto no qual bons projetos são criados, pro-
jetos ruins são consertados e o projeto atual é aprendido por todos aqueles que pre-
cisam aprendê-lo.
Como vocês verão nos capítulos seguintes, a maneira com a qual a XP produz um
projeto é bem diferente da de muitos outros processos de software. O projeto faz par-
te das funções diárias de todos os programadores XP em meio a sua codificação. Mas
independentemente da estratégia usada para produzi-lo, a atividade de projetar não
é uma opção. É preciso pensar seriamente para que o desenvolvimento de software
seja obtido.
Conclusão
Então você codifica porque se você não codificar você não terá nada. Você testa por-
que se você não testar você não saberá quando você terminou de codificar. Você ou-
ve porque se você não ouvir você não saberá o que codificar ou o que testar. E você
projeta para que você possa codificar, testar e ouvir indefinidamente. Isso é tudo. Es-
tas são as atividades que devemos ajudar a estruturar:
• codificar
• testar
• ouvir
• projetar
SEÇÃO II
A Solução
A
gora nós já preparamos o terreno. Conhecemos o problema que precisamos re-
solver: decidir como devem ser executadas as atividades básicas do desenvol-
vimento de software – codificar, testar, ouvir e projetar. Temos um conjunto de
valores e princípios para nos guiar assim como escolhemos estratégias para cada
uma dessas atividades. E temos a curva de custos achatada como nossa carta na
manga para simplificar as estratégias que escolhermos.
CAPÍTULO 10
Uma Rápida Visão Geral
Nós nos basearemos na sinergia entre práticas simples, que muitas ve-
zes foram abandonadas décadas atrás por serem consideradas simpló-
rias, simples demais ou impraticáveis.
A
s matérias-primas do nosso novo método de desenvolvimento de software são:
• a história sobre aprender a dirigir;

• os quatro valores – comunicação, simplicidade, feedback e coragem;
• os princípios;
• as quatro atividades básicas – codificar, testar, ouvir e projetar.
Nosso trabalho é estruturar as quatro atividades. Teremos não apenas que estru-
turar as atividades, mas fazer isso sob a ótica da longa lista de princípios por vezes
contraditórios. E ao mesmo tempo precisamos tentar melhorar a performance econô-
mica do desenvolvimento de software o suficiente para que alguém nos dê ouvidos.
Ora, sem problemas.
Er, ahm, rom, rahm...
Já que o propósito deste livro é explicar como isso poderia funcionar, eu explica-
rei brevemente as mais importantes áreas de atuação da XP. No próximo capítulo, ve-
remos como soluções tão ridiculamente simples poderiam funcionar. Onde uma prá-
tica é fraca, os pontos fortes das outras práticas compensarão essa fraqueza. Os capí-
tulos seguintes abordarão alguns dos tópicos em maiores detalhes.
Primeiramente, aqui estão todas as práticas:
• O Jogo do Planejamento – Determine brevemente o escopo da próxima versão

combinando prioridades de negócio e estimativas técnicas. Quando a realida-
de se opuser ao planejamento, atualize o planejamento.
• Entregas freqüentes – Coloque um sistema simples rapidamente em produção ,
e depois libere novas versões em ciclos curtos.
• Metáfora – Guie o desenvolvimento com uma simples história, compartilhada
por todos, sobre como o sistema funciona como um todo.
• Projeto simples – O sistema deve ser projetado da maneira mais simples possí-
vel em qualquer momento. A complexidade desnecessária é removida assim
que for descoberta.
• Testes – Os programadores escrevem testes de unidade continuamente, os
quais devem executar sem falhas para que o desenvolvimento prossiga. Os
clientes escrevem testes demonstrando que as funções estão terminadas.
• Refatoração – Os programadores reestruturam o sistema sem alterar seu com-
portamento a fim de remover duplicidade, melhorar a comunicação, simplifi-
car e acrescentar flexibilidade.
• Programação em pares – Todo código de produção é escrito por dois programa-
dores em uma máquina.
• Propriedade coletiva – Qualquer um pode modificar qualquer código, em qual-
quer lugar do sistema, a qualquer momento.
• Integração contínua – Integre e atualize as versões do sistema várias vezes por
dia, cada vez que uma tarefa for terminada.
• Semana de 40 horas – Como regra, trabalhe no máximo 40 horas por semana.
Nunca faça hora extra por duas semanas seguidas.
• Cliente presente – Inclua um cliente real no time, disponível todo o tempo para
responder a questões.
• Padrões de codificação – Os programadores escreverão código respeitando as re-
gras que enfatizam comunicação através do código.
Neste capítulo, faremos um resumo do que está envolvido na execução de cada

prática. No próximo capítulo (Como Isso Poderia Dar Certo?), examinaremos as co-
nexões entre as práticas que permitem que os pontos fracos de uma prática sejam
compensados pelos pontos fortes de outras.
O Jogo do Planejamento
Nem as considerações do negócio nem as considerações técnicas devem prevalecer.
O desenvolvimento de software é sempre um diálogo evolutivo entre o possível e o
desejável. A natureza do diálogo é tal que ele altera o que parece ser possível e o que
parece ser desejável.
UMA RÁPIDA VISÃO GERAL 67
As pessoas da área do negócio precisam decidir sobre:
• Escopo – Quanto de um problema precisa ser resolvido para que o sistema te-
nha valor em produção? A pessoa da área de negócios está em posição de en-
tender o quanto não é suficiente e o quanto é demais.
• Prioridade – Se em um primeiro momento você só pudesse ter A ou B, qual vo-
cê escolheria? A pessoa da área de negócios está em posição de decidir isso,
muito mais do que um programador.
• Composição das versões – O quanto precisa ser feito para que o(s) negócio(s)
esteja(m) em melhor situação com o desenvolvimento do software do que sem
desenvolvê-lo? A intuição do programador sobre essa questão pode estar com-
pletamente errada.
• Datas de entrega – Quais são as datas importantes, quando a presença do soft-
ware (ou uma parte dele) faria bastante diferença?
A área de negócios não consegue tomar essas decisões no vácuo, a partir de nada. A
área de desenvolvimento precisa tomar as decisões técnicas que fornecem a matéria-
prima para as decisões do negócio.
As pessoas da área técnica decidem sobre:
• Estimativas – Quanto tempo levará para implementar uma funcionalidade?

• Conseqüências – Existem decisões estratégicas de negócios que devem ser fei-
tas apenas quando há informações sobre as conseqüências técnicas. A escolha
do banco de dados é um bom exemplo. A área de negócios pode preferir tra-
balhar com uma grande companhia do que com uma iniciante. Mas o dobro
em produtividade pode fazer o risco extra ou o desconforto valerem a pena.
Ou não. A área de desenvolvimento precisa explicar as conseqüências.
• Processo – De que forma o trabalho e o time serão organizados? O time preci-
sa se adequar à cultura na qual vai operar, mas é mais importante programar
bem o software do que preservar a irracionalidade de uma cultura fechada.
• Cronograma detalhado – Dentro de um ciclo de entrega, quais histórias serão
feitas primeiro? Os programadores precisam ter a liberdade de colocar primei-
ro no cronograma os segmentos de desenvolvimento mais arriscados, para re-
duzir o risco total do projeto. Considerando essa restrição, eles tendem ainda
a colocar as prioridades de negócios mais cedo no processo, reduzindo a chan-
ce de que histórias importantes precisem ser eliminadas perto do fim do de-
senvolvimento de uma versão.
Entregas Freqüentes
Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de
maior valor para o negócio. A entrega precisa fazer sentido como um todo – ou seja,
você não pode implementar meia função e entregá-la, só para tornar mais curto o ci-
clo de entrega.
É muito melhor planejar em um ou dois meses de cada vez do que em seis meses
ou um ano. Uma companhia que entrega software volumoso para seus clientes pode
não ser capaz de manter ciclos de entrega tão curtos. Mesmo assim, deve reduzir seu
ciclo o máximo possível.
Metáfora
Cada projeto de software XP é guiado por uma única metáfora abrangente. Às vezes,
a metáfora é simplória, como um sistema de gerenciamento de contratos que é refe-
rido em termos de contratos, clientes e endossos. Às vezes a metáfora requer algu-
mas explicações, como dizer que o computador deve ser semelhante a uma mesa de
escritório, ou que o cálculo da pensão é como uma planilha de cálculo. Entretanto,
elas são apenas metáforas, porque não queremos dizer literalmente que “o sistema é
uma planilha de cálculo”. A metáfora apenas ajuda todos os envolvidos no projeto a
entenderem os elementos básicos e seus relacionamentos.
As palavras usadas para identificar entidades técnicas devem ser obtidas de for-
ma consistente na metáfora escolhida. Com o andar do desenvolvimento e com o
amadurecimento da metáfora, todo o time encontrará nova inspiração ao examinar
a metáfora.
A metáfora na XP substitui muito daquilo que outras pessoas chamam de “arqui-
tetura”. O problema em chamar a visão panorâmica do sistema de arquitetura é que
arquiteturas não necessariamente acrescentam ao sistema um senso de coesão. Uma
arquitetura consiste em caixas pretas e suas conexões.
Você poderia dizer: “Mas é claro que uma arquitetura malfeita é ruim”. Nós pre-
cisamos enfatizar o objetivo da arquitetura, que é dar a todos uma história coerente
dentro da qual possam trabalhar, uma história que possa ser compartilhada facil-
mente entre o pessoal de negócios e o de desenvolvimento. Ao desejarmos uma me-
táfora, é provável que consigamos uma arquitetura fácil de comunicar e elaborar.
Projeto Simples
O projeto correto para o software em qualquer momento é aquele que:
1. Executa todos os testes.

2. Não tem lógica duplicada. Tome cuidado com as duplicações escondidas,
como hierarquias de classes paralelas.
3. Expressa todas as intenções importantes para os programadores.
4. Tem o menor número possível de classes e métodos.
Cada parte do projeto do sistema precisa justificar sua existência nesses termos. Ed-
ward Tufte1 propõe um exercício para designers gráficos – desenhe um gráfico da for-
ma que você quiser. Então apague todos os elementos, desde que você não remova
nenhuma informação. O que restar quando você não puder apagar mais nada é o de-
sign certo para o gráfico. Projeto simples é isso – remova todos os elementos de pro-
jeto que você conseguir sem violar as regras 1, 2 e 3 acima.
1
Edward Tufte, The Visual Display of Quantitative Information, Graphics Press, 1992.
Esse é um conselho que se opõe ao que geralmente se ouve: “Implemente para

hoje, projete para o amanhã”. Se você acredita que o futuro é incerto, e que você po-
de mudar de idéia sem grandes gastos, então acrescentar funcionalidades baseadas
em especulações é loucura. Acrescente o que você precisa quando você precisar.
Testes
Qualquer aspecto/função do programa que não tenha um teste automatizado sim-
plesmente não existe. Os programadores escrevem teste de unidade para que sua
confiança na operação do programa possa se tornar parte do programa em si. Os
clientes escrevem testes de funcionalidade para que sua confiança na operação do
programa possa também se tornar parte do programa. O resultado é um programa
que se torna cada vez mais confiável com o tempo – ele torna-se mais capaz de acei-
tar modificações, e não menos.
Você não precisa escrever um teste para cada método que programar, apenas mé-
todos de produção que poderiam falhar. Às vezes você só quer descobrir se algo é
possível. Você explora as possibilidades por uma meia hora. Sim, é possível. Agora
você joga fora o seu código e recomeça com testes.
Refatoração
Ao implementar uma função do programa, os programadores sempre se perguntam
se existe uma maneira de alterar o programa existente para fazer com que a adição
da nova função seja simples. Depois que eles a adicionaram, se perguntam como po-
dem simplificar o programa, mantendo ainda todos os testes executando. Isso é a
chamada refatoração (refactoring).
Note que isso significa que algumas vezes você tem de trabalhar mais do que o
absolutamente necessário para acrescentar uma função. Mas, ao trabalhar dessa for-
ma, você garante que poderá adicionar a próxima função com uma quantidade acei-
tável de esforço, e todas as seguintes também. No entanto, você não refatora com ba-
se em especulações; você refatora quando o sistema precisa. Quando o sistema re-
quer código duplicado, ele está precisando de refatoração.
Se um programador percebe uma maneira arriscada de fazer um teste funcionar
em um minuto, e uma maneira de fazê-lo funcionar em dez minutos com um proje-
to simples, a escolha correta é gastar os dez minutos. Felizmente, você pode fazer até
mesmo mudanças radicais no projeto de um sistema em etapas pequenas e de baixo
risco.
Programação em Pares
Todo código de produção é programado com duas pessoas olhando para uma má-
quina, com um teclado e um mouse.
Existem dois papéis em cada par. Um parceiro, aquele com o teclado e o mouse, es-
tá pensando qual é o melhor jeito de implementar este método especifico. O outro
parceiro está pensando mais estrategicamente:
• Essa abordagem como um todo vai funcionar?

• Que outros casos de testes podem não funcionar?
• Existe uma maneira de simplificar todo o sistema para que o problema sim-
plesmente desapareça?
A programação em pares é dinâmica. Se duas pessoas formam um par pela ma-

nhã, à tarde elas podem facilmente fazer duplas com outros colegas. Se você for res-
ponsável por uma tarefa de uma área que não lhe é familiar, você pode pedir a al-
guém com experiência recente para fazer uma dupla. Mas na maioria das vezes,
qualquer pessoa do time servirá como parceiro.
Propriedade Coletiva
A qualquer momento, qualquer um que perceba uma oportunidade de acrescentar
valor a alguma parte do código é obrigado a fazê-lo.
Compare isso com dois outros modelos de propriedade de código – ausência de
propriedade e propriedade individual. Antigamente ninguém possuía nenhum códi-
go em particular. Se alguém quisesse modificar um código, o fazia para servir aos
seus propósitos, quer isso se encaixasse ou não no que já estava pronto. O resultado
era caótico, especialmente com objetos cuja relação entre uma linha de código aqui e
outra lá adiante não era fácil de ser determinada estaticamente. O código crescia ra-
pidamente, mas também ficava cada vez mais instável.
Para controlar essa situação, surgiu a propriedade individual. A única pessoa que
poderia alterar um trecho de código era seu proprietário oficial. Qualquer pessoa que
percebesse que o código precisava de alterações precisava submeter seu pedido ao
proprietário. O resultado dessa propriedade restrita é que o código passa a afastar-se
do entendimento do time, porque as pessoas ficam relutantes em interromper o pro-
prietário do código. Afinal, eles precisam da modificação agora, e não depois. Então
o código permanece estável, mas não evolui tão rapidamente quanto deveria. E en-
tão o proprietário deixa o time...
Na XP, todos são responsáveis pelo sistema inteiro. Nem todos conhecem todas as
partes igualmente bem, mas todos sabem um pouco sobre cada parte. Se um par es-
tá trabalhando e vê uma oportunidade de melhorar o código, eles vão em frente e o
melhoram se isso facilitar suas vidas.
Integração Contínua
O código é integrado e testado após algumas horas – no máximo um dia de desen-
volvimento. Uma maneira simples de fazer isso é ter uma máquina dedicada apenas
à integração. Quando a máquina estiver livre, um par com código para ser integrado
a ocupa, baixa a versão atual, baixa as modificações (conferindo e resolvendo qual-
quer colisão) e executa os testes até que eles passem (100% corretos).
Integrar apenas um conjunto de modificações de cada vez é uma prática que fun-
ciona bem porque fica óbvio quem deve fazer as correções quando um teste falha –
nós devemos, já que fomos nós que estragamos, afinal o último par tinha deixado to-
dos os testes a 100%. E se não conseguirmos deixar os testes a 100%, devemos jogar
fora o que tínhamos feito e começar tudo de novo, já que obviamente não sabíamos
o suficiente para programar aquela função (entretanto, é possível que já saibamos o
suficiente agora).
Semana de 40 Horas
Eu quero estar disposto e animado a cada manhã, e cansado e satisfeito todas as noi-
tes. Na sexta-feira, eu quero estar cansado e satisfeito o suficiente para me sentir bem
com dois dias para pensar em algo que não seja trabalho. E então na segunda-feira eu
quero chegar cheio de energia e idéias.
O fato de isso se traduzir em precisamente 40 horas por semana no local de traba-
lho ou não não é extremamente importante. Pessoas diferentes têm tolerâncias dife-
rentes para o trabalho. Uma pessoa é capaz de agüentar 35 horas concentradas, ou-
tra, 45. Mas ninguém consegue agüentar 60 horas por semana durante muitas sema-
nas, e ainda estar disposto, criativo, cuidadoso e confiante. Não faça isso.
Horas extras são o sintoma de um problema sério no projeto. A regra da XP é sim-
ples – você não pode trabalhar uma segunda semana com horas extras. Por uma se-
mana, tudo bem, vá adiante e trabalhe algumas horas extras. Se você chega na segun-
da e diz: “Para completar nossos objetivos, vamos ter de trabalhar até tarde de no-
vo”, então você já tem um problema que não pode ser resolvido com horas extras.
Uma questão relacionada são as férias. Os europeus geralmente tiram duas, três
ou quatro semanas seguidas de férias. Os norte-americanos raramente tiram mais do
que alguns dias. Se fosse a minha companhia, eu insistiria para que o pessoal tirasse
férias de duas semanas seguidas todo ano, com pelo menos uma ou duas outras se-
manas disponíveis para pausas mais curtas.
Cliente Presente
Um cliente real deve ficar com o time, estar disponível para responder questões, resol-
ver disputas e definir prioridades de menor escala. Por “cliente real”, eu quero dizer
alguém que vá realmente usar o sistema quando ele estiver em produção. Se você es-
tá construindo um sistema para o serviço de atendimento ao consumidor, então o
cliente será um representante do serviço de atendimento. Se você está construindo um
sistema de negociação de penhores, o consumidor será um negociador de penhores.
A maior objeção a essa regra é que usuários reais do sistema em desenvolvimen-
to são muito valiosos para ser emprestados ao time. Os gerentes terão de decidir o
que vale mais – ter o software acabado mais cedo e melhor ou acumular o trabalho de
uma ou duas pessoas. Se ter o sistema não agrega mais valor ao negócio do que ter
uma pessoa a mais trabalhando, talvez o sistema não devesse ser desenvolvido.
Também não quer dizer que o cliente no time não consiga trabalhar em sua fun-
ção habitual. Nem os programadores conseguem gerar 40 horas de questões a cada
semana. O cliente presente terá a desvantagem de estar fisicamente separado dos ou-
tros clientes, mas é provável que ele tenha tempo para fazer seu trabalho habitual.
A desvantagem de ter um cliente presente ocorre quando ele já passou centenas
de horas ajudando os programadores e então o projeto é cancelado. Dessa forma, vo-
cê perdeu o trabalho que ele fez, e também o trabalho que ele poderia ter feito se não
estivesse contribuindo em um projeto fracassado. A XP faz o possível para garantir
que o projeto não fracassará.
Eu trabalhei em um projeto em que a muito custo nos foi fornecido um cliente

real, mas “apenas por pouco tempo”. Depois que o sistema foi entregue com sucesso
e podia obviamente continuar evoluindo, os gerentes do lado dos clientes nos deram
três clientes reais. A empresa podia ter obtido mais valor do sistema se tivesse cedi-
do mais pessoal de negócio.
Padrões de Codificação
Se você terá todos esses programadores trabalhando em tantas partes diferentes do
sistema, trocando de dupla várias vezes por dia e refatorando os códigos uns dos ou-
tros constantemente, você não pode ter conjuntos diferentes de práticas de codifica-
ção. Com um pouco de prática, será impossível dizer qual pessoa do time escreveu
que código.
O padrão adotado deve exigir a menor quantidade de trabalho possível, consis-
tente com a regra do “uma e somente uma vez” (sem código duplicado). O padrão
deve enfatizar a comunicação. Finalmente, o padrão deve ser adotado voluntaria-
mente por todo o time.
CAPÍTULO 11
Como Isso Poderia Dar Certo?
As práticas apóiam umas às outras. O ponto fraco de uma é compensa-

da pelos pontos fortes das outras.
M
as espere aí! Nenhuma das práticas descritas anteriormente é única ou ori-
ginal. Todas têm sido usadas desde a codificação dos primeiros programas.
Quando os seus pontos fortes tornaram-se aparentes, a maioria deles foi
abandonada por práticas mais complicadas e mais caras. Então por que a XP não é
uma abordagem simplista do software? Antes de continuarmos, é melhor convencer-
mos a nós mesmos de que essas práticas simples não nos prejudicarão como prejudi-
caram os projetos de software a décadas atrás.
O colapso da curva exponencial do custo das modificações trouxe todas essas
práticas de volta ao jogo. Cada uma dessas práticas tem os mesmos pontos fracos de
antes, mas e se esses pontos fracos fossem agora compensados pelos pontos fortes
das outras práticas? Nós talvez possamos ir adiante fazendo as coisas de maneira
simples.
Este capítulo apresentará as práticas sob uma outra perspectiva, desta vez focada
no que normalmente torna a prática insustentável e mostrando como as outras prá-
ticas impedem que os seus efeitos negativos sobrecarreguem o projeto. Este capítulo
também apresenta como toda a história da XP poderia dar certo.
Seria impossível começar o desenvolvimento com apenas um esboço de plano. Você
não conseguiria atualizar constantemente o plano – isso levaria muito tempo e inco-
modaria os clientes. A não ser que:
• o cliente fizesse ele mesmo as atualizações do plano, baseado em estimativas

feitas pelos programadores;
• você tivesse, no início, um plano que desse uma idéia ao cliente do que pode-
ria acontecer nos próximos dois anos;
• você definisse pequenos ciclos de entrega para que qualquer erro no plano ti-
vesse um impacto de algumas semanas ou meses no máximo;
• seu cliente estivesse trabalhando junto com o time, possibilitando o rápido reco-
nhecimento de potenciais modificações e oportunidades para melhoramentos.
Dessa forma, talvez seja possível começar o desenvolvimento com um plano sim-
ples e refiná-lo constantemente ao longo do tempo.
Ciclos de Entrega Curtos

Seria impossível entrar na fase de produção depois de apenas alguns meses. Você
certamente não poderia fazer novas versões do sistema em ciclos com duração entre
um dia e alguns meses. A não ser que:
• o Jogo do Planejamento o ajudasse a trabalhar nas histórias mais importantes,
fazendo com que até mesmo um sistema pequeno tivesse valor para o negócio;
• você estivesse integrando constantemente, tornando mínimo o custo de empa-
cotar uma versão;
• seus testes reduzissem a taxa de erros o suficiente para que você não precisas-
se passar por um extenso ciclo de testes antes de permitir que o software fosse
liberado;
• você pudesse fazer um projeto simples, suficiente para essa versão, e não para
sempre.
Dessa forma, talvez seja possível fazer versões pequenas, começando logo após o
início do desenvolvimento.
Metáfora
Seria impossível começar o desenvolvimento com uma metáfora apenas. Ela não
apresenta detalhes suficientes e, além disso, o que acontece se ela estiver errada? A
não ser que:
• você tenha feedback concreto rapidamente do código real e testes para verificar
se a metáfora está funcionando na prática;
• seu cliente sinta-se à vontade falando sobre o sistema utilizando a metáfora;
• você refatorasse para refinar continuamente o seu entendimento do que a me-
táfora quer dizer na prática.
Dessa forma, talvez seja possível começar o desenvolvimento com apenas uma
metáfora.
COMO ISTO PODERIA DAR CERTO? 75
Projeto Simples
Seria impossível ter apenas um projeto que fosse suficiente para a codificação de ho-
je. A limitação levaria você a um beco sem saída, deixando-o incapaz de prosseguir
na evolução do sistema. A não ser que:
• você estivesse acostumado a refatorar, fazendo com que modificações não fos-
sem uma preocupação;
• você tivesse uma metáfora global clara para certificar-se de que modificações
futuras tenderiam a seguir um caminho convergente;
• você estivesse programando com um parceiro, assim você teria certeza de es-
tar fazendo um projeto simples, e não um estúpido.
Dessa forma, talvez seja possível trabalhar com um projeto para hoje.
Testes
Seria impossível escrever todos aqueles testes. Levaria tempo demais. Os programa-
dores não escreverão testes. A não ser que:
• o projeto seja o mais simples possível, fazendo com que escrever testes não se-
ja tão difícil;
• você esteja programando com um parceiro, de forma que, se você não conse-
guir imaginar um novo teste, o seu parceiro conseguirá, e se ele quiser mandar
todos os testes longe, você gentilmente tirará o teclado dele.
• você se sinta bem ao ver todos os testes executando;
• seus clientes se sintam bem em relação ao sistema ao ver todos os testes deles
executando.
Dessa forma, talvez programadores e clientes escrevam testes. Além disso, se vo-
cê não escrever testes automatizados, o resto da XP não funcionará tão bem.
Refatoração
Seria impossível refatorar o projeto do sistema freqüentemente. Demoraria muito tem-
po, seria muito difícil controlar e provavelmente estragaria o sistema. A não ser que:
• você esteja acostumado à propriedade coletiva, não se importando em fazer

mudanças sempre que necessário;
• você tenha padrões de codificação, não sendo preciso reformatar antes de re-
fatorar;
• você programe em pares, tornando mais provável que você tenha a coragem
de enfrentar uma refatoração complicada e menos provável que você estrague
algo;
• você tenha um projeto simples, tornando a refatoração mais fácil;
• você tenha testes, fazendo com que seja menos provável que você estrague al-
go sem perceber;
• você tenha integração freqüente, de modo que, se você acidentalmente estra-
gar algo sem perceber, ou se uma de suas refatorações entrar em conflito com
o código de outra pessoa, você ficará sabendo em poucas horas;
• você esteja tranqüilo, o que lhe dará mais coragem e diminuirá a probabilida-
de de cometer erros.
Dessa forma, talvez seja possível refatorar sempre que você perceber uma opor-
tunidade de simplificar o sistema, de reduzir as duplicações e de comunicar algo
mais claramente.
É impossível escrever todo o código de produção em pares. Será muito lento. E se
duas pessoas não se entenderem? A não ser que:
• os padrões de codificação reduzam brigas mesquinhas;

• todo mundo esteja descansado e tranqüilo, reduzindo mais ainda a chance de
discussões não proveitosas;
• os pares escrevam testes juntos, o que dá a eles a chance de se sintonizarem an-
tes de começarem a implementação;
• os pares tenham a metáfora para apoiar suas decisões sobre nomeação e pro-
jeto básico;
• os pares estejam trabalhando com um projeto simples, para que os dois enten-
dam o que está acontecendo.
Dessa forma, talvez seja possível escrever todo o código de produção em pares.
Além disso, é mais provável a ocorrência de erros, o reprojeto e o desrespeito às prá-
ticas quando as pessoas programam sozinhas, principalmente sob pressão.
Seria impossível que todos pudessem mudar qualquer coisa em qualquer parte do
sistema. O pessoal estaria sempre estragando algo, e o custo de integração subiria
drasticamente. A não ser que:
• você integre as mudanças após um período suficientemente curto, diminuin-

do as chances de conflito;
• você escreva e execute testes, diminuindo a chance de estragar algo acidental-
mente;
• você programe em pares, diminuindo a probabilidade de estragar algum códi-
go e aprendendo mais rapidamente o que pode ser modificado com sucesso;
• você defina padrões de codificação, evitando aqueles pequenos desentendi-
mentos que por vezes terminam em uma verdadeira guerra.
COMO ISTO PODERIA DAR CERTO? 77
Dessa forma, talvez seja possível que todos alterem código em qualquer lugar do
sistema assim que perceberem uma chance de melhorá-lo. Além disso, sem proprie-
dade coletiva, a taxa de evolução do projeto diminui drasticamente.
Seria impossível integrar depois de apenas algumas horas de trabalho. Integração
demora muito tempo e há muitos conflitos e chances de se estragar algo acidental-
mente. A não ser que:
• você possa executar testes rapidamente para certificar-se de que não estragou
nada;
• você programe em pares, diminuindo pela metade as quantidades de modifi-
cações que precisam ser integradas;
• você refatore para que haja mais pedaços pequenos, reduzindo a probabilida-
de de conflito.
Dessa forma, talvez seja possível integrar depois de algumas horas. Além disso,
se você não integrar rapidamente, a probabilidade de haver conflitos cresce, e o cus-
to de integração aumenta acentuadamente.
Semana de 40 horas
Seria impossível trabalhar 40 horas por semana. Você não consegue produzir algo
que tenha valor em apenas 40 horas. A não ser que:
• seu Jogo do Planejamento lhe dê trabalho mais valioso para fazer;

• a combinação do seu Jogo do Planejamento com os testes reduza a freqüência
de surpresas desagradáveis quando houver mais trabalho a ser feito do que
você esperava.
• as práticas como um todo lhe ajudem a programar em sua velocidade máxi-
ma, de forma que não haja como ir mais rápido.
Dessa forma, talvez seja possível produzir algo suficientemente valioso em 40 ho-
ras semanais. Além disso, se o time não tiver vigor e energia, ele não será capaz de
executar o resto das práticas.
Cliente Presente
Seria impossível ter um cliente real junto ao time durante todo o tempo. Eles podem
agregar muito mais valor ao negócio se estiverem em outro lugar. A não ser que:
• eles possam acrescentar valor ao projeto escrevendo testes funcionais;

• eles possam acrescentar valor ao projeto tomando decisões de pequena escala
quanto à prioridade e ao escopo para os programadores.
Cliente presente
Jogo do Planejamento
Semana de 40 horas
Metáfora
Refatoração Projeto simples
Ciclos de entrega curtos

Testes
Programação em pares
Padrões de
codificação
Integração contínua
Propriedade coletiva
Figura 4 As práticas reforçam umas as outras.
Dessa forma, talvez os clientes possam agregar mais valor à empresa ao contri-
buír com o projeto. Além disso, se não for incluído um cliente no time, será preciso
adicionar risco ao projeto. Afinal, eles precisarão planejar de forma antecipada e co-
dificar sem saber exatamente que testes precisam ser satisfeitos e quais podem ser ig-
norados.
Padrões de Codificação
Seria impossível pedir ao time para codificar seguindo um padrão comum. Progra-
madores são profundamente individualistas e prefeririam desistir do projeto a mu-
dar seu estilo de indentação. A não ser que:
• a XP como um todo faça com que eles desejem fazer parte de um time vence-
dor.
Dessa forma, talvez eles possam estar mais dispostos a mudar um pouco o seu es-
tilo. Além disso, sem padrões de codificação, os atritos adicionais dificultarão a pro-
gramação em pares e a refatoração de maneira significativa.
Conclusão
Nenhuma prática consegue se manter por si só (com exceção dos testes). Elas reque-
rem outras práticas para manter-se equilibradas. O diagrama da Figura 4 resume as
práticas. Uma linha conectando duas práticas mostra que elas reforçam uma à outra.
Eu não queria apresentar essa figura no começo porque ela faz a XP parecer compli-
cada. As peças individuais são simples. A riqueza vem da interação entre as partes.
CAPÍTULO 12
Estratégia de Gerenciamento
Vamos gerenciar o projeto como um todo usando princípios básicos de

negócios – entrega em fases, feedback concreto e rápido, articulação
clara das necessidades dos negócios do sistema e o uso de especialistas
para tarefas especiais.
O
dilema do gerenciamento: por um lado, você gostaria que o gerente tomasse
todas as decisões. Não há degradação de comunicação porque há apenas
uma pessoa. Uma pessoa será responsável pelo gerenciamento superior.
Uma pessoa terá a visão. Mais ninguém precisa estar a par disso, porque todas as de-
cisões virão de uma só pessoa.
Sabemos que essa estratégia não funciona, porque uma única pessoa não sabe o
suficiente para tomar todas as decisões corretas. Estratégias de gerenciamento que
são balanceadas no sentido de um controle centralizado são também difíceis de exe-
cutar, porque requerem muito desgaste daqueles que estão sendo gerenciados.
Por outro lado, a estratégia oposta também não funciona. Você não pode simples-
mente deixar que todos façam o que quiserem, sem supervisão. As pessoas inevita-
velmente saem pela tangente. Alguém precisa ter uma visão maior do projeto e ser
capaz de influenciá-lo quando ele sai de curso.
Mais uma vez, nós podemos contar com os princípios para nos ajudar a navegar
entre estes dois extremos:
• Aceitação de responsabilidades – afirma que a função do gerente é destacar o

que precisa ser feito, e não delegar trabalho.
• Trabalho de qualidade – afirma que a relação entre gerentes e programadores
precisa se basear na confiança, pois os programadores querem fazer um bom
trabalho. Por outro lado, isso não quer dizer que o gerente não faça nada. Exis-
te uma grande diferença entre “Eu estou tentando fazer com que esses cara fa-
çam um trabalho razoável” e “Eu ajudo esses caras a fazerem um trabalho ain-
da melhor”.
• Modificações incrementais – afirma que o gerente atua como um guia o tempo

todo, e não apenas fornece um grande manual de políticas da empresa no início.
• Adaptação local – afirma que o gerente precisa assumir a liderança ao adaptar
a XP para as condições locais, saber como a cultura XP entra em conflito com a
cultura da companhia e ainda encontrar uma maneira de resolver as diferenças.
• “Viajar com pouca bagagem” – afirma que o gerente não impõe muito desgas-
te – longas reuniões coletivas e longos relatórios de status. O que quer que o
gerente exija dos programadores, não deve ser uma coisa que exija muito tem-
po para ser feito.
• Métricas genuínas – afirma que quaisquer que sejam as métricas escolhidas
pelo gerente, elas devem ter níveis realistas de precisão. Não tente contar os
segundos se o seu relógio só tem ponteiro de minutos.
A estratégia que emerge desta avaliação está mais para tomada de decisões des-
centralizada do que controle centralizado. O papel do gerente é fazer o Jogo do Pla-
nejamento acontecer, coletar métricas, garantir que as métricas sejam vistas por aque-
les cujo trabalho está sendo medido e, ocasionalmente, intervir em situações que não
podem ser resolvidas de forma distribuída.
Métricas
A métrica é a ferramenta básica de gerenciamento da XP. Por exemplo, a razão entre
tempo estimado de desenvolvimento e tempo de calendário é a medida básica para
fazer o Jogo do Planejamento acontecer. Ela deixa que o time defina a velocidade do
projeto. Se a razão aumenta (menos tempo de calendário para uma dada quantidade
estimada de desenvolvimento), isso pode significar que o processo do time está indo
bem. Ou pode significar que o time não está fazendo outras coisas além de cumprir
com as exigências (como refatoração e programação em pares), e que, a longo prazo,
um preço será pago por isso.
O meio de comunicação das métricas é o Grande e Visível Mural. Em vez de man-
dar e-mail a todos, que eles aprendem a ignorar, o gerente periodicamente (pelo me-
nos uma vez por semana) atualiza um proeminente mural. Esta é geralmente toda a
intervenção necessária. Você acha que não estão escrevendo testes suficientes? Colo-
que um gráfico do número de testes escritos até agora, e atualize-o diariamente.
Não utilize muitas métricas e esteja preparado para retirar as métricas que já ser-
viram ao seu propósito. Três ou quatro métricas a cada vez são geralmente o que o ti-
me agüenta.
As métricas tendem a se deteriorar com o tempo. Particularmente, é provável que
qualquer métrica que se aproxime dos 100% seja inútil. Para os escores dos testes de
unidade, que devem ser de 100%, esse conselho não se aplica, mas aí os escores de
teste de unidade estão mais para um pressuposto do que para uma métrica. No en-
tanto, você não pode concluir que, ao ter 97% de escore nos testes funcionais, lhe fal-
tem 3% de trabalho a ser feito. Se uma métrica se aproxima dos 100%, você deve
substituí-la por uma outra que inicie bem abaixo.
ESTRATÉGIA DE GERENCIAMENTO 81
Isso tudo não sugere que você possa gerenciar um projeto XP através dos núme-
ros apenas. Na verdade, os números são uma maneira sutil e não-coerciva de comu-
nicar a necessidade de mudar. O barômetro mais apurado do gerente XP para a ne-
cessidade de mudança é a consciência de suas próprias sensações, tanto físicas quan-
to emocionais. Se você fica com um nó no estômago quando entra no carro pela ma-
nhã, algo está errado com o projeto e é sua função fazer as mudanças.
Funções do Treinador
O que a maioria das pessoas entende por gerenciamento é dividido em dois papéis
na XP: o treinador e o rastreador (que podem ser desempenhados ou não pela mes-
ma pessoa). O treinador está envolvido principalmente com a execução (e a evolu-
ção) técnica do processo. O treinador ideal é um bom comunicador, alguém que não
entra em pânico facilmente, com habilidades técnicas (apesar de que este não é um
requisito absoluto) e confiante. É provável que você queira usar como treinador a
pessoa que em outros times teria sido o programador líder ou o arquiteto do sistema.
No entanto, o papel de treinador na XP é muito diferente.
As expressões “programador líder” e “arquiteto do sistema” invocam a idéia de
gênios isolados tomando as decisões importantes do projeto. O treinador é exatamen-
te o oposto. A medida de um treinador é quão poucas são as decisões técnicas que ele
ou ela toma: sua função é fazer com que todos os outros tomem boas decisões.
O treinador não assume a responsabilidade por muitas tarefas de desenvolvimen-
to. Na verdade, suas ocupações são as seguintes:
• estar disponível como um parceiro de desenvolvimento, em especial para pro-

gramadores novos começando a assumir responsabilidades e para tarefas téc-
nicas difíceis;
• enxergar os objetivos de longo prazo da refatoração, e encorajar refatorações
de curto prazo que contemplem partes destes objetivos;
• ajudar programadores com suas habilidades técnicas individuais, como testes,
formatação e refatoração;
• explicar o processo para os gerentes superiores.
Mas talvez o trabalho mais importante do treinador seja a aquisição de brinque-

dos e comida. Os projetos XP tendem a atrair brinquedos. Muitos deles são do tipo
quebra-cabeça, recomendados por todos os consultores defensores do raciocínio in-
direto (lateral thinking). Mas às vezes o treinador terá a oportunidade de influenciar
profundamente o desenvolvimento ao comprar o brinquedo certo, e esta possibilida-
de é a razão de ser do treinador. Por exemplo, no projeto C3 da Chrysler, as reuniões
de projeto estavam durando horas e não geravam resoluções. Então eu comprei um
desses cronômetros de cozinha e decretei que nenhuma reunião de projeto poderia
demorar mais do que 10 minutos. Acho que o cronômetro nunca foi usado, mas sua
presença visível ajudava a manter todos cientes de quando uma discussão tinha dei-
xado de ser útil e se tornado uma maneira para evitar escrever um pouco de código
para confirmar a resposta.
A comida é também uma marca da XP. Existe algo de poderoso em dividir o pão
com alguém. Você tem uma discussão completamente diferente com ele se vocês es-
tiverem mastigando ao mesmo tempo. Então os projetos XP têm sempre comida à
sua volta. (Eu recomendo particularmente as barras de chocolate Frigor Noir, se vo-
cê encontrá-las, mas alguns projetos parecem sobreviver com barrinhas licorosas
Twizzler. Você pode desenvolver um menu local.)
Rob Mee escreve:
Sabe, esses conjuntos de testes são bastante traiçoeiros. No meu time,

nós nos recompensamos com comidas e bebidas. Às 14:45: “Se
voltarmos aos 100% até às 15:00, podemos fazer um lanchinho e tomar
um chá”. É claro que, de qualquer forma, fazemos o lanche, mesmo que
demore até as 15:15. Mas quase nunca lanchamos antes dos testes
funcionarem – a realização do trabalho faz do intervalo uma pequena
festa.
Rastreamento
O rastreamento é o outro principal componente do gerenciamento na XP. Você pode
fazer quantas estimativas quiser, mas se você não comparar o que realmente aconte-
ceu com o que você previu que aconteceria, você nunca aprenderá.
É função do rastreador reunir todas as métricas que estão sendo rastreadas no
momento e garantir que o time conheça aquilo que foi efetivamente mensurado (e se
lembre daquilo que foi previsto e desejado).
Fazer o Jogo do Planejamento acontecer faz parte do rastreamento. O rastreador
precisa conhecer as regras do jogo de cor e estar preparado para as impor mesmo em
situações emocionais (o planejamento é sempre emocional).
O rastreamento precisa ocorrer sem muito desgaste. Se a pessoa que está reco-
lhendo o tempo real de desenvolvimento pergunta aos programadores sobre seu sta-
tus duas vezes ao dia, logo os programadores fugirão das interrupções. O rastreador
deve experimentar qual o mínimo de mensuração que ele pode fazer e ainda ser efe-
tivo. Recolher dados reais de desenvolvimento real duas vezes por semana é sufi-
ciente. Mais mensurações provavelmente não lhe darão melhores resultados.
Intervenção
Gerenciar um time XP não é mamão com açúcar. Algumas vezes, o problema sim-
plesmente não pode ser resolvido pelo brilhantismo emergente do time, encorajado
por um dedicado e cuidadoso gerente. Em momentos como esse, o gerente XP preci-
sa se sentir confortável para intervir, tomando decisões – até mesmo algumas impo-
pulares – e observando as conseqüências até o fim.
Mas, em primeiro lugar o gerente deve investigar cuidadosamente para descobrir
se havia algo que eles deveriam ter sabido ou feito mais cedo e que pudesse ter evi-
tado o problema. O momento da intervenção não é para a autopromoção do gerente.
Na verdade, é um momento para se aproximar do time dizer: “Eu não sei como dei-
xei as coisas chegarem a esse ponto, mas agora preciso fazer XXX”. Humildade é a re-
gra para uma intervenção.
Um assunto sério o suficiente para uma intervenção é a troca de pessoal. Se um
membro do time não está funcionando, o gerente precisa pedir para que ele saia.
ESTRATÉGIA DE GERENCIAMENTO 83
Uma decisão como esta é melhor ser feita cedo do que tarde. Tão-logo você puder
imaginar um cenário em que a demissão seria mais uma ajuda do que um obstáculo,
você deve efetuá-la.
Uma função um pouco mais agradável é a intervenção quando o processo do ti-
me precisa de alterações. Geralmente não é dever do gerente ditar aquilo que deve
ser alterado nem como, mas apenas indicar a necessidade de alteração. O time deve
criar um ou mais experimentos a serem tentados. Então o gerente reporta as mudan-
ças mensuradas, causadas pelo experimento.
A última função intervencionista do gerente é matar o projeto. O time provavel-
mente nunca o mataria por si só. Mas virá o dia em que mais investimento de enge-
nharia no sistema atual é menos atrativo do que alguma outra alternativa, como co-
meçar um projeto de substituição. O gerente tem a responsabilidade de estar ciente
do momento em que esse limite foi ultrapassado e de informar o gerenciamento su-
perior da necessidade de mudança.
CAPÍTULO 13
Estratégia de Ambiente de Trabalho
Criaremos uma área de trabalho aberta para o nosso time, com pequenos
espaços privados nas áreas periféricas e uma área comum de programa-
ção no meio.
S
obre a Figura 5, Ron Jeffries comenta:
Essa figura nos mostra a área de trabalho do time do projeto C3 da

Folha de Pagamento da DaimlerChrysler. Duas grandes mesas com
seis máquinas de desenvolvimento em cada uma delas. Pares de
programadores sentam-se a qualquer máquina disponível para fazer
seu trabalho. (Eles não posaram para essa foto, eles realmente
trabalham juntos como mostra a imagem. O fotógrafo estava
trabalhando com Chet, na mesa de trás, de costas para a câmera).
Nas duas paredes visíveis, estão quadros brancos que mostram
testes funcionais que precisam de atenção, sessões CRC planejadas e,
no quadro ao fundo, o Plano de Interação. As folhas de papel coladas
acima dos quadros na esquerda são pequenas placas contendo as
regras XP do grupo.
As paredes da esquerda e abaixo da câmera dispõem de pequenos
cubículos, grandes o suficiente para caberem um telefone e um bloco
de anotações.
Bem ao fundo da sala, entre a mesa dos computadores e o quadro
branco, há uma mesa convencional na qual a time se reúne para sessões
CRC. Essa mesa normalmente está coberta com cartões CRC e comida,
já que uma das regras do time é “Precisa haver comida”.
A sala foi projetada pelo time: nós realmente ESCOLHEMOS este
lugar. As pessoas falam baixo e o nível de barulho era
Figura 5 A área de trabalho do DaimlerChrysler C3.
surpreendentemente baixo. Mas quando alguém precisa de ajuda, você

pode apenas aumentar um pouco o tom de voz e será atendido. Você
obterá ajuda imediatamente. Perceba que o chão não é acarpetado,
fazendo com que nossas cadeiras possam realmente se movimentar.
Se você não tem um bom lugar para trabalhar, o seu projeto não será bem sucedido.
A diferença entre um lugar bom e um mau lugar para o time é gritante e imediata.
Um dos momentos decisivos em minha carreira de consultor foi quando me pe-
diram para revisar o projeto orientado a objetos para um sistema. Eu olhei o sistema
e estava realmente uma bagunça. Então, eu reparei onde cada um se sentava. O time
era composto por quatro programadores seniores. Todos tinham seu próprio escritó-
rio, cada um ocupando um dos quatro cantos de uma sala de tamanho médio. Eu lh-
es disse que eles deveriam juntar os escritórios. Consultaram-me por causa de meus
conhecimentos em Smalltalk e objetos, e a sugestão mais valiosa que eu tinha era que
eles deveriam reorganizar a mobília.
Organizar o ambiente de trabalho é uma tarefa difícil em qualquer situação, pois
sempre há muitas restrições conflitantes. O planejador do ambiente de trabalho é
avaliado pelo quão pouco de dinheiro ele gasta e em quanta flexibilidade ele man-
tém. As pessoas que utilizam as instalações querem trabalhar perto do restante do ti-
me, mas ao mesmo tempo precisam de privacidade para telefonar e marcar uma con-
sulta com o seu médico.
ESTRATÉGIA DE AMBIENTE DE TRABALHO 87
A XP prefere exagerar no espaço público. A XP é um método de desenvolvimen-

to de software em comunidade. Os membros do time precisam ser capazes de ver uns
aos outros, de ouvir uma pergunta pensada em voz alta, de ouvir “acidentalmente”
conversas para as quais eles têm contribuições vitais.
A XP pode se esforçar no ambiente de trabalho. O leiaute dos escritórios comuns
não serve para a XP. Colocar seu computador em um canto, por exemplo, não vai dar
certo, pois torna impossível duas pessoas sentarem-se uma ao lado da outra para
programar. A altura usual das divisórias dos cubículos comuns não funciona direito
– as divisórias devem ter a metade da altura ou devem ser eliminadas completamen-
te. Mas, ao mesmo tempo, o time deve ser separado de outros times.
A melhor configuração para a XP é um espaço aberto cercado por pequenos cubí-
culos que possam ser usados para manter objetos pessoais, fazer ligações telefônicas
e para alguém passar algum tempo sozinho sem ser interrompido. O resto do time
precisa respeitar a privacidade “virtual” de alguém sentado em seu cubículo. Colo-
que as maiores e mais rápidas máquinas no meio da sala (cubículos podem ou não
ter computadores). Assim, se alguém quiser programar, será naturalmente atraído
para o espaço público, aberto. Deste espaço, todo mundo consegue ver o que está
acontecendo, pares se formam facilmente, e cada par pode exercer influência sobre
os pares vizinhos que também estão desenvolvendo.
Se for possível, reserve uma pequena parte do espaço mais confortável para uma
área comum. Coloque uma máquina de café expresso, sofás, alguns brinquedos e
outras coisas que atraiam as pessoas para o local. Freqüentemente, a melhor manei-
ra de conseguir resolver um problema é se afastando um pouco dele. Se existir um lo-
cal agradável para onde se afastar, é mais provável que você o faça, quando precisar.
O valor da coragem pode ser expresso através da atitude XP em relação ao am-
biente de trabalho. Se a atitude corporativa em relação às instalações for ao encontro
das atitudes do time, então este sai ganhando. Se os computadores estiverem no lu-
gar errado, eles são transferidos para outro local. Se as divisórias estão atrapalhando,
elas são derrubadas. Se o toque dos telefones está muito alto, um dia, misteriosamen-
te, algodão aparece colocado dentro do telefone para abafar o toque.
Uma vez fui a um banco no primeiro dia de trabalho e descobri que haviam sido
dadas a nós mesas feias e velhas, em que cabiam apenas uma pessoa. As mesas ti-
nham dois compartimentos para gavetas, um de cada lado do pequeno espaço que
sobrava para colocar as pernas. Isso claramente não funcionaria. Olhamos em volta
e encontramos uma chave de fenda industrial. Então tiramos um dos compartimen-
tos para gavetas, de modo que duas pessoas pudessem sentar lado a lado em cada
mesa.
Ficar modificando a mobília de um lugar pode lhe causar problemas. As pessoas
que gerenciam as instalações podem ficar furiosas ao saber que alguém está mudan-
do mesas de lugar sem a permissão ou envolvimento delas (não importando que um
pedido para alguma modificação possa levar semanas ou até meses para ser atendi-
do). Eu digo apenas: “Que pena!”. Eu tenho um software para desenvolver, e se me li-
vrar das divisórias fará com que eu o desenvolva melhor, eu não pensarei duas ve-
zes. Se a empresa não consegue suportar tanta iniciativa, então eu é que não vou que-
rer trabalhar lá.
A tomada de controle do ambiente físico passa uma mensagem importante para
o time. Eles não deixarão interesses irracionais opostos da empresa atrapalharem o
andamento do projeto. Controlar o ambiente físico é o primeiro passo para controlar
o modo como se vai trabalhar como um todo.
Vale a pena experimentar modificações nas instalações constantemente (o valor

do feedback em ação). Afinal, a empresa gasta rios de dinheiro com móveis para escri-
tórios que sejam flexíveis. Todo esse dinheiro seria jogado fora se você não adaptas-
se a mobília para as suas necessidades. E se os cubículos destas duas pessoas fossem
mais próximos? Mais afastados? E se a máquina de integração estivesse no meio? Ou
no canto? Experimente. O que funcionar, fica. O que não funcionar é eliminado no
próximo experimento.
CAPÍTULO 14
Dividindo as Responsabilidades
Técnicas e de Negócios
Outro ponto-chave da nossa estratégia é manter o pessoal técnico focado

nos problemas técnicos e as pessoas de negócios focadas nos problemas
de negócios. O projeto precisa ser dirigido pelas decisões de negócio, mas
elas precisam ser informadas pelas decisões técnicas sobre custo e risco.
E
xistem dois modos comuns de errar na relação entre os Negócios e o Desenvol-
vimento. Se um deles ganha tiver demais, o projeto é prejudicado.
Os Negócios
Se os Negócios têm o poder, eles sentem que é apropriado determinar todas as qua-
tro variáveis para o Desenvolvimento. “Isto é o que você vai fazer. Esta é a data em
que tem que estar pronto. Não, você não vai ter nenhuma workstation nova. E é bom
que seja da mais alta qualidade, ou vai sobrar pra você, malandro!”.
Neste cenário, os Negócios sempre definem demais. Alguns dos itens da lista de
requisitos são absolutamente essenciais. Mas outros não são. E se o Desenvolvimen-
to não tiver nenhum poder, ele não pode se opor; não podem forçar os Negócios a
decidir qual é qual. Então o Desenvolvimento vai trabalhar obedientemente, de ca-
beça baixa, na tarefa impossível que lhe foi dada.
Parece estar na natureza dos requisitos menos importantes o fato de eles acarreta-
rem os mais altos riscos. São tipicamente os menos compreendidos, logo há grande
risco de que os requisitos mudem completamente durante o desenvolvimento. De al-
guma maneira, eles também tendem a ser os tecnicamente mais arriscados.
O resultado do cenário “Negócios no comando” é que o projeto demanda muito
esforço e um risco tremendamente alto, para um retorno muito pequeno.
Desenvolvimento
Agora, quando o Desenvolvimento tem sua chance no comando, você imagina que a
situação melhoraria. Mas não. O efeito final é exatamente o mesmo.
Quando o Desenvolvimento está no comando, eles colocam em dia todo o proces-
so e tecnologia para o qual eles não tinham tempo quando os “engravatados” esta-
vam controlando-os. Eles instalam novas ferramentas, linguagens e tecnologias. E es-
sas ferramentas, linguagens e tecnologias são escolhidas porque são interessantes e
modernas. Modernismo implica risco. (Se nós ainda não aprendemos isso, quando
iremos aprender?)
Então, o resultado do cenário “Desenvolvimento no comando” é também muito
esforço e um risco tremendamente alto para um retorno muito pequeno.
O que Fazer?
A solução é, de alguma forma, dividir a responsabilidade e o poder entre Negócios e
Desenvolvimento. Pessoas de Negócios devem tomar as decisões que lhes cabem.
Programadores devem tomar as decisões que lhes cabem. Cada decisão tomada por
uma das partes deve ser informada à outra. Nenhuma das partes deve poder decidir
unilateralmente coisa alguma.
Manter esse equilíbrio político pode parecer impossível. Se as Nações Unidas não
conseguem fazê-lo, que chances você pode ter? Bom, se tudo que você tivesse fosse o
vago objetivo de “balancear o poder político”, você não teria chance. A primeira pes-
soa de personalidade forte que aparecesse atrapalharia o equilíbrio. Felizmente, o ob-
jetivo pode ser bem mais concreto do que isso.
Primeiramente, uma história. Se alguém me pergunta se eu prefiro uma Ferrari
ou uma minivan, eu com certeza escolheria a Ferrari. Será inevitavelmente mais di-
vertido. No entanto, assim que alguém diz: “Você quer a Ferrari por 200.000 francos
ou a minivan por 40.000 francos?”, eu posso tomar uma decisão mais bem-informa-
do. Acrescentar novos requisitos como “Eu preciso ser capaz de levar cinco crianças”
ou “Ele precisa correr a 200 km/h” esclarece ainda mais as coisas. Há casos em que
ambas as decisões fazem sentido, mas você não pode tomar uma boa decisão com ba-
se apenas em propaganda. Você precisa saber que recursos você tem, quais as limita-
ções e quanto cada uma delas custa.
De acordo com esse modelo, pessoas de Negócios devem decidir sobre:
• o escopo ou o tempo das entregas;

• as prioridades relativas das funções propostas;
• o escopo exato das funções propostas.
Para essas decisões, a organização de desenvolvimento deve contribuir com:
• Estimativas do tempo requerido para implementar diversas funções.

• Estimativas das conseqüências de várias alternativas técnicas.
• Um processo de desenvolvimento que se adapte às suas personalidades, ao
seu ambiente de negócios e à cultura da companhia. Nenhuma lista do tipo
“Aqui está como escrever software” pode adequar-se a todas as situações. Na
DIVIDINDO AS RESPONSABILIDADES TÉCNICAS E DE NEGÓCIOS 91
verdade, nenhuma lista se adapta a uma situação, pois a situação é sempre um

fluxo constante.
• A definição de qual conjunto de práticas eles usarão para começar e com que
processo eles revisarão os efeitos dessas práticas e experimentarão com altera-
ções. Isso se parece um pouco com a Constituição dos Estados Unidos, que es-
tabelece uma filosofia básica, um conjunto de regras básicas (The Bill of Rights,
as 10 primeiras emendas) e regras para alterar as regras (adicionar novas
emendas).
Já que as decisões de negócios são tomadas durante todo o ciclo de vida do proje-
to, dar às pessoas de negócios a responsabilidade pelas decisões de negócios implica
que um cliente faz parte do time XP tanto quanto um programador. Particularmente,
para obter melhores resultados, eles deveriam ficar junto ao time e estar disponíveis
em tempo integral para responder a questões.
A Escolha da Tecnologia
Mesmo que a escolha de uma tecnologia pareça ser em princípio uma decisão técni-
ca, ela é na verdade uma decisão de negócios, mas que deve ser tomada levando em
conta informações do Desenvolvimento. O cliente precisará viver com um fornece-
dor de um banco de dados ou de uma linguagem por muitos anos e ele precisa sen-
tir-se confortável com a relação tanto a nível de negócios quanto no nível técnico.
Se um consumidor me diz: “Nós queremos este sistema, e você precisa usar este
banco de dados relacional e esta IDE Java”, minha função é apontar as conseqüências
dessas decisões. Se eu penso que um banco de dados orientado a objetos e C++ é a
melhor escolha, eu faço estimativas do projeto dos dois jeitos. E então as pessoas de
negócios podem tomar uma decisão de negócios.
Existe ainda um outro aspecto das decisões tecnológicas, que se insere no domí-
nio do Desenvolvimento. Quando uma tecnologia é introduzida em uma compa-
nhia, alguém deve mantê-la viva enquanto ela estiver em uso. Os custos das mais
recentes e melhores tecnologias não ocorrem apenas no início do desenvolvimento
da produção, nem mesmo se restringem ao período de desenvolvimento. Os custos
precisam incluir o preço de construir e preservar a competência que mantém a tec-
nologia viva.
E se for Difícil?
Na maioria das vezes, as decisões que surgem desse processo são surpreendente-
mente simples de implementar. Programadores são bons em enxergar os monstros
escondidos em cada história. As pessoas de negócios dizem: “Eu não sabia que is-
so iria sair tão caro. Reduza isso para um terço do trabalho. Vai ser suficiente por
enquanto”.
Algumas vezes, no entanto, as coisas não funcionam assim. Às vezes, a menor e
mais valiosa parte do desenvolvimento é grande e arriscada na perspectiva dos pro-
gramadores. Quando isso acontece, você não pode nem piscar e precisará ser cuida-
doso. Só poderá arcar com alguns poucos erros. Talvez precise arranjar mais recursos
externos. Mas quando chegar a hora de atacar, então você faz por merecer o seu di-
nheiro. Você faz o possível para estimular um escopo menor. Você faz tudo que pode
imaginar para reduzir o risco. E então, você parte para a luta.
Outra maneira de dizer isso é que a divisão de poder entre Negócios e Desenvol-
vimento não é uma desculpa para evitar o trabalho duro. Muito pelo contrário. É
uma maneira de diferenciar aqueles trabalhos que são realmente difíceis daqueles
que você ainda não encontrou um jeito de simplificar. Na maior parte, o trabalho se-
rá mais simples do que você imaginou em princípio. Quando não for, de qualquer
forma você o faz, afinal você é pago para isso.
CAPÍTULO 15
Estratégia de Planejamento
Planejaremos definindo rapidamente um plano geral, e então o refina-

remos em períodos cada vez mais curtos – anos, meses, semanas, dias.
Faremos o plano de maneira rápida e barata, de forma que haverá pouca
inércia quando precisarmos mudá-lo.
P
lanejar é o processo de adivinhar como será desenvolver um software com um
cliente. Alguns dos propósitos do planejamento são:
• unir o time;
• decidir o escopo e as prioridades;
• estimar custo e cronograma;
• dar a todos a confiança de que o sistema realmente pode ser feito;
• prover parâmetros (benchmark) para feedback.
Vamos recapitular os princípios que afetam o planejamento. (Alguns deles são

princípios gerais do Capítulo 8 – Princípios Básicos. Outros são específicos do plane-
jamento.)
• Faça apenas o planejamento necessário para o próximo período – usando

qualquer nível de detalhamento, planeje apenas para o próximo período – ou
seja, a próxima versão, o fim da próxima iteração. Isso não quer dizer que vo-
cê não possa planejar a longo prazo. Você pode, mas não com muitos detalhes.
Você pode cobrir a próxima versão com muito detalhamento e cobrir as próxi-
mas cinco versões (propostas) com um conjunto de itens numerados. Tentar
planejar todas as seis versões com detalhamento de uma vez só não é mais
vantajoso do que fazer um esboço desse tipo.
• Aceitação de responsabilidades – a responsabilidade só pode ser aceita, não

dada. Isso quer dizer que não existe planejamento de cima para baixo em XP.
O gerente não pode chegar para o time e dizer: “Eis aqui uma pilha de coisas
que temos que fazer e aqui este é o tempo que levaremos para fazer tudo isso”.
O gerente do projeto precisa pedir para o time assumir a responsabilidade de
fazer o trabalho. E precisa então escutar a resposta.
• Cabe ao responsável pela implementação fazer estimativas – se o time se res-
ponsabiliza por fazer alguma coisa, ele precisa determinar quanto demorará
para ficar pronto. Se uma pessoa no time assume a responsabilidade por fazer
algo, ela precisa dizer quanto tempo levará.
• Ignore interdependências – planeje como se as partes do desenvolvimento pu-
dessem ser mexidas de um lado para o outro à vontade. Contanto que você te-
nha o cuidado de implementar as maiores prioridades do negócio primeiro,
esta regra simples o afastará dos problemas. Coisas assim não tendem a acon-
tecer: “Quanto custa o café?” “O café custa 25 centavos, mas o refil é de graça.”
“Então me dá só um refil, por favor”.
• Planejar para as prioridades versus planejar para o desenvolvimento – esteja
ciente dos propósitos do planejamento. É mais valioso quando planejamos de
forma que o cliente possa estabelecer prioridades, se comparado com o deta-
lhamento exigido em um planejamento para implementação, no qual você
precisa de casos de teste específicos.
O planejamento da XP abstrai propositalmente o processo de planejamento para dois
participantes – Negócios e Desenvolvimento. Isso ajuda a remover parte do envolvi-
mento emocional desnecessário nas discussões sobre os planos. Em vez de: “Joe, seu
idiota, você me prometeu isso para sexta”, o Jogo do Planejamento diz: “O Desenvol-
vimento aprendeu algo. Ele precisa da ajuda dos Negócios para obter o melhor de-
sempenho”. Mas não há como um simples conjunto de regras eliminar a emoção, e
não é isso o que nós queremos. As regras existem para lembrar a todos de como seria
o ideal, além de fornecer uma referência comum quando as coisas não vão bem.
Os Negócios muitas vezes não gostam do Desenvolvimento. O relacionamento
entre as pessoas que precisam de sistemas e as pessoas que desenvolvem os sistemas
é tão tenso que lembra os relacionamentos entre inimigos de vários séculos. Descon-
fiança, acusações e manipulações sutis e indiretas existem em quantidade. Você não
consegue desenvolver software de qualidade em um ambiente como esse.
Se essa descrição não se aplica ao seu ambiente, sorte sua. O melhor ambiente é
aquele onde existe confiança mútua. Cada parte respeita a outra e acredita que ela
tem as melhores intenções, que visam ao bem da comunidade. Cada parte está dis-
posta a deixar a outra fazer seu trabalho, unindo as habilidades, experiências e pers-
pectiva de ambos.
Você não pode impor esse tipo de relacionamento. Não pode apenas dizer: “Nós
sabemos que estragamos tudo. Realmente sentimos muito. Isso não acontecerá nova-
mente. Vamos trabalhar de maneira totalmente diferente daqui pra frente, começan-
do logo depois do almoço”. O mundo e as pessoas não funcionam desse jeito. Sob es-
tresse, as pessoas regridem ao comportamento anterior, não importando o quão mal
esse comportamento tenha funcionado no passado.
ESTRATÉGIA DE PLANEJAMENTO 95
O que é preciso para construir um relacionamento de respeito mútuo é um con-

junto de regras para governar a maneira como o relacionamento será conduzido –
quem fica responsável por tomar as decisões, quando as decisões serão tomadas e co-
mo elas serão registradas.
Nunca se esqueça, porém, de que as regras do jogo são um auxílio, um passo à
frente na obtenção do relacionamento que você realmente deseja ter com os seus
clientes. As regras nunca irão capturar a sutileza, a flexibilidade e a paixão das ver-
dadeiras relações humanas. Sem um conjunto de regras, no entanto, você não conse-
gue começar a melhorar a situação. Uma vez que as regras estejam definidas e o re-
lacionamento esteja melhorando, então você pode começar a modificá-las para dei-
xar o desenvolvimento prosseguir mais naturalmente. Posteriormente, quando elas
virarem um hábito, você poderá abandoná-las.
Mas primeiramente você precisa aprender a jogar seguindo as regras. Aqui estão
elas:
O Objetivo
O objetivo do jogo é maximizar o valor do software produzido pelo time. Do valor do
software, você precisa tirar o custo do desenvolvimento e o risco a que estamos expos-
tos durante o desenvolvimento.
A Estratégia
A estratégia para o time é investir o mínimo possível para colocar as funcionalidades
mais valiosas em produção o mais cedo possível, mas apenas em conjunto com as es-
tratégias de programação e de projeto criadas para reduzir o risco. Sob a luz das li-
ções de tecnologia e de negócios aprendidas neste primeiro sistema, fica claro para os
Negócios qual a funcionalidade mais valiosa no momento, e o time coloca-a rapida-
mente em produção. E assim por diante.
As Peças
As peças do jogo do planejamento são os cartões de histórias. A Figura 6 mostra um
exemplo.
Os Jogadores
Os dois jogadores no Jogo do Planejamento são Desenvolvimento e Negócios. Desen-
volvimento consiste coletivamente em todas as pessoas que serão responsáveis por
implementar o sistema. Os Negócios consistem coletivamente em todas as pessoas
que tomarão as decisões sobre o que o sistema deve fazer.
Algumas vezes é fácil perceber quem faz o papel de “Negócios” no Jogo do Pla-
nejamento. Se um negociante de contratos está pagando por um software feito sob
medida, então ele representa “os Negócios”. Ele decide o que é mais importante fa-
zer primeiro. E se você está fazendo um produto de prateleira para o grande públi-
co? Quem são os Negócios? Os Negócios precisam tomar decisões de escopo, prio-
ridade e conteúdo das versões. Essas decisões normalmente são feitas pelo depar-
Figura 6 Um cartão de histórias.
tamento de marketing. Se eles forem espertos, eles argumentarão as decisões refe-

rindo-se a:
• usuários reais do produto;

• grupos específicos (focus groups);
• vendedores.
Alguns dos melhores jogadores dos Negócios que eu já vi foram usuários experien-
tes. Por exemplo, eu trabalhei em um sistema de serviço ao consumidor para fundos
de pensão. Os Negócios eram interpretados principalmente por uma supervisora de
serviços ao consumidor que tinha sido promovida após ter trabalhado com o sistema
anterior por muitos anos. Ela conhecia cada detalhe dele. De tempos em tempos, ela
encontrava problemas para distinguir o que o novo sistema deveria fazer de o que o
outro sistema fazia, mas depois de um tempo trabalhando com histórias, ela aprendeu.
Os Movimentos
Existem três fases no jogo:
• exploração – descubra que novas coisas o sistema pode fazer;
• compromisso – decida que subconjunto de todos os possíveis requisitos será
desbravado a seguir;
• direcionamento – guie o desenvolvimento deixando a realidade moldar o plano.
Os movimentos de cada fase são freqüentemente feitos naquela fase específica,
mas não apenas nela. Você escreverá novas histórias durante a fase de direcionamen-
to, por exemplo. Além disso, as fases são cíclicas; depois de um tempo direcionando,
você precisa voltar para a exploração.
Fase de Exploração
O objetivo da fase de exploração é dar a ambos os jogadores uma visão de o que o sis-
tema fará. Esta fase tem três movimentos:
Escreva uma história – Os Negócios escrevem uma história descrevendo algo que o
sistema precisa fazer. As histórias são escritas em cartões indexados, com um nome e
um curto parágrafo descrevendo o propósito da história.
Estime uma história – O Desenvolvimento estima quanto tempo levará para imple-
mentar a história. Se o Desenvolvimento não conseguir estimar uma história, pode
solicitar aos Negócios que esclareça ou separe a história em partes. Um método sim-
ples para estimar histórias é perguntar a você mesmo: “Quando tempo levaria para
implementar isto se eu tivesse que implementar apenas esta história e não fosse in-
terrompido e nem tivesse reuniões?”. Na XP, chamamos isso de Tempo Ideal de De-
senvolvimento. Como você verá adiante (em “Defina a Velocidade”), antes de se
comprometer com um cronograma, você mede a razão entre o tempo ideal e o calen-
dário.
Separe a história em partes – Se o Desenvolvimento não consegue estimar uma his-
tória inteira, ou se os Negócios percebem que parte de uma história é mais importan-
te do que o resto, os Negócios podem separá-la em duas ou mais histórias.
Fase de Comprometimento
O propósito da fase de comprometimento é que os Negócios escolham o escopo e a
data da próxima entrega, e que o Desenvolvimento se comprometa a fazer a entrega
com confiança. A fase de comprometimento tem quatro movimentos.
Classificação por valor – Os Negócios classificam as histórias em três pilhas: (1)
aquelas sem as quais o sistema não funciona, (2) aquelas que são menos essenciais
mas proporcionam um valor significativo para os negócios e (3) aquelas que seria in-
teressante ter.
Classificação por risco – O Desenvolvimento classifica as histórias em três pilhas: (1)
aquelas que eles podem estimar precisamente, (2) aquelas que eles podem estimar
razoavelmente bem e (3) aquelas que eles não conseguem estimar.
Definição de velocidade – O Desenvolvimento diz aos Negócios a rapidez com que
o time pode programar em Tempo Ideal de Desenvolvimento por mês de calendário.
Escolha do escopo – Os Negócios escolhem o conjunto de cartões que farão parte da
versão, seja definindo uma data para o desenvolvimento ser terminado e então esco-
lhendo cartões baseados nas suas estimativas e na velocidade do projeto, seja esco-
lhendo cartões e calculando a data.
Fase de Direcionamento
O propósito da fase de direcionamento é atualizar o plano com base no que o Desen-
volvimento e os Negócios aprenderam. A fase de direcionamento tem quatro movi-
mentos:
Iteração – No começo de cada iteração (a cada período de uma a três semanas), os

Negócios escolhem o equivalente a uma iteração dentre as histórias mais valiosas a
serem implementadas. As histórias da primeira iteração devem resultar em um siste-
ma que execute do começo ao fim, mesmo que em um estado embrionário.
Recuperação – Se o Desenvolvimento percebe que superestimou sua velocidade,
ele pode solicitar aos Negócios que definam qual é o conjunto de cartões mais va-
lioso a ser mantido na versão atual com base na nova velocidade e nas novas esti-
mativas.
Nova história – Se os Negócios percebem que precisam de uma nova história no
meio do desenvolvimento de uma versão, eles podem escrevê-la. O Desenvolvimen-
to estima a história e então os Negócios removem do plano remanescente histórias
com estimativas equivalentes e inserem a nova história.
Reestimativa – Se o Desenvolvimento percebe que o plano não mais proporciona
um mapa preciso do desenvolvimento, ele pode reestimar todas as histórias rema-
nescentes e definir a velocidade novamente.
Planejamento de Iteração
O Jogo do Planejamento descrito acima fornece ao cliente a capacidade de direcionar
o desenvolvimento a cada três semanas. Dentro de cada iteração, o time de desenvol-
vimento aplica praticamente as mesmas regras para planejar suas atividades.
O Jogo do Planejamento das Iterações é parecido com o Jogo do Planejamento, no
qual cartões são usados como peças. Desta vez, no entanto, em vez de as peças serem
cartões de histórias, são cartões de tarefas. Os jogadores são todos os programadores.
A escala de tempo é mais curta – todo o jogo acontece em uma iteração (período de
uma a quatro semanas). As fases e os movimentos são parecidos.
Fase de Exploração
Escreva uma tarefa – Tome as histórias da iteração e transforme-as em tarefas. Em
geral, as tarefas são menores do que uma história inteira, porque você não consegue
implementar uma historia inteira em alguns poucos dias. Algumas vezes, uma tare-
fa dará suporte para diversas histórias. Outras vezes, uma tarefa não estará relacio-
nada diretamente com nenhuma história em particular – por exemplo, uma migra-
ção para uma nova versão do software do sistema. A Figura 7 mostra um exemplo de
um cartão de tarefas real.
Combine tarefas/separe em partes uma tarefa – Se uma tarefa não puder ser estimada
para uns poucos dias, divida-a em partes menores. Se várias tarefas levam uma hora
cada, combine-as para formarem uma única tarefa maior.
Fase de Comprometimento
Aceite uma tarefa – Um programador aceita a responsabilidade por uma tarefa.
Estime a tarefa – A programador responsável estima o número ideal de dias de de-
senvolvimento para implementar cada tarefa. Com freqüência, isso depende de se
obter ajuda de um outro programador que esteja mais familiarizado com o código a
Figura 7 Um cartão de tarefas.
ser modificado. As tarefas que demoram mais de alguns dias devem ser separadas
em mais tarefas (você terá de descobrir o seu próprio limiar exato comparando tare-
fas que foram concluídas em tempo com aquelas que não foram).
Você talvez pense que deveria incluir explicitamente os efeitos da programação
em pares nas suas estimativas, mas você precisa ignorar isso. O tempo que você gas-
ta ajudando outros programadores, falando com o cliente e indo a reuniões aparece
no fator de carga de trabalho.
Defina fatores de carga de trabalho – Cada programador define seus próprios fatores
de carga de trabalho para a iteração – a porcentagem de tempo que irão gastar real-
mente desenvolvendo. Este é um número calculado – a relação entre os dias de pro-
gramação ideais e o calendário. Se você completou as ultimas três iterações em o
equivalente a 6, 8 e 7,5 dias ideais de tarefas, então esta é a média que você deve in-
dicar na próxima iteração. O número de dias ideais de tarefas por iteração pode ser
bem baixos para novos membros do time ou para um treinador, chegando a dois ou
três dias em uma iteração de três semanas. Esse fator não pode ser maior do que se-
te ou oito para ninguém, ou eles não passarão tempo suficiente ajudando outros.
Faça o Balanceamento – Cada programador soma suas estimativas de tarefas e mul-
tiplica por seu fator de carga de trabalho. Os programadores que se descobrirem
comprometidos de maneira demasiada devem desistir de algumas tarefas. Se o time
inteiro está sobrecarregado, ele deve achar uma maneira de voltar ao equilíbrio (ve-
ja a seguir “Recuperação”).
Fase de Direcionamento
Implemente uma tarefa – Um programador toma um cartão de tarefas, acha um parcei-
ro, escreve os casos de teste para a tarefa, os faz funcionar e então integra e libera o
novo código quando o conjunto universal de testes executar.
Registre o progresso – A cada dois ou três dias, um dos membros do time pergunta
para cada programador o tempo que eles gastaram em cada uma das tarefas e quan-
tos dias eles ainda têm.
Recuperação – Os programadores que se descobrirem comprometidos em demasia
pedem por ajuda (1) reduzindo o escopo de algumas tarefas, (2) solicitando que o
cliente reduza o escopo de algumas histórias, (3) largando tarefas não essenciais, (4)
obtendo mais ou melhor ajuda, e como um último recurso, (5) solicitando ao cliente
para postergar algumas histórias para uma iteração posterior.
Verifique a história – Tão-logo os testes funcionais estejam prontos e as tarefas pa-
ra uma história estejam completas, os testes funcionais são executados para verificar
se a história funciona. Os casos interessantes que surgirem durante a implementação
podem ser adicionados ao conjunto de testes funcionais.
As principais diferenças entre o planejamento das iterações e o planejamento de
entrega é que você pode tolerar mais desvios no cronograma de iteração do que no
cronograma de comprometimento. Se uma das três semanas de uma iteração já pas-
sou e o progresso foi muito lento, é possível parar por um dia e fazer uma grande re-
fatoração colaborativa, necessária para o progresso de todos. Nenhum programador
sentirá que todo o projeto estará desabando naquele momento (pelo menos não de-
pois de ter alguma experiência). Porém, se o cliente vir tais modificações aparente-
mente drásticas diariamente, ele rapidamente ficará nervoso.
De certa forma, isso pode parecer uma mentira, pois você está omitindo para o
cliente alguns dos processos do desenvolvimento. É importante que isso não aconte-
ça. Você não omite as coisas deliberadamente. Se um cliente quiser estar presente du-
rante um dia inteiro de refatoração, ele certamente é bem-vindo, mas provavelmen-
te ele tem coisas mais importantes a fazer. A diferença entre os planejamentos de in-
ter e de intra-iteração é uma extensão do princípio de separação das responsabilida-
des técnicas de nogócio. Há modificações em um certo nível de detalhamento que
não dizem mais respeito aos Negócios – os programadores sabem como microgeren-
ciar o tempo de forma melhor do que qualquer pessoa de negócios.
Uma diferença entre o Jogo do Planejamento e o Jogo do Planejamento das Itera-
ções é que os programadores se candidatam a uma tarefa antes de estimá-la. O time
implicitamente assume responsabilidade coletiva pelas histórias, então as estimati-
vas devem ser feitas pelo time coletivamente. Programadores individuais assumem
a responsabilidade por tarefas, então eles devem estimar as tarefas por si mesmos.
Uma outra diferença do planejamento das iterações é que algumas tarefas não es-
tão relacionadas às necessidades do cliente. Se alguém precisa fortalecer as ferramen-
tas de integração, e este trabalho é grande o suficiente para que não seja possível efe-
tuá-lo nas brechas do desenvolvimento, então ele se torna uma tarefa, datada e prio-
rizada como todas as outras.
Vamos relembrar as restrições no processo de planejamento das iterações e como
a estratégia acima as atende.
• Você não quer gastar muito tempo planejando, já que a realidade nunca fecha-
rá exatamente com o plano. Meio dia em um intervalo de 15 dias não é um
atraso muito grande. Claro que se você pudesse reduzir esse tempo seria me-
lhor, mas não é tanto tempo assim.
• Você quer feedback rápido sobre o seu progresso, então, ao percorrer um terço
do caminho,l você saberá se está com problemas. As respostas às perguntas
que o responsável por rastrear o progresso faz dão a você, no meio da iteração,
uma noção razoável quanto ao cumprimento do cronograma. O tempo restan-
te é geralmente suficiente para reagir localmente aos problemas, sem solicitar
modificações ao cliente.
• Você quer que os indivíduos responsáveis por entregar algo também sejam
responsáveis por estimar esse algo. Desde que os programadores se candida-
tem às tarefas antes de estimá-las, isso funcionará.
• Você quer limitar o seu escopo de desenvolvimento para o que realmente é ne-
cessário. É sempre estranho dizer que você pode trabalhar apenas 7,5 dias em
um período de três semanas (15 dias úteis divididos por um fator de carga de
trabalho de 2). No entanto, enquanto suas estimativas vão ficando cada vez
melhores, você descobrirá que é absolutamente verdade. Essa sensação de que
você não está realmente trabalhando tanto assim faz com que você queira fa-
zer mais tarefas. Mas você sabe que quer manter os padrões e a qualidade ao
fazer isso (e você tem um parceiro olhando para a mesma tela para certificar-
se de que você manterá a qualidade). Assim, você tende a trabalhar de manei-
ra simples, e ainda poder dizer honestamente que acabou a tarefa.
• Você quer um processo que não gere pressão suficiente para forçar as pes-
soas a fazerem coisas estúpidas, somente para atender as necessidades de
um plano de curto prazo. Novamente, isso retorna ao fato de que você pode
trabalhar por 7,5 dias. Você simplesmente não pode assumir tarefas demais.
Se você fizer isso em uma iteração, haverá feedback amplo e público de que
você não deveria ter tentado fazer tanta coisa. Então você não fará isso nova-
mente. Isso faz com que você se comprometa a fazer apenas aquilo que real-
mente pode, com qualidade.
Em projetos menores, eu eliminei o planejamento das iterações. Ele certamente é

necessário para coordenar o trabalho de 10 programadores, e com certeza não é ne-
cessário para coordenar o trabalho de apenas dois. Dependendo do projeto, você per-
ceberá que a necessidade de coordenar faz valer a pena o esforço extra envolvido no
planejamento formal das iterações.
Planejamento em uma Semana

Como é possível planejar um projeto se você tem apenas uma semana? Essa situação
ocorre freqüentemente com times que aceitam propostas com preço fixo. Você recebe
uma oferta e tem uma semana para dar a resposta. Você não tem tempo suficiente pa-
ra escrever um conjunto completo de histórias, as quais você possa estimar e testar, e
não tem tempo para construir protótipos a fim de poder estimar as histórias através
da experiência.
A solução da XP é aceitar mais risco no plano tendo histórias maiores. Escreva his-
tórias que você possa estimar em termos de meses ideais de programação em vez de
semanas ideais de programação. Você pode dar ao cliente a oportunidade de fazer
escolhas ao encolher ou postergar algumas histórias, exatamente como faria no Jogo
de Planejamento normal.
Estimativas deveriam ser baseadas na experiência. Diferentemente do Jogo do Pla-
nejamento, ao responder uma proposta em uma semana, é impossível ter tempo para
adquirir muita experiência. Você deve estimar com base em suas experiências anterio-
res escrevendo sistemas parecidos. Se você não tem experiências anteriores escreven-
do sistemas parecidos, você não tem como aceitar uma oferta com preço fixo.
Uma vez que você fechou o contrato, a primeira coisa a fazer é voltar e jogar os es-
tágios inicias do Jogo do Planejamento. Dessa forma, você confirma imediatamente
a sua capacidade de entrega conforme o contrato.
CAPÍTULO 16
Estratégia de Desenvolvimento
Ao contrário da estratégia de gerenciamento, a estratégia de desenvolvi-

mento é um desvio radical da sabedoria convencional – nós cuidadosa-
mente criaremos hoje a solução para os problemas de hoje, e acreditare-
mos que seremos capazes de resolver amanhã os problemas de amanhã.
A
XP usa a metáfora da programação para suas atividades – ou seja, tudo que
você faz se parece, de alguma forma, com programação: programar em XP é
como programar, com o acréscimo de algumas pequenas coisas, como testes
automatizados. Entretanto, como o resto da XP, o desenvolvimento XP é enganosa-
mente simples. Todas as partes são simples o suficiente para explicar, mas executá-
las é difícil. O medo surge. Sob pressão, velhos hábitos reaparecem.
A estratégia de desenvolvimento começa com o planejamento de iteração. A inte-
gração contínua reduz conflitos de desenvolvimento e cria um desfecho natural pa-
ra um episódio de desenvolvimento. A propriedade coletiva encoraja todo o time a
fazer todo o sistema de forma melhor. Finalmente, a programação em pares amarra
o processo como um todo.
Nenhum código permanece não-integrado por mais do que algumas horas. Ao fim
de cada episódio de desenvolvimento, o código é integrado com a última entrega, e
todos os testes precisam executar a 100%.
No extremo da integração contínua, toda vez que você modificasse um método, a
modificação seria instantaneamente refletida no código de todos os outros. Além da
infra-estrutura e da largura de banda requeridas para suportar esse estilo, a propos-
ta em si não funcionaria bem. Enquanto você está desenvolvendo, você quer fingir
que é o único programador do projeto. Você quer ir adiante com toda velocidade, ig-
norando a relação entre as modificações que você faz e as que os outros estão fazen-
do. Fazer com que as modificações possam ocorrer fora do seu controle imediato des-
truiria essa ilusão.
Integrar após algumas horas (certamente não mais do que um dia) fornece mui-
tos dos benefícios dos dois estilos – programador único e integração instantânea. En-
quanto você está desenvolvendo, pode fazer de conta que você e seu parceiro são a
única dupla do projeto. Podem fazer modificações onde quiserem. E então vocês tro-
cam de papel: como integradores, vocês sabem (a ferramenta os informa) onde estão
as colisões nas definições de classes e métodos. Ao executar os testes, vocês desco-
brem as colisões semânticas.
Se a integração demorasse algumas horas, não seria possível trabalhar dessa for-
ma. É importante ter ferramentas que suportem um ciclo rápido de integração/con-
figuração (build) de versões/testes. Você também precisa de um conjunto de testes ra-
zoavelmente completos que execute em alguns minutos. O esforço necessário para
corrigir as colisões não pode ser muito grande.
Mas isso não é um problema. A refatoração constante tem o efeito de dividir o sis-
tema em vários pequenos objetos e vários pequenos métodos. Isso minimiza as chan-
ces de que dois pares de programadores mudem a mesma classe ou o mesmo méto-
do ao mesmo tempo. Se eles o fizerem, o esforço necessário para conciliar as modifi-
cações é pequeno, porque cada uma delas representa umas poucas horas de desen-
volvimento.
Outra razão importante para aceitar os custos da integração contínua é que ela re-
duz drasticamente o risco do projeto. Se duas pessoas têm idéias diferentes sobre a
aparência ou a operação de um trecho de código, você estará sabendo em horas.Vo-
cê nunca passará dias procurando um bug que foi criado em um momento qualquer
das últimas semanas. E toda essa prática em integração é muito útil quando chega a
hora de criar o projeto final. A configuração (build) da versão de produção final não é
grande coisa. Todos os membros do time podem fazê-lo dormindo quando chegar o
momento, porque eles estiveram fazendo isso todos os dias durante meses.
A integração contínua fornece também um benefício humano durante o desenvol-
vimento. Enquanto trabalha em uma tarefa, você tem centenas de coisas em mente.
Ao trabalhar até que haja uma interrupção natural – não há mais itens pequenos no
cartão de coisas a fazer – e então integrar, você dá um ritmo ao desenvolvimento.
Aprenda/teste/codifique/entregue. É quase como respirar. Você forma uma idéia, a
expressa e a acrescenta ao sistema. Agora sua mente está limpa, pronta para a nova
idéia.
De tempos em tempos, a integração contínua força você a dividir a implementa-
ção de uma tarefa em dois episódios. Nós aceitamos a sobrecarga causada por isso: a
necessidade de lembrar o que já foi feito e o que ainda precisa ser feito. Nesse ínte-
rim, você pode descobrir o que fez com que o primeiro episódio ocorresse tão deva-
gar. Você começa o próximo episódio com um pouco de refatoração, e o resto do se-
gundo episódio ocorre sem problemas.
A propriedade coletiva é esta idéia aparentemente maluca de que qualquer um pode
modificar qualquer trecho de código do sistema, a qualquer hora. Sem os testes, vo-
cê nunca conseguiria fazer isso. Com os testes e com a qualidade de teste que você
obtém após alguns meses escrevendo muitos testes, você pode conseguir. Mas você
só conseguirá se integrar apenas algumas horas de modificações a cada vez. O que,
obviamente, você fará.
ESTRATÉGIA DE DESENVOLVIMENTO 105
Um dos efeitos da propriedade coletiva é que códigos complexos não têm vida
longa. Pelo fato de todos estarem acostumados a olhar o sistema inteiro, esse código
será encontrado logo. E quando for encontrado, alguém tentará simplificá-lo. Se a
simplificação não funcionar, o que é evidenciado pela falha dos testes, então o códi-
go será jogado fora. Mesmo que isso aconteça, haverá alguém além do par original
que compreenda por que o código precisa ser complexo. O mais comum, no entanto,
é que a simplificação funcione, ou pelo menos parte dela.
A propriedade coletiva também previne que um código complexo entre no siste-
ma. Se você sabe que outra pessoa em breve estará olhando o que você está escreven-
do neste momento, você pensará duas vezes antes de colocar uma complexidade que
não possa ser imediatamente justificada.
A propriedade coletiva aumenta a sensação de poder pessoal em um projeto. Em
um time XP, você nunca precisa agüentar a estupidez de outra pessoa. Se algo está no
seu caminho, você tira. Se você escolhe deixar algo como está por enquanto, porque
lhe é conveniente, isso é problema seu. Mas você nunca fica preso. Então você nunca
pensa “Eu poderia fazer o meu trabalho se não tivesse de lidar com esses idiotas”.
Uma frustração a menos. Mais um passo rumo a uma forma mais clara de se pensar.
A propriedade coletiva também tende a espalhar o conhecimento do sistema por
todo o time. É improvável que exista uma parte do sistema que apenas duas pessoas
conhecem (precisa ser ao menos um par, o que já é melhor do que a situação usual,
em que um programador esperto mantém a todos como reféns). Isso reduz ainda
mais o risco do projeto.
A programação em pares mereceria o seu próprio livro. É uma habilidade refinada,
que você pode passar o resto da vida aperfeiçoando. Para os propósitos deste capítu-
lo, nós examinaremos apenas por que ela funciona para a XP.
Primeiramente algumas palavras sobre o que a programação em pares não é. Não
é uma pessoa programando enquanto outra assiste. Apenas assistir outra pessoa pro-
gramar é tão interessante quanto assistir grama morrer no deserto. Programação em
pares é um diálogo entre duas pessoas tentando programar simultaneamente (e ana-
lisar, projetar e testar) e entender em conjunto como programar melhor. É uma con-
versação em muitos níveis, assistida por um computador e focada nele .
Programação em pares também não é uma sessão de tutoria. Às vezes os pares
contêm um parceiro com muito mais experiência do que o outro. Quando isso acon-
tece, as primeiras sessões serão parecidas com uma tutoria. O parceiro iniciante fará
muitas perguntas e digitará muito pouco. Rapidamente, entretanto, o parceiro júnior
começará a detectar pequenos erros bobos, como parênteses não-balanceados. O par-
ceiro sênior agradecerá a ajuda. Após mais algumas semanas, o parceiro júnior vai
começar a compreender os padrões (patterns) que o parceiro sênior está usando, e
perceber desvios desses padrões.
Geralmente, em alguns meses, a diferença entre os parceiros não é tão evidente
quanto no princípio. O parceiro júnior digita mais freqüentemente. O par nota que
cada um deles tem pontos fortes e fracos. Produtividade, qualidade e satisfação au-
mentam.
Programar em pares não é como ser gêmeos siameses. Se você olhar o Capítulo 2,
Um Episódio de Desenvolvimento, notará que a primeira coisa que eu fiz foi pedir
ajuda. Algumas vezes, você está procurando por um parceiro em particular – ao ini-
ciar uma tarefa. No entanto, é mais comum que você apenas ache alguém que esteja
disponível. E se vocês dois têm tarefas a serem feitas, você concordam em trabalhar
em uma delas pela manhã e na outra à tarde.
E se duas pessoas simplesmente não se dão bem? Elas não precisam programar
em pares. O fato de haver duas pessoas que não podem formar pares complica o ar-
ranjo dos outros pares. Se o problema interpessoal for bastante sério, gastar alguns
momentos combinando pares é melhor do que uma briga.
E se alguém se recusar a formar pares? Pode escolher entre aprender a trabalhar
como o resto do time ou procurar trabalho fora dele. A XP não é para todo mundo e
nem todos são para a XP. No entanto, você não precisa formar pares em tempo inte-
gral desde o primeiro dia em que você for trabalhar de forma eXtrema. Como sempre,
você precisa trabalhar pouco a pouco nesta direção. Tente durante uma hora. Se não
funcionar, tente descobrir o que deu errado e tente novamente por mais uma hora.
Afinal, por que a programação em pares funciona para a XP? Bom, o primeiro
valor é a comunicação, e existem poucas formas de comunicação mais intensas do
que face a face. Assim, a programação em pares funciona para a XP porque encoraja
a comunicação. Eu gosto da analogia com uma tanque de água. Quando uma nova e
importante informação é aprendida por alguém do time, é como colocar uma gota de
corante na água. Pelo fato de os pares serem embaralhados o tempo todo, a informa-
ção se difunde rapidamente pelo time, assim como o corante se espalha na água. No
entanto, ao contrário do corante, a informação torna-se mais rica e intensa quando se
espalha e é enriquecida pela experiência e perspicácia de todos no time.
De acordo com a minha experiência, a programação em pares é mais produtiva do
que dividir o trabalho entre dois programadores e então integrar os resultados. A pro-
gramação em pares é geralmente um ponto delicado para o pessoal que quer adotar a
XP. Tudo o que eu posso dizer é que você deve aprender a praticá-la bem e depois ten-
tar fazer uma iteração onde se faz todo o código de produção em pares, e outra onde
o código é feito individualmente. Então você pode tomar sua própria decisão.
Mesmo que não fosse mais produtivo, você ainda ia querer formar pares, porque
a qualidade do código resultante é muito mais alta. Enquanto um parceiro está ocu-
pado digitando, o outro está pensando em um nível mais estratégico. Qual a valida-
de desta linha de desenvolvimento? Ela vai levar a um beco sem saída? Existe uma
estratégia geral melhor? Há oportunidade para refatorar? – Outra característica po-
derosa da programação em pares é que algumas das práticas não funcionariam sem
ela. Sob estresse, as pessoas regridem. Elas deixarão de escrever testes. Desistirão de
refatorar. Evitarão integrar. Entretanto, com o seu parceiro ao seu lado, é provável
que, mesmo que você queira ignorar algumas dessas práticas, seu parceiro não quei-
ra. Isso não quer dizer que os pares nunca cometem erros de processo. Eles certamen-
te o fazem, ou você não precisaria do treinador. Mas as chances de você ignorar seu
compromisso com o resto do time são muito menores em pares do que quando você
está trabalhando sozinho.
ESTRATÉGIA DE DESENVOLVIMENTO 107
A natureza conversacional da programação em pares também melhora o proces-

so de desenvolvimento de software. Você aprende rapidamente a falar em muitos ní-
veis diferentes – este código em especial, códigos como este em outros lugares do sis-
tema, episódios de desenvolvimento parecidos com este que ocorreram no passado,
sistemas parecidos com este já feitos, as práticas que você está usando e como elas
podem ser melhoradas.
CAPÍTULO 17
Estratégia de Projeto
Continuamente nós refinaremos o projeto do sistema, partindo de um

começo muito simples. Retiraremos todas as flexibilidades que não se
provarem úteis.
D
e muitas maneiras, este é o capítulo mais difícil de escrever. A estratégia de
projeto da XP é sempre ter o projeto mais simples que execute o conjunto de
testes atual.
Bem, não foi tão ruim assim. O que há de errado com simplicidade? O que há de
errado com conjuntos de testes?
A Coisa Mais Simples que Poderia Funcionar

Vamos voltar um pouco e aproximar-nos dessa resposta passo a passo. Todos os qua-
tro valores fazem parte desta estratégia:
• Comunicação – Um projeto complicado é mais difícil de ser comunicado do que

um simples. Devemos, portanto, criar uma estratégia de projeto que resulte no
projeto mais simples possível, consistente com os nossos demais objetivos. Por
outro lado, devemos criar uma estratégia de projeto que gere projetos comuni-
cativos, em que os elementos do projeto comuniquem ao leitor aspectos im-
portantes do sistema.
• Simplicidade – Devemos ter uma estratégia de projeto que produza projetos
simples, mas a estratégia em si deve ser simples também. Isso não quer dizer
que ela precise ser de fácil execução. Bons projetos nunca são fáceis. Mas a ex-
pressão da estratégia deve ser simples.
• Feedback – Um dos problemas que eu sempre encontrava ao projetar antes de
começar a praticar a XP era saber se eu estava certo ou errado. Quanto mais
tempo eu passava projetando, pior tornava-se o problema. Um projeto simples
resolve isso, pois ele é concluído rapidamente. A próxima coisa a fazer é codi-
ficar e ver como o código se comporta.
• Coragem – O que poderia ser mais corajoso do que parar depois de ter desen-
volvido uma pequena parte do projeto, confiante de que, quando chegar a ho-
ra, você poderá adicionar algo mais, como e quando for necessário?
Seguindo esses valores, temos de:
• criar uma estratégia de projeto que resulte em um projeto simples;

• achar rapidamente uma maneira de verificar a qualidade desse projeto;
• utilizar o que aprendemos para melhorar o projeto;
• reduzir ao máximo o tempo de ciclo para todo esse processo.
Os princípios também colaboram para a estratégia de projeto.
• Investimento inicial pequeno – Devemos fazer o menor investimento possível no

projeto antes de receber algo por ele.
• Simplicidade presumida – Devemos assumir que o projeto mais simples que nós
imaginamos funcionando irá, de fato, funcionar. Isso nos dará mais tempo pa-
ra realizar um trabalho meticuloso caso o projeto mais simples não funcione.
Enquanto isso, não precisaremos carregar conosco o custo da complexidade
extra.
• Mudanças incrementais – A estratégia de projeto funcionará através de modifi-
cações graduais. Projetaremos um pouco a cada vez. Nunca haverá um mo-
mento em que o sistema terá um projeto definitivo. Ele estará sempre sujeito a
modificações, mesmo que haja partes do sistema que permaneçam inalteradas
por um tempo.
• Viajar com pouca bagagem – A estratégia de projeto não deve produzir projeto
“extra”. É preciso ter o suficiente para satisfazer nossos propósitos atuais (a
necessidade de fazer um trabalho de qualidade), mas nada mais. Se acolher-
mos as mudanças, estaremos dispostos a começar de forma simples e ir refi-
nando continuamente.
A XP vai de encontro aos instintos de muitos programadores. Como programado-

res, nós adquirimos o hábito de antecipar os problemas. Quando eles aparecem mais
tarde, nós ficamos felizes. Quando eles não aparecem, nós nem notamos. Assim, a es-
tratégia de projeto terá de conviver com esse comportamento de “adivinhar o futu-
ro”. Felizmente, a maioria das pessoas consegue desaprender o hábito de “pegar pro-
blemas emprestados” (como dizia minha avó). Infelizmente, quanto mais esperto vo-
cê for, mais difícil será desaprender esse hábito.
Uma outra forma de olhar para isto é fazendo a seguinte pergunta: “Quando vo-
cê adiciona algo ao projeto?”. Uma resposta comum é que você deveria projetar pen-
sando no amanhã, como mostra a Figura 8.
ESTRATÉGIA DE PROJETO 111
Essa estratégia funciona se nada mudar entre o agora e o mais tarde. Se você sa-
be exatamente o que vai acontecer, e sabe exatamente como resolver isso, normal-
mente é melhor adicionar aquilo que você precisa agora e também que precisará
mais tarde.
O problema desta estratégia é a incerteza. Em especial:
• algumas vezes, o amanhã nunca chega (ou seja, a funcionalidade que você an-
tecipou no projeto é deixada de lado pelo cliente);
• algumas vezes, você aprende uma maneira melhor de fazer as coisas entre o
agora e o mais tarde.
Em ambos os casos, você deve escolher entre arcar com o custo de retirar o exces-
so de projeto ou com o custo contínuo de carregar um projeto mais complicado e que
não trará benefícios reais.
Eu nunca aposto em que mudanças não ocorrerão, e certamente não aposto con-
tra a possibilidade de eu aprender algo. Neste caso, precisamos mudar o quadro pa-
ra que ele reflita nossa opção por projetar hoje para os problemas de hoje e amanhã
para os problemas de amanhã, como mostra a Figura 9.
Isso nos leva à seguinte estratégia de projeto:
1. Comece por um teste, assim saberemos quando terminamos. É preciso de-

senvolver uma certa quantidade de projeto apenas para escrever o teste:
quais são os objetos e seus métodos visíveis?
2. Projete e implemente apenas o suficiente para executar esse teste. Você terá
de projetar a implementação o bastante para fazer este e todos os testes an-
teriores executem.
3. Repita os passos 1 e 2.
4. Sempre que você perceber uma oportunidade para simplificar o projeto,
simplifique. Veja a subseção O que é Mais Simples? para a definição dos
princípios que guiam a simplificação.
Essa estratégia talvez aparente ser ridiculamente simples. É simples, mas não é ri-
dícula. Ela é capaz de criar sistemas grandes e sofisticados. No entanto, ela não é fá-
Agora Mais tarde
O que você acha que precisará mais tarde

Complexidade
do projeto
O que você precisa agora
O que você tem agora
Tempo
Figura 8 Se o custo das modificações crescer drasticamente ao longo do tempo.

Agora Mais tarde
O que você acha que precisará mais tarde
Complexidade O que você precisa agora

do projeto
O que você tem agora
Tempo
Figura 9 Se as modificações se mantêm baratas ao longo do tempo.
cil. Nada é mais difícil do que trabalhar com um prazo de entrega apertado e ainda
ter de parar para pôr as coisas em ordem enquanto você progride.
Projetando dessa forma, você implementará qualquer coisa de maneira bem sim-
ples na primeira vez que se deparar com ela. Na segunda vez que utilizá-la, você a
tornará mais generalizada. O primeiro uso rende apenas aquilo que é necessário. O
segundo, rende flexibilidade. Desta forma, você nunca paga pela flexibilidade que
não usa e tende a deixar o sistema flexível onde ele precisa ser flexível para a tercei-
ra, quarta e quinta variações.
Como o “Projeto Através de Refatoração” Funciona?

É na execução que a estratégia de projeto vai parecer estranha. Escolheremos o pri-
meiro caso de teste. Diremos: “Se tudo o que tivéssemos de fazer fosse implementar
este caso de teste, então precisaríamos apenas de um objeto com dois métodos”. Nós
implementaremos o objeto e os dois métodos. E teremos terminado. Todo nosso pro-
jeto resume-se a um objeto. Por cerca de um minuto.
Então escolheremos o próximo caso de teste. Bem, poderíamos apenas engendrar
uma solução ou poderíamos reestruturar o único objeto existente em dois objetos.
Dessa forma, implementar o caso de teste envolveria substituir um dos objetos. As-
sim, primeiramente reestruturamos, depois executamos o caso de teste inicial para
ter certeza de que funciona, e só então implementamos o próximo.
Depois de um dia ou dois trabalhando dessa forma, o sistema é grande o suficien-
te para que possamos imaginar dois times trabalhando nele sem se preocuparem em
atrapalhar um ao outro o tempo todo. Então colocamos dois pares implementando
casos de teste ao mesmo tempo e periodicamente (umas poucas horas) integrando
suas modificações. Mais um ou dois dias e o sistema pode suportar todo o time de-
senvolvendo nesse mesmo estilo.
De tempos em tempos, o time terá a sensação de que o lixo está sendo acumulado
atrás de si. Talvez eles tenham medido um desvio significativo de suas estimativas.
Ou talvez os seus estômagos se revirem quando sabem que precisam modificar uma
certa parte do sistema. Em qualquer um dos casos, alguém pede: “Tempo!”. O time
se reúne por um dia e reestrutura o sistema como um todo, usando uma combinação
de cartões CRC, esboços e refatoração.
Produto 1
Contrato Produto
Contrato de Pensão Contrato de Seguro Produto de Pensão Produto de Seguro
Figura 10 Contrato e produto têm subclasses paralelas.
Nem todos as refatorações podem ser realizadas em alguns minutos. Se você des-
cobrir que construiu uma grande e embaralhada hierarquia de heranças, talvez leve
um mês de esforço concentrado para desembaralhá-la. Mas você não dispõe de um
mês de esforço concentrado para gastar; precisa entregar histórias para essa iteração.
Quando enfrentamos uma grande refatoração, precisamos realizá-la em peque-
nos passos (novamente as mudanças incrementais). Você estará no meio de um caso
de teste e perceberá a oportunidade de avançar mais um passo em direção à sua me-
ta maior. Avance este único passo. Modifique um método aqui, uma variável ali. Fi-
nalmente, tudo o que restará da grande refatoração será um pequeno trabalho, e en-
tão você poderá terminá-lo em poucos minutos.
Eu experimentei fazer refatorações de larga escala em um sistema de gerencia-
mento de contratos de seguros avançando um passo de cada vez. Tínhamos a hierar-
quia mostrada na Figura 10.
Este projeto viola a regra once and only once (uma e somente uma vez). Então co-
meçamos a trabalhar para transformar tal projeto no mostrado na Figura 11.
No ano em que eu passei trabalhando no sistema, avançamos pequenos passos
em direção ao projeto desejado. Passamos a responsabilidade das subclasses de Con-
trato para as subclasses ou de Função ou de Produto. Quando meu contrato termi-
nou, ainda não tínhamos eliminado as subclasses de Contrato, mas elas eram muito
mais enxutas do que no começo, e estavam perto de serem eliminadas. E nesse meio
tempo, continuávamos colocando novas funcionalidades em produção.
E isso é tudo. É assim que você projeta de forma eXtrema. Do ponto de vista da
XP, projetar não é desenhar um monte de figuras e depois implementar o sistema
conforme os desenhos. Isso seria como simplesmente alinhar o carro. O capítulo
Aprendendo a Dirigir mostra o caminho para um estilo diferente de projeto – dê a
partida e então direcione o carro um pouco para este lado, depois um pouco para
aquele lado e então para este lado novamente.
Produto 1
Contrato Produto
Fluxo 1
Fluxo de Caixa Esperado Produto de Pensão Produto de Seguro
Figura 11 O contrato se refere a uma função, mas não tem subclasses.

O que é Mais Simples?

Então a definição de melhor projeto é o projeto mais simples que execute todos os ca-
sos de teste. A eficiência dessa definição depende do que queremos dizer com “mais
simples”.
O projeto mais simples é aquele com menos classes? Isso nos levaria a objetos
grandes demais para serem eficientes. O projeto mais simples é aquele com menos
métodos? Isso nos levaria a métodos grandes e duplicação. O projeto mais simples é
aquele que tem menos linhas de código? Isso nos levaria à compressão sem sentido
do código, e perderíamos em comunicação.
Aqui está o que eu quero dizer com “mais simples” – quatro restrições, por ordem
de prioridade:
1. o sistema (tanto código quanto testes) deve comunicar tudo aquilo que você
queria comunicar;
2. o sistema não deve conter código duplicado (os itens 1 e 2 juntos constituem
a regra “uma e somente uma vez” – once and only once rule );
3. o sistema deve ter a menor quantidade de classes possível;
4. o sistema deve ter o menor número de métodos possível.
O propósito do projeto do sistema é, em primeiro lugar, comunicar a intenção dos

programadores e, em segundo, prover um lugar para acomodar a lógica do sistema.
As restrições acima proporcionam um quadro com o qual é possível satisfazer a es-
ses dois requisitos.
Se você vê o projeto como um meio de comunicação, então você terá objetos ou
métodos para cada conceito importante. Você escolherá os nomes das classes e méto-
dos que irão trabalhar juntos.
Forçado desta forma a se comunicar, então você precisa encontrar uma maneira
de eliminar toda lógica duplicada no sistema. Esta é a parte mais difícil do projeto
para mim, porque você primeiro tem de achar a duplicação e então descobrir uma
maneira de eliminá-la. Eliminar duplicações naturalmente leva você a criar diversos
pequenos objetos e diversos pequenos métodos, porque, se não fizermos assim, ine-
vitavelmente teremos duplicações.
Mas você não cria novos objetos e métodos só porque é divertido. Se você alguma
vez encontrar uma classe ou um método que não faz nada e não comunica nada, en-
tão os elimine.
Uma outra forma de olhar para esse processo é como uma eliminação. Você tem
um sistema que executa os casos de testes. Você apaga tudo que não tem um propó-
sito – seja um propósito de comunicação, seja um propósito computacional. O que
sobrou é o projeto mais simples que poderia funcionar.
Como Isso Poderia Funcionar?

A estratégia tradicional para reduzir o custo de um software ao longo do tempo é re-
duzir a probabilidade e o custo de se refazer algo. A XP faz exatamente o contrário.
Em vez de reduzir a freqüência do refazer, a XP se esbanja nele. Um dia sem refato-
ração é como um dia sem sol. Como isso poderia custar menos?
O segredo é que risco é dinheiro da mesma forma que tempo é dinheiro. Se você
acrescentar uma funcionalidade ao projeto hoje e a usar amanhã, você ganha, porque
você paga menos por acrescentá-la hoje. Entretanto, o Capítulo 3, A Economia no De-
senvolvimento de Software, sugere que essa avaliação não é completa. Se existe incer-
teza suficiente, o valor da opção de esperar é alto o suficiente para que seja melhor
esperar.
O projeto não sai de graça. Outro aspecto dessa situação é que, quando você
acrescenta mais ao projeto hoje, você aumenta a sobrecarga do sistema. Há mais coi-
sas para testar, para entender e para explicar. Então todos os dias você não apenas
paga os juros sobre o dinheiro que você gasta, mas paga também uma pequena taxa
de projeto. Com isso em mente, a diferença entre os investimentos de hoje e os de
amanhã pode ser muito maior, e é ainda uma boa idéia projetar amanhã para os pro-
blemas de amanhã.
Como se isso não fosse suficiente, o risco é que nos mata. Como o Capítulo A Eco-
nomia no Desenvolvimento de Software demonstra, você não consegue avaliar o cus-
to de algo que acontecerá amanhã. Você também precisa avaliar a probabilidade isso
acontecer. É claro que eu adoro adivinhar e acertar tanto quanto todo mundo, mas o
que eu descobri quando comecei a prestar atenção foi que minhas suposições não
eram tão corretas quanto eu imaginava. Freqüentemente o projeto maravilhoso que
eu desenvolvi há um ano não tinha praticamente nenhuma suposição correta. Eu
precisava refazer todas as partes do projeto antes do fim do contrato; em algumas si-
tuações, até duas ou três vezes.
Assim, o custo de tomar uma decisão de projeto hoje é igual ao custo de tomar a
decisão somado aos juros que pagamos sobre esse custo mais a inércia que isso adi-
ciona ao sistema. O benefício de tomar uma decisão de projeto hoje é o valor espera-
do decorrente da decisão ser lucrativamente usada no futuro.
Se o custo das decisões de hoje é alto e a probabilidade de elas serem corretas é
baixa, e ainda a probabilidade de descobrirmos uma alternativa melhor amanhã é al-
ta e o custo de adicioná-la ao projeto amanhã é baixo, então podemos concluir que
nunca deveríamos tomar uma decisão de projeto hoje se não precisamos dela hoje.
Na verdade, isso é o que a XP conclui. “Os problemas de hoje já são suficientes”.
Muitos fatores podem tornar a avaliação acima inútil ou vazia. Se o custo de fazer
uma modificação amanhã é extremamente alto, então devemos tomar a decisão hoje
para o caso de estarmos certos. Se a inércia do projeto é suficientemente baixa (por
exemplo, você tem pessoas extremamente inteligentes no time), então os benefícios
de um projeto em cima da hora são menores. Se você é um ótimo adivinho, então vá
em frente e desenvolva todo o projeto hoje. Para o resto de nós, no entanto, eu não
vejo nenhuma alternativa à conclusão de que o projeto de hoje deve ser feito hoje e o
projeto de amanhã deve ser feito amanhã.
O Papel dos Diagramas no Projeto

Mas e todos aqueles diagrama de projeto e análise? Algumas pessoas realmente ra-
ciocinam melhor sobre seu projeto em termos de diagramas do que de código. De
que forma uma pessoa de orientação visual traz contribuições para o projeto?
Primeiramente, não há nada de errado em desenvolver software usando diagra-
mas em vez de um modelo puramente mental ou textual do sistema, e há muito o
que dizer a favor da abordagem gráfica. Problemas ao desenhar os diagramas po-
dem lhe dar pistas importantes sobre o bem-estar de um projeto. Se você não con-
seguir reduzir o número de elementos em uma figura a um nível gerenciável; se
existir uma assimetria óbvia; se existirem muito mais linhas do que caixas. Tudo is-
so são pistas de um projeto ruim que se tornam evidentes através de sua represen-
tação gráfica.
Outro ponto a favor de projetar com diagramas é a velocidade. No tempo que le-
varia para codificar um projeto, você pode comparar e contrastar três projetos alter-
nativos utilizando diagramas.
O problemas com os diagramas, no entanto, é que eles não podem lhe dar um
feedback concreto. Eles fornecem certos tipos de feedback sobre o projeto, mas o privam
de outros. Infelizmente, o privam exatamente daquele que lhe ensina o mais impor-
tante – Isto executará os casos de teste? Isto suporta código simples? Esse tipo de feed-
back você só consegue codificando.
Então, por um lado, podemos avançar rapidamente quando projetamos com dia-
gramas. Por outro lado, corremos riscos quando desenvolvemos com diagramas.
Precisamos de uma estratégia que nos deixe tirar vantagem dos pontos fortes de pro-
jetar com diagramas, mas que também reduza seus pontos fracos.
Mas não estamos sozinhos. Temos os princípios para nos guiar. Vejamos:
• Investimento inicial pequeno – sugere que desenhemos uns poucos diagramas de

cada vez;
• Jogar para ganhar – sugere que não usemos diagramas apenas por medo (por
exemplo, por querer adiar o dia em que admitiremos não saber como o proje-
to deve ser);
• Feedback rápido – sugere que descubramos rapidamente se nossos diagramas
estão no caminho certo ou não;
• Trabalhar a favor dos instintos do pessoal – sugere que encorajemos a elaboração
de diagramas às pessoas que trabalham melhor com eles;
• Acolher mudanças e viajar com pouca bagagem – sugere que descartemos os dia-
gramas uma vez que eles já tiverem afetado código, visto que as decisões re-
presentadas por eles provavelmente mudarão no futuro de qualquer forma.
A estratégia XP é que todos possam desenvolver todo o projeto que quiserem com
diagramas, mas tão-logo uma questão que possa ser resolvida com código seja levan-
tada, os desenvolvedores devem voltar-se ao código para achar a resposta. Os dia-
gramas não são mantidos. Por exemplo, os diagramas poderiam ser desenhados em
um quadro branco. Desejar que o quadro não seja apagado é certamente um sinal de
que o projeto não foi bem comunicado, seja para o time ou para o sistema.
Se há um tipo de código-fonte que é mais bem expresso com diagramas, então vo-
cê definitivamente deveria expressá-lo, editá-lo e mantê-lo em diagramas. Ferramen-
tas CASE que permitem que você especifique todo o comportamento do sistema fun-
cionam bem. As pessoas podem chamar o que essas ferramentas fazem de “geração
de código”, mas para mim parece ser uma linguagem de programação. Minha obje-
ção não é aos diagramas, mas à tentativa de manter múltiplos formatos da mesma in-
formação sincronizados.
Se você estiver usando uma linguagem de programação textual, siga esse conse-
lho e você nunca passará mais do que 10 a 15 minutos desenhando diagramas. As-
sim, você saberá que pergunta quer fazer ao sistema.
Depois de obter a resposta, você pode desenhar mais alguns diagramas, até que
encontre uma outra pergunta que precise de uma resposta concreta.
O mesmo conselho se aplica para outras notações que não utilizam código, como
cartões CRC. Passe alguns minutos fazendo-os, o suficiente para esclarecer a ques-
tão, e então volte ao sistema para reduzir o risco de você estar se enganando.
Arquitetura do Sistema
Não utilizei essa palavra que começa com “A” em nenhum momento até agora. A ar-
quitetura é tão importante em projetos XP quanto em qualquer outro projeto de soft-
ware. Parte da arquitetura é capturada pela metáfora do sistema. Se você tem uma
boa metáfora, todos os integrantes do time são capazes de dizer de que forma o sis-
tema como um todo funciona.
O próximo passo é ver de que maneira a história se transforma em objetos. As re-
gras do Jogo do Planejamento declaram que o resultado da primeira iteração deve
ser um esqueleto funcional do sistema como um todo. Mas você ainda precisa fazer
a coisa mais simples que possa funcionar. Como você pode conciliar os dois?
Para a primeira iteração, escolha um conjunto de histórias básicas e simples que
você espera que o forcem a criar toda a arquitetura. Então estreite seu horizonte e im-
plemente as histórias da maneira mais simples que possa funcionar. Ao fim desse
exercício você terá sua arquitetura. Talvez não seja a arquitetura que você esperava,
mas você terá aprendido algo.
E se você não conseguir achar um conjunto de histórias que o force a criar, com ab-
soluta certeza, a arquitetura de que irá precisar? Ou você define toda a arquitetura por
especulação ou você define a parte da arquitetura que atende às suas necessidades
atuais, confiando que poderá definir mais coisas mais tarde. Eu defino a arquitetura
de que preciso agora e confio em minha habilidade para modificá-la mais tarde.
CAPÍTULO 18
Estratégia de Testes
Escreveremos os testes antes de codificar, minuto a minuto. Preserva-

remos esses testes para sempre, e executaremos todos eles juntos fre-
qüentemente. Também derivaremos testes sob a perspectiva do cliente.
Q ue chato. Ninguém quer falar sobre testes. Teste é o enteado feioso do desen-
volvimento de software. A questão é que todos sabem que testar é importan-
te. Todos sabem que não fazem testes suficientes. E nós sentimos isso – nos-
sos projetos não vão tão bem quanto deveriam, e sentimos que mais testes poderiam
resolver o problema. Mas, então, nós lemos um livro sobre testes e ficamos atolados
nos vários tipos e maneiras de testes. Não há como fazer tudo aquilo e ainda conse-
guir desenvolver algo.
Vejamos como são os testes na XP. Toda vez que um programador escreve um có-
digo, ele imagina que vai funcionar. Assim, toda vez que ele imagina que um código
vai funcionar, ele pega essa confiança que surgiu do nada e a transforma em um ar-
tefato que é inserido no programa. A confiança lá fica, para o seu próprio uso. E por-
que ela está no programa, todos os outros também podem usá-la.
A mesma história é válida para o cliente. Toda vez que ele imagina algo concreto
que o programa deveria fazer, ele transforma isso em outra porção de confiança que
vai no programa. Agora a confiança dele está lá, juntamente com a do programador.
O programa fica cada vez mais confiante.
Na verdade, uma pessoa da área de testes iria olhar para os testes XP e debocha-
ria deles. Esse não é o trabalho de uma pessoa que ama testar. Muito pelo contrário.
Este é o trabalho de alguém que ama fazer os programas funcionarem. Então você
deveria escrever os testes que ajudam a fazer o programa funcionar e a mantê-lo fun-
cionando. Nada mais.
Lembre-se do princípio “Trabalhe a favor da natureza humana, e não contra ela”.
Esse é o erro fundamental dos livros de testes que eu li. Eles começam com a premis-
sa de que os testes são o centro do desenvolvimento. Você precisa fazer este teste, e
este também, e sim, mais este. Se quisermos programadores e clientes que escrevam
testes, é melhor que façamos o processo o menos dolorosamente possível, perceben-
do que os testes existem como instrumentação. É o comportamento do sistema que
está sendo instrumentado que importa, e não os testes em si. Se fosse possível desen-
volver sem testes, nós nos livraríamos deles em um minuto.
Massimo Arnoldi afirma:
Infelizmente para mim (e não só para mim) testar vai contra a

natureza humana. Se você liberar o porco que existe em você, perceberá
que você programa sem testes. Então depois de algum tempo, quando
sua parte racional vencer, você pára e começa a escrever testes. Você
também mencionou isto: a programação em pares reduz a probabilidade
de que ambos os parceiros liberem seus porcos no mesmo momento.
(Fonte: e-mail.)
Os testes que você precisa escrever na XP são isolados e automáticos.

Em primeiro lugar, nenhum teste interage com os outros que você escreve. Dessa
forma, você evita o problema de que um teste falhe e cause centenas de outras falhas.
Nada desencoraja mais os testes do que falsas negativas. Você recebe uma descarga
de adrenalina quando chega pela manhã e encontra uma pilha de defeitos. Quando
eles acabam não sendo nada sérios, é uma grande decepção. Você prestará cuidado-
samente atenção aos testes depois que algo assim acontecer cinco ou 10 vezes? Claro
que não.
Os testes também são automáticos. Os testes são mais valiosos quando o nível de
estresse aumenta, quando as pessoas estão trabalhando demais, quando o julgamen-
to humano começa a falhar. Logo, os testes precisam ser automáticos – retornando
um indicativo não-qualificativo, do tipo polegar para cima, polegar para baixo, de
como o sistema está se comportando.
É impossível testar absolutamente tudo sem que os testes sejam tão complicados
e tão inclinados a falhas quanto o código. É suicídio não testar nada (neste sentido de
testes isolados, automatizados). Então, dentre todas as coisas que você imagina que
possa testar, quais você deve testar?
Você deve testar as coisas que podem falhar. Se o código é tão simples que não é
possível que ele falhe, e você julga que o código em questão na prática não falha, en-
tão você não deve escrever um teste para ele. Se eu lhe falasse para testar absoluta-
mente tudo, logo você perceberia que a maior parte dos testes não teria valor, e, se
você fosse parecido comigo, logo pararia de escrevê-los. “Essa história de testar é
uma bobagem”.
Testar é apostar. A aposta vale a pena quando suas expectativas são contrariadas.
Uma maneira de ganhar é quando um teste que você não esperava que funcionasse
funciona. Então é melhor descobrir por que ele funciona, porque o código é mais es-
perto do que você. Outra maneira de ganhar é quando um teste falha e você espera-
va que ele funcionasse. Em ambos os casos, você aprende algo. E desenvolvimento
de software é aprendizado. Aprendendo melhor, você desenvolve melhor.
Assim, se você pudesse, você escreveria apenas aqueles testes que valem a pena.
Como você não possa saber quais valerão a pena (se você soubesse, então você já sa-
beria de antemão e não estaria aprendendo nada), você escreve testes que podem va-
ler a pena. Enquanto você testa, você reflete sobre que tipos de teste tendem a valer a
pena e que tipos não, e escreve mais daqueles que valem, e menos dos que não valem.
ESTRATÉGIA DE TESTES 121
Quem Escreve Testes?

Como eu disse no início do capítulo, os testes vêm de duas fontes:
• programadores;
• clientes.
Os programadores escrevem testes método a método. Um programador escreve

um teste sob as seguintes circunstâncias:
• Se a interface de um método não está muito clara, você escreve um teste antes
de escrever o método.
• Se a interface é clara, mas você imagina que a implementação será um pouco
complicada, você escreve um teste antes de escrever o método.
• Se você imagina circunstâncias inusitadas em que o código deve funcionar co-
mo esperado, você escreve um teste para comunicar as circunstâncias.
• Se você descobre um problema depois, você escreve um teste que isole o pro-
blema.
• Se você está prestes a refatorar código, e você não está certo de como ele vai se
comportar, e ainda não existe um teste para esse aspecto do comportamento
em questão, você escreve um teste primeiro.
Os testes de unidade escritos pelo programador sempre executam a 100%. Se um

dos testes de unidade falha, ninguém no time tem um trabalho mais importante do
que consertar os testes. Isso porque, se um teste está falhando, você tem uma quanti-
dade desconhecida de trabalho a fazer para consertá-lo. Pode levar apenas um minu-
to. Mas pode levar um mês. Você não sabe. E porque os programadores controlam a
escrita e a execução dos testes de unidade, eles podem manter os testes em completa
sintonia.
Os clientes escrevem testes história por história. A pergunta que eles precisam fa-
zer a si mesmos é “O que precisaria ser conferido para eu ter certeza de que essa his-
tória está OK?” Cada cenário que eles inventam torna-se um teste, neste caso, um tes-
te funcional.
Os testes funcionais não executam necessariamente a 100% o tempo todo. Pelo fa-
to de eles virem de uma fonte diferente do código em si, eu não descobri uma manei-
ra de sincronizar os testes funcionais e o código da mesma forma que o código e os
testes de unidade são sincronizados. Então, enquanto a medida dos testes de unida-
de é binária – 100% ou nada – a medida dos testes funcionais é, por necessidade, ba-
seada em porcentagens. Com o tempo, você espera que os testes funcionais atinjam
escores próximos a 100%. Quando você se aproximar da data de uma entrega, o
cliente precisará categorizar os testes funcionais que estão falhando. Alguns serão
mais importantes de corrigir do que outros.
Tipicamente, os clientes não conseguem escrever testes funcionais sozinhos. Eles
precisam da ajuda de alguém que possa primeiro traduzir os dados de teste em tes-
tes e, com o tempo, possa criar ferramentas que possibilitem ao cliente escrever, exe-
cutar e manter seus próprios testes. É por isso que um time XP de qualquer tamanho
tem ao menos um testador dedicado. A função do testador é traduzir as idéias de tes-
tes às vezes vagas do cliente em testes reais, automatizados e isolados. O testador
também usa os testes inspirados no cliente como o ponto de partida para variações
que possivelmente farão o software falhar.
Mesmo que você tenha um testador dedicado, alguém cujo prazer é ver falhar o
software que se imaginava já estar pronto, ele trabalha dentro da mesma estrutura
econômica que os programadores escrevendo testes. O testador está fazendo apostas,
torcendo para que um teste obtenha sucesso quando deveria falhar ou que falhe
quando deveria obter sucesso. Então o testador também está aprendendo a escrever
testes cada vez melhores com o tempo, testes que muito provavelmente valerão a pe-
na. O testador certamente não está lá apenas para fazer o maior número de testes
possível.
Outros Testes
Enquanto os testes funcionais e de unidade são o centro da estratégia de aplicação de
testes XP, existem outros que podem ser úteis de vez em quando. Um time XP reco-
nhecerá quando não está no caminho certo e quando um novo tipo de teste pode aju-
dar. Eles podem escrever qualquer um dos seguintes tipos de teste (ou qualquer ou-
tro teste que você possa encontrar em um livro a esse respeito):
• Teste paralelo – um teste projetado para provar que o novo sistema funciona
exatamente como o sistema antigo. Na verdade, o teste mostra a forma como
o novo sistema difere do sistema antigo, para que uma pessoa de negócios
possa tomar uma decisão de negócios quando a diferença é suficientemente
pequena para colocar o novo sistema em produção.
• Teste de estresse – um teste projetado para simular a pior carga possível. Testes
de estresse são bons para sistemas complexos, em que as características de per-
formance não são fáceis de prever.
• Teste do macaco – um teste projetado para garantir que o sistema reage de for-
ma adequada frente a entradas sem sentido.
SEÇÃO III
Implementando a XP
N
esta seção, discutiremos como colocar em prática as estratégias da última se-
ção. Ao escolher um conjunto de estratégias radicalmente simplificado, você
repentinamente terá muito mais flexibilidade para trabalhar. Você pode usar
essa flexibilidade para muitos propósitos, mas precisa estar ciente de sua existência
e das possibilidades que ela oferece.
CAPÍTULO 19
Adotando a XP
Adote uma prática da XP a cada vez, sempre abordando o problema que

mais preocupa o seu time. Uma vez que ele não é mais o seu problema
mais importante, passe para o próximo.
A
gradeço a Don Wells pela resposta simples e obviamente correta para a ques-
tão de como adotar a XP:
1. escolha o seu pior problema;

2. resolva-o da maneira XP;
3. quando ele não for mais seu pior problema, repita os passos 1 e 2 acima.
Os dois lugares óbvios por onde começar são os testes e o Jogo de Planejamento.
Muitos projetos estão impregnados com problemas de qualidade ou com um dese-
quilíbrio de poder entre negócios e desenvolvimento. O segundo livro sobre a XP, Ex-
treme Programming Applied: Playing to win, irá abordar esses dois tópicos por eles se-
rem lugares tão comuns para começar.
Existem muitas vantagens nesta abordagem. É tão simples que até mesmo eu con-
segui entender (uma vez que Don a elucidou para mim). Visto que você aprenderá
apenas uma prática de cada vez, você pode fazer um bom trabalho ao aprender cada
uma delas. Já que você irá sempre abordar seus problemas mais difíceis, você terá
muita motivação para fazer mudanças e obterá feedback positivo imediato de seus
esforços.
Abordar o problema mais difícil também resolve a objeção que fazem à XP, de que
ela é do tipo “tamanho único”. Ao adotar cada uma das práticas, você irá moldá-la
de acordo com a sua situação. Se você não tiver um problema, nem mesmo vai con-
siderar resolvê-lo usando XP.
Não subestime a importância do espaço físico quando adotar a XP, mesmo que
você não considere isto um problema. Eu geralmente começo com uma chave de fen-
da e um alicate. Vou adicionar ainda dois passos ao processo.
1. reorganize a mobília de forma que voce possa fazer a programação em pares

e o cliente possa se sentar com você;
0. compre alguns salgadinhos.
CAPÍTULO 20
Ajustando a XP
Projetos que querem alterar sua cultura atual são muito mais comuns
do que projetos que podem criar uma cultura completamente nova. Ado-
te a XP um pouco de cada vez em projetos que já estão acontecendo, co-
meçando com testes ou planejamento.
A
dotar XP com um time novo é um desafio. Adotá-la com um time e uma base
de código já existentes é ainda mais difícil. Você tem todos os desafios que já
existiam – desenvolver as habilidades, treinamento, adaptar o processo as
suas condições. Você também tem a pressão imediata de manter o software de produ-
ção executando. É improvável que o software seja escrito de acordo com seus novos
padrões. É provável que seja mais complexo do que precisa ser. É improvável que se-
ja testado da forma que você gostaria. Em um time novo, você pode selecionar ape-
nas aquelas pessoas que se dispõem a tentar a XP. Em um time já existente, é prová-
vel que haja alguns céticos. Ainda por cima, todas as mesas já estão arrumadas, e vo-
cê nem pode programar em pares.
Você precisará de mais tempo para ajustar a XP em um projeto do que para ado-
tá-la em um time novo equivalente. Essa é a má notícia. A boa notícia é que existem
alguns riscos enfrentados por um desenvolvimento XP com um time novo que você
não precisará enfrentar. Você nunca estará na arriscada situação de pensar que você
tem uma boa idéia para software, mas não tem certeza. Você nunca estará na posição
arriscada de fazer muitas decisões sem o feedback imediato e brutal que você obtém
de clientes reais.
Eu converso com muitos times que dizem: “Sim, claro, já estamos fazendo XP. Tu-
do menos essa história de testes. E temos um documento de requisitos com 200 pá-
ginas. Mas todo o resto é exatamente como fazemos”. É por isso que este capítulo es-
tá arranjado prática a prática. Se você já está fazendo uma dada prática defendida pe-
la XP, pode ignorar a seção correspondente. Se há alguma prática nova que você
queira adotar, confira a seção voltada a essa prática.
Como você pode adotar a XP em um time já existente, com software já em produ-

ção? Você precisará modificar a estratégia de adoção nas seguintes áreas:
• testes;
• projeto;
• planejamento;
• gerenciamento;
• desenvolvimento.
Testes
Os testes são provavelmente a área mais frustrante quando você está mudando o có-
digo existente para XP. O código escrito antes de haver testes é assustador. Você nun-
ca sabe direito onde está. Esta modificação será segura? Você nunca tem certeza.
Tão-logo você começa a escrever os testes, tudo muda de figura. Você confia no
novo código. Você não se importa em fazer modificações. Na verdade, é até um pou-
co divertido.
Mudar de código velho para novo é como noite e dia. Você começará a evitar o có-
digo velho. Você precisa evitar essa tendência. A única maneira de ter o controle da
situação é trazer todo o código à tona. Do contrário, coisas terríveis crescerão no es-
curo. Você terá riscos de magnitude desconhecida.
Nesta situação, é tentador simplesmente voltar e escrever testes para todo o códi-
go já existente. Não faça isso. Em vez disso, escreva os testes sob demanda.
• Quando você precisa adicionar funcionalidade em código não testado, escre-

va testes para suas funcionalidades atuais primeiro.
• Quando você precisa concertar um bug, escreva um teste primeiro.
• Quando você precisa refatorar, escreva testes primeiro.
O que você descobrirá é que o desenvolvimento parecerá lento no princípio. Você

gastará muito mais tempo escrevendo testes do que você gastaria normalmente na
XP, e sentirá que faz progressos em uma nova funcionalidade mais devagar do que
antes. Entretanto, as partes do sistema que você verifica o tempo todo, as partes que
atraem atenção e novas funcionalidades, serão completamente testadas de forma
rápida. Logo, as partes mais usadas do sistema terão a aparência de ter sido escritas
em XP.
Projeto
A transição para o projeto XP é muito parecida com a transição para a fase de testes
XP. Você notará que o novo código é completamente diferente do antigo. Você dese-
jará consertar tudo de uma vez. Não faça isso. Faça um pouco de cada vez. Enquan-
to você adiciona uma nova funcionalidade, esteja preparado para primeiro refatorar.
Você está sempre preparado para refatorar antes de implementar no desenvolvimen-
to XP, mas você precisará fazer isso mais freqüentemente quando estiver efetuando a
transição para XP.
AJUSTANDO A XP 129
Bem cedo durante o processo, faça com que o time identifique alguns objetivos de
refatoração em larga escala. Pode haver uma hierarquia de herança particularmente
emaranhada, ou uma funcionalidade qualquer espalhada por todo o sistema que vo-
cê deseja unificar. Defina esses objetivos, coloque-os em cartões, e deixe-os visíveis
de forma destacada. Quando você puder dizer que a refatoração pesada está termi-
nado (o que pode levar meses ou até mesmo um ano de lento progresso), dê uma
grande festa. Queime os cartões como em uma cerimônia. Coma e beba à vontade.
O efeito desta estratégia é muito parecido com o efeito da estratégia de testes sob
demanda. Aquelas partes do sistema que você verifica o tempo todo em suas ativi-
dades de desenvolvimento logo parecerão com o código que você está escrevendo
agora. A sobrecarga da refatoração extra logo desaparecerá.
Planejamento
Você precisará converter a informação de requisitos já existente em cartões de histó-
rias. Você precisará educar seu cliente sobre as regras do jogo. O cliente precisará de-
cidir do que se constitui a próxima entrega.
O maior desafio (e oportunidade) de mudar para o planejamento XP é ensinar ao
cliente o quanto a mais ele pode obter do time. Eles provavelmente nunca tiveram a
experiência de um time de desenvolvimento que aprecia modificações nos requisi-
tos. Demora algum tempo para se acostumar com o quanto a mais o cliente pode
conseguir do time.
Gerenciamento
Uma das transições mais difíceis é acostumar-se com o gerenciamento XP. O geren-
ciamento XP é um jogo de dissimulação e influência. Se você for um gerente, você
provavelmente perceberá que está tomando decisões que deveriam ser tomadas por
programadores ou clientes. Se estiver, não entre em pânico. Apenas lembre a si mes-
mo e a todos presentes que você está aprendendo. E então peça à pessoa certa para
tomar a decisão e informe-se sobre o que ela decidiu.
É improvável que programadores subitamente confrontados com novas respon-
sabilidades façam um bom trabalho imediatamente. Como gerente, você precisa ser
cuidadoso durante o período de transição para lembrar a todos das regras que eles
escolheram. Sob pressão, todos voltarão aos padrões de comportamento anterior,
não importando se esses padrões funcionassem ou não.
A sensação será um pouco como a da transação de projeto ou de testes. No come-
ço, haverá uma sensação estranha. Você saberá que não está indo a toda velocidade.
Ao prestar atenção nas situações que ocorrem no dia-a-dia, você (e os programado-
res e clientes) aprenderá a lidar com elas de forma tranqüila. Rapidamente você co-
meçará a se sentir confortável com seu novo processo. Porém, de vez em quando,
surgirá um a situação que você não tinha enfrentado de maneira eXtrema antes.
Quando isso acontecer, respire fundo. Lembre as regras, os valores e os princípios ao
time. E então decida o que fazer.
Um dos aspectos mais difíceis de gerenciar uma mudança radical para XP é con-
cluir que um dos membros do time não trabalha de maneira satisfatória. Nesta situa-
ção, você estará melhor sem ele. Você deve fazer a alteração assim que estiver certo
de que a situação não irá melhorar.
Desenvolvimento
A primeira coisa que você tem de fazer é arrumar as mesas direito. Sem brincadeira.
Leia novamente o material sobre programação em pares (Capítulo 16, Estratégia de
Desenvolvimento). Arrume as mesas para que duas pessoas possam se sentar lado a
lado e passar o teclado uma para a outra sem precisar mover suas cadeiras.
Por um lado, quando você está fazendo a transição para XP, você deve ser mais rí-
gido sobre a programação em pares do que normalmente precisaria ser. A programa-
ção em pares pode ser desconfortável no princípio. Force a si mesmo a praticá-la,
mesmo que você não queira. Por outro lado, faça uma pausa de vez em quando. Fi-
que sozinho e programe por algumas horas. Jogue fora o resultado, é claro, mas não
destrua a sua satisfação em programar apenas para poder dizer que você pareou por
30 horas em uma semana.
Vá resolvendo os problemas de teste e projeto aos poucos. Faça com que todo o có-
digo em que vocês tocam fique condizente com os padrões de codificação combina-
dos. Você se surpreenderá com o quanto pode aprender com essa simples atividade .
Com Problemas?
Alguns de vocês lendo este livro terão um time já existente, mas seu software não es-
tá ainda em produção. Seu projeto pode estar em apuros. A XP pode parecer uma sal-
vação possível.
Não conte com isso. Se você tivesse usado XP desde o início, você poderia (ou
não) ter evitado sua situação atual. Se trocar de cavalo no meio de um rio é difícil,
trocar de um cavalo que está se afogando é dez vezes mais difícil. As emoções esta-
rão fortes. O moral estará baixo.
Se a escolha for entre trocar para XP ou ser despedido, primeiramente considere
que suas chances de adotar consistentemente novas práticas não são muito boas. Sob
estresse, você volta para hábitos antigos. Você já está sob muito estresse. Suas chan-
ces de fazer a troca com sucesso são reduzidas drasticamente. Defina um objetivo
mais humilde para você do que salvar todo o projeto. Viva um dia de cada vez. Cele-
bre o quanto você pode aprender sobre testes, ou gerenciar indiretamente, ou quão
bonito você pode deixar um projeto, ou quanto código você pode apagar. Talvez do
caos possa emergir ordem suficiente para que você nem queira vir trabalhar no dia
seguinte.
Mas se você for mudar um projeto problemático para XP, faça disto um gesto dra-
mático. Meias medidas vão deixar todos mais ou menos na mesma situação que es-
tavam antes. Avalie cuidadosamente a base de código atual. Você estaria melhor sem
ela? Se a resposta for sim, livre-se dela. Toda ela. Faça uma fogueira e queime as fitas
antigas. Tire uma semana de férias. Comece novamente tudo de novo.
CAPÍTULO 21
Ciclo de Vida de um Projeto XP Ideal
O projeto XP ideal passa por uma curta fase de desenvolvimento inicial,

seguida por anos de suporte à produção e refinamento simultâneos, e fi-
nalmente chega a uma graciosa aposentadoria quando o projeto não faz
mais sentido.
E
ste capítulo lhe dará uma idéia da história global de um projeto XP. Ele é ideali-
zado – você talvez tenha percebido a essa altura que dois projetos XP não pode-
riam (ou deveriam) ser exatamente iguais. O que eu espero que você obtenha
neste capítulo é uma idéia do fluxo global de um projeto.
Exploração
Pré-produção é um estado não-natural para um sistema e deveria ser tirada do cami-
nho o mais rápido possível. Como foi mesmo a frase que eu ouvi recentemente? “Ir
para a produção é morrer.” A XP diz exatamente o contrário. Não estar em produção
é estar gastando dinheiro sem fazer dinheiro. Talvez seja apenas a minha carteira,
mas eu acho o estado de ter apenas gastos e nenhuma renda muito desconfortável.
Antes de passar para a fase de produção, no entanto, você precisa acreditar que
pode ir para a produção. Você precisa confiar suficientemente em suas ferramentas
para acreditar que conseguirá terminar o programa. Você precisa acreditar que, uma
vez que o código estiver terminado, você poderá executá-lo dia após dia. Você tem de
acreditar que possui (ou pode aprender) as habilidades de que precisa. Os membros
do time precisam aprender a confiar uns nos outros.
A fase de exploração é onde tudo isso acontece. Você terminou a exploração quan-
do o cliente está confiante de que existe material mais do que suficiente nos cartões
de histórias para fazer uma boa primeira entrega, e os programadores estão confian-
tes de que não conseguem estimar melhor sem realmente implementar o sistema.
Durante a exploração, os programadores estão usando toda a tecnologia que será
usada no sistema de produção. Eles estão explorando ativamente as possibilidades
para a arquitetura do sistema. Eles o fazem passando uma ou duas semanas cons-
truindo um sistema parecido com o que eles irão construir realmente, mas fazendo
isso de três ou quatro maneiras distintas. Pares diferentes podem fazer experimentos
com os sistemas de formas diferentes e depois comparar, ou você pode ter dois pares
experimentando o sistema da mesma forma e ver se alguma diferença emerge.
Se uma semana não for suficiente para fazer funcionar uma determinada tecnolo-
gia, então eu classificaria essa tecnologia como arriscada. Não quer dizer que você
não deva utilizá-la. Mas você deveria explorá-la mais cuidadosamente e considerar
alternativas.
Talvez você considere trazer especialistas em tecnologia durante a fase de ex-
ploração, para que seus experimentos não sejam prejudicados por coisas insignifi-
cantes que poderiam ser resolvidas facilmente por alguém que já tem experiência.
No entanto, seja cauteloso ao aceitar cegamente um conselho para o eventual uso
da tecnologia. Às vezes, os especialistas desenvolvem hábitos baseados em siste-
mas de valores que não estão totalmente em sintonia com a programação eXtrema.
O time precisará sentir-se confortável com as práticas que escolherem. Não é mui-
to agradável dizer: “Os especialistas disseram que é assim” quando o projeto está
saindo de controle.
Os programadores devem também fazer experimentos com os limites de perfor-
mance da tecnologia que eles irão utilizar. Se possível, eles devem simular cargas rea-
lísticas com o hardware e a rede de produção. Você não precisa ter todo o sistema pron-
to para escrever uma simulação de carga. Você pode obter experiência apenas calcu-
lando, por exemplo, quantos bytes por segundo sua rede terá de suportar e então exe-
cutar um experimento para verificar se ela fornece a largura de banda necessária.
Os programadores devem também experimentar idéias de arquiteturas – como
construir um sistema para múltiplos níveis de undo? Implemente isso de três formas
diferentes durante um dia e verifique qual é a melhor. Essas pequenas explorações de
arquitetura são muito importantes quando o usuário apresenta histórias que você
não tem a mínima idéia de como implementar.
Os programadores devem estimar cada tarefa de programação a qual se dedica-
rão durante a exploração. Quando uma tarefa está completa, eles devem reportar o
tempo real de calendário requerido para a tarefa. A prática de estimativas irá aumen-
tar a confiança do time nessa esfera quando chegar a hora de assumir um comprome-
timento público.
Enquanto o time estiver treinando com a tecnologia, o cliente está praticando a es-
crita das histórias. Não espere que isso ocorra sem problemas. Em um primeiro mo-
mento, as histórias não serão o que você precisa. O segredo é dar ao cliente muito feed-
back rápido das primeiras histórias, para que ele possa aprender rapidamente a espe-
cificar o que os programadores precisam e a não especificar o que eles não precisam.
A pergunta-chave é: “Os programadores conseguem estimar com segurança o esfor-
ço requerido pela história?”. Algumas das histórias precisam ser escritas de maneira
diferente; algumas vezes, os programadores precisam fazer mais experimentos.
Se você tem um time que já conhece a tecnologia e cujos membros já se conhecem,
a fase de exploração pode levar apenas algumas semanas. Com um time que não co-
nhece a tecnologia ou o domínio, você talvez precise gastar alguns meses. Se a explo-
ração levar mais tempo do que isso, eu talvez procuraria um projeto pequeno mas
real que eles pudessem concluir facilmente, a fim de dar urgência ao processo.
CICLO DE VIDA DE UM PROJETO XP IDEAL 133
Planejamento
O propósito da fase de planejamento é fazer os clientes e os programadores chega-
rem a um acordo sobre a data na qual o menor e mais valioso conjunto de histórias
estará terminado. Veja no Jogo do Planejamento uma maneira de executar isso. Se vo-
cê se preparar durante a fase de exploração, o planejamento (a produção de um cro-
nograma de comprometimento) deverá levar um ou dois dias.
O plano para a primeira entrega deve ter entre dois e seis meses de duração. Você
provavelmente não será capaz de resolver nenhum problema de negócios significati-
vo em menos tempo do que isso. (Mas se você conseguir, ótimo! Veja Principles of Soft-
ware Engineering Management, de Tom Gilb, para idéias sobre como encolher o prazo
da primeira entrega). Em mais do que alguns meses, o risco será grande demais.
Iterações para a Primeira Entrega

O cronograma de comprometimento será dividido em iterações com duração entre
uma e quatro semanas. Cada iteração produzirá um conjunto de casos de testes fun-
cionais para cada uma das histórias programadas para esta iteração.
A primeira iteração define a arquitetura. Escolha histórias para a primeira itera-
ção que o forcem a criar o “sistema todo”, mesmo que seja um esqueleto.
As histórias escolhidas para as iterações subseqüentes ficam totalmente a critério
do cliente. A pergunta a fazer é: “Nesta iteração, que coisa para nós teria maior valor
ao ser implementada?”
Enquanto as iterações vão ocorrendo, você fica procurando pelos desvios do pla-
no. Tudo está levando o dobro do tempo planejado? Metade do tempo? Os casos de
teste estão ficando prontos a tempo? Você está se divertindo?
Quando você detecta desvios do plano, você precisa modificar algo. Talvez o pla-
no precise de modificações – adicione ou remova histórias ou modifique seus esco-
pos. Talvez o processo precise de modificações – você descobre maneiras melhores
de trabalhar a sua tecnologia, ou melhores maneiras de trabalhar a XP.
Idealmente, ao final de cada iteração, o cliente terá completado os testes funcio-
nais, e todos estarão executando. Faça uma pequena cerimônia no fim de cada itera-
ção – compre pizza, atire fogos de artifícios, faça o cliente assinar os cartões de histó-
rias já prontos. Afinal, você acabou de entregar software de qualidade no prazo. Tal-
vez tenham sido somente três semanas de trabalho, mas ainda é uma vitória e vale
ser celebrada.
No fim da última iteração, você estará pronto para entrar em produção.
Produção
O jogo final de uma entrega (produção) enfrenta um ciclo de feedback mais apertado.
Em vez de iterações com duração de três semanas, você talvez passará para iterações
com duração de uma semana. Você talvez tenha uma reunião em pé diária para que
todos conheçam aquilo em que todos os outros estão trabalhando.
Tipicamente haverá algum processo para se certificar de que o software está pron-
to para entrar em produção. Esteja preparado para implementar novos testes para
provar que ele está em boa forma. Testes paralelos são freqüentemente aplicados nes-
ta etapa.
Você talvez precise ajustar o desempenho do sistema durante esta fase. Eu não
falei muito sobre ajustes de desempenho neste livro. Eu acredito fortemente no le-
ma “Faça-o executar, faça-o certo, faça-o rápido”. Mais tarde, durante o jogo, é o mo-
mento perfeito para ajustar, visto que você terá todo o conhecimento possível embu-
tido no projeto do sistema, você terá as estimativas mais realistas possíveis sobre a
carga de produção no sistema e é provável que você tenha o hardware de produção
já disponível.
Durante a produção, você diminuirá o ritmo de evolução do software. O software
não pára de evoluir, mas o risco torna-se mais importante em sua avaliação quanto
às mudanças que merecem ser acrescentadas nesta versão. No entanto, esteja ciente
de que, quanto mais experiência você tiver com um sistema, mais idéias você terá so-
bre como ele deveria ser projetado. Se você começar a ter muitas idéias, mas não en-
contrar justificativas para acrescentá-las ao sistema nesta versão, faça uma lista visí-
vel delas para que todos possam ver qual será o caminho depois que esta versão en-
trar em produção.
Quando o software entrar em produção de fato, dê uma grande festa. Muitos pro-
jetos nunca entram em produção. Um projeto que “ganha vida”* é motivo para co-
memorar. Se você não estiver um pouco assustado ao mesmo tempo, você é maluco,
mas a festa pode ajudá-lo a eliminar um pouco da tensão excessiva que com certeza
se acumulou.
Manutenção
Manutenção é realmente o estado normal de um projeto XP. Você precisa simultanea-
mente produzir novas funcionalidades, manter o sistema existente executando, in-
corporar novas pessoas ao time e dizer adeus aos membros que sairão do time.
Cada versão começa com uma fase de exploração. Você talvez tente grandes refa-
torações que temia inserir na entrega anterior. Você talvez experimente novas tecno-
logias que pretende adicionar na próxima entrega, ou migre para novas versões das
tecnologias que você já está utilizando. Você talvez experimente novas idéias de ar-
quitetura. O cliente talvez tente escrever novas histórias mirabolantes na procura de
um grande trunfo para os negócios.
Desenvolver um sistema que está em produção é muito diferente de desenvolver
um sistema que ainda não está em. Você é mais cuidadoso com as modificações que
você faz. Você precisa estar preparado para interromper o desenvolvimento a fim
reagir a problemas de produção. Você tem dados reais com os quais é necessário ter
cuidado para migrar ao fazer modificações no projeto. Se a pré-produção não fosse
tão perigosa, você evitaria entrar em produção para sempre.
Estar em produção provavelmente modificará sua velocidade de desenvolvimen-
to. Seja conservador em relação às suas novas estimativas. Enquanto você está explo-
rando, meça o efeito que o suporte à produção tem em suas atividades de desenvol-
vimento. Eu tenho visto um aumento de 50% na razão entre o tempo ideal de desen-
volvimento e o tempo de calendário após ter-se entrado em produção (de dois dias
de calendário por dia de desenvolvimento, passou-se a três). Entretanto, não adivi-
nhe: meça.
*N. de T. A expressão “ganha vida” foi usada aqui para traduzir a expressão americana go live significando que o soft-
ware é produzido e passa a ser utilizado por usuários reais).
CICLO DE VIDA DE UM PROJETO XP IDEAL 135
Esteja preparado para modificar a estrutura do time que vai lidar com a produ-
ção. Você talvez queira fazer rodízio no “help desk”, de forma que a maioria dos pro-
gramadores não tenham de lidar com interrupções de produção na maior parte do
tempo. Cuide para circular todos os programadores por todas as posições – existem
coisas que você aprende dando suporte à produção que você não conseguiria apren-
der de nenhuma outra forma. Por outro lado, não é tão divertido quanto desenvol-
ver.
Coloque o software recentemente desenvolvido em produção enquanto você vai
avançando. Você talvez saiba que certas partes de um software não serão executadas.
Coloque-as no sistema em produção mesmo assim. Eu já estive em projetos em que
este ciclo era diário ou semanal. Em qualquer situação, é melhor você não deixar có-
digo parado por mais do que uma iteração. O momento adequado depende de quan-
to custam a verificação e a migração. A última coisa de que você precisa quando está
no fim de uma versão é integrar uma montanha de códigos, que “de forma alguma”
poderiam estragar algo. Se você mantiver a base de código de produção e a base de
código de desenvolvimento praticamente em sincronia, você ficará sabendo de pro-
blemas de integração muito mais cedo.
Quando novos membros entrarem no time, dê a eles duas ou três iterações em
que suas únicas funções sejam fazer muitas perguntas, agir como parceiros de pro-
gramação e ler muitos testes e códigos. Quando eles se sentirem prontos, podem as-
sumir a responsabilidade por algumas tarefas de programação, mas com um fator de
carga de trabalho reduzido. Quando eles demonstrarem que conseguem acompa-
nhar, podem aumentar seus fatores de carga de trabalho.
Se o time mudar gradualmente, em menos de um ano você poderá substituir o ti-
me original de desenvolvimento por novas pessoas sem perturbar o suporte à pro-
dução ou o desenvolvimento em andamento. Esta é uma solução muito menos arris-
cada do que o típico “aqui está uma pilha de papéis que contém toda a informação
de que você precisa”. Na verdade, comunicar a cultura que cerca o projeto é tão im-
portante quanto comunicar os detalhes do projeto e da implementação, e isso só po-
de ser feito pelo de contato pessoal.
Morte
Morrer bem é tão importante quanto viver bem. Isso é verdade tanto para a XP quan-
to para as pessoas.
Se o cliente não consegue produzir novas histórias, então é hora de guardar o sis-
tema no armário. Agora é a hora de escrever um tour pelo sistema que tenha de cin-
co a 10 páginas, o tipo de documento que você deseja encontrar quando for preciso
mudar algo daqui a cinco anos.
Este é o bom motivo para morrer – o cliente está satisfeito com o sistema e não
consegue pensar em nada que gostaria de adicionar em um futuro próximo. (Eu nun-
ca tive essa experiência, mas já ouvi falar, por isso inclui aqui).
Também há um motivo não tão bom para morrer – o sistema não está agregando
valor. O cliente precisa de funcionalidades, e você não consegue adicioná-las de for-
ma econômica. A taxa de erros sobe assustadoramente para um nível intolerável.
Essa é a morte entrópica contra a qual você lutou por tanto tempo. XP não é má-
gica. A entropia eventualmente alcança projetos XP também. Você apenas prefere que
isso ocorra o mais tarde possível.
De qualquer forma, nós já postulamos o impossível – o sistema precisa morrer.
Todos devem permanecer de olhos abertos quando isso acontecer. O time precisa es-
tar ciente do aspecto econômico da situação. Eles, os clientes e os gerentes, devem ser
capazes de concordar que o time e o sistema não conseguem mais agregar o valor ne-
cessário.
Então é hora de um adeus emocionado. Faça uma festa. Convide todo mundo que
já trabalhou no sistema para vir e trocar reminiscências. Aproveite a oportunidade pa-
ra tentar apontar as razões da queda do sistema, para que você saiba o que procurar
no futuro. Imagine com o time um jeito de fazer as coisas diferentes da próxima vez.
CAPÍTULO 22
Papéis para Pessoas
Certos papéis precisam ser preenchidos para que um time eXtremo fun-
cione – programador, cliente, treinador, rastreador.
U
m time esportivo funciona melhor quando existem certos papéis pelos quais
alguém é responsável. No futebol existem o goleiro, o atacante, o zagueiro,
etc. No basquete existem o armador, o pivô, o ala e outros.
Um jogador que assume uma dessas posições aceita um certo conjunto de respon-
sabilidades – criar condições para que o colega faça o ponto, evitar que o outro time
faça pontos, talvez controlar uma determinada parte do campo. Alguns papéis são
quase solitários. Outros requerem que o jogador corrija os erros dos colegas, ou con-
trole suas interações.
Esses papéis tornam-se habituais, e às vezes se incorporam às regras do jogo, pre-
cisamente porque eles funcionam. É provável que, em algum momento, todas as
outras combinações de responsabilidades já tenham sido tentadas. As que você vê
hoje em dia estão lá porque elas funcionaram, e as outras não.
Bons treinadores são eficientes para fazer que um jogador seja competente em sua
posição. Eles identificam desvios da prática usual das posições e ajudam o jogador a
corrigir o desvio ou entendem porque é aceitável que este jogador em especial faça
as coisas de forma um pouco diferente.
Entretanto, o grande treinador sabe que as posições são apenas um costume, e
não leis da natureza. De tempos em tempos, o jogo ou os jogadores mudam tanto que
novas posições tornam-se possíveis, e as antigas tornam-se obsoletas. Grandes trei-
nadores estão sempre procurando as vantagens que poderiam surgir da criação de
novas posições e da eliminação de existentes.
Outra facilidade dos grandes treinadores esportivos é sua habilidade de moldar
o sistema tático aos seus jogadores, e não o inverso. Se você tem um sistema tático
que funciona maravilhosamente com jogadores rápidos, e o time que se apresenta no
primeiro treino é grande e forte, então será melhor criar um novo esquema tático que
deixe os talentos do time brilharem. Muitos treinadores não conseguem fazer isso.
Em vez disso, eles ficam tão focados na beleza do “esquema tático” que não perce-
bem que não está funcionando.
Tudo isso é um preâmbulo para um aviso importante sobre o que vem adiante.
Aqui estão alguns papéis que funcionaram bem em projetos anteriores. Se você tem
pessoas que não se adaptam aos papéis, mude os papéis. Não tente mudar as pessoas
(não muito...). Não aja como se não houvesse um problema. Se um papel diz: “Esta
pessoa deve estar disposta a correr riscos” e você não tem uma pessoa assim, você
precisa encontrar uma divisão diferente de responsabilidades, uma que corresponda
aos seus objetivos sem que o papel em questão seja preenchido por alguém inclina-
do a atitudes arriscadas.
Um exemplo. Eu estava conversando com um gerente sobre um de seus times.
Um programador era também o cliente. Eu disse que isso não poderia funcionar, já
que o programador precisa executar o processo, tomar decisões técnicas e delegar de-
cisões de negócios para o cliente (veja o Jogo do Planejamento).
O gerente argumentou: “Esse cara é um verdadeiro negociante de contratos;
acontece que ele também sabe programar. Os outros negociantes de contratos gostam
dele e o respeitam, e estão dispostos a confiar e acreditar nele. Ele tem uma visão ní-
tida do caminho que o sistema deve seguir. Os outros programadores sabem quando
ele está falando como cliente e quando está tomando decisões técnicas”.
Tudo bem. As regras dizem que um programador não pode ser o cliente. Neste
caso, as regras não se aplicam. O que se aplica ainda é a separação das decisões téc-
nicas e de negócios. O time todo, o programador/cliente, e especialmente o treinador
precisam estar cientes de que papel o programador/cliente está assumindo em qual-
quer momento. E o treinador precisa saber que, não importa quão bem o arranjo te-
nha funcionado no passado, se eles tiverem problemas, é provável que o papel duplo
seja a causa dos problemas.
Programador
O programador é o coração da XP. Na verdade, se programadores pudessem sempre
tomar decisões que cuidadosamente balanceassem prioridade de curto e longo pra-
zo, não haveria necessidade de nenhum outro pessoal técnico no projeto além dos
programadores. Obviamente, se o cliente não precisasse realmente do software para
manter seu negócio andando, não haveria necessidade de programadores, então não
fique convencido com essa história de o programador ser vital.
À primeira vista, ser um programador XP é muito parecido com ser um progra-
mador em qualquer outro método de desenvolvimento de software. Você passa o tem-
po trabalhando com programas, tornando-os maiores, mais simples, mais rápidos.
Observando mais atentamente, no entanto, vemos que o foco é bastante diferente.
Seu trabalho não termina quando o computador entende o que fazer. Seu primeiro
valor é a comunicação com outras pessoas. Se o programa executa, mas existe um
componente de comunicação vital que ainda precisa ser feito, você não terminou. Vo-
cê escreve testes que demonstram algum aspecto vital do software. Você divide o pro-
grama em pedaços menores, ou junta pedaços muito pequenos para formar pedaços
maiores e mais coerentes. Você encontra um sistema de nomeação que reflita as suas
intenções mais precisamente.
PAPÉIS PARA PESSOAS 139
Isso pode parecer uma ambiciosa busca pela perfeição. Não é nada disso. Você
procura desenvolver o software mais valioso para o cliente, mas sem desenvolver na-
da que não seja valioso. Se você pode reduzir suficientemente o tamanho do proble-
ma, então você pode se dar ao luxo de ser cuidadoso com o trabalho que resta. E en-
tão, você é cuidadoso por hábito.
Existem habilidades que você precisa ter para ser um programador XP, que não
são necessárias nem enfatizadas em outros estilos de desenvolvimento. A programa-
ção em pares é uma habilidade que se aprende, mas geralmente conflita com as ten-
dências do tipo de pessoa que tipicamente programa. Talvez eu devesse expressar is-
so de maneira menos equívoca – nerds* geralmente não são bons em falar. Claro, exis-
tem algumas exceções, e é possível aprender a falar com outros colegas, mas na ver-
dade, você precisará coordenar-se e comunicar-se intensamente com outros progra-
madores para obter sucesso.
Outra habilidade necessária para um programador eXtremo é o hábito da simpli-
cidade. Quando o cliente diz: “Você precisa fazer isto e aquilo”, você precisa estar
preparado para discutir quais dessas coisas são realmente necessárias e o quanto de
cada. A simplicidade estende-se também ao código que você escreve. Um programa-
dor sempre disposto a utilizar os mais recentes padrões (patterns) de análise e proje-
to provavelmente não terá sucesso na XP. É claro que você pode fazer um serviço me-
lhor se tiver mais ferramentas a sua disposição, mas é muito mais importante ter um
punhado de ferramentas que você sabe quando não usar do que saber tudo sobre tu-
do e arriscar utilizar soluções demais.
Você precisará de habilidades mais orientadas a aspectos técnicos também. Você
precisa ser capaz de programar razoavelmente bem. Você precisa ser capaz de refa-
torar, que é uma habilidade com pelo menos tanta profundidade e sutileza quanto
programar. Você precisa ser capaz de fazer testes de unidade com seu código, o que,
como a refatoração, requer discernimento e bom senso.
Você precisa estar disposto a abrir mão do sentimento de posse individual de par-
te do sistema em troca de uma posse compartilhada do sistema como um todo. Se al-
guém modifica o código que você escreveu, ou qualquer parte do sistema, você pre-
cisa confiar nas alterações e aprender com elas. Obviamente, se as modificações são
para pior, é sua responsabilidade corrigir a situação.
Acima de tudo, você precisa reconhecer seus medos. Todos têm medo:
• medo de parecer bobo;

• medo de que o considerem inútil;
• medo de se tornar obsoleto;
• medo de não ser bom o bastante.
Sem coragem, a XP simplesmente não funciona. Você passaria o tempo todo ten-
tando desesperadamente não falhar. Em vez disso, se você está disposto, com a aju-
da do time, reconheça seus medos. E então você pode seguir em frente, pertencendo
a um time que se diverte programando um ótimo software.
*N. de T.Nerd é uma gíria norte-americana para pessoas excluídas da sociedade talvez por serem exageradamente afi-
cionadas por tecnologia, computadores e programação).
Cliente
O cliente é a outra metade da dualidade essencial da programação eXtrema. O pro-
gramador sabe como programar. O cliente sabe o que programar. Bem, não em prin-
cípio, claro, mas o cliente está tão disposto a aprender quanto o programador.
Ser um cliente XP não é fácil. Há habilidades que você precisa aprender, como es-
crever boas histórias, e uma atitude que fará você ter sucesso. Porém, o mais impor-
tante é que você precisará sentir-se confortável em influenciar o projeto sem poder
controlá-lo. Forças que fogem ao seu controle vão moldar o que realmente é desen-
volvido tanto quanto as decisões que você toma. Alterações nas condições de negó-
cios, na tecnologia, na composição e na capacidade do time, todas elas têm um im-
pacto enorme sobre o software que será entregue.
Você precisará tomar decisões. Essa é a habilidade mais difícil para alguns dos
clientes com quem trabalhei. Eles estão acostumados ao fato de a TI não entregar
nem metade do que prometera, e ainda por cima, o que é entregue estar meio errado.
Eles aprenderam a não confiar na TI, já que, de qualquer forma, eles acabariam desa-
pontados. A XP não funcionará com esse tipo de cliente. Se você é um cliente XP, o ti-
me precisa que você afirme com confiança “Isto é mais importante do que aquilo”,
“Esta parte da história já é o bastante”, “Estas histórias aqui já são suficientes”. E
quando os tempos forem difíceis, e eles sempre ficam difíceis, o time precisa ser ca-
paz de fazer você mudar de idéia. “Bem, eu acho que não é tão importante assim ter
isto pronto até o próximo trimestre.” Ser capaz de tomar decisões como esta às vezes
salva o time e reduz o estresse, o bastante para que eles possam dar o melhor de si
para você.
Os melhores clientes são aqueles que de fato usam o sistema que está sendo de-
senvolvido, mas que também têm uma certa visão do problema a ser resolvido. Se
você é um desses clientes, você precisará distinguir se está pensando de uma certa
forma porque as coisas sempre foram feitas desse jeito, ou por alguma característica
intrínseca do problema. Se você não tem tanta intimidade com o sistema, precisará se
esforçar muito para garantir que possa representar as necessidades do usuário real.
Você precisará aprender a escrever histórias. Pode parecer uma tarefa impossível
em princípio, mas o time o beneficiará com grande quantidade de feedback nas pri-
meiras histórias que você escrever, e rapidamente você aprenderá o quanto cada his-
tória deve cobrir e que informações devem ser incluídas ou excluídas.
Você precisará aprender a escrever testes funcionais. Se você é o cliente de uma
aplicação com base matemática, será um trabalho mais fácil – alguns minutos ou ho-
ras com uma planilha serão suficientes para criar os dados de um caso de teste. Ou
talvez seu time construa para você uma ferramenta para facilitar a entrada de novos
casos de teste. Programas com funcionamento já bastante conhecido e popularizado
(como Workflow, por exemplo) também precisam de testes funcionais. Você terá de
trabalhar intensamente com o time para aprender que tipo de coisa é interessante tes-
tar e que tipos de teste são redundantes. Alguns times podem até lhe fornecer uma
ajuda técnica para escolher, escrever e executar os testes. Seu objetivo é escrever tes-
tes que lhe permitam dizer: “Bem, se estes executarem, então eu tenho certeza de que
o sistema vai funcionar”.
Por fim, você deve demonstrar coragem. Existe um caminho que une o lugar em
que você está hoje e onde você quer chegar. Esse time pode ajudar você a encontrá-
lo, se você também ajudá-los nisso.
Testador
Já que grande parte da responsabilidade pelos testes pertence aos programadores, o
papel do testador em um time XP é, na verdade, focado no cliente. Você é responsá-
vel por ajudar o cliente a escolher e escrever testes funcionais. Se os testes funcionais
não fazem parte do conjunto de integração, você é responsável por executar os testes
funcionais regularmente e apresentar os resultados em um lugar bem visível.
Um testador XP não é uma pessoa separada, que se dedica a fazer o sistema fa-
lhar e a humilhar os programadores. Porém, alguém tem de executar todos os tes-
tes regularmente (se você não puder executar seus testes de unidade e funcionais
juntos), divulgar os resultados dos testes e garantir que as ferramentas para testes
executem bem.
Rastreador
Como um rastreador, você é a consciência do time (pense no Grilo Falante, mas com
roupas melhores).
Fazer boas estimativas é uma questão de prática e feedback.Você precisa fazer mui-
tas estimativas e então verificar se a realidade ajustou-se aos seus palpites. Seu traba-
lho é fechar o ciclo baseado no feedback. A próxima vez que o time estiver fazendo
estimativas, você precisa poder dizer: “Dois terços das nossas estimativas na última
vez estavam pelo menos 50% mais altas do que a realidade”. Em termos individuais,
você precisa poder dizer: “Suas estimativas de tarefas estão ou muito baixas, ou mui-
to altas”. As próximas estimativas a serem dadas ainda são responsabilidade das
pessoas que precisam implementar, seja lá o que está sendo estimado, mas você deu
a elas o feedback para que, quando as estimativas forem divulgadas, elas possam ser
melhores do que as últimas.
Você também é responsável pela visão global do andamento. Na metade de uma
iteração, você deve ser capaz de dizer ao time se eles vão conseguir terminar seguin-
do o curso atual, ou se eles precisam mudar alguma coisa. Algumas poucas iterações
com um cronograma de compromisso e você será capaz de informar ao time se ele
poderá fazer a próxima versão sem grandes mudanças.
Você é o historiador do time. Você mantém um registro dos escores dos testes fun-
cionais. Você mantém um registro dos defeitos que foram reportados, quem assumiu
a responsabilidade por cada um deles e quais casos de testes foram adicionados pa-
ra verificar cada defeito.
A habilidade que você mais precisa cultivar é a capacidade de coletar a informa-
ção de que precisa sem perturbar o processo mais do que o necessário. Você precisa
perturbar o processo pelo menos um pouco, para manter o pessoal ciente de quanto
tempo eles realmente gastam em uma tarefa, de uma forma que não seria possível ca-
so você não perguntasse. Mas você não pode ser tão chato a ponto de fazer as pessoas
evitarem lhe responder.
Treinador
Como treinador, você é responsável pelo processo como um todo. Você nota quando
as pessoas estão se desviando do processo do time e chama a atenção deste para is-
so. Você permanece calmo quando todos os outros estão entrando em pânico, lem-
brando-se de que, nas próximas duas semanas, você conseguirá o equivalente a duas
semanas de trabalho ou menos, e essas duas semanas serão suficientes, ou não.
Todo participante de um time XP é responsável por compreender sua aplicação
de XP até certo ponto. Você é responsável por entendê-la muito mais profundamen-
te – que práticas alternativas podem ajudar no conjunto de problemas atuais, como
outros times estão usando XP, que idéias estão por trás da XP e como elas se relacio-
nam com a situação atual.
Eu descobri que a coisa mais difícil em ser um treinador é que você trabalha me-
lhor quando trabalha indiretamente. Se você percebe um erro no projeto, primeira-
mente você precisa decidir se ele é importante o bastante para que você tenha de in-
terferir. Toda vez que você guia o time, você os torna um pouco menos autoconfian-
tes. Muito direcionamento e eles perdem a habilidade de trabalhar sem você, resul-
tando na diminuição da produtividade, da qualidade e do moral. Então, primeira-
mente você tem de decidir se o problema que você percebe é grande o suficiente pa-
ra que aceite o risco de interferir.
Se afinal decidir que o melhor é interferir, é preciso que você o faça com a menor
impertinência possível. Por exemplo, é preferível sugerir um caso de teste que para
ser implementado corretamente exija a correção do projeto a simplesmente corrigir o
projeto você mesmo. Não dizer diretamente o que você percebe, mas dizê-lo de for-
ma que o time também perceba, é uma habilidade.
Algumas vezes, no entanto, você precisa ser direto, direto a ponto de ser rude.
Programadores confiantes e ofensivos são valiosos justamente porque são confiantes
e ofensivos. Entretanto, isso os deixa vulneráveis a um certo tipo de cegueira, cuja
única cura é ser curto e grosso. Quando você deixar uma situação se deteriorar a pon-
to de uma mão gentil nas rédeas não funcionar mais, você precisa estar preparado
para agarrá-las com as duas mãos e direcioná-las. Mas apenas o suficiente para que
o time reencontre o caminho. Então você precisa soltar novamente uma das mãos.
Mais uma observação quanto às habilidades do treinador. Eu estou sempre ensi-
nando as habilidades para XP – projeto simples, refatoração, testes. Mas não acredi-
to que elas façam necessariamente parte do trabalho do treinador. Se você tivesse um
time tecnicamente auto-suficiente, mas que precisasse de ajuda com o processo, vo-
cê poderia ser o treinador sem precisar dominar os aspectos técnicos. Você ainda pre-
cisaria convencer os propeller-heads* que eles deveriam escutá-lo. Mas uma vez que
exista a habilidade, meu trabalho é basicamente lembrar o time do que eles haviam
se proposto a fazer em varias situações.
O papel do treinador diminui com o amadurecimento do time. Se aderirmos ao
princípio do controle distribuído e da aceitação de responsabilidades, “o processo” de-
ve ser responsabilidade de todos. No início da transição para XP, isso é pedir demais.
*N. de T.Técnicos que resolvem qualquer problema computacional como se fosse mágica. O nome propeller-head vem
do chapéu colorido com uma hélice que representa este tipo de pessoa nos EUA.
Consultor
Projetos XP não geram muitos especialistas. Como todos eles formam pares com to-
dos os outros, e os pares mudam tanto, e qualquer um pode assumir a responsabili-
dade por uma tarefa se assim quiser, existem poucas chances de que surjam buracos
negros em que apenas uma ou duas pessoas compreendam o sistema.
Isso é um ponto forte, porque o time é extremamente flexível, mas é também uma
desvantagem, porque às vezes o time precisa de conhecimento técnico aprofundado.
A ênfase na simplicidade do projeto reduz a ocorrência da necessidade de um espe-
cialista, mas isso acontecerá de tempos em tempos.
Quando acontece, o time precisa de um consultor. É provável que, sendo você um
consultor, não esteja acostumado ao trabalho eXtremo. É possível que você encare a
maneira de trabalhar do time com um certo ceticismo. Mas o time precisa ser extre-
mamente claro quanto ao problema que precisam resolver. Serão capazes de lhe for-
necer testes para mostrar exatamente quando ele foi resolvido (na verdade, eles farão
questão dos testes).
O que eles não permitirão é que você resolva o problema sozinho. Se um time pre-
cisa de conhecimento técnico aprofundado em uma área alguma vez, é provável que
eles precisem de novo. O objetivo deles é que você os ensine a resolverem seus pró-
prios problemas. Eles possivelmente lhe farão inúmeras perguntas. Desafiarão seu
projeto e seus pressupostos, para ver se conseguem encontrar algo mais simples e
que ainda funcione.
E quando você terminar, é bem provável que eles joguem fora tudo o que você fez
e refaçam por si mesmos. Não se sinta insultado. Todos os dias eles fazem um pouco
disso consigo mesmos e provavelmente uma vez por mês eles joguem fora um dia in-
teiro de trabalho.
O Chefão
Se você é o chefão, o que o time mais precisa de você é coragem, confiança e insistên-
cia ocasional para que eles façam o que dizem fazer. É possível que, no princípio, se-
ja difícil para você trabalhar com o time. Eles pedirão que você preste atenção neles
freqüentemente. Eles explicarão as conseqüências das modificações na situação. Por
exemplo, se você não fornecer a eles o novo testador que eles solicitaram, eles vão ex-
plicar exatamente como eles pensam que isso influenciará o cronograma. Se você não
gostar da resposta deles, eles vão sugerir que você reduza o escopo do projeto.
Vindo de um time XP, isso constitui comunicação franca. Eles realmente não estão
choramingando. Querem que você saiba o mais cedo possível quando as coisas estão
diferindo do plano, para que você tenha o maior tempo possível para reagir.
O time precisa que você tenha coragem, porque o que eles fazem às vezes parece-
rá loucura, especialmente se você já tem experiência em desenvolvimento de soft-
ware. Algumas idéias você irá aceitar e aprovar, como a forte ênfase nos testes. Algu-
mas não parecem fazer sentido à primeira vista, como o fato de a programação em
pares ser um modo mais efetivo de programar, e refinar constantemente o projeto ser
uma forma de baixo risco de projetar. Mas observe e veja como eles produzem. Se
não funcionar, você pode intervir. Se funcionar, você está com tudo, porque terá um
time que está trabalhando de forma produtiva, que mantém os clientes satisfeitos e
que faz o possível para não surpreendê-lo.
Isso não quer dizer que o time não vá se atrapalhar de vez em quando. Eles vão.
Você observará o que eles estão fazendo e isso não fará o menor sentido para você, e
você pedirá que eles expliquem, e a explicação não fará sentido. Nesse momento, o
time está contando com você para fazê-los parar e analisar o que estão fazendo. Vo-
cê chegou na posição em que está hoje por alguma razão. O time quer colocar essa
habilidade funcionando para eles quando precisarem. E, francamente, querem man-
tê-la distante quando não precisarem dela.
CAPÍTULO 23
A Regra 20-80
O valor total da XP não virá até que todas as práticas estejam sendo efe-
tuadas. Muitas das práticas podem ser adotadas em pequenas porções,
mas seus efeitos serão multiplicados quando elas estiverem ocorrendo
juntas.
O
s programadores de software estão acostumados a lidar com a regra 20-80 –
80% dos benefícios vêm de 20% do trabalho. A XP também faz uso desta re-
gra – coloque os 20% de funcionalidades mais valiosos em produção, faça os
20% de projeto mais valiosos, conte com a regra 20-80 para adiar otimizações.
Para que a regra 20-80 se aplique, o sistema em questão precisa ter controles que
sejam relativamente independentes uns dos outros. Por exemplo, quando eu ajusto a
performance de um programa, cada lugar que eu poderia ajustar geralmente tem pou-
co efeito sobre os outros lugares que eu poderia ajustar. Eu nunca me encontro na si-
tuação de gastar muito tempo ajustando um local somente para descobrir que, por
causa desse ajuste, não é possível ajustar o próximo local. Em um sistema com con-
troles independentes, alguns deles estão destinados a ser mais importantes do que
outros.
Ward Cunningham fala de um livro que o elucidou sobre esqui avançado chama-
do The Athletic Skier1. Metade do livro trata sobre como ajustar suas botas, colocando-
as da maneira certa para que você possa sentir a montanha e manter o equilíbrio. E
então é dito no livro: “mas você só verá 20% de melhoramento quando você fizer
80% desses exercícios”. O livro segue explicando que há uma diferença enorme entre
manter o equilíbrio e perdê-lo. Se você está um pouco desequilibrado, é quase o mes-
mo que estar muito desequilibrado. E é uma série de pequenos fatores, como colocar
suas botas da maneira certa, que lhe permite estar equilibrado. Se qualquer um des-
ses fatores falhar, você cairá. Você verá pequenas melhorias ao longo do tempo, mas
1
Warren Witherell e Doug Evrad, The Athletic Skier, Johnson Books, 1993.
as últimas poucas modificações que você fizer melhorarão drasticamente o seu de-
sempenho no esqui.
Eu acho (e isso é apenas uma hipótese) que a XP funciona da mesma forma. As
práticas e os princípios trabalham em conjunto para criar uma sinergia maior do que
a soma das partes. Não é apenas o fato de você testar, mas sim o fato de você estar
testando um sistema simples, que ficou simples porque você teve um parceiro de
programação que o desafiou a refatorar e lembrou-lhe de escrever mais testes e elo-
giou-o quando você eliminou a complexidade e...
Isto cria um dilema. A XP é “tudo ou nada”? Precisamos seguir essas práticas ao
pé da letra ou então correremos o risco de não ver nenhuma melhoria? Nada disso.
Você pode obter ganhos significativos de partes da XP. Porém, acredito que há mui-
to mais a ser ganho quando você une todas as peças.
CAPÍTULO 24
O que Torna a XP Difícil
Mesmo que as práticas individuais possam ser executadas pelos progra-

madores, reunir todas as peças e mantê-las unidas é difícil. São primei-
ramente as emoções – principalmente o medo – que tornam a XP difícil.
Q uando as pessoas me ouvem falar sobre XP, elas dizem: “Mas você faz pare-
cer tão simples”. Bem, é porque ela é simples. Não é necessário um doutora-
do em Ciência da Computação para contribuir para um projeto XP (de fato,
às vezes quem tem mais problemas são os doutores).
A XP é simples em seus detalhes, mas é difícil de executar.
Recapitulando. Quer dizer que a XP é simples, mas não é fácil? Exatamente. As
práticas que compõem a XP podem ser aprendidas por qualquer um que tenha con-
vencido alguém a pagá-lo para programar. Essa não é a parte difícil. A parte difícil é
reunir todas as peças e então mantê-las equilibradas. As peças tendem a apoiar umas
às outras, mas existem muitos problemas, preocupações, medos, eventos e erros que
podem levar ao desequilíbrio. A única razão pela qual você “sacrificaria” um técnico
experiente para torná-lo treinador é que o problema de manter o processo equilibra-
do é muito difícil.
Não quero assustá-lo. Não mais do que o necessário. A maior parte dos grupos de
desenvolvimento seria capaz de executar a XP (veja as exceções no próximo capítulo).
Aqui estão algumas das coisas que eu considero difíceis na XP, tanto quando eu a
estou aplicando em meu próprio código, como quando estou treinando times que a
estão adotando.
Não quero que você fique se preocupando desnecessariamente, mas quando a
transição para XP estiver difícil (e às vezes ela será, eu garanto), você precisa saber
que não está sozinho. Você está tendo dificuldades porque o que você está fazendo é
difícil.
É difícil fazer coisas simples. Parece loucura, mas às vezes é mais fácil fazer algo
mais complicado do que algo simples. Isso é verdade especialmente quando você ob-
teve sucesso fazendo a coisa complicada no passado. Aprender a ver o mundo da

forma mais simples possível é uma habilidade e um desafio. O desafio é que talvez
você tenha de mudar seu sistema de valores. Em vez de ficar impressionado quando
alguém (por exemplo, você) consegue fazer algo complicado funcionar, você tem que
aprender a ficar insatisfeito com a complexidade, e a não descansar enquanto você
não conseguir imaginar nada mais simples que funcione.
É difícil admitir que estamos errados. Isso torna a adoção da XP um desafio pes-
soal, uma disciplina baseada na premissa de que você só pode desenvolver na mes-
ma velocidade em que aprende. E se você está aprendendo, quer dizer que não sabia
antes. Será assustador pedir ao cliente que ele explique quais são os conceitos mais
elementares para ele. Será assustador admitir ao seu parceiro de programação que
existem coisas básicas da ciência da computação que, francamente, você nunca en-
tendeu direto quando estava na escola. Ou que você esqueceu.
É difícil colaborar. Todo nosso sistema educacional é voltado para a conquista in-
dividual. Se você trabalha com alguém em um projeto, o professor chama de “cola”
e pune você. O sistema de premiação na maioria das companhias, com avaliações e
aumentos individuais (geralmente um esquema em que ficam “elas por elas”), tam-
bém encoraja o pensamento individual. É provável que você precise aprender novas
habilidades de relacionamento pessoal, interagindo tão proximamente com seu time
quanto faz na XP.
É difícil destruir barreiras emocionais. A facilidade no andamento de um projeto
XP depende da facilidade de expressar emoções. Se alguém está ficando frustrado ou
irritado e não está falando sobre isso, não demorará muito para a performance do time
começar a decair. Nós aprendemos a separar nossas vidas emocionais e nossos negó-
cios, mas o time não pode funcionar de forma efetiva se a comunicação não for man-
tida, os medos reconhecidos, a raiva descarregada e a alegria compartilhada.
Se isso faz com que a XP pareça uma experiência piegas e sentimental, bem, eu
não vejo as coisas dessa forma. Eu tentei desenvolver software fingindo que não tinha
nenhuma emoção e mantendo distanciamento dos meus colegas de trabalho. Não
funcionou. Eu falo sobre como me sinto e escuto quando outros falam sobre como se
sentem, e o processo corre bem mais tranqüilo.
As práticas da XP são completamente opostas àquilo que, no passado, ouvimos,
dissemos e com que até mesmo obtivemos sucesso. Uma das maiores dificuldades é
justamente o quão contrária à regra a XP aparenta ser. Quando eu conheço um novo
gerente, eu geralmente receio parecer radical, louco ou não-prático. Entretanto, eu
não conheço uma forma melhor de desenvolver software, então eu acabo superando
isso. De qualquer forma, esteja preparado para encontrar pessoas que reajam vigoro-
samente quando você explicar a XP.
Pequenos problemas podem ter efeitos gigantescos. Eu considero os checks and ba-
lances* da XP bastante robustos, e o processo, capaz de tolerar muitas variações. No
entanto, pequenas coisas muitas vezes podem fazer uma enorme diferença. Certa
vez, no projeto de folha de pagamento Chrysler C3, o time estava tendo problemas
para atingir suas estimativas. Iteração após iteração, uma ou duas histórias acaba-
vam não sendo implementadas. Eu levei três ou quatro meses para diagnosticar o
problema. Eu escutei alguém comentado sobre a “Síndrome da Primeira Terça”. Eu
*N. de T. A expressão checks and balances denota um sistema de limites imposto pela Constituição americana a todos
os poderes – Judiciário, Executivo e Legislativo. Esse sistema concede a cada poder o direito de modificar ou cancelar
os atos que se referem a sua jurisdição mas que foram estipulados por um outro poder.
O QUE TORNA A XP DIFÍCIL 149
perguntei o que era e um membro do time respondeu: “A sensação que dá no dia

após a reunião de planejamento de iteração, quando você volta, olha suas histórias e
percebe que não faz a menor idéia de como implementá-las no tempo estimado”.
Eu tinha originalmente especificado o processo como:
1. candidatar-se para as tarefas;

2. estimar as tarefas;
3. reequilibrar se alguém estiver sobrecarregado.
O time tinha tentado evitar o último passo, então eles alteraram o processo para:
1. estimar as tarefas coletivamente;

2. candidatar-se para as tarefas.
O problema era que a pessoa que aceitara a responsabilidade por uma tarefa não
era dono da estimativa. Eles voltavam no dia seguinte e diziam: “Por que isso vai de-
morar três dias? Eu nem sei o que está envolvido”. Você pode imaginar que essa não
é a condição mais produtiva para um programador. As pessoas estavam perdendo
um ou dois dias para a Síndrome da Primeira Terça em todas as iterações. Não é de
se admirar que eles não estivessem conseguindo atingir suas metas.
Eu conto essa história para ilustrar como pequenos problemas com o processo po-
dem ter grandes efeitos. Isso não quer dizer que você precise fazer tudo exatamente
como eu digo, do contrário você se arrependerá amargamente. Você ainda precisa
aceitar a responsabilidade pelo seu próprio processo. Mas o que torna a XP difícil é
exatamente isso – ao aceitar a responsabilidade pelo seu próprio processo de desen-
volvimento, você está aceitando a responsabilidade de estar ciente e de consertá-lo
quando houver um problema.
Dirigir projetos ajustando a direção um pouco de cada vez vai de encontro à me-
táfora do carro plenamente alinhado, prevalente em muitas empresas. Uma dificul-
dade final, e uma que pode facilmente afundar um projeto XP, é que redirecionar é
simplesmente inaceitável em muitas culturas de empresas. O aviso antecipado de
problemas é visto como um sinal de fraqueza ou reclamação. Você precisará de cora-
gem quando a sua companhia exigir que você aja de forma contrária ao processo que
você tenha escolhido para si.
CAPÍTULO 25
Quando Você não Deveria usar a XP
Os limites exatos da XP ainda não estão claros. Porém, existem alguns

estraga-prazeres que fazem a XP não funcionar – grandes times, clien-
tes desconfiados, tecnologias que não suportam elegantemente as modi-
ficações.
H
á certas práticas na XP que são boas, independentemente da sua opinião so-
bre o todo. Você deveria praticá-las. Ponto final. Os testes são um bom exem-
plo. O Jogo do Planejamento provavelmente funcione, mesmo se você gastar
mais tempo em estimativas e projeto antecipado. No entanto, como a regra 20-80 pro-
põe, é provável que exista uma grande diferença entre toda a XP e quase toda.
E, francamente, toda a XP não é para todos, e nem deveria ser para todos. Há mo-
mentos, lugares, pessoas e clientes que explodiriam um projeto XP como se ele fosse
um balão barato. É importante não utilizar a XP nestes projetos. Tão importante
quanto não utilizar a XP onde ela está destinada a fracassar, é utilizá-la onde ela po-
de proporcionar vantagens reais. É sobre isso que este livro fala – decidir quando
usar a XP e quando não usá-la.
Dito isso, eu não diria a vocês “Não use XP para construir software para mísseis”.
Eu nunca construí software para mísseis, então não sei como é isso. Por isso, não pos-
so lhe dizer que a XP funcionará. Mas eu também não posso lhe dizer que não irá
funcionar. Se você escrever um software para mísseis, você pode decidir se a XP tal-
vez funcione ou não.
No entanto, eu fracassei utilizando a XP vezes suficientes para conhecer alguns
dos casos em que ela certamente não funciona. Considere isto como uma lista de am-
bientes em que eu sei que a XP não dá certo.
A maior barreira para o sucesso de um projeto XP é a cultura. Não a cultura nacio-
nal, embora esta tenha algum impacto, mas a cultura empresarial. Qualquer negócio
que gerencie projetos tentando apontar o carro para a direção certa logo de cara terá
conflitos com um time que insiste em ir acertando a direção continuamente.
Uma variação de “apontar o carro” é a especificação gigante. Se um cliente ou um
gerente insiste em uma completa especificação, análise ou projeto antes de começar
o insignificante problema de programar, então haverá conflitos entre as culturas do

time e dos clientes ou gerentes. O projeto talvez ainda possa obter sucesso utilizando
a XP, mas não será fácil. Você estará pedindo ao cliente ou gerente que troque um do-
cumento que lhes dava sensação de controle por um diálogo (o Jogo do Planejamen-
to) que requer que eles estejam continuamente engajados. Isso pode ser assustador
para uma pessoa que já está sobrecarregada com compromissos.
Por outro lado, eu trabalhei com um cliente – um banco – que simplesmente ado-
rava enormes pilhas de papel. Eles insistiram durante todo o projeto que deveríamos
“documentar” o sistema. Nós lhes dissemos que, obviamente, se o cliente quisesse
fazer uma troca, obtendo menos funcionalidade e mais papel, nós ficaríamos felizes
em obedecer. Fomos cobrados sobre essa “documentação” por meses. Com o avanço
do projeto, e com os testes mostrando seu evidente valor para manter o sistema está-
vel e para comunicar o uso proposto dos objetos, os pronunciamentos sobre docu-
mentação se tornaram cada vez menos freqüentes. Mas eles ainda existiam. No fim,
o que o gerente de desenvolvimento requisitou foi uma introdução de quatro pági-
nas aos principais objetos no sistema. Em sua opinião, qualquer um que não fosse ca-
paz de descobrir o resto de que precisava através dos códigos e testes não deveria
mexer no código.
Outra cultura que não contribui para a XP é aquela na qual você é requisitado a
trabalhar horas e mais horas para provar o seu “comprometimento com a empresa”.
Você não consegue executar a XP se estiver cansado. Se aquilo que o seu time produz
trabalhando em velocidade máxima não é suficiente para a sua empresa, então a XP
não é sua solução. A segunda semana consecutiva de trabalho com hora extra em um
projeto XP é certamente um sinal de que algo está errado com o processo, e é melhor
você consertar o que está errado.
Programadores realmente inteligentes às vezes sentem dificuldades com a XP. Al-
gumas vezes as pessoas mais espertas têm dificuldade em trocar o jogo da adivinha-
ção pela comunicação intensa e pela evolução contínua.
Tamanho obviamente é importante. Você provavelmente não conseguiria geren-
ciar um projeto XP com 100 programadores. Nem 50. Nem 20, provavelmente. Com
10 é definitivamente possível. Com três ou quatro programadores você pode segura-
mente excluir algumas das práticas que são focadas na coordenação de programado-
res, como o Jogo do Planejamento de Iterações. A quantidade de funcionalidade a ser
produzida e o número de pessoas produzindo-a não têm nenhum tipo de relação li-
near simples. Se você tem um projeto grande, você talvez queira experimentar a XP
– tente fazer isso por um mês com o time pequeno – para testar o quão rápido você é
capaz de desenvolver.
O maior gargalo na escala de um projeto é o processo de integração não paralelo.
Você precisaria expandir isto de maneira a lidar com mais fluxos de código do que os
que poderiam ser facilmente acomodados por uma única máquina de integração.
Você não deveria usar a XP se estiver usando uma tecnologia cuja curva de custo
seja inerentemente exponencial. Por exemplo, se você está desenvolvendo o enésimo
sistema mainframe para usar o mesmo banco de dados relacional e você não está tão
certo de que o esquema de banco de dados é exatamente aquele de que você precisa
agora e para todo o sempre, você não deveria usar a XP. A XP baseia-se em manter o
código limpo e simples. Se você fizer um código complicado para evitar modificar as
200 aplicações já existentes, em breve você perderá a flexibilidade que o atraiu para
a XP em um primeiro momento.
QUANDO VOCÊ NÃO DEVERIA USAR A XP 153
Uma outra barreira tecnológica para a XP é um ambiente no qual é necessário um

longo tempo para se obter feedback. Por exemplo, se o seu sistema leva 24 horas para
compilar e linkar, será difícil integrar, compilar e testar várias vezes ao dia. Se você
precisa passar por um ciclo de certificação de qualidade com duração de dois meses
antes de poder colocar o software em produção, você terá problemas em aprender o
necessário para obter sucesso.
Eu já vi ambientes nos quais era simplesmente impossível testar software de ma-
neira realista – você está em produção em uma máquina que custa um milhão de dó-
lares, operando em sua capacidade máxima e simplesmente não há outro milhão de
dólares disponível. Ou então há tantas combinações de problemas possíveis que vo-
cê não consegue executar nenhum conjunto de testes significativo em menos de um
dia. Nesse caso, você está absolutamente certo ao trocar testar por pensar. Mas a par-
tir deste ponto, você não está mais fazendo XP. Quando eu programei nesse tipo de
ambiente, nunca senti liberdade para evoluir o projeto do software; primeiramente eu
precisava incluir a flexibilidade. Você ainda pode construir um ótimo software dessa
maneira, mas não deveria usar XP para isso.
Lembra-se da história do pessoal sênior, com escritórios nos cantos? Se você tem
o ambiente físico errado, a XP não pode funcionar. Uma grande sala com pequenos
cubículos em volta e máquinas poderosas em mesas no centro da sala é o melhor am-
biente que eu conheço. Ward Cunningham conta a história do projeto WyCash, em
que eles tinham escritórios individuais. No entanto, os escritórios eram grandes o su-
ficiente para duas pessoas trabalharem com conforto. Assim, quando o pessoal que-
ria programar em pares, eles simplesmente iam a um ou outro escritório. Se você não
pode mover as mesas, ou o nível de barulho impede a conversação, ou ainda se você
não consegue se aproximar o suficiente para uma comunicação em voz baixa, você
não conseguirá realizar a XP em potência máxima.
O que com certeza não funciona? Se você tem programadores em dois andares
diferentes, esqueça. Se você tem programadores muito separados em só um andar,
esqueça. Separados geograficamente – você talvez pudesse fazer isso se tivesse
dois times trabalhando em projetos relacionados e com interação limitada. Eu ini-
ciaria trabalhando com eles com um time único, faria a primeira entrega e então di-
vidiria o time conforme as divisões naturais da aplicação, trabalhando as duas par-
tes separadamente.
Finalmente, não há como executar a XP com um bebê aos berros na sala. Acredite
em mim quanto a isso.
CAPÍTULO 26
A XP em Ação
A XP pode ajustar-se às formas habituais de contrato, se bem que com

pequenas modificações. Em particular, os contratos de preço fixo/escopo
fixo se transformam em contratos de preço fixo/data fixa/escopo razoa-
velmente fixo quando desenvolvidos com o Jogo do Planejamento.
C
omo você pode encaixar a XP nas práticas habituais de negócios? Uma forma
de contrato equivocada pode facilmente destruir um projeto, não importando
as ferramentas, a tecnologia e o talento.
Este capítulo examina alguns arranjos comerciais para o desenvolvimento de
software e a forma como você pode utilizá-los com a XP.
Preço Fixo
O pessoal tende a enfrentar maiores problemas ao desenvolver um contrato de pre-
ço fixo extremo. Como você pode fazer um contrato de preço fixo/data fixa/escopo
fixo se você joga o Jogo do Planejamento? Você acabará com um contrato de preço fi-
xo/data fixa/escopo razoavelmente variável.
Todos os projetos em que trabalhei que tinham preço e escopo fixos, terminaram
com ambas as partes dizendo: “Os requerimentos não estavam claros”. E o típico
projeto de preço e escopo fixos puxa as duas partes em direções exatamente opostas.
O fornecedor quer fazer o mínimo possível, e o cliente quer exigir o máximo possí-
vel. Mesmo com essa tensão, ambas as partes querem que o projeto seja bem-sucedi-
do, então eles abrem mão de seus objetivos primários, mas a tensão continua lá.
Com a XP, a relação se altera de uma forma sutil, mas importante. O escopo inicial
é uma suposição. “Por exemplo, por 5 milhões de marcos alemães, nós acreditamos
que possamos produzir estas histórias em 12 meses”. O cliente precisa decidir se es-
sas histórias realmente valem 5 milhões de marcos alemães. Se essas histórias iniciais
são as que o time acaba produzindo, ótimo. É mais provável que o cliente troque al-
gumas histórias por outras de maior valor. Ninguém reclama se recebe algo de maior
valor do que esperava. Todos reclamam se recebem aquilo que pediram, mas o
“aquilo” não é o que eles agora sabem que querem.
Ao invés de preço/data/escopo fixos, o time XP oferece algo que mais se parece
com uma assinatura. O time trabalhará à velocidade máxima para o cliente por um
determinado período de tempo. Eles rastrearão o aprendizado do cliente. No come-
ço da cada iteração, o cliente tem uma oportunidade formal de mudar a direção, de
introduzir novas histórias.
Outra diferença que a XP introduz é causada pelos ciclos de entrega curtos. Você
nunca faria um projeto XP por 18 ou até mesmo 12 meses sem entrar em produção.
Uma vez que o time se propnha a fazer o equivalente a 12 meses de histórias, eles vão
jogar o Jogo do Planejamento com o cliente para determinar o escopo da primeira
versão. Então um contrato de 12 meses pode colocar o sistema em produção após três
ou quatro meses, com as versões seguintes saindo a cada mês ou bimestre. Entregas
incrementais apóiam-se na oportunidade que o cliente tem de terminar o contrato se
o progresso for mais lento do que o estimado inicialmente, ou se as condições comer-
ciais acabaram tornando o projeto inútil e ainda dá ao cliente pontos naturais para
mudar a direção do projeto.
Terceirização (Outsourcing)
No desenvolvimento terceirizado, o cliente acaba com uma pilha de códigos que não
sabe como manter. Ele tem três escolhas:
• pode fazer uma grande bagunça ao tentar fazer a evolução do sistema sozi-
nho;
• pode contratar o fornecedor original para continuar evoluindo o sistema (mas
o fornecedor original pode cobrar uma fortuna);
• pode contratar outro fornecedor que não conhece bem o código.
Você até poderia fazer isto com XP, se você fizesse questão. O time poderia mu-
dar-se para o ambiente do cliente ou o cliente poderia mudar-se para o ambiente do
time. Eles jogariam o Jogo do Planejamento para decidir o que fazer. Quando o con-
trato estivesse terminado, o time poderia ir embora e deixar o cliente com o código.
De certa forma, isso poderia ser melhor do que um acordo típico de terceirização.
O cliente teria os testes funcionais e de unidade para garantir que qualquer modifi-
cação que ele fizesse não destruiria as funcionalidades existentes. O cliente teria al-
guém para espiar por sobre os ombros dos programadores, para que ele pudesse ter
idéia de como é o sistema por dentro. E o cliente poderia ainda direcionar o desen-
volvimento com o decorrer do projeto.
Utilização de Pessoal Interno (Insourcing)

Talvez você tenha percebido que eu não sou muito fã da terceirização. A entrega
brusca “em um lote” que envolve a terceirização viola o princípio da modificação in-
A XP EM AÇÃO 157
cremental. Mas há uma pequena alteração na terceirização que a XP pode fazer para
melhorar a situação. E se você substituísse gradualmente os membros do time por
pessoal técnico do cliente? Eu chamo isso de “utilização de pessoal da casa” ou “uti-
lização de pessoal interno” ou ainda “primeirização”*.
Ela tem muitas das vantagens da terceirização. Por exemplo, permite que o forne-
cedor dê ao cliente o benefício do conhecimento técnico detalhado. Ao gradualmen-
te repassar a responsabilidade pelo sistema, a primeirização não faz o cliente correr
o risco de herdar um programa que não é capaz de sustentar.
Vejamos um exemplo de um arranjo de primeirização provida por um fornecedor
de um time de 10 pessoas. O contrato é de 12 meses. O desenvolvimento inicial dura
três meses, seguido de uma entrega a cada mês durante nove meses. O cliente forne-
ce um técnico para o desenvolvimento inicial. Depois, a cada mês, o cliente traz uma
nova pessoa, e o fornecedor elimina uma também. Ao fim do contrato, metade do ti-
me é formada por empregados do cliente, aptos a dar suporte ao programa e conti-
nuar o desenvolvimento, mesmo que em um ritmo mais lento.
O desenvolvimento certamente não será tão rápido com todas essas trocas no ti-
me se comparado a um arranjo de terceirização em que o time do fornecedor perma-
nece estável. Mas a redução no risco pode valer a pena.
A XP dá suporte à primeirização por ter o time medindo constantemente sua ve-
locidade. Com a troca dos membros, o time como um todo está fadado a ir mais rá-
pido e mais devagar. Ao medir constantemente a produtividade alcançada, o time
pode ajustar quanto eles se comprometem a fazer nas iterações do Jogo do Planeja-
mento. Com a saída dos experts e sua substituição por pessoal menos experiente, o ti-
me pode reestimar as histórias remanescentes.
Tempo e Recursos Materiais

Em um contrato de tempo e recursos materiais (abreviado T&RM), o time XP cobra
por hora ou dia. O resto do processo funciona como descrito anteriormente.
O problema com T&RM é que ele coloca os objetivos do fornecedor em conflito
com os objetivos do cliente. O fornecedor quer colocar o maior número de pessoas no
projeto durante o maior tempo possível para aumentar a receita. Está inclinado a dei-
xar o time trabalhar horas extras para aumentar a receita mensal. Já o cliente quer
pronto o maior número de funcionalidades possível no menor período possível com
o menor número de pessoas possível.
Uma boa relação entre fornecedor e cliente pode fazer o T&RM funcionar, mas a
tensão implícita vai sempre existir.
Bônus por Conclusão

Uma excelente maneira de unir os interesses do fornecedor e do cliente nas situações
de preço fixo ou T&RM é fornecer um bônus para a conclusão a tempo do projeto. De
uma certa forma, é uma aposta já ganha para o time XP. O nível de controle que o Jogo
do Planejamento fornece faz com que seja muito provável que eles recebam o bônus.
*N. de R. T. Optamos por traduzir insourcing por primeirização devido à clara intenção do autor de fazer oposição à
outsourcing (terceirização).
O contrário do bônus por conclusão é a penalidade por atraso. Novamente, o Jo-

go do Planejamento dá ao time XP uma vantagem ao aceitarem uma penalidade por
atraso. O time pode estar certo de que terminará o sistema a tempo, então é pouco
provável que eles precisem pagar.
Uma característica tanto da cláusula do bônus por conclusão quanto da cláusula
da penalidade por atraso a que se deve prestar atenção quando usadas na XP é que o
Jogo do Planejamento inevitavelmente resulta em mudanças no escopo do projeto.
Um cliente que estivesse muito disposto a atrapalhar a vida do fornecedor poderia
dizer: “É primeiro de abril e você não terminou todas as histórias do contrato origi-
nal. Nada de bônus pra você, e pode começar a pagar”. E eles poderiam afirmar isso
mesmo se o sistema estivesse em produção.
De maneira geral, isso não será um problema. Se for Natal e houver presentes sob
a árvore, o cliente provavelmente não irá conferir para ver se são exatamente os pre-
sentes que havia na carta original para o Papai Noel, especialmente se foram os pró-
prios clientes que fizeram a substituição.
Se você receia que um cliente vá prender-se à carta das histórias originais para li-
vrar-se de pagar o bônus, esqueça o bônus. Eu teria receio de assinar qualquer tipo
de contrato com esse tipo de cliente.
Término Antecipado
Uma das características da XP é que o cliente pode saber ao longo do projeto exata-
mente o que vai receber. E se eles descobrirem no meio do caminho que o projeto não
faz mais sentido? O cliente economizará dinheiro se puder terminá-lo mais cedo.
Considere acrescentar uma cláusula que permita ao cliente parar o projeto e pagar
apenas o valor proporcional ao período trabalhado, talvez com um pagamento adi-
cional para compensar o fornecedor por este ter de procurar um novo contrato sem
aviso prévio.
Frameworks
Como você poderia utilizar a XP para desenvolver um framework? Se uma das regras
é que você exclua qualquer funcionalidade que não esteja sendo usada atualmente,
você não acabaria excluindo todo o framework?
A XP não é muito boa em “reutilização adiantada”. Em um projeto XP, você nun-
ca passaria seis meses criando frameworks para então começar a usá-los. E também
não separaria o time do framework do time da aplicação. Com XP, fazemos aplicações.
Se, após alguns anos de refinamento constante, algumas das abstrações começam a
parecer úteis de uma forma geral, é tempo de pensar em como torná-las disponíveis
de maneira mais ampla.
Se o objetivo do projeto fosse desenvolver um framework para uso externo, você ain-
da poderia usar XP. No Jogo do Planejamento, os Negócios seriam jogados por um pro-
gramador que tivesse realmente construído o tipo de aplicação a que o framework pre-
tende dar suporte. As características do framework se transformariam em histórias.
A XP EM AÇÃO 159
Uma vez que o framework fosse implantado fora do time, você precisaria de uma
abordagem mais conservadora nas refatorações que alterassem interfaces visíveis.
Para amenizar a situação, você avisa ao cliente da iminente transformação de uma
característica, permitindo que você continue evoluindo a interface do framework ao
custo de manter duas interfaces vivas por algum tempo.
Software de Prateleira
Você também pode usar a XP para software de prateleira*. O papel dos Negócios no
Jogo do Planejamento é representado pelo departamento de marketing. São eles que
identificam que histórias o mercado deseja, o quanto de cada história é necessário e
em que ordem as histórias devem ser implementadas.
Contratar um usuário expert no software para ser parte dos Negócios também é
uma possibilidade. Por exemplo, companhias de jogos contratam jogadores experts
para testarem os seus softwares. Companhias que desenvolvem software para transa-
ções financeiras contratam corretores. Se você está desenvolvendo um programa pa-
ra composição tipográfica, seria loucura não ter um tipógrafo no time. E essa é exa-
tamente a pessoa que deve escolher se é a história A ou a história B que deve ser adia-
da para a próxima versão.
*N. de R. T. Também conhecido pelos termos software de pacote, solução pronta.

CAPÍTULO 27
Conclusão
T
odas as metodologias baseiam-se no medo. Você tenta criar hábitos que impe-
çam que seus medos tornem-se realidade. Neste aspecto, a XP não é diferente
de nenhuma outra metodologia. A diferença está nos medos que estão embuti-
dos na XP. Já que a XP é o meu bebê, ela reflete os meus medos. Eu tenho medo de:
• fazer trabalho desnecessário;

• ter projetos cancelados porque eu não tive progresso técnico suficiente;
• tomar as decisões de negócios erradas;
• ter pessoal de negócios tomando as decisões técnicas erradas no meu lugar;
• chegar ao fim de uma carreira dedicada à construção de sistemas e descobrir
que eu deveria ter passado mais tempo com meus filhos;
• fazer um trabalho do qual não tenho orgulho.
A XP também reflete as coisas de que não tenho medo:
• codificar;
• mudar de idéia;
• seguir em frente sem saber absolutamente tudo sobre o futuro;
• contar com as outras pessoas;
• mudar a análise e o projeto de um sistema em andamento;
• escrever testes.
Eu precisei aprender a não ter medo dessas coisas. Isso não vem naturalmente, es-
pecialmente quando todos lhe dizem que essas são exatamente as coisas de que eu
deveria ter medo, as coisas que eu deveria a todo custo evitar.
Expectativa
Um jovem rapaz foi até um mestre espadachim. Sentado sob o sol em frente à caba-
na do mestre, teve sua primeira lição: “Aqui está sua espada de madeira para prati-
car. Eu posso acertá-lo a qualquer momento com a minha espada de madeira e você
precisa me bloquear”. Zap!
– Ai!
– Eu disse a qualquer momento. Zap!
– Ai!
O aprendiz ergueu sua espada e encarou o mestre ferozmente.
Durante os dias que se seguiram, o aprendiz reuniu uma adorável coleção de ma-
chucados. Ele tentava prestar atenção em tudo à sua volta. Mas toda vez que desvia-
va sua atenção, zap!
O aprendiz não podia comer em paz. Não podia dormir. Ele tornou-se paranóico,
espiando cuidadosamente em cada canto e escutando atentamente a cada ruído. Mas
a cada vez que seus olhos pendiam ou esquecia de escutar, Zap!
Logo ele chorou de frustração: “Eu não posso agüentar. Eu não tenho capacidade
para ser um espadachim. Eu vou para casa”. Neste momento, sem saber exatamente
porque, ele puxou sua espada e girou-a, bloqueando o ataque do mestre. O mestre
disse: “Agora você está pronto para aprender”.
Nós podemos ficar malucos com a expectativa. Mas, ao nos prepararmos para ab-
solutamente tudo o que possamos imaginar, nós nos tornamos vulneráveis às even-
tualidades que não podemos imaginar.
Existe outra forma. O time pode estar perfeitamente preparado para, a qualquer
momento, seguir em qualquer direção que os negócios ou o sistema exijam. Ao expli-
citamente desistir de preparar-se para as mudanças, paradoxalmente ele prepara-se
inteiramente para qualquer mudança. Ele nada espera. Ele não pode mais ser sur-
preendido.
Bibliografia Comentada
O
propósito desta seção é dar-lhe a oportunidade de se aprofundar nos aspec-
tos da XP que mais lhe interessaram.
Filosofia
Sue Bender, Plain and Simple. A Woman’s Journey to the Amish, HarperCollins, 1989;
ISBN 0062501860.
Mais não é melhor. Menos talvez não seja melhor, também.
Leonard Coren, Wabi-Sabi: For Artists, Designers, Poets, and Philosophers, Stone Bridge
Press, 1994; ISBN 1880656124.
A XP não busca nenhum tipo de perfeição transcendental em seus programas.
Wabi-sabi é uma celebração estética do rústico e funcional.
Richard Coyne, Designing Information Technology in the Postmodern Age: From Method
to Metaphor, MIT Press, 1995; ISBN 0262032287.
Discute as diferenças entre os pensamentos modernista e pós-modernista, um
tema presente na XP. Há ainda uma excelente discussão sobre a importância das
metáforas.
164 BIBLIOGRAFIA COMENTADA
Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain, Mentor Books,
1992; ISBN 0451625854.
Desfaz o modelo compensatório das quatro variáveis – tempo, escopo, custo e
qualidade. Você não consegue terminar um software mais rápido se diminuir a
qualidade. Na verdade, você termina o software mais rápido se aumentar a qua-
lidade.
George Lakoff, Mark Johnson, Philosophy in the Flesh: The Embodied Mind and Its Chal-
lenge to Western Thought, Basic Books, 1998; ISBN 0465056733.
Mais uma boa discussão sobre metáforas e pensamento. Além disso, a descrição
de como as metáforas se misturam para formar novas metáforas é tal qual o que
está acontecendo com as idéias na engenharia de software. As metáforas antigas
emprestadas da engenharia civil, da matemática e de outras áreas estão lenta-
mente se tornando uma metáfora singular da engenharia de software.
Bill Mollison, Rena Mia Slay, Introduction to Permaculture, Ten Speed, 1997; ISBN
0908228082.
Alta intensidade, no mundo ocidental, geralmente está associada à exploração
e à exaustão. A permaculture é uma disciplina de cultivo que objetiva o uso sus-
tentável e de alta intensidade através dos efeitos sinérgicos de práticas simples.
A idéia mais interessante é a de que o maior crescimento se dá na interação en-
tre as áreas. A permaculture maximiza a interação com espirais de interplantação
e lagos com bordas bastante irregulares. A XP maximiza a interação através de
clientes presentes e programação em pares.
Atitude
Chistopher Alexander, Notes on the Synthesis of Form, Harvard University Press, 1970;
ISBN 0674627512.
Alexander começa encarando o projeto como decisões que resolvem restrições
conflitantes, levando a mais decisões para resolver as restrições remanescentes.
Chistopher Alexander, The Timeless Way of Building, Oxford University Press, 1979;
ISBN 0195024028.
A relação descrita entre projetistas/construtores e os usuários das construções
é muito parecida com a relação entre os programadores e o cliente.
Cynthia Heimel, Sex Tips for Girls, Simon & Schuster, 1983; ISBN 0671477250.
O entusiasmo genuíno é a melhor técnica. Com ele, todo o resto funciona. Sem
ele, esqueça.
A Princesa Prometida, Rob Reiner, diretor, MGM/UA Studios, 1987.

“Nós não vamos sobreviver a isto!”
“Bobagem. Você só diz isso porque ninguém nunca sobreviveu.”
Field Marshal Irwin Rommel, Attacks: Rommel, Athena, 1979; ISBN 0960273603.
Exemplos interessantes sobre como prosseguir sob circunstâncias aparentemen-
te sem saída.
BIBLIOGRAFIA COMENTADA 165
Frank Thomas, Ollie Johnston, Disney Animation: The Illusion of Life, Hyperion, 1995;
ISBN 0786860707.
Descreve como a estrutura dos times na Disney evoluiu com o passar dos anos
para lidar com negócios e tecnologia mutáveis. Há também várias boas dicas
para projetistas de interfaces e algumas imagens muito legais.
Processos Emergentes
Christopher Alexander, Sara Ishikawa, Murray Silverstein, A Pattern Language, Ox-
ford University Press, 1997; ISBN 0195019199.
Um exemplo de um sistema de regras que pretende produzir propriedades
emergentes. Podemos discutir se as regras obtêm sucesso ou não, mas as regras
em si são uma leitura interessante. Apresenta também uma discussão excelen-
te, se bem que um tanto curta, a respeito do projeto de ambientes de trabalho.
James Gleick, Chaos: Making a New Science, Penguin USA, 1988; ISBN 0140092501.
Uma introdução suave à teoria do caos.
Stuart Kauffman, At Home in the Universe: The Search for Laws of Self-Organization and
Complexity, Oxford University Press, 1996; ISBN 0195111303.
Uma introdução menos suave à teoria do caos.
Roger Lewin, Complexity: Life at the Edge of Chaos, Collier Books, 1994; ISBN
0020147953.
Ainda mais caos.
Margaret Wheatley, Leadership and the New Science, Beret-Koehler Pub, 1994; ISBN
1881052443.
Responde à questão: “E se nós utilizássemos a teoria dos sistemas auto-organi-
zados como uma metáfora para o gerenciamento?”.
Sistemas
Gerald Weinberg, Quality Software Management: Volume 1, Systems Thinking, Dorset
House, 1991; ISBN 0932633226.
Um sistema e uma notação para pensar sobre sistemas de ações interativas.
Norbert Weiner, Cybernetics, MIT Press, 1961; ISBN 1114239089.

Uma introdução muito mais aprofundada e difícil aos sistemas.
Warren Witherell, Doug Evrard, The Athletic Skier, Johnson Books, 1993; ISBN
1555661173.
Um sistema de regras inter-relacionadas para esquiar. A fonte da regra 20-80.
Pessoas
Tom DeMarco, Timothy Lister, Peopleware, Dorset House, 1999; ISBN 0932633439.
Seguindo The Psychology of Computer Programming, este livro expandiu o diálo-
go prático sobre como são os programas escritos por pessoas, e em particular,
por grupos de pessoas. Este livro foi a fonte do princípio da “aceitação de res-
ponsabilidades”.
Carlo d’Este, Fatal Decision: Anzio and the Battle for Rome, Harper-Collins, 1991; ISBN
006092148X.
O que acontece quando o ego impede o pensamento claro.
Robert Kanigel, The One Best Way: Frederick Winslow Taylor and the Enigma of Efficiency,
Penguin, 1999; ISBN 0140260803.
Uma biografia de Taylor que coloca seu trabalho em um contexto que ajuda a
mostrar os limites de seu pensamento.
Gary Klein, Sources of Power, MIT Press, 1999; ISBN 0262611465.

Um texto simples e de fácil leitura sobre como pessoas experientes tomam deci-
sões em situações difíceis.
Thomas Kuhn, The Structure of Scientific Revolutions, University of Chicago Press,

1996; ISBN 0226458083.
A XP surge como uma mudança de paradigma para algumas pessoas. Mudan-
ças de paradigma têm efeitos previsíveis. Veja aqui alguns deles.
Scott McCloud, Understanding Comics, Harper Perennial, 1994; ISBN 006097625X.

Os últimos capítulos falam sobre o porquê de as pessoas escreverem histórias
em quadrinhos. Isso me fez pensar sobre por que eu escrevo programas. Há
também um bom material sobre as conexões entre o ofício das histórias em qua-
drinhos e a arte das histórias em quadrinhos, com paralelos ao ofício de escre-
ver programar (testar, refatorar) e a arte de escrever programas. Há ainda um
bom material para projetistas de interface sobre como comunicar-se através dos
espaços entre coisas e como apresentar informações em pequenos espaços sem
amontoá-las.
Geoffrey A. Moore, Crossing the Chasm: Marketing and Selling High-Tech Products to
Mainstream Customers, HarperBusiness, 1999; ISBN 0066620023.
Mudanças de paradigma sob a perspectiva dos negócios. Pessoas diferentes es-
tarão preparadas para adotar a XP em diferentes estágios da sua evolução. Al-
gumas das barreiras são previsíveis e há estratégias simples para abordá-las.
Frederick Winslow Taylor, The Principles of Scientific Management, 2nd ed. Institute of
Industrial Engineers, 1988 (1st ed. 1911); ISBN 0898061822.
Este é o livro que gerou o “taylorismo”. Especialização e rígida divisão-e-con-
quista serviram para produzir mais carros, mais barato. Minha experiência diz
que estes princípios não fazem sentido como estratégias para o desenvolvimen-
to de software: nem sentido comercial, nem sentido humano.
Barbara Tuchman, Practicing History, Ballantine Books, 1991; ISBN 0345303635.

Uma historiadora que reflete sobre como ela faz história. Como Understanding
Comics, este livro é bom para refletir sobre por que você faz o que faz.
Colin M. Turnbull, The Forest People: A Study of the Pygmies of the Congo, Simon &
Schuster, 1961; ISBN 0671640992.
Uma sociedade com abundância de recursos. Meu sonho é que seja possível cri-
ar esse sentimento no time.
————, The Mountain People, Simon & Schuster, 1972; ISBN 0671640984.
Uma sociedade com recursos escassos. Descreve apropriadamente diversos
projetos de que participei. Nunca mais quero viver dessa forma.
Mary Walton, W. Edwards Deming, The Deming Management Method, Perigee, 1988;
ISBN 0399550011.
Deming explicitamente identifica o medo como uma barreira para a perform-
ance. Todos estão focados em métodos de controle de qualidade estatísticos,
mas há muito a ser considerado sobre emoções humanas e seus efeitos.
Gerald Weinberg, Quality Software Management: Volume 4, Congruent Action, Dorset

House, 1994; ISBN 0932633285.
Quando você diz uma coisa e faz outra, coisas ruins acontecem. Este livro fala
sobre como ser coerente consigo mesmo, como reconhecer incoerência nos ou-
tros e o que fazer sobre isso.
————, The Psychology of Computer Programming, Dorset House, 1998; ISBN

0932633420.
Programas são escritos por pessoas. Incrível, não? Incrível como muitas pessoas
ainda não entenderam isso...
————, The Secrets of Consulting, Dorset House, 1986; ISBN 0932633013.

Estratégias para introduzir mudanças. Útil para treinadores.
Gerência de Projeto
Fred Brooks, The Mythical Man-Month, Addison-Wesley, 1995; ISBN 0201835959.
Histórias para fazê-lo pensar sobre as quatro variáveis. A edição comemorativa
tem também um diálogo interessante sobre o famoso artigo No Silver Bullet.
Brad Cox, Andy Novobilski, Object-Oriented Programming – An Evolutionary Approach,

Addison-Wesley, 1991; ISBN 0201548348.
As origens do paradigma da engenharia elétrica para o desenvolvimento de
software.
Ward Cunningham, “Episodes: A Pattern Language of Competitive Development,”

in Pattern Languages of Program Design 2, John Vlissides, ed., Addison-Wesley, 1996;
ISBN 0201895277 (também diponível em http://c2.com/ppr/episodes.html).
Muitas das idéias da XP foram primeiramente expressas neste texto.
Tom DeMarco, Controlling Software Projects, Yourdon Press, 1982; ISBN 0131717111.
Exemplos excelentes de criação e uso de feedback para mensurar projetos de soft-
ware.
Tom Gilb, Principles of Software Engineering Management, Addison-Wesley, 1988; ISBN

0201192462.
Uma forte defesa da entrega evolutiva – pequenas versões, refatoração constan-
te, diálogo intenso com o cliente.
Ivar Jacobson, Object-Oriented Software Engineering: A Case Driven Approach, Addison-

Wesley, 1992; ISBN 0201544350.
Minha fonte para guiar o desenvolvimento por histórias (casos de uso).
Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified Software Development Pro-
cess, Addison Wesley Longman, 1999; ISBN 0201571692.
Filosoficamente, há muito com que eu concordo neste livro – iterações curtas,
ênfase na metáfora e uso de histórias para guiar o desenvolvimento.
Philip Metzger, Managing a Programming Project, Prentice-Hall, 1973; ISBN

0135507561.
O mais antigo texto sobre gerenciamento de projetos de programação que eu
pude encontrar. Há coisas válidas nele, mas a perspectiva é taylorismo puro.
Das 200 páginas, ele gasta exatamente dois parágrafos com manutenção – o
oposto da XP.
Jennifer Stapleton, DSDM Dynamic Systems Development Method: The Method in Prac-
tice, Addison-Wesley, 1997; ISBN 0201178893.
DSDM é uma perspectiva na obtenção de controle sobre o desenvolvimento rá-
pido de aplicações sem abrir mão de seus benefícios.
Hirotaka Takeuchi, Ikujiro Nonaka, “The new product development game”, Harvard
Business Review [1986], 86116:137-146.
Uma abordagem orientada ao consenso para uma entrega evolutiva. Há idéias
interessantes aqui para dimensionar a XP para mais programadores.
Jane Wood, Denise Silver, Joint Application Development, 2nd ed, John Wiley and Sons,
1995; ISBN 0471042994.
Os facilitadores da JAD e os treinadores da XP compartilham um sistema de va-
lores comum – facilitar sem direcionar, dar poder àqueles que melhor sabem to-
mar a decisão e, por fim, sair de cena. A JAD é focada na criação de um docu-
mento de requisitos cujos desenvolvedores e clientes concordem que possa e
deva ser implementado.
Programação
Kent Beck, Smalltalk Best Practices Patterns, Prentice-Hall, 1996; ISBN 013476904X.
A modéstia me impede.
Kent Beck, Erich Gamma, “Test Infected: Programmers Love Writing Tests”, in Java
Report, July 1998, volume 3, number 7, pp. 36-50.
A escrita de testes automatizados com JUnit, a versão Java do framework de tes-
tes xUnit.
Jon Bentley, Writting Efficient Programs, Prentice –Hall, 1982; ISBN 013970251-2.
Uma cura para a síndrome do “não vai ser rápido o bastante”.
Edward Dijkstra, A Discipline of Programming, Prentice-Hall, 1976; ISBN 013215871X.

Programação como matemática. Fui particularmente inspirado pela ênfase na
busca pela beleza através da programação.
Martin Fowler, Analysis Patterns, Addison Wesley Longman, 1996; ISBN 0201895420.
Um vocabulário comum para tomar decisões de análise. Mais difícil de absor-
ver do que os padrões de projeto, mas de muitas formas mais profundo, já que
padrões de análise estão ligados ao contexto de negócios.
Erich Gamma, Richard Helms, Ralph Johnson, John Vlissides, Design Patterns: Ele-
ments of Reusable Object-Oriented Software, Addison-Wesley, 1995; ISBN 0201633612.
Um vocabulário comum para tomar decisões de projeto.
Donald E. Knuth, Literate Programming, Stanford University, 1992; ISBN 0937073814.

Um método de programação orientado à comunicação. Manter programas le-
trados (literate programs) é muito chato, violando o princípio de que devemos
viajar com pouca bagagem. Mesmo assim, todo programador deveria escrever
um programa letrado de vez em quando, apenas para lembrar-se de o quanto
há para comunicar.
Steve McConnell, Code Complete: A Practical Handbook of Software Construction, Micro-

soft Press, 1993; ISBN 1556154844.
Um estudo sobre quanto cuidado você lucrativamente pode ter com o código.
Bertrand Meyer, Object-Oriented Software Construction, Prentice-Hall, 1997; ISBN

0136291554.
Projeto por contrato é uma alternativa ou extensão aos testes de unidade.
Outros
Barry Boehm, Software Engineering Economics, Prentice-Hall, 1981; ISBN 0138221227.
A referência-padrão para idéias sobre quanto o software custa e por quê.
Larry Gonick, Mark Wheelis, The Cartoon Guide to Genetics, HarperPerennial Library,
1991; ISBN 0062730991.
Uma demonstração do poder dos desenhos como meio de comunicação.
John Hull, Options, Futures, and Other Derivatives, Prentice-Hall, 1997; ISBN
0132643677.
A referência-padrão para mercado de opções.
Edward Tufte, The Visual Display of Quantitative Information, Graphics Press, 1992;
ISBN 096139210X.
Mais técnicas para se comunicar informação numérica através de figuras. Útil
para entender qual a melhor forma de apresentar gráficos de métricas, por
exemplo. Além do mais, a edição é muito bonita.
Glossário
Quando possível, a XP usa um vocabulário amplamente aceito. Quan-

do existem conceitos na XP que são significativamente diferentes de ou-
tros conceitos, destacamos as diferenças utilizando novas palavras. Aqui
estão as expressões importantes no dicionário da XP.
Após alguns dos verbetes abaixo, foram inseridas explicações (entre parênteses e com destaque) pelo re-
visor técnico com a colaboração de Guilherme Lacerda, Diretor de Tecnologia da APOENA Software
Livre, Mestrando em Informática (UFRGS) e palestrante do eXtreme Programming Brasil 2002, um dos
pioneiros na prática da XP no Brasil e a quem agradecemos.
Carga de trabalho (load factor) A razão entre o tempo de programação ideal e o ca-
lendário. Tipicamente varia entre 2 e 4. (Na prática de XP, existe um ditado sobre a velo-
cidade: “Tão rápido quanto o mais lento”, ou seja, por mais rápido que um par trabalhe, ele
sempre terá que acompanhar o par mais lento. Por isso, são promovidos rodízios entre mem-
bros de cada par.)
Caso de teste (test case) Um conjunto automatizado de estímulos e respostas do sis-
tema. Cada caso de teste deve deixar o sistema no mesmo estado em que foi encon-
trado. Assim, cada teste pode executar independentemente dos outros.
Cliente Um papel no time para alguém que escolhe as histórias a que o sistema pre-
cisa satisfazer, quais histórias são necessárias primeiro e quais podem ser posterga-
das, e que define testes que verifiquem o funcionamento das histórias. (Em XP, exis-
te o conceito de time coeso. O cliente é o maior interessado no sucesso do projeto, pois está
investindo tempo e dinheiro.)
Cronograma de comprometimento (commitment schedule) Uma entrega e uma data.
O cronograma de comprometimento é refinado a uma iteração por vez e modifica-
do através da reestimativa e recuperação.
Entrega (release) Uma pilha de histórias que, juntas, tem relevância para o pessoal
dos Negócios. (Cada entrega – usa-se também o termo lançamento – disponibiliza 100%
do sistema funcional a cada iteração. Assim, o risco é reduzido pois, se o projeto terminar,
parte do sistema – a parte entregue – existe e funciona.)
172 GLOSSÁRIO
Entropia A tendência de o sistema apresentar mais erros com o passar do tempo e

de as modificações se tornarem muito mais caras.
Exploração A fase do desenvolvimento em que o cliente informa o que o sistema to-
do poderia fazer de forma geral.
Gerente (manager) Um papel no time para alguém que vai alocar os recursos. (É im-
portante ressaltar que os papéis em XP não significam hierarquia mas uma definição organi-
zada de responsabilidades e ações. O gerente é o “escudo” da equipe em relação aos proble-
mas de projeto. Mantém em alta o ânimo da equipe, além de buscar recursos necessários ao
desenvolvimento do projeto.)
História (story) Algo que o cliente quer que o sistema faça. A estimativa de tempo
das histórias deve estar entre uma e cinco semanas ideais de programação. Histó-
rias devem ser testáveis.
Iteração Um período com duração de uma a quatro semanas. No começo, o cliente
escolhe as histórias a serem implementadas na iteração. No fim, o cliente pode exe-
cutar seus testes funcionais para verificar se a iteração obteve sucesso.
Jogo do Planejamento (Planning Game) O processo de planejamento da XP. Os Ne-
gócios especificam o que o sistema precisa fazer. O Desenvolvimento especifica
quanto cada funcionalidade custa e que orçamento está disponível por dia/sema-
na/mês.
Metáfora do sistema (system metaphor) Uma história sobre como o sistema funciona
que todos – clientes, programadores e gerentes – podem contar.
Parceiro (partner) A outra pessoa que está programando com você. (Na prática de
XP, usa-se adicionalmente os termos piloto e co-piloto. É comum um parceiro se dirigir ao
outro e dizer: “Posso pilotar?”.)
Plano de iteração (iteration plan) Uma pilha de histórias e uma pilha de tarefas. Pro-
gramadores se candidatam a tarefas e as estimam.
Produção A fase do desenvolvimento em que o cliente está efetivamente ganhando
dinheiro com o sistema.
Programação em pares (pair programming) Uma técnica de programação em que
duas pessoas programam com apenas um teclado, um mouse e um monitor. Na XP,
geralmente os pares mudam duas vezes por dia. (O tempo de troca dos pares pode va-
riar bastante. O que realmente norteia este rodízio é a conclusão da tarefa que o par está rea-
lizando.)
Programador Um papel no time para alguém que analisa, projeta, testa, programa e
integra.
Rastreador (tracker) Um papel no time para alguém que irá medir o progresso atra-
vés de números. (Usa-se também o termo acompanhador, pois ele mantém o controle das es-
timativas do projeto e quanto tempo foi necessário para realizá-lo – relação cronograma previs-
to/cronograma realizado –, acompanhando a velocidade do projeto.)
Recuperação (recovery) Um movimento de planejamento em que o cliente preserva
a data do término de uma versão reduzindo o escopo da mesma, em resposta ao
aumento das estimativas ou à desaceleração do time.
GLOSSÁRIO 173
Reestimativa Um movimento de planejamento em que o time reestima todas as

histórias remanescentes na entrega.
Refatoração (refactoring) Uma modificação no sistema que mantém seu comporta-
mento inalterado, mas aprimora algumas qualidades não funcionais – simplicida-
de, flexibilidade, legibilidade, desempenho.
Tarefa de engenharia (engineering tasks) Algo que o programador sabe que o siste-
ma precisa fazer. A estimativa de tempo das tarefas deve estar entre um e três dias
ideais de programação. Muitas tarefas serão derivadas diretamente de histórias.
Tempo ideal de programação A medida de uma tática de estimativa em que você
pergunta a si mesmo: “Quanto tempo isto levaria se não ocorressem distrações ou
acidentes?”.
Teste de unidade (unit test) Um teste escrito sob a perspectiva do programador. (Po-
de-se afirmar que, em XP, o desenvolvimento é dirigido por testes – Test Driven Develop-
ment: primeiro desenvolve-se o código de teste e depois o código de produção.)
Teste funcional Um teste escrito sob a perspectiva do cliente.
Testes automatizados (automated test) Um caso de teste que executa sem nenhuma
intervenção humana. O teste verifica se o sistema calcula os valores esperados. (Tes-
tes automatizados certificam a execução correta dos métodos, não somente dos cálculos de
valores esperados. Um código só é válido se passar 100% nos testes.)
Treinador (coach) Um papel no time para alguém que observa o processo como um
todo e chama a atenção do time para os problemas iminentes ou as oportunidades
para melhoria. (Como em um time de futebol, o treinador não apenas observa mas controla
a aplicação da XP sem perda do foco.)
Velocidade do time (team speed) O número de semanas ideal de programação em
que o time pode produzir em um dado período de tempo. (Há aqui uma forte ligação
com a carga de trabalho.)
Índice
A B
Adaptação local, princípios de gerenciamento e, Bibliografia, 163-171
55, 79-80 seção sobre atitude, 164-165
Adotando XP, 125-127 seção sobre filosofia 163-164
Ajustando a XP, 127-130 seção sobre gerência de projeto, 167-169
desenvolvimento e, 129-130 seção sobre outros, 171
seção sobre pessoas, 166-168
gerenciamento e, 129-130
seção sobre processos emergentes, 164-166
planejamento e, 128-130
seção sobre programação, 169-170
projeto e, 128-129 seção sobre sistemas, 165-166
projetos problemáticos e, 130 Bônus por conclusão, 157-158
testes e, 127-129
Ajuste de desempenho, , 133-134
Ambiente de trabalho C
experimentando com, 87-88 Cartões de histórias, jogo do planejamento e , 95-
produtividade e, 85-86 96
quando usar a XP e, 153 Cartões de tarefa, 98-99
rearranjando, 86-87, 129-130 Chefe, 143-144
Classes, 114
Aprendendo
Classificar por risco, fase de comprometimento,
codificando e, 57-58
97
ensinando e, 52-53 Classificar por valor, fase de comprometimento,
Arquitetura 97
estratégia de projeto e, 117 Clientes, 139-141
fase de exploração e, 131-132 cliente presente e, 77-78
iterações e, 133-134 coragem e, 140-141
metáfora guia e, 67-69 definição, 172
176 ÍNDICE
escrevendo histórias e, 132-133, 140 corrigindo falhas e, 48

habilidades necessárias aos, 140 estratégia de projeto e, 109-110
jogo do planejamento e, 73-74 jogando código fora e, 48
metáforas e, 74-75 programadores e, 139-140
mudando para XP e, 128-130 suportando a, 48-49
processo de desenvolvimento de sistemas e, 70- Cronograma, elaboração do, 66-68
72 Cronograma, gerenciamento de software e atraso
processo de tomada de decisão e, 140 no, 21-22
testes e, 120-122, 140-141 Cronograma de comprometimento, 172
Codificação, 57-59 Custo das mudanças, 39-42
comunicação e, 57-58 aumentando exponencialmente com o tempo,
coragem e, 48 39-40, 110-112
eliminar duplicação, 114 mantendo-o baixo, 41-42
facilidade de modificação, 42 não aumentando drasticamente com o tempo,
integrando código antigo e novo, 127-128 40-41, 111-113
prevenindo complexidade na, 104-105 processo de tomada de decisão e, 42
processo de aprendizado e, 57-58 simplicidade e, 45-46
testes e, 58-59 Custos, 33
Codificação, padrões justificativas para, 77-78 efeitos das restrições nos, 34-35
práticas XP e, 66, 71-72 estratégia de projeto e, 114-116
Código-fonte. Veja Codificação gerenciamento de projeto e, 30-31
Coletiva, propriedade, 70, 76-77. Veja também Res- idéia geral sobre os, 33-34
ponsabilidade
Complexidade, projetos e, 60-61
Comprometimento, fase, 98-100 D
aceitar uma tarefa, 98-99 Desenvolvimento, ciclo
balanceamento, 99-100 importância de testar no, 25-26
definindo fatores de carga, 99-100 pares de programadores no, 25
estimando uma tarefa, 98-99 testes de integração no, 25-27
movimentos na, 97 Desenvolvimento, estratégia de, 103-107
Comunicação, 45-46 integração contínua, 103-105
codificação e, 57-58 programação em pares, 114-107
estratégia de projeto e, 109 propriedade coletiva, 104-106
falhas na, 45-46 realimentando a XP e, 129-130
princípio da franqueza e honestidade na, 53-54 Desenvolvimento, responsabilidades
programação em pares e, 106 estratégia de planejamento e, 93-95
técnicas que suportam a, 45-46 lista de, 90-91
Considerações técnicas relação com os negócios, 89-90
conseqüências das, 66-67 Direcionamento, fase de, 99-101
considerações de negócio e, 66-68, 89-90 Documentação, 151-152
decisões de desenvolvimento e, 90-91
difundindo conhecimento técnico, 105-106
lista de responsabilidades, 90-91 E
Consultor, 142-143 Economia, desenvolvimento de software, 29-31
Contratos, 155-162 estratégia para, 29-30
bônus por conclusão e, 157-158 estratégias de gerenciamento de projeto e, 29-
insourcing e, 156-157 31
outsourcing e, 155-157 exemplo de, 30-31
preço fixo e, 155-156 fatores na, 29
tempo e recursos materiais e, 157-158 opções da, 29-30
término antecipado e, 158-159 E-mail, 79-81
Coragem, 48-49 Entrega
clientes e, 140-141 composição das, 66-67
ÍNDICE 177
data das, 66-67 estratégia de projeto e, 109-110

definição, 175-176 produção precoce e, 47-48
manutenção e, 134-135 projetando com figuras e, 115-116
pequenas versões e, 67-68 quando usar a XP e, 152-153
planejamento das iterações e, 99-101 rápido e, 51-52
Entregas pequenas testes e, 46-47
justificando o uso de, 73-74
Férias, 70-71
práticas da XP e, 66-68
Figuras
Entropia, 172
benefícios das, 115-116
Escopo
decisões de negócios e, 66-67, 90-91 falta de feedback das, 115-116
funcionalidade do projeto e, 36-37 princípios para, 116
idéia geral sobre o, 33-34 Fluxo de caixa, 29-30
importância do, 35-37 Frameworks, 158-159
relação com outras variáveis, 36-37 Funcionalidades, priorizando, 90-91
variáveis do desenvolvimento de software e, 33
Escopo, fase de comprometimento e escolha de,
97 G
Escrever uma história, fase de exploração, 97 Gerenciamento, estratégia de, 79-83
Estimando centralização versus descentralização, 79
estratégia de planejamento e, 93-94 gerenciamento de projeto e, 29-31
fase de direcionamento reestimando, 97 intervenção e, 82-83
implementação de funcionalidades e, 66-67 métricas e, 79-81
propriedade do projeto e, 149 princípios para, 79-80
rastreamento e, 82 rastreamento e, 82
tarefas na fase de exploração, 131-133
realimentando a XP e, 129-130
Estimar uma história, fase de exploração, 97
treinador e, 80-82
Estratégias. Veja Projeto, estratégia de; Desenvol-
Gerenciamento de projetos
vimento, estratégia de; Gerenciamento, estraté-
gia de; Planejamento, estratégia de; Testes, estra- exemplo de, 30-31
tégia de “matando” o projeto e, 82-83
Experimentos, 53-54 maximizando o valor de, 30-31
Exploração, fase de, 97-99, 131-133 opções e, 29-31
definição, 172 recomeçando, 130
dividir uma tarefa/combinar tarefas e, 98-99 Gerente, 175
duração da, 132-133 Glossário, 172-176
escrever uma tarefa e, 97-98
estimando tarefas de programação em, 131-133
histórias dos clientes e, 132-133 H
movimentos na, 97 Histórias
praticando com tecnologia e, 131-132 clientes e, 140
testando a arquitetura e, 131-132 definição, 175-176
fase de exploração e, 132-133
F iterações e, 133-134
metáforas e, 117
Falhas, coragem para corrigir, 48
nova história e, 97
Falhas, desenvolvimentos de software, 21-22
Fator de carga, 171 separar em partes e, 97
Feedback, 46-48 verificando, 99-100
cronograma apertado de, 133-134 Hora extra
determinando a efetividade da metáfora com, como um sintoma de problemas no projeto, 70-
73-74 71
escalas de tempo de, 33-34, 46-48 quando usar a XP e, 151-152
178 ÍNDICE
I fase de comprometimento e, 97-100

fase de direcionamento e, 97-101
Idéia geral
fase de exploração e, 97-98
aceitando responsabilidade e, 148-149
fases do, 95-96
adotando XP para novos projetos, 125-126
objetivo do, 94-95
ajustando a XP para um projeto existente, 127-
participantes do, 95-96
130
práticas da XP e, 66-68
dificuldades na colaboração e, 147-149
rastreamento e, 82
dificuldades na simplicidade e, 147-148 relações entre Negócios e Desenvolvimento no,
execução, dificuldades na, 147 93-96
pequenos problemas com grandes efeitos e, Juros, taxas de, 29-30
148-149
quando usar, 30-31
Insourcing, 156-157 M
Instalações. Veja Ambiente de trabalho Manutenção
Integração contínua, 103-105 exemplo de projeto XP e, 134-135
benefícios humanos da, 103-105 novas versões e, 134
custos da, 103-105 Mensagens, 41-42
ferramentas que suportam velocidade e, 103- Mensuração, princípio da honestidade na, 55, 79-
104 80
justificativas para, 76-77 Metáforas
práticas XP e, 66, 70-71 definição, 67-68
reduzindo riscos com, 103-104 justificando o uso de, 73-75
referência de tempo para, 103-104 práticas XP e, 66-69
Integração não-paralela, 152-153 transformando histórias em objetos e, 117
Intervenção, 82-83 Métodos, simplicidade do projeto, 114
“matar” o projeto, 82-83 Métricas, 79-81
mudanças de pessoal, 82-83 ferramentas de gerenciamento XP e, 79-80
mudanças no processo, 82-83 mural grande e visível, 79-81
quando e como intervir, 82 uso efetivo de, 80-81
Investimento inicial pequeno Mobília, rearranjando, 87-88. Veja também Am-
estratégia de projeto e, 109-110 biente de trabalho
princípio do, 52-53 Mudanças
projetando com figuras e, 116 acolhendo as mudanças como princípio funda-
Investimentos, gerenciamento de projeto e, 30-31 mental, 51-52
Iteração, fase de, 100-101 custo das, 39-42
Iterações de iteração, 133-134
arquitetura e, 133-134 desenvolvimento de software e, 21-22
definição, 172 projetando com figuras e, 116
duração das, 132-133 Mudanças incrementais
exemplo de projeto XP e, 132-134 estratégia de projeto e, 109-110
fase de direcionamento, 97 outsourcing e, 156-157
histórias para, 133-134 princípios de gerenciamento e, 79-80
mudanças resultantes das, 133-134 princípios fundamentais e, 51-52
Mural grande e visível
atualizando freqüentemente, 80-81
J como ferramenta de gerenciamento, 79-81
Jogar para ganhar, 52-54, 116
Jogo do Planejamento, 93-96
adotando a XP e, 125 N
cartões de histórias e, 95-96 Negócios, arranjos. Veja Contratos
defendendo a simplicidade do, 73-74 Negócios, desenvolvimento de software e mudan-
definição, 175 ças nos, 21-22
estratégia para, 94-96 Negócios, responsabilidades dos
ÍNDICE 179
estratégia de planejamento e, 93-95 Práticas

integrando com considerações técnicas, 66-68 ciclos de entrega curtos, 67-68, 73-74
lista de, 90-91 cliente presente, 70-72, 77-78
relação com o processo de desenvolvimento, decisões de desenvolvimento e, 90-91
89-90 integração contínua, 70-71, 76-77
Novas histórias, fase de direcionamento, 97 jogo do planejamento, 66-68, 73-74
metáforas, 67-69, 73-75
padrões de codificação, 71-72, 77-78
O programação em pares, 69-70, 75-77
Objetivos, jogo do planejamento, 94-95 projeto simples, 68-69, 74-75
Objetos, programação baseada em, 41-42 propriedade coletiva, 70, 76-77
Objetos, transformando histórias em, 117 refatoração, 69, 75-76
Outsourcing, 155-157 semana de 40 horas e, 70-71, 77
Ouvir, 60-61 suporte mútuo entre, 77-78
testes, 68-69, 74-76
Preço. Veja Custos
P Preço fixo, contratos de, 155-156
Padrões, 66, 71-72, 77-78 Primeirização. Veja Insourcing
Papéis, 137-144 Princípios
chefe, 143-144 estratégia de planejamento e, 93-94
cliente, 139-141 estratégia de projeto e, 109-111
consultor, 142-143 projetando com figuras e, 115-117
idéia geral sobre os, 137-138 Princípios de apoio, 52-55
programador, 138-140 aceitação de responsabilidades, 54-55
testador, 140-142 adaptação local, 55
treinador, 141-143 comunicação honesta e franca, 53-54
Parceiros, 175 ensinar aprendendo, 52-53
Pares, programação em, 105-107 experimentação concreta, 53-54
base de diálogo da, 105-106 investimento inicial pequeno, 52-53
comunicação e, 45-46, 106 jogar para ganhar, 52-54
definição, 175 métricas genuínas, 55
exemplo de desenvolvimento e, 25 trabalhar a favor dos instintos das pessoas, 54-
justificando o uso da, 75-77 55
natureza do time da, 106 viajar com pouca bagagem, 55
práticas da XP e, 66, 69-70 Princípios fundamentais, 51-52
produtividade da, 106 aceitação das mudanças, 51-52
realimentando a XP e, 129-130 alta qualidade, 51-52
Pessoal, mudanças de, 82-83 feedback rápido, 51-52
Planejamento, estratégia de, 93-102 mudanças incrementais, 51-52
funções do planejamento e, 93 simplicidade presumida, 51-52
jogo do planejamento e, 93-96 Prioridades, decisões de negócios e
limite de uma semana para planejamento e, como considerações de negócios, 66-67
101-102 como decisões de negócios, 90-91
princípios que afetam a, 93 Produção, 133-134
realimentando a XP e, 128-130 Produção, fase de, 175
Planejamento, fase de duração da, 132-133 Produção precoce, 47-48
exemplo de projeto XP e, 132-133 Produtividade, 106-107
Planejamento das iterações Programador líder, 80-81
definição, 172 Programadores, 138-140
integração contínua e, 103 coragem e, 139-140
jogo do planejamento e, 97-98 definição, 175
limitações, estratégia e, 100-101 habilidades necessárias aos, 138-140
planejamento de entrega e, 99-101 programação XP e, 138-139
180 ÍNDICE
propriedade coletiva e, 139-140 Reestimativa

testes e, 120-122 definição, 175
Projeto, cancelamento, 21-22 fase de direcionamento e, 97
Projeto, estratégia de, 60-61, 109-117 Refactoring. Veja Refatoração
arquitetura do sistema e, 117 Refatoração
custo das modificações e, 110-113 definição, 175-176
custos e funcionalidades da, 114-116 estratégia de projeto e, 112-113
papel das figuras na, 115-117 integração contínua e, 103-104
princípios que suportam a, 109-111 justificando o uso de, 75-76
projeto ruim , 60-61 práticas XP e, 66, 69
realimentando a XP e, 128-129 Regra aplicada à XP, 145-146
refatoração e, 112-113 independência de controles e, 145
refinamento e, 42 Regras
simplicidade e, 42, 68-69, 74-75, 114-115 20-80, 145-146
valor da, 60-61 “uma e somente uma vez”, 113-114
valores que suportam a, 109 Release. Veja Entrega
Projeto, gerenciamento Responsabilidade. Veja também Propriedade cole-
exemplo de, 30-31 tiva
“matando” o projeto e, 82-83 aceitação da, 54-55, 79, 148-149
maximizando o valor do, 30-31 estratégia de planejamento e, 93-94
opções e, 29-31 Riscos, desenvolvimento de software
recomeçando, 130 atraso no cronograma, 21-22
Projetos
cancelamento do projeto, 21-22
mortalidade de projeto e, 29-30
estratégia de projeto e, 114-115
sintomas de problemas em, 130
falhas, 21-22
Propriedade coletiva, 104-106
mudanças nos negócios, 21-22
benefícios da, 104-106
reduzindo com integração contínua, 103-104
justificativas para, 76-77
troca de pessoal, 21
práticas XP e, 66, 70
programadores e, 139-140
simplificação como resultado da, 104-105 S
Semana de 40 horas
Q justificando o uso de, 77
práticas da XP e, 66, 70-71
Qualidade
efeito das restrições na, 34-36 Separar história em partes, fase de exploração, 97
efeito humano da, 35-36 Simplicidade
idéia geral sobre a, 33-34 curva de custos das mudanças e, 45-46
interna versus externa, 35-36 dificuldade da, 147-148
princípios de gerenciamento e, 51-52, 79-80 estratégia de projeto e, 109-110, 114-115
variáveis de desenvolvimento de software e, 33 práticas da XP e, 66, 68-69, 74-75
princípios fundamentais e, 51-52
valores da XP e, 45-47
R Sistema, arquiteto do, 80-81
Rastreadores Software, episódio de desenvolvimento, 25-27
medindo o progresso e, 175-176 Software, riscos do desenvolvimento de, 21-23
papéis do time e, 140-142 atrasos no cronograma, 21-22
Rastreamento, 82 cancelamentos de projeto, 21-22
Recovery. Veja Recuperação falhas, 21-22
Recuperação funcionalidade desnecessária, 21-23
definição, 175 mudanças nos negócios, 21-22
fase de direcionamento e, 97 troca de pessoal, 21-23
ÍNDICE 181
T macaco, 122
paralelo,122
Tamanho do projeto, quando usar a XP e , 152-153
unidade, 122
Tarefas
Times
aceitar uma tarefa, 98-99
considerações técnicas e, 66-67
definição, 173
processo de mudança de time, 82-83
dividir uma tarefa/combinar tarefas, 98-99
velocidade dos, 175-176
escrever, 97-98
Treinador, 80-82, 141-143
estimar, 45-46, 98-99
como papel no gerenciamento, 80-81
implementar, 99-100
Tecnologia definição, 171
decisões de negócios e, 90-92 fornecendo comida e brinquedos, 81-82
fase de exploração e, 131-132 funções do, 81-82
Tempo habilidades do, 142-143
custo das mudanças e, 39-41 responsabilidade do, 141-142
decisões de desenvolvimento e, 90-91 Troca de pessoal, 21-23
efeito das limitações de, 34-35
feedback e, 46-48 V
idéia geral sobre, 33-34
variáveis de desenvolvimento de software e, 33 Valores, 45-49
Tempo de entrega, 90-91 colocando em prática, 48-49
Tempo e recursos materiais, contratos de, 157-158 comunicação, 45-46
Tempo ideal de programação, 173 coragem, 48-49
Terceirização. Veja Outsourcing estratégia de projeto e, 109
Término antecipado, 158-159 feedback, 46-48
Testador, 140-141 simplicidade, 45-47
Teste, casos de, 175-176 Variáveis, desenvolvimento de software, 33-37
Testes, 58-60 idéia geral sobre, 33-34
adotando XP e, 125 importância do escopo, 35-37
ajustando a XP e, 127-129 interações entre, 33-36
aumentando a confiança através de, 59-60 variável custo, 33-34
automatizando, 42 variável escopo, 33-34
ciclo de desenvolvimento e, 25-26 variável qualidade, 33-34
cliente e, 140-141 variável tempo, 33-34
codificação e, 57-58 visibilidade das, 33-34
comunicação e, 45-46 Velocidade, fase de comprometimento e definição
de integração e, 25-27 da, 97
falhas nos, 60 Viaje com pouca bagagem
feedback e, 46-47 estratégia de projeto e, 109-110
fundamentação para, 58-59, 74-76 princípios de gerenciamento e, 55, 79-80
práticas da XP e, 66, 68-69 projetando com figuras e, 116
velocidade dos, 59-60
vida do programa e, 59-60
Testes, estratégia, 119-122 X
fontes de testes e, 120-122 XP, exemplo, 131-136
isolando e automatizando, 119-120 fase de exploração, 131-133
minimizando testes, 119-120 fase de planejamento, 132-133
tipos de testes e, 122 iterações para a primeira versão, 132-134
Testes, tipo de manutenção, 134-135
automatizados, 172 morte do projeto, 135-136
estresse, 122 produção e, 133-134
funcionais, 173 XP, quando usar, 151-153
182 ÍNDICE
adivinhações corretas versus comunicação e especificação prévia versus diálogo contínuo,

evolução, 152-153 151-152
ambiente de trabalho e, 153 feedback e, 151-152
cultura do negócio como uma obstrução ao uso hora extra e, 151-152
da, 151-152 integração não-paralela e, 152-153
documentação e, 151-152 tamanho e, 152-153

Programação Extrema (XP) Explicada - Acolha As Mudanças

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Programação Extrema (XP) Explicada - Acolha As Mudanças

Enviado por

Direitos autorais:

Formatos disponíveis

Kent Beck é dono e presidente da First Class Software, Inc.

, onde ele con-

B126p Beck, Kent.

Editado também como livro impresso em 2004.

1. Computação – Programação de software – XP. I. Título.

Catalogação na publicação: Mônica Ballejo Canto – CRB 10/1023

Consultoria, supervisão e revisão técnica desta edição:

Tradução autorizada a partir do original em idioma inglês, publicado por Pearson

Capa: Amarílis Barcelos

Leitura final: Carla Krohn

Supervisão editorial: Denise Weber Nowaczyk

Editoração eletrônica: Laser House

Reservados todos os direitos de publicação, em língua portuguesa, à

É proibida a duplicação ou reprodução deste volume, no todo ou em parte, sob quaisquer

SAC 0800 703-3444

Deixe-me refletir um pouco sobre meu próprio trabalho com desenvolvimento.

Kent estava entre os líderes da Tektronix que reconheceram a potencialidade da

• se revisar o código é bom, revisaremos código o tempo inteiro (programação

• Aos programadores, a XP promete que eles poderão trabalhar naquilo que

Resumindo, a XP promete reduzir o risco do projeto, melhorar a resposta às mu-

• seu feedback antecipado, concreto e contínuo derivado dos ciclos curtos;

A XP é uma disciplina de desenvolvimento de software. É uma disciplina porque

• colocar todas essas práticas juntas, sob um só teto;

SEÇÃO I O Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

CAPÍTULO 1 Risco: O Problema Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

CAPÍTULO 2 Um Episódio de Desenvolvimento . . . . . . . . . . . . . . . . . . . . .25

CAPÍTULO 3 A Economia no Desenvolvimento de Software . . . . . . . . . . . .29

CAPÍTULO 4 Quatro Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

CAPÍTULO 5 O Custo das Modificações . . . . . . . . . . . . . . . . . . . . . . . . . . .39

CAPÍTULO 6 Aprendendo a Dirigir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

CAPÍTULO 7 Quatro Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

CAPÍTULO 8 Princípios Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

CAPÍTULO 9 De Volta ao Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

SEÇÃO II A Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

CAPÍTULO 10 Uma Rápida Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

CAPÍTULO 11 Como Isso Poderia Dar Certo? . . . . . . . . . . . . . . . . . . . . . . . .73

CAPÍTULO 12 Estratégia de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . .79

CAPÍTULO 13 Estratégia de Ambiente de Trabalho . . . . . . . . . . . . . . . . . . . .85

CAPÍTULO 14 Dividindo as Responsabilidades Técnicas e de Negócios . . .89

CAPÍTULO 15 Estratégia de Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . .93

CAPÍTULO 16 Estratégia de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . .103

CAPÍTULO 17 Estratégia de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109

CAPÍTULO 18 Estratégia de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

SEÇÃO III Implementando a XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

CAPÍTULO 19 Adotando a XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125

CAPÍTULO 20 Ajustando a XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127

CAPÍTULO 21 Ciclo de Vida de um Projeto XP Ideal . . . . . . . . . . . . . . . . .131

CAPÍTULO 22 Papéis para Pessoas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137

CAPÍTULO 23 A Regra 20-80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145

CAPÍTULO 24 O que Torna a XP Difícil . . . . . . . . . . . . . . . . . . . . . . . . . . .147

CAPÍTULO 25 Quando Você não Deveria usar a XP . . . . . . . . . . . . . . . . .151

CAPÍTULO 26 A XP em Ação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

CAPÍTULO 27 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

Bibliografia Comentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163

O desenvolvimento de software tem falhas na entrega e falhas nos va-

• Deslizes no cronograma – o dia de entrega chega e você tem de dizer ao clien-

• Rotatividade da equipe – após dois anos, todos os bons programadores no

• Deslizes no cronograma – a XP exige ciclos curtos de entrega, de no máximo

menos chance de um programador ficar frustrado por ser solicitado a fazer o

A programação quotidiana inicia-se com uma tarefa conectada de forma

• Pares de programadores programam juntos.

Precisamos desenvolver nosso software economicamente mais valioso

• entrada e saída do fluxo de caixa