IV_Teorico (1)

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Projetos Ágeis com Extreme 
Programming (XP)
Padrões e Práticas em XP
Responsável pelo Conteúdo:
Prof. Me. Artur Ubaldo Marques júnior
Revisão Textual:
Prof.ª Me. Natalia Conti
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução;
• Semana de 40h;
• Cliente no Local;
• Padrões de Codificação;
• Práticas Gerais em XP;
• Gerenciamento de Projetos.
Fonte: iStock/Getty Im
ages
Objetivos
• Conhecer a parte de execução processual da XP.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Padrões e Práticas em XP
UNIDADE 
Padrões e Práticas em XP
Contextualização 
Programação extrema é iterativa e incremental e é impulsionada por ciclos numa 
“caixa de tempo”, onde as atividades dessa iteração se desenvolvem. Portanto, o ritmo 
do processo Extreme Programming é crucial.
O feedback em XP é uma atividade contínua em todo o projeto e em todos os níveis 
de atividade da metodologia.
De que forma XP lida com toda a articulação de tempo e pessoas necessárias para 
fazer todas essas atividades?
É relativamente simples essa resposta, mas envolve um pacto ajustado com todos os 
participantes do projeto, e como você sabe, isso inclui clientes também. Transparência de 
atitude também é fundamental, assim como a confiança mútua, mas acredite, nada substitui 
o bom senso dos sponsors, gerentes de projeto e chefes em geral para evitar fatigar seus co-
laboradores. Regrar a semana de trabalho em práticas ágeis é útil, mas em XP é mandatório. 
Não se agarre ao antigo e antiquado, convido você a abraçar o novo e assertivo em 
desenvolvimento, afinal já deve estar acostumado aqui em nosso país à seguinte situação 
em equipes de desenvolvimento de software em empresas por aí...
Trabalhar até tarde é geralmente mais visível e, portanto, você vai mais longe do 
que começar a trabalhar cedo. Chegar depois do chefe pode ser muito visível e muito 
negativo em algumas culturas corporativas como as latinas, por exemplo. Você também 
já deve ter visto ou trabalhado com aquele chefe adiantado que chega 1 hora antes que 
todos e são “medidores de tempos de chegada de funcionários em geral”. Você deve 
ter percebido até aqui que o foco é o tempo e não a “entrega funcional”. Então você 
trabalha 60 ou 80 horas por semana por quê? Qual o sentido disso?
Veja o que Andreas Krueger* escreveu sobre esse espinhoso tema para sua reflexão: 
“Why Do You Permit This To Be Done To You? 
Por que você permite que isso seja feito a você?
Essa é uma pergunta muito boa. O simples fato é que realmente per-
mitimos isso. O que eu estou querendo saber é por que, em um merca-
do de mão-de-obra curta, com todo o poder de barganha disponível no 
mundo para nós desenvolvedores, não citamos simplesmente Marcel 
Marceau no Filme “Silencioso” de Mel Brooks e dizemos “Não!”. Qual 
é o problema conosco? Não temos coragem de dizer «Basta!».
É claro que os empregadores estão nos pressionando para trabalhar mais 
horas para compensar a escassez, mas o que, realmente, é a escassez? 
Considerando a grande porcentagem de desperdício que acontece em 
nossa indústria de software devido a cronogramas insanos, produtos 
mal definidos, metodologias defeituosas, ferramentas ruins, ideias idio-
tas, etc. (para não mencionar o websurfing para acompanhar nossos 
investimentos no mercado de ações!). Podemos realmente ter um ex-
cedente de pessoas que são mal utilizadas.
6
7
Você sabe, se realmente limitarmos a semana de trabalho a 40 horas 
ou menos (uma ideia melhor) e levarmos algum tempo para reflexão, 
poderemos descobrir que metade de todos os projetos de software são 
totalmente desnecessários, e a metade restante pode ser facilmente 
manipulada em semanas normais pelo pessoal existente. 
Como obviamente não vamos usar nosso poder coletivo para extrair 
mais dinheiro, controle e status de nossas firmas, poderíamos pelo 
menos nos dedicar a ter mais algum tempo livre.
Nós realmente somos um bando de covardes, você não acha? 
Nós reclamamos das nossas longas horas, por um lado, mas nos diver-
timos com o quanto trabalhamos no outro. 
Hora de sair de cima do muro, pessoal. 
Ou você possui o seu trabalho ou você é possuído pelo trabalho. 
O que vai ser? 
Quem realmente controla sua vida, seu tempo?
É assim: vive para trabalhar ou trabalha para viver?
Hum... qual é o melhor?
Eu acho que “trabalhar como parte de sua vida” (então, certifique-se 
de aproveitar o seu trabalho) é o melhor que você pode fazer”.
XP nos instiga a fazer melhor sempre, vamos refletir um pouco sobre o que estamos 
fazendo como desenvolvedores, líderes, supervisores, coordenador e gestores de projetos?
Convido você a refletir mais profundamente!
*Quem é Andreas Krueger: https://goo.gl/vP1gqJ 
7
UNIDADE 
Padrões e Práticas em XP
Introdução
XP, como você já viu, tem um corolário de práticas e seguidores, não é mesmo?
Essas práticas fazem muito sentido se você utilizá-las de maneira sinérgica, ou seja, 
em conjuntos, seguindo grupos de afinidades. Isoladamente elas podem além de não 
produzirem o resultado esperado, piorar muito o que está sendo feito.
Parte disso se deve à falta de cuidado em trabalhar os elementos sociológicos empre-
sariais da sua organização para a mudança e a proposta da própria metodologia ágil que 
você pretende adotar.
Mudança não é um decreto, mudança é sempre uma escolha consciente e normal-
mente coletiva, porque envolve muitas outras pessoas, que tem seus papéis, como os 
atores numa grande peça de teatro para produzirem o resultado esperado, que nada 
mais é que a entrega do software em funcionamento.
Quando tratamos de certas práticas XP, elas podem gerar certa discussão em nosso 
meio, em parte pelos costumes arraigados, muitas vezes arcaicos, dos gestores de área e 
até mesmo gerentes de projeto, que não se atualizaram com as formas ágeis de gestão.
40 horas de trabalho semanal no desenvolvimento ágil ou menos para a metodologia 
XP é item obrigatório. Vejamos a polêmica em torno disso inicialmente.
Semana de 40h
Um pouco de história antes, para entendermos a origem das coisas, afinal, durante 
a primeira e segunda revolução industrial, as fábricas precisavam estar funcionando sem 
parar e muitos trabalhadores trabalhavam jornadas entre 10 e 16 horas por dia.
Por incrível que pareça, Henry Ford foi o primeiro a tentar mudar esse panorama; ele 
acreditava que 8h de trabalho por dia durante 5 dias por semana seriam suficientes, já que 
sua linha de produção era altamente eficaz. Porém as razões não eram científicas, muito 
ao contrário, eram para incrementar o consumo, principalmente de comprar seus carros.
Era uma época selvagem, como você pode ver... Não existiam computadores, softwa-
res, smartphones e outros brinquedinhos que nós de TIC amamos.
Interessante porque tudo nos estudos fundamentais e no trabalho gira em torno de 
um ciclo de 8h. Embora este tenha sido o padrão por gerações, a semana de trabalho 
de 40 horas não funciona mais.
Por isso XP é muito claro nisso, a semana pode ir até 40h, preferencialmentemenos 
que isso.
Fácil entendermos isso, afinal, passamos de uma economia baseada em indústria e 
escala para outra, baseada em informação e inovação.
Há fatores como os biológicos que determinam a sua disposição, de tal maneira que 
essa combinação de fatores faz com que seu ciclo seja mais longo ou mais curto. Isso 
8
9
tem consequências surpreendentes, tanto no seu rendimento profissional quanto na sua 
disposição para o dia. Se o seu ciclo for um pouco mais longo, você será considerado 
uma coruja da noite e terá mais energia neste período, senão seu ciclo será mais curto, 
então você provavelmente é um madrugador.
Como nota pessoal deixo aqui uma constatação, de que nesses mais de 35 anos como 
profissional de TIC, o maiores e melhores profissionais de desenvolvimento que conheci 
eram todos ”corujas da noite” e passavam praticamente a manhã toda como zumbis. 
O fato é que, após dez horas de vigília, nós começamos a mostrar atividade reduzida 
em áreas do cérebro associadas à atenção e concluímos tarefas mais lentamente, fica-
mos com o humor alterado em alguns casos e estamos muito mais suscetíveis a erros de 
toda natureza, que vão do nosso trabalho a acidentes de trânsito, segundo JIMENEZ et 
HAMMER, 2018.
A conclusão é simples, estudos têm demonstrado repetidas vezes que horas mais 
longas significam redução na produção, mas ainda há uma tendência em trabalhar mais 
horas para os funcionários, pensando que mais será feito.
Qual a solução que XP encontrou para esse desafio? Bom, em XP, nós não contamos 
as horas da forma que qualquer empresa onde você bate seu ponto conta. A entrega de 
software funcional se dá pelo nível de energia e concentração de cada membro do time, 
ou seja, tempo real dedicado ao trabalho, sem desvios, sem whatsapp, sem facebook, 
sem web surfing, por exemplo.
Ok, para acontecer isso numa empresa com um projeto XP é necessário termos indi-
víduos experientes, autogerenciáveis, em nível pleno pelo menos. Sim, mas tem que ser 
assim em qualquer metodologia ágil. 
Não se assuste, há espaço para os mais jovens e aprendizes, você os mescla nas 
equipes com os membros fortes para que eles possam ir se desenvolvendo e ganham da 
cultura de agilidade. Não há atalhos, jeitinhos ou fórmulas mágicas, em XP há trabalho, 
trabalho e mais trabalho. Porém, os resultados são excepcionais.
Coisas simples ajudam a estruturar um dia com menos que 8h de trabalho, levando 
em conta que atualmente a maioria dos profissionais de nossa área, mesmo no Brasil 
atuam como empresas, não há desculpa para manter aquele velho horário da CLT, afinal 
você é o dono do seu tempo e o valor/hora determinado em seu orçamento é o volume 
de horas a ser cumprido. Você não vai ganhar trabalhando mais, a menos que você seja 
uma empresa trabalhando sob o julgo de seu superior exigindo CLT, bom, daí é fraude.
O interessante é que em XP, como em qualquer metodologia ágil, você deve fazer 
o que está proposto para ser feito e o tempo deve ser aproveitado, mas as coisas são 
simples, veja o que se sugere:
• Tenha sempre pronto para o começo do dia ou semana, vamos pensar num sprint, 
na lista realista de tarefas a serem feitas. Seja honesto!
• Tudo é iterativo e circular em XP, portanto crie ciclos no seu trabalho, quer um exemplo?
 » Comece o dia fazendo a tarefa mais importante que mais exija sua criatividade. 
Até 1,5h fazendo isso é mais que o suficiente.
9
UNIDADE 
Padrões e Práticas em XP
 » Faça uma parada de 20 a 30 minutos (não faça nada, ou seja, se for o caso pode 
almoçar) O quê? Assustou-se com 30 minutos de almoço?!
 » Pegue mais uns 30 minutos para fazer as tarefas mundanas, como responder e-
-mails, telefonar, facebook, whatsapp, o básico. 
 » Dê mais uma puxada focada no seu trabalho, mais um sprint de 1,5h direto sem 
paradas e distrações, se alguém vier falar com você sem ser uma reunião ou sem 
ser convidado, é simples, dispense.
 » Tente repetir esse ciclo de sprint e intervalo de 30 minutos mais uma vez no dia 
pelo menos, além dessas duas de cima.
• O influente Steve Blank, pioneiro do Lean Startup Movement, usa um dia toda 
semana para remover completamente o trabalho, ficar com a família ou consigo 
mesmo. Sábados e Domingos não contam.
• Você deve se ver como uma empresa, portanto adote métricas suas, verdadeiras e ho-
nestas para medir o desempenho das tarefas que você faz. Cuidado, estamos falando 
de qualidade e não de quantidade, até porque isso é fácil, você senta e escreve 3 horas 
de código e faz X linhas, mas qual o propósito desse código que você escreveu? Ou, 
há quantos dias você está escrevendo esse código? Precisaria de tudo isso mesmo?
O interessante é que uma semana com mais de 40 horas não faz mal somente a nós, 
desenvolvedores, faz mal também aos gerentes e donos de empresa que ultrapassam os 
limites. Veja o estudo de psicologia aplicada feito em 2004 pelo CDC (Departamento de 
Saúde e Serviços Humanos dos EUA) em números:
• Pessoas que regularmente trabalham horas extras são menos saudáveis do que 
aquelas que não fazem. Eles são mais propensos a ganhar peso, adoecer e se 
machucar no trabalho.
• As pessoas estão menos alertas e mais propensas a cometer erros após a 8ª hora 
de trabalho.
• As pessoas que trabalham rotineiramente em horário estendido e horas extras são 
menos produtivas do que aquelas que trabalham oito horas por dia e 40 horas por 
semana. (GREENE, 2018)
O IGDA – Associação Internacional dos Desenvolvedores de Jogos acrescenta dados 
de um artigo, defendendo que:
“Os trabalhadores podem manter a produtividade mais ou menos indefini-
damente em 40 horas por semana de trabalho de cinco dias. Ao trabalhar 
mais horas, a produtividade começa a diminuir. Em algum lugar entre qua-
tro dias e dois meses, os ganhos de horas adicionais de trabalho são ne-
gados pelo declínio da produtividade horária. Em casos extremos (dentro 
de um ou dois dias, assim que os trabalhadores pararem de receber pelo 
menos 7-8 horas de sono por noite), a degradação pode ser abrupta.”
Qual a base por trás desse princípio de gestão em XP?
Ninguém pode trabalhar uma segunda semana consecutiva de horas extras. Mesmo 
as horas extras isoladas usadas com muita frequência são um sinal de problemas mais 
profundos que precisam ser resolvidos.
10
11
Cliente no Local
Apenas lembrando que, o cliente participará do Jogo de Planejamento, trabalhando com 
os requisitos do negócio, priorizando e definindo. Quando o desenvolvimento é iniciado, o 
cliente entrará em conversas contínuas conforme os desenvolvedores começam a codificar.
Wells (1999) escreve que um dos poucos requisitos mandatórios em XP é ter o cliente 
disponível no local. Não apenas para ajudar a equipe de desenvolvimento, mas também 
para fazer parte dela. Todas as fases de um projeto XP requerem comunicação com o 
cliente, de preferência frente a frente, no local. 
O cliente é quem escreve as histórias de usuários, tira a dúvida dos desenvolvedores 
com relação a aspectos obscuros e técnicos relativos ao negócio, afinal as histórias dos 
usuários são feitas de forma sintética. Eles também participam do jogo de planejamento, 
respondendo perguntas e definindo as prioridades de desenvolvimento e no planejamen-
to de liberações; ele é quem negocia com o desenvolvimento as histórias de usuários a 
serem incluídas em cada lançamento agendado. Por fim, o cliente deve estar presente 
durante os testes funcionais e de aceitação, criando dados de teste e verificando o resul-
tado dos testes automatizados.
Dessa maneira, as responsabilidades explícitas do Cliente são conduzir o projeto, for-
necendo requisitos (histórias do usuário) e controlando a qualidade (teste de aceitação). 
Implicitamente, por outro lado, incluem fazer a ligação com as partes interessadas exter-
nas do projeto, especialmente financiadores, outros clientes e usuários finais, mantendo 
a confiança da equipe de desenvolvimento e do negócio em geral.
Então aqui há um “baita pulo do gato”, não é mesmo? O cliente no localserve para 
evitar que o pessoal de desenvolvimento fale ou converse com o pessoal que tem a “cha-
ve do cofre” e isso evita que um volume enorme de pressão e estresse se acumule com 
desenvolvedores (isso normalmente não é nada bom). Desenvolvedores são muito pro-
cessuais e vão discutir sobre documentação e isso com pessoal de negócios não adianta 
muito, porque “negócios mudam”, como você não sabia?
Também não se engane, cliente no local não é um estagiário da área que encomen-
dou a demanda (nada contra estagiários, ok?), mas seria praticamente a mesma coisa 
que colocar uma foca num tanque cheio de tubarões, “a foca não tem como sair e os 
tubarões simplesmente não querem sair”.
Normalmente são usadas as pessoas chave da área demandante, ou seja, seus cam-
peões, e como acabei de escrever, podem ou devem ser mais que um. Portanto, o termo 
cliente no local, refere-se à área e não ao indivíduo.
O que se espera de um time do cliente no local, e que papéis devem representar para 
auxiliarem na consecução do projeto XP?
• Intérprete Geek: uma pessoa técnica que apoia o negócio para melhorar a sua co-
municação e colaboração com programadores.
• Assessor político: uma pessoa que está ciente das dimensões políticas dentro da Orga-
nização e é adepta de navegar essas dimensões para ajudar o projeto a obter sucesso.
11
UNIDADE 
Padrões e Práticas em XP
• Ligação técnica: uma pessoa que tem conhecimento e já passou por vários pro-
jetos relacionados e sabe onde estão os repositórios de documentação técnica 
dentro da organização.
• Testador de aceitação: uma pessoa que ajuda a escolher e escrever testes de aceita-
ção e verificar o software.
• Designer de interação do usuário: uma pessoa com habilidades de design centradas 
no usuário que ajuda projetar o que construir.
• Coach cliente: uma pessoa que apoia os outros membros da equipe de clientes para 
desempenharem os seus papéis.
Claro que de forma articulada esses papéis todos devem ser segmentados, está claro 
que não dá para apenas uma pessoa ser tudo isso ao mesmo tempo durante o ciclo de 
vida do projeto. Martin (2009) tenta descrever os elementos essenciais dentro de um 
time da área CLIENTE através de 3 macro funções, a saber:
• “O cliente que serve de guia de colaboração: intérprete geek, assessor político e 
ligação técnica. O núcleo função dessas funções é ajudar com a colaboração e cons-
trução de relacionamentos, tanto internamente dentro da equipe e externamente 
entre a equipe do projeto e a organização maior. Todas estas funções são papéis 
informais e, por vezes (especialmente no caso dos dois primeiros), vão apenas ser 
diretamente visíveis para a equipe principal do cliente (diplomata/negociador).
• O cliente que serve de especialista em habilidades: testador de aceitação, de-
signer de interação do usuário e escritor técnico. A função principal destas funções 
é ajudar o cliente a empreender atividades como a escrita de histórias, aceitando 
histórias e escrevendo documentação do usuário final. Muitas vezes, estes papéis 
são formais ou papéis reconhecidos na equipe, mas nem sempre. Às vezes é o su-
ficiente ter alguém na equipe com este conjunto de habilidades.
• O cliente que atua com ajustador de direção do projeto: diplomata, negociador, 
super secretário e treinador de clientes. O núcleo função dessas funções é definir 
a visão do software e estabelecer o que a equipe vai construir para atender a ne-
cessidade de negócios. Estes papéis se combinam para fazer o coração do cliente 
Equipe”. (MARTIN, 2009)
Agora fica bem mais fácil quando você for aplicar as práticas de XP e montar uma 
área de projetos ágeis, o que precisa passar ao time do cliente, quais as regras do jogo e 
o que se espera deles. Como você percebe, o termo ágil não é sinônimo de bagunça e 
falta de documentação em projeto de software, muito pelo contrário.
12
13
Padrões de Codificação
O código deve ser formatado de acordo com os padrões de codificação acertados 
entre todos os desenvolvedores do projeto. 
Os padrões de codificação mantêm o código consistente e fácil para toda a equipe 
ler e refatorar. 
Os desenvolvedores fazem isso para fomentar a propriedade coletiva do código, uma 
das práticas fundamentais de uma metodologia ágil e presente em XP.
Na maioria dos casos, esses padrões são documentados e formalizados como parte 
técnica do processo de desenvolvimento de software. 
Há várias categorias de padrão de codificação:
• Obrigatório: padrões que devem ser seguidos por todos os membros da equipe.
• Diretrizes: são as melhores práticas e descrevem a abordagem geral para o desen-
volvimento.
• Recomendações: devem ser usadas em todos os momentos, a menos que haja cir-
cunstâncias excepcionais que devam ser discutidas pela equipe.
Se você estiver usando XP, significa que você obrigatoriamente trabalhará com progra-
mação em pares, cada um se revezando no teclado. Baird (2002) escreve que, antes do iní-
cio da codificação, você precisará de um conjunto de regras acordadas sobre como atacar 
o desenvolvimento. Isso remove argumentos mesquinhos sobre formatação, nomenclatura 
e outros. Sem padrões de codificação, a troca de pares se tornaria difícil porque você seria 
forçado a aprender todos os outros estilos e abordagens de desenvolvedores.
Portanto, os padrões de codificação não são apenas uma prática recomendada, eles 
engraxam as engrenagens da equipe de desenvolvimento e garantem que todos ganhem.
Baird (2002) ainda expõe uma lista de padrões de codificação usados em XP. Logo 
abaixo na tabela há alguns dos principais:
Tabela 1 – Tipos de padrões de codifi cação. Adaptado de BAIRD, 2002
Padrão Descrição
Formatação
Formatação inclui o uso de espaço em branco, indention e comprimento de linhas 
de instrução no código. Alguns padrões podem incluir, por exemplo, configuração e 
manipulação comuns de editor para guias versus espaços para recuo.
Estrutura de 
código
A estrutura de código inclui o layout geral do projeto (arquivos e assim por diante), 
classes, recursos e outros tipos de arquivos de origem.
Convenções 
de Nomenclatura
As convenções de nomenclatura especificam como os desenvolvedores nomeiam 
seus métodos, classes, variáveis, eventos e parâmetros.
Tratamento 
de erros Tratamento de erros descreve como os objetos manipulam erros, relatórios e registros.
Comentários
Comentários são uma descrição em inglês no código que explica a lógica do 
código. (O código de qualidade deve ser autodocumentado por padrão.) O uso de 
comentários de qualidade fornece ao código de qualidade melhor capacidade de 
manutenção e facilidade de compreensão.
13
UNIDADE 
Padrões e Práticas em XP
Quer trabalhar com padrões de codificação em XP para unificar as práticas das equi-
pes de desenvolvimento e poder aproveitar tudo o que a propriedade coletiva de código 
pode proporcionar?
Então vou sugerir que acesse o link abaixo para que você encontre o que precisa e 
possa praticar.
Convenções de código para a linguagem de programação Java TM. 
Disponível em: https://goo.gl/RFmaH 
O princípio com esta abordagem de padrões de codificação é que, mesmo se não 
existir um padrão para sua tarefa, convoque rapidamente uma reunião (gire as cadeiras 
em círculo e converse, ou vá para o quadro branco e escreva com seus colegas) e con-
corde em conjunto. O pacto entre desenvolvedores é uma das maiores forças em XP. 
Quando o padrão for aceito, adicione-o ao site do Wiki Wiki para o projeto ou crie um.
WIKI WIKI é um repositório para projetos ágeis que requerem mandatoriamente uma 
base de conhecimento comum, compartilhada pelo time do projeto e de desenvolvimen-
to. Aqui tem um link para você usar e criar seus próprios wiki wiki para XP.
Wiki-wiki : https://goo.gl/KuPJc8 
Práticas Gerais em XP
A ideia dessa seção não é dar exemplos, isso você terá nos cases do material de 
apoio. Nós vamos explorar as regras do jogo XP, pegar o ciclo de vida e mostrar o que 
deve ser feito em cada fase. Se seguir esses passos, mais os exemplos,templates e cases 
das unidades anteriores e dessa, vai resolver o desafio do fórum facilmente.
Vamos lá então:
XP como metodologia segue regras, como num jogo. Aliás, não se joga um jogo sozi-
nho, certo? XP é totalmente orientado à colaboração entre desenvolvimento e negócios 
principalmente. Mas XP tem valores, princípios, práticas e regras. 
As regras fornecem uma referência comum para todos da equipe, de modo que 
eles lembrem a todos de que e como precisam fazer quando as coisas correm bem e 
quando não.
O objetivo do jogo XP de planejamento, por exemplo, é maximizar o valor do sof-
tware produzido pela equipe. A partir do valor do software, você deve deduzir o custo 
de seu desenvolvimento e o risco incorrido durante o desenvolvimento. Em metodologia 
ágil não há receita pronta de bolo e templates milagrosos que vão evitar que você pense. 
Aliás, pensar é o que mais se vai fazer.
14
15
A estratégia para a equipe é investir o mínimo para colocar a funcionalidade mais 
valiosa em produção o mais rápido possível, em conjunto com as estratégias de projeto 
e codificação para reduzir o risco. Toda empresa tem sua forma de apurar custos de 
desenvolvimento de software, use ou adapte à que você tem contato ou crie uma. Há 
modelos de sobra pela internet incluindo vídeos no youtube para isso, basta dar uma 
procurada. Vamos dar uma olhada/surfada na web?
Bom, vamos começar.
XP possui em seu ciclo de vida as seguintes fases ou tempos, se preferir, e como XP 
é iterativo e circular, essas fases estão sempre no gerúndio, e o motivo disso é óbvio, 
tudo está sempre acontecendo ao mesmo tempo em momentos diferentes, mas com a 
mesma equipe, então estamos sempre:
• Planejando
• Gerenciando
• Projetando
• Codificando
• Testando
Figura 1 – Resumo do SDLC – Ciclo de Vida do Desenvolvimento de Software para o XP (próprio autor), por ser 
iterativa, o próprio ciclo é contínuo, as funcionalidades prontas vão sendo retiradas no processo de integração 
contínua na saída dos testes de aceitação para entrada em produção.
Talvez você pense que deveríamos colocar também uma fase chamada “integrando”, 
mas não precisa, pois a integração é contínua e a qualidade faz parte de todo o fra-
mework, portanto não faz sentido algum.
15
UNIDADE 
Padrões e Práticas em XP
Vamos conhecer as atividades de cada fase da metodologia XP.
Figura 2 – Visão Analítica do SDLC-XP (próprio autor). 
Importante notar a participação e responsabilidade do cliente em todas as fases, bem como o ciclo de iterações e 
a constante liberação de produtos de software funcionais.
Planejamento
Há dois tipos: o de liberação e o de iteração
Liberação
• Negócios e a equipe são os jogadores.
• Cartas de história são usadas. (você já viu os modelos e as regras em unidades an-
teriores).
• As histórias do usuário são escritas pelo cliente em cartões de histórias (os famosos 
index cards já vistos).
• Negócios decidem a prioridade da funcionalidade para implementação.
• As estimativas são dadas pela equipe de desenvolvimento com base nos cartões de 
história (planning poker, se lembra?).
• Lançamentos curtos (frequentes e pequenos) devem ser planejados.
• O cronograma do lançamento deve ser criado em acordo mútuo. Para a primeira 
versão ou lançamento.
• As próximas versões devem ser divididas em iterações (ou seja, você já tem o ba-
cklog montado, a primeira entrega escolhida das funcionalidades desse backlog 
chama-se lançamento, daí por diante criamos os sprints, se preferir, as iterações e 
segue o ciclo até o término).
16
17
Iteração: cada iteração iniciada seguirá essas regras:
• Os membros da equipe de desenvolvimento são os jogadores.
• Cartões de tarefas são usados.
• Para cada história selecionada para a iteração, os cartões de tarefas são produzidos.
• Os membros da equipe precisam estimar as tarefas com base nos cartões de tarefas.
• Cada membro da equipe é atribuído com cartões de tarefas.
• Cada membro da equipe deve então reestimar com base em sua tarefa. É proibido; 
uma vez estimado deverá ser mantido. Esse membro deverá:
 » Aceitar o trabalho.
 » Assumir a responsabilidade da conclusão do trabalho.
 » Obter feedback sobre o tempo real gasto.
 » Melhorar as estimativas
 » Respeitar essas estimativas.
• A atribuição final é feita considerando a semana de 40 horas e o fator de carga.
Gerenciando
• A equipe recebe um espaço de trabalho aberto dedicado.
• Cada estação de trabalho deve ser organizada de modo que dois desenvolvedores 
possam se sentar lado a lado e facilmente deslizar o teclado e o mouse.
• Ritmo sustentável deve ser definido (40 horas por semana e sem horas extras por 
mais de uma semana) e gerenciado por métricas. Use um software para controle 
de empenho para dar indicadores e evitar que a equipe tenha sensação de que não 
está sendo monitorada e vire, você sabe...
• Reforce as regras do jogo de planejamento (elas estão um pouco mais acima e fo-
ram detalhadas na unidade que tratou desse tema).
• Corrigindo qualquer prática de programação extrema quando ela quebra (isso deve 
realmente ser feito, um momento de frouxidão e seu projeto literalmente “irá para 
o espaço”).
• Garantir a comunicação entre a equipe (reunião diária, bases compartilhadas, chat, 
whatsapp, conversa, vale tudo desde que seja eficaz).
• Desencorajar comunicação que: (é para cortar mesmo)
 » não ajuda
 » não está na hora certa
 » feita em grande detalhe
• Faça as pessoas se movimentarem, ou seja, devem produzir código, de qualidade, tes-
tado e funcionando. As metodologias ágeis são pressionadoras por natureza, então não 
se engane. A pressão em times ágeis existe sim, é grande e precisamos ser maduros 
psicologicamente e profissionalmente para entender isso tudo que estamos passando e 
17
UNIDADE 
Padrões e Práticas em XP
se motivar. Pense nisso como se fosse a academia de ginástica, nos primeiros dias dói 
o corpo todo, quer desistir, inventa 500 coisas para não ir, mas quando seu corpo (no 
nosso caso, seu cérebro) se acostuma, você quer ir para a academia até em feriado.
• Meça os tempos reais e transmita para a equipe periodicamente, para que cada 
membro conheça o desempenho em relação à previsão. Isso garante que este me-
lhore na estimativa.
• Disponibilize alimentos para a equipe como e quando necessário (parece besteira, 
mas os gestores que fazem isso melhoram quase 20% o desempenho do time, é 
simples, são pessoas, gostam de reconhecimento e de saber que há pessoas preo-
cupadas com elas, mesmo sendo o chefe).
Projetando: tratamos de design, siga o seguinte:
• Escolha uma metáfora para o sistema e evolua conforme o desenvolvimento avança 
(lembra da metáfora? Não? Retorne algumas unidades para recordar, vale a pena).
• Mantenha o design simples.
• Nenhuma funcionalidade é adicionada antecipadamente (siga o fluxo determinado, 
afinal quem definiu a sequência foi o cliente, certo?).
• Coloque a arquitetura em suspenso por um tempo, pegue o que você precisa para 
atender às suas necessidades atuais, e confie que você pode colocar a arquitetura 
toda mais tarde, encaixe e adapte.
• Refatore quando e onde for possível. (se lembra? Refatore sempre, sempre e sempre).
Codificando
• O negócio (quem representa o cliente) deve estar sempre disponível.
• Os desenvolvedores devem escrever todo o código de acordo com as regras que 
enfatizam a comunicação através dele (documentação no código inclusive, siga as 
regras e os padrões, se lembra?).
• A programação em pares deve ser assegurada.
• Padrões de codificação devem ser seguidos.
• Todo o código deve ter testes de unidade.
• Escreva um teste de unidade primeiro, antes que o código seja escrito para cada parte 
do sistema, de modo que seja muito mais fácil e rápido criar seu código. O tempo 
combinado necessário para criar um teste de unidade e criar algum código para fazê-lo 
passar é quase o mesmo que codificá-lo imediatamente. Facilita o teste de regressão.
• Quando você está codificando, deve usar apenas um dos seguintesquatro chapéus: 
(só e somente só isso, ok!).
 » Ou você está: Adicionando nova funcionalidade, mas apenas alterando a imple-
mentação.
 » Ou você está: Adicionando nova funcionalidade, mas apenas alterando a interface.
18
19
 » Ou você está: Refatorando o código, mas apenas alterando a implementação.
 » Ou você está: Refatorando o código, mas apenas alterando a interface.
• Uma estação de trabalho de integração dedicada é fornecida para toda a equipe 
(completa e separada das de uso desta; isso mesmo, tem que ser outra!). Ela é como 
uma catedral, ali acontece a junção das coisas e o fruto do trabalho do time é todo 
integrado e fortalecido.
• Apenas um par integra o código por vez e garante que todos os testes sejam aprovados. 
Atenção, isso é importantíssimo e determina o motivo pelo qual precisa haver uma es-
tação somente para integração, senão cada desenvolvedor vai integrar quando der “na 
telha” e muitos vão fazer ao mesmo tempo, dando problemas tão sérios que não tenho 
ideia de como você vai resolver. Uma dica é manter sempre backup, redundância e 
contingência do ambiente e dos repositórios; mas acredite, dá tanto trabalho fazer isso, 
e principalmente recuperar isso, que vale a pena seguir essa regra de verdade.
• A integração deve ser feita frequentemente.
• A propriedade coletiva deve ser usada. (XP não é anarquia, puna quem não seguir 
as regras exemplarmente, até mesmo tire da equipe, você estará fazendo um gran-
de favor para o projeto e para os desenvolvedores, sem falar no cliente).
Testando
Todos os códigos devem passar em todos os testes unitários antes de serem liberados.
Os testes devem ser escritos quando um defeito é encontrado.
Os testes de aceitação devem ser executados com frequência. (aqui entra o usuário sempre)
O pessoal do TUTORIALSPOINT (2018) coloca um texto interessante dobre os lo-
ops de feedback em XP. É o feedback contínuo que mantém todos focados e o desenvol-
vimento continua na direção certa, sem atrasos. Na Programação Extrema, o feedback 
é realizado em diferentes níveis, com os detalhes necessários e suficientes. Isso é feito 
continuamente e constantemente entre as iterações e versões também.
Tabela 2 – Eventos de feedback e a duração do feedback sugerida
Evento de Feedback Duração do Feedback
Par de programação Segundos
Testes Unitários Minutos
Esclarecimentos entre a equipe e com o cliente Horas
Progresso Em um dia
Teste de aceitação Dias
Planejamento de Iteração Semanas
Planejamento de Liberação Meses
Fonte: Adaptado de: https://goo.gl/uyZmCD
19
UNIDADE 
Padrões e Práticas em XP
Gerenciamento de Projetos
Em XP, não há nenhuma ênfase nesse papel, na verdade o gerente da área téc-
nica XP acaba fazendo as seguintes atividades incorporadas em seu dia a dia sem 
muitos problemas.
• Planejamento de Liberação
 » O escopo é definido por histórias de usuários em cartões de histórias.
 » Estimativas são estimativas de histórias, que podem estar em pontos de história. 
(planning game)
 » Os marcos de entrega são capturados pelos planos de liberação.
 » A liberação é dividida em iterações.
• Planejamento de Iteração
 » Histórias estão em tarefas em cartões de tarefas.
 » Estimativas são estimativas de tarefas.
 » Alocações de tarefas são feitas pelo balanceamento do fator de carga em toda a 
equipe. (quantas horas/homem há em cada tarefa, levando-se em consideração 
40hs por semana por pessoa?)
 » A aceitação da tarefa é pelo comprometimento e responsabilidade da equipe.
• Rastreamento
 » Velocidade em termos de pontos de história do tempo real para implementação 
feita no nível do projeto. (planejado x realizado)
 » Produtividade em termos de estimativas de tarefas a partir do tempo real para 
implementação feita no nível do desenvolvedor.
 » Rastreamento de defeitos
Gere
ncian
do
Projetando
Testando
Incrementando
Produto de SW
Planejamento Codi�cando
Cartões de Histórias
Cartões de Tarefas
Testes de
Aceitação
Refatoração
de Código
Testes de
Unideade
Projeto Simples
Programação
em Pares
Cartões de Histórias
Cartões de Tarefas
Testes de
Aceitação
Refatoração
de Código
Testes de
Unideade
Projeto Simples
Programação
em Pares
Figura 3 – Mapa de um Projeto XP com as Práticas Principais inseridas no SDLC. (do próprio autor). 
Nesse quadro temos uma revisão do ciclo XP com todas as etapas importantes até a entrega de software 
em produção. Não se esqueça de que todas as práticas precisam ser consideradas como um todo, para que 
se apoiem mutuamente. A fraqueza de uma é coberta pelas forças das outras.
Bom, agora você já tem a “missa” toda para poder fazer sozinho seguindo todas as 
práticas e técnicas, então, mãos à obra!
Sucesso!
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Leitura
Why Do You Permit This To Be Done To You
https://goo.gl/UmH9QV
On-Site Customer in an XP Project: Empirical Results from a Case Study
https://goo.gl/7wbmXi
The role of customers in extreme programming projects
https://goo.gl/k49pxG
Developers Best Practices Tutorial
https://goo.gl/3KtBE4
21
UNIDADE 
Padrões e Práticas em XP
Referências
BAIRD, S. Extreme Programming Practices in Action. 2002. Disponível em: http://www.
informit.com/articles/article.aspx?p=30187&seqNum=14>. Acesso em 10/06/2018
GREENE, J. Is 40 Hours a Week Too Much? Here’s What History and Science Say. 
2018. Disponível em: <https://www.askspoke.com/blog/hr/40-hour-work-week/>. 
Acesso em: 10/06/2018
IGDA - Does Sustainable Pace mean a 40 hours week? Disponível em: <https://www.
igda.org/blogpost/1253156/IGDA-Community-Blog>. Acesso em 10/06/2018.
JIMÉNEZ, M. et HAMMER, K. Want to get ahead? Sleep in. 2009 atualizado em 2018. 
Disponível em: <https://www.theglobeandmail.com/life/health-and-fitness/health/
conditions/want-to-get-ahead-sleep-in/article572722/>. Acesso em: 10/06/2018
TUTORIALS POINT INC. Developers Best Practices Tutorial. 2018. Disponível em: 
<https://www.tutorialspoint.com/developers_best_practices/index.htm>. Acesso em: 
10/06/2018
22