Extreme Programming

Jéssyka F. F. Vilela, Lenivaldo Ribeiro de Souza, Manoel Alexandre Vieira,

Rodrigo M. Bacurau
Colegiado de Engenharia da Computação – Universidade Federal do Vale do São
Francisco (UNIVASF)

Avenida Antônio Carlos Magalhães, 510, Santo Antônio – 48.902-300 – Juazeiro – BA

– Brasil
{jessykaflavyanne,manoelalexvieira}@gmail.com, leninho123@hotmail.com,
rodrigo.bacurau@univasf.edu.br

1. Introdução
Extreme Programming (XP) é uma metodologia de abordagem deliberada e
disciplinada para o desenvolvimento de software, salientando a satisfação dos clientes.
O primeiro projeto XP foi iniciado em 6 de março, 1996 e sua implementação foi bem
sucedida pois realça a satisfação do cliente.
O grande diferencial deste método é salientar o trabalho em equipe como o
melhor caminho para o sucesso no desenvolvimento dos sistemas. Todas as pessoas,
gerentes, clientes e desenvolvedores, que fazem parte da equipe são igualmente
respeitados por fazerem parte ativamente do desenvolvimento do projeto.
Os projetos implementados sob a metodologia XP seguem cinco valores
essenciais para o sucesso final: comunicação, simplicidade, feedback, respeito e
coragem. Estes valores interagem entre si e fazem com que a equipe de
desenvolvimento do sistema seja altamente produtiva. Os valores começam a interagir
quando os extreme programadores iniciam a comunicação com seus clientes e os
demais integrantes da equipe de desenvolvimento. Os desenvolvedores devem manter o
projeto simples e limpo e utilizar o feedback para testar o seu software a cada dia. Cada
sucesso na elaboração do sistema aprofunda o respeito pelas contribuições únicas de
cada membro da equipe, alem disso programadores XP são capazes de encarar novos
requisitos e tecnologias com coragem.
Segundo Kent as 12 práticas da metodologia XP são muito parecidas com um
quebra-cabeça, ou seja, individualmente as peças não fazem sentido, mas quando
combinadas formam uma imagem completa. Essas regras podem parecer simples e até
mesmo ingênuas, porém são baseadas em valores e princípios sólidos. A Figura 1 ilustra
como as práticas e os valores (que serão explicadas nas seções seguintes) são ligados
para assim conseguir a harmonia no desenvolvimento de um projeto sob a metodologia
XP.
 Figura 1. Valores e práticas do XP integrados.

2. Valores do XP
Segundo Kent, o sucesso para o desenvolvimento de um sistema é alcançado quando
temos uma conduta que valoriza um conjunto de comportamentos que servem tanto as
necessidades humanas quanto as comerciais: comunicação, simplicidade, feedback e
coragem. O site oficial do XP ainda acrescenta outro valor, o respeito, e aconselha que
após inserir os valores já citados, adicionar os próprios valores que a equipe de
desenvolvimento ache pertinente.
1. Comunicação: todo mundo faz parte da equipe e se comunicar frente a frente
diariamente é fundamental. Problemas com o projeto podem passar
despercebidos pelo simples fato de falta de comunicação entre os integrantes da
equipe. O XP tem como objetivo manter o fluxo de comunicação empregando
principalmente nas práticas de programação em pares e testes.
2. Simplicidade: para este valor Kent ressalta a importância da seguinte pergunta
“Qual a coisa mais simples que poderia funcionar?”. É sabido que em
programação simplicidade não é fácil. A equipe de desenvolvimento deve focar
no que for necessário e solicitado, mas não mais. Esse tópico irá maximizar o
valor criado para o investimento feito. É importante ter em mente que se
tomarmos passos simples para os nossos objetivos as falhas também serão,
quando ocorrerem.
3. Feedback: segundo Kent o otimismo profissional é um perigo de programação e
o feedback é o tratamento. O feedback funciona a partir do momento que os
programadores escrevem rotinas de teste para qualquer lógica do sistema que
pode quebrar, assim o próprio sistema manda um feedback sobre o seu estado.
 4. Coragem: esse valor enfatiza a honestidade e respeito entre a equipe, pois o fato
de querermos o sucesso não pode sobrepor a necessidade de dizer a verdade
sobre o progresso e as estimativas. Kent diz que,
“comunicação apóia coragem porque abre a possibilidade de mais
alto risco, experimentos de grande recompensa. Simplicidade suporta
coragem, pois você pode dar ao luxo de ser muito mais corajoso com
um sistema simples. Coragem apóia simplicidade, porque assim você
vê a possibilidade de simplificar o sistema que você desenvolveu.
Feedback concreto suporta coragem porque se sente muito mais
seguro tentar uma cirurgia no código, se você pode empurrar um
botão e ver o resultado dos testes no final.”
5. Respeito: todos da equipe devem se tratar com respeito pela importância
fundamental que cada um tem no desenvolvimento do sistema. Desenvolvedores
devem respeitar a experiência dos clientes assim como os clientes devem
respeitar a experiência dos desenvolvedores.

3. Práticas do XP
Podemos agora dar início ao desenvolvimento do nosso software, pois já sabemos o
problema a ser resolvido e temos um conjunto de valores para nos orientar de como
melhor proceder em cada uma das atividades (codificação, testes, monitoramento e
projeto).
Contamos com práticas simples que muitas vezes são abandonadas por serem
vistas como impraticáveis ou ingênuas. As principais praticas em XP são estruturadas
sob as quatro atividades visando fazê-las seguindo seus princípios.
Sempre que uma prática é fraca os pontos fortes das outras cobrirão as referidas
fraquezas o que constitui uma das vantagens do método.
As 12 práticas são conceituadas a seguir:
1. Jogo de Planejamento: nessa etapa o cliente é essencial, pois ele identifica
quais funcionalidades é prioridade para serem estimadas pelos desenvolvedores.
Ainda nessa etapa o cliente fica sabendo o que ira acontecer durante o projeto;
2. Pequenas Versões: o conceito de pequenas versões é colocar um sistema
simples em produção de imediato e em seguida disponibilizar uma nova versão
em intervalo espaço de tempo;
3. Metáfora: é onde os desenvolvedores traduzem as palavras do cliente para o
que ele espera no projeto. Essa é a etapa guia de todo o desenvolvimento, pois
cria uma historia de como funciona todo o sistema;
4. Projeto Simples: o sistema deve ser implementado de maneira simples.
Qualquer complexidade encontrada deve ser removida assim que for descoberto;
5. Teste: são testes criados pelos clientes e desenvolvedores para identificar quais
funcionalidades já estão prontas. Os testes devem rodar sem falhas de
desenvolvimento para continuar;
 6. Refatoração: é a etapa que proporciona uma melhoria continua ao sistema
desenvolvido. Os desenvolvedores reestruturam o sistema sem executar
alterações a fim de eliminar a duplicação, melhorar a comunicação, simplificar
e/ou adicionar flexibilidade;
7. Programação em Pares: todo o código fonte é feito por dois programadores em
uma mesma máquina;
8. Propriedade ou Posse Coletiva: o código fonte não pertence a apenas um
membro da equipe e sim a todos, assim, qualquer um pode alterar qualquer parte
do código em qualquer lugar no sistema e a qualquer momento;
9. Integração Contínua: consiste em adicionar e/ou fortalecer quantas vezes for
possível a cada vez que uma tarefa for concluída. Esta etapa permite saber o
status real do desenvolvimento do sistema e diminui a possibilidade de conflitos
e erros no código fonte;
10. 40 horas por semana ou Ritmo Sustentável: respeitar o ritmo de trabalho
buscando formas de trabalhar com qualidade e saudável. Como regra não
exceder 40 horas semanais e se necessário fazer horas extras, porém nunca fazê-
las duas vezes consecutivas;
11. Time Coeso: consiste em incluir um usuário real do sistema, em tempo integral,
para esclarecer possíveis duvidas;
12. Padrões de Codificação: a equipe de desenvolvimento deve estabelecer regras
de padronização do código que deve ser seguida por todos e enfatizar a
comunicação através do código;

4. Papéis de cada membro no XP

Beck (200) define sete papéis dos integrantes de um projeto que utilizam o XP:
Supervisor (Tracker), programador, gerente (Big Boss), consultor, testador, técnico
(Coach) e o cliente.
 O supervisor (tracker):
o é a consciência do time;
o Precisa cultivar a capacidade de coletar as informações que precisa sem
perturbar o processo inteiro mais do que o necessário;
o Tem como responsabilidade:
 coletar sinais vitais do projeto (métricas) uma ou 2 vezes por
semana;
 manter todos informados do que esta acontecendo;
 tomar atitudes sempre que as coisas parecerem ir mal;
 manter um registro dos resultados dos testes funcionais;
 manter um registro dos defeitos relatados;
 O programador é o coração do XP;
 o estima prazos das histórias do cliente;
o define os cartões de tarefas a partir dos cartões de histórias;
o estima os cartões de tarefa;
o implementa testes unitários (antes do código);
o implementa o código de produção;
o faz refatoração sempre que necessário;
o solicitar ao cliente que esclareça ou divida uma história quando
necessário.
o Habilidades necessárias:
 trabalhar em par;
 Hábito de simplicidade;
 O gerente é a pessoa que precisa transmitir coragem, confiança e saber cobrar o
que é de responsabilidade de cada um.
o É responsável por:
o gerenciar o time e os problemas do time;
o agendar as reuniões de planejamento;
o garantir que as reuniões fluam como planejado;
o escrever o que foi definido nas reuniões;
o manter o supervisor (tracker) informado dos acontecimentos das
reuniões;
o buscar recursos;
 O consultor é chamado quando a equipe precisa de conhecimentos técnicos
profundos.
o Ensina a equipe a resolver seus próprios problemas;
o Após resolver o problema, a equipe provavelmente irá jogar fora tudo
que o consultor fez e fazem novamente;
o Não deve se sentir insultado;
 O testador em XP tem o papel realmente focado no cliente.
o É a pessoa do time que aplica os testes;
o Tem por responsabilidade:
 definir com o cliente os testes funcionais do projeto;
 escreve os testes funcionais;
 executa os testes e publica os resultados para o time.
  O treinador é responsável pelo processo como um todo.
o Notifica as pessoas quando elas estão se desviando do processo e conduz
o time novamente para o processo.
o Tem a função de:
 garantir que o projeto permaneça extremo;
 ajudar com o que for necessário;
 manter a visão do projeto;
 formular e comunicar uma tarefa que um programador pode
querer trabalhar.
 O cliente é fundamental no XP;
o sabe o que deve ser programado;
o paga pelo desenvolvimento do projeto e também precisa estar disposto a
aprender. Pois, não é fácil executar funções como:
o definir os requisitos do software;
o escrever os cartões de história;
o definir as prioridades para os cartões de história;
o validar e definir os testes funcionais sempre que solicitado;
o esclarecer dúvidas sempre que solicitado;
o tomar decisões

5. Etapas de desenvolvimento
Um projeto considerado ideal utilizando a metodologia Extreme Programming inicia
por uma curta fase de desenvolvimento, seguida de anos de produção e refinamentos
simultâneos e finalmente encerra quando o projeto não faz mais sentido (BECK, 2000).
O ciclo de vida XP é considerado bastante curto e, à primeira vista, difere dos
padrões dos modelos de processo convencionais. De acordo com Pressman (2006), as
atividades-chave do XP podem ser resumidas em quatro: planejamento, projeto,
codificação e testes. A Figura 2 ilustra o processo XP e mostra algumas das idéias-
chave e tarefas que estão associadas a cada atividade.
Nas subseções a seguir serão detalhadas as atividades presentes na Figura 2, bem
como suas fases e subfases.
 Figura 2. O processo Extreme Programming (PRESSMAN, 2006).

5.1 Planejamento
A atividade de planejamento é realizada diversas vezes ao longo do projeto para
garantir que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá
gerar maior valor para o cliente a cada dia (TELES, 2005).
É preciso garantir que as ferramentas utilizadas permitirão a finalização do
projeto, além disso, que o código implementado irá executar adequadamente todos os
dias e, principalmente, que os desenvolvedores aprenderão as habilidades necessárias
para o desenvolvimento do sistema. Dessa forma, antes da etapa de planejamento
propriamente dita, existe uma etapa de preparação que os autores denominam de
Exploração que tem como objetivo entender o que o sistema deve fazer de forma a
proporcionar confiança suficiente para que o time consiga iniciar e finalizar o
programa, utilizando as ferramentas que possui.
Durante a exploração os programadores testam a performance da tecnologia a
ser utilizada, como exemplo podem ser citados os requisitos de hardware necessários
para rodar o sistema ou a largura de banda viável para que a rede possa sustentar o
sistema. Além disso, os programadores, divididos em duplas, desenvolvem um sistema,
sobre visões diferentes, semelhante ao que será realmente desenvolvido, durante uma
ou duas semanas. A melhor opção será escolhida. Se o período estimado não for
suficiente para testar a tecnologia, então ela deve ser classificada como um risco para o
projeto.
De acordo com Beck (2000), a exploração da arquitetura fornece aos
programadores uma boa noção da implementação quando o usuário apresentar seus
cartões de história (que serão detalhados na subseção seguinte), pois os programadores
precisarão estimar a duração de cada tarefa.
Entende-se que essa fase termina quando o cliente está convencido que existem
materiais suficientes para uma boa primeira entrega e os programadores estarem
convencidos de que não é possível melhorar, sem implementar o sistema.
5.1.1 User Stories

Enquanto os programadores exploram as tecnologias o cliente escreve user

stories. As user stories descrevem as características e funcionalidades requeridas para o
software e são registradas em pequenos cartões (Figura 3).
As histórias de usuários, às vezes, necessitam de um determinado nível de
abstração por parte dos desenvolvedores com o intuito de compreender a real
necessidade do cliente. Segundo Beck (2000), no início as histórias não serão
satisfatórias, no entanto deve-se fornecer feedback rápido ao cliente para que ele possa
especificar o que os programadores realmente precisam.

Figura 3. Exemplo de cartão de User Story

É importante notar que a escrita de user stories pode acontecer a qualquer

momento durante todo o projeto XP. Um conjunto inicial de user stories é criado no
inicio do projeto. Em seguida, novas user stories podem ser criadas como resultado de
novos requisitos. Elas também podem ser criadas para refinar os itens a serem entregues
à medida que novas expectativas de funcionalidades existentes são descobertas.
O cliente atribui um valor (prioridade) para a história com base no valor de
negócio global, da característica ou função. Os programadores avaliam cada história e
lhe atribuem um custo. Se o projeto for muito grande ou a história precisar mais do que
três semanas, pede-se ao cliente para dividir a história em partes menores (tarefas),
registradas em novos cartões (Figura 4), e a atribuição do valor e custo ocorre
novamente. Assim os desenvolvedores implementam tarefas ao invés de user stories.
 Figura 4. Modelo de cartão de tarefa (Adaptado de Beck, 2000).

Wake (2002) considera que, histórias menores tendem a apresentar risco menor.
Quando os programadores não sabem como estimar alguma coisa, eles podem fazer
uma pontuação (spike), isto é, uma rápida programação da história, que pode durar
minutos, horas ou no máximo dois dias. O resultado de uma pontuação é conhecimento
suficiente para tentar uma estimativa.
Na realização de um projeto XP utiliza-se o conceito de “dia ideal de
desenvolvimento”, que representa um dia no qual o programador só trabalha na
implementação de funcionalidades, sem ser atrapalhado por uma atividade externa
(reuniões, atender telefone, etc.). Isso é importante, pois dará uma melhor noção ao
desenvolvedor ao estimar a implementação de user stories.

5.1.2 Jogo de planejamento

O tempo disponível para o projeto é dividido utilizando dois conceitos: releases e
iterações. As releases duram alguns poucos meses e se dividem em iterações de duas
semanas que, por sua vez, se dividem em tarefas que duram alguns dias. Esses conceitos
são ilustrados na Figura 5.

Figura 5. Releases, iterações e tarefas em um projeto XP.

 No início de cada release e de cada iteração ocorre o jogo de planejamento. São
reuniões onde o cliente avalia as funcionalidades que devem ser implementadas no
sistema e prioriza aquelas que farão parte do próximo release ou da próxima iteração.
O envolvimento do cliente é apoiado pelo engajamento em tempo integral deste
na equipe de desenvolvimento. Ele está intimamente envolvido na especificação e
priorização das histórias, faz parte do desenvolvimento e é responsável pela definição
de testes.
Um dia de trabalho de uma equipe XP sempre começa com um stand up
meeting. O stand up meeting é uma reunião usada para o planejamento diário das
atividades e que força uma aproximação dos desenvolvedores de forma diária e
contínua. Além de disseminar informações sobre o dia anterior, diminuindo os tempos
de feedback, a equipe prioriza o trabalho a ser feito no dia que se inicia. Isso permite
também que toda a equipe tenha um rápido conhecimento dos desafios enfrentados, das
soluções criadas, das idéias colocadas em prática e dos problemas que precisam ser
tratados com urgência.
Uma release corresponde a um marco no tempo no qual um conjunto coeso de
funcionalidades é finalizado e lançado para consumo de seus usuários. O trabalho se
encaixa no cronograma baseado no valor para o negócio, dificuldade e a velocidade de
implementação da equipe.
Wake (2002) apresenta alguns passos, que também podem ser visualizados na
Figura 6, para auxiliar a fase de release no jogo de planejamento:
 Classificação por valor: o cliente seleciona as histórias por valor alto, médio ou
baixo;
 Classificação por risco: os programadores qualificam as histórias em: alto,
médio ou baixo;
 Definição de velocidade: os programadores declaram a velocidade,
empiricamente calculada, ou seja, baseada na experiência dos programadores;
 Escolha do escopo: cliente escolhe as histórias para a próxima versão.

Iterações são incrementos de software útil (funcionalidades) projetados,

programados, testados, integrados e entregues pela equipe de desenvolvimento durante
um espaço de tempo curto e fixo, no espaço de tempo de uma release. O final de uma
iteração representa um ponto de sincronização no projeto, um momento no qual o
cliente e os desenvolvedores avaliam as funcionalidades produzidas e reavaliam as
prioridades para as iterações seguintes, permitindo também detectar eventuais falhas.
Portanto, elas fornecem um aumento dramático de feedback em relação a metodologia
seqüencial, promovendo comunicação muito mais ampla entre as várias pessoas que
possuem interesses no sistema.
Os clientes e programadores trabalham juntos para decidir como agrupar
histórias na versão seguinte ao próximo incremento de software a ser desenvolvida pela
equipe XP. Uma vez feito um compromisso básico para a versão (um acordo quanto às
histórias a serem incluídas, data de entrega e outros assuntos do projeto), a equipe XP
determina as histórias que serão desenvolvidas.
 Figura 6. Jogo de Planejamento: Release (adaptado de WAKE, 2002).

Wake (2002) ressalta que as histórias dos clientes são quebradas em pequenas
tarefas e, definidos quais os programadores que irão trabalhar em cada tarefa. No
primeiro dia de cada iteração, o time decide quais as histórias que serão trabalhadas. Os
programadores selecionam as tarefas, estimam e aceitam as tarefas que irão programar
a cada dia de trabalho. A Figura 7 mostra como funciona a fase de iteração.
A primeira iteração mostrará como a arquitetura do sistema irá se comportar.
Após a primeira versão de projeto ter sido entregue, a equipe calcula a velocidade do
projeto que corresponderá à quantidade de histórias do cliente implementadas durante a
primeira versão. Se um comprometimento excessivo ocorrer, o conteúdo das versões
será modificado ou as datas de entrega finais são alteradas.

Figura 7. Jogo de Planejamento: Iteração (adaptado de WAKE, 2002).

 O progresso da iteração é monitorado diariamente utilizando-se ferramentas
como o quadro de acompanhamento diário proposto por Teles (2005). O seu principal
objetivo é determinar a velocidade da equipe em uma iteração e a carga de trabalho que
cada história efetivamente consumiu.
Quando não mais existir novas histórias, é o momento de finalizar o projeto. É o
momento de escrever um documento, entre 5 e 10 páginas, sobre a funcionalidade do
sistema, que auxilie no futuro a saber como realizar alguma alteração no sistema. Uma
boa razão para finalizar o projeto é o cliente estar satisfeito com o sistema e não ter
mais nada que consiga prever para o futuro. Toda a equipe que trabalhou no sistema
deve ser reunida para reavaliação (dificuldades e avanços). A Figura 8 resume o ciclo
de vida nos projetos XP.

Figura 8. O ciclo de vida nos projetos XP (WELLS, 2011).

6.2 Projeto
O processo Extreme Programming segue rigorosamente o princípio da simplicidade.
Um projeto simples é sempre preferível em relação a uma representação mais
complexa. Além disso, o projeto fornece diretrizes de implementação para uma história
como ela está escrita – nada mais, nada menos. O projeto de uma funcionalidade que
não esteja marcada para a iteração corrente é desencorajado, pois o desenvolvedor
considera que ela será exigida depois. Desta forma, o prazo final de cada interação será
seriamente respeitado.
O XP encoraja o uso de cartões CRC (Class-Responsibility-Colaborator) como
um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos.
Os cartões CRC (Figura 9) identificam e organizam as classes orientadas a objetos que
são relevantes para o incremento de software atual.
Se em alguma parte do projeto de uma história for detectado um problema de
alta complexidade, o XP recomenda a criação imediata de um protótipo operacional
daquela parte do projeto. Denominado de solução de ponta o protótipo de projeto é
implementado e avaliado. A intenção é diminuir o risco quando a implementação
verdadeira começa e validar as estimativas originais correspondentes à história que
contém o problema proposto.
 Figura 9. Modelo e exemplo de um cartão CRC (adptado de Taylor, 2003).

O XP encoraja a refatoração – uma técnica de construção que é também uma

técnica de projeto. Refatoração, neste caso, é o processo de modificar um sistema de
software de tal modo que ele não altere o comportamento externo do código, mas
aperfeiçoe a estrutura interna. Portanto, é um modo disciplinado de limpar o código.
O projeto utilizando Extreme Programming é visto como um artefato provisório
que pode e deve ser continuamente modificado à medida que a construção prossegue. A
intenção da refatoração é controlar essas modificações sugerindo pequenas alterações
de projeto que podem aperfeiçoar o projeto. Deve-se notar, no entanto, que o esforço
necessário à refatoração pode crescer sensivelmente à medida que o tamanho de uma
aplicação cresce.
Uma noção central do XP é de que o projeto ocorre tanto antes quanto depois
que a codificação começa. Refatoração significa que o projeto ocorre continuamente à
medida que o sistema é construído. De fato, a atividade de construção em si vai
fornecer à equipe do XP diretrizes sobre como aperfeiçoar o projeto.

5.3 Codificação
Na fase de codificação a partir das histórias é desenvolvido o aplicativo executável.
Esta fase é suportada pelas seguintes práticas do XP: programação em par, padrão de
desenvolvimento, refatoração, integração contínua, propriedade coletiva e ritmo
sustentável, descritas a seguir.

5.3.1 Programação em Par

A programação em par é uma das praticas mais polêmicas do XP que sugere que todo
código produzido seja sempre implementado por dois desenvolvedores trabalhando
juntos no mesmo computador (TELES, 2011b).
Na programação em par uma pessoa deve ficar conduzindo (condutor) o teclado
enquanto a outra fica orientando e observando o código (navegador). Desta forma cada
um tem uma visão diferente do sistema em desenvolvimento. Quem digita foca sua
atenção para a linha que esta digitando e nas adjacentes. O navegador, por sua vez, tem
uma visão mais ampla que permite observar o restante do código na tela. Desta forma
cada um dos desenvolvedores tem uma visão complementar com relação à do outro.
Essa visão complementar permite que o navegador atue mais como um estrategista,
olhando para o código como um todo e identificando problemas que passam
despercebidos para quem está mais preocupado com a linha que está sendo digitada
(TELES, 2011b)
Quando um programador desenvolve em par, ele conta com a presença de outro
desenvolvedor que faz uma inspeção imediata de todo o código que é produzido. Desta
forma revisões em pares (também conhecidas como inspeção do código) representam
uma das formas mais eficazes para encontrar defeitos em software, reduzindo
drasticamente custos futuros em correções e manutenção (TELES, 2005).
Em 1971, em um livro chamado The Psychology of Computer Programming,
Gerald Weinberg mostrou que o olho humano tem uma incrível capacidade de só
enxergar aquilo que deseja e, naturalmente, ignorar aquilo que não quer ver. Sendo
assim, os programadores quando sozinhos ignoram erros gritantes que seriam
facilmente identificados por qualquer outra pessoa. Esse princípio é conhecido na
psicologia como dissonância cognitiva, definida como a tendência natural de acreditar
que aquilo que escrevemos está certo (TELES, 2011b).
Quando tentamos resolver algum problema, geralmente adotamos a primeira
solução que encontramos, característica psicológica é conhecida como tunelamento.
Quando encontramos uma solução, é como se entrássemos em um túnel e não
conseguíssemos enxergar mais nada além daquele caminho. O problema é que nem
sempre a primeira solução encontrada é a melhor. Mas quando sozinhos é ela que
tenderemos a escolher (TELES, 2011b). Desta forma dois desenvolvedores trabalhando
juntos geralmente vislumbram mais de uma resposta o que por sua vez culmina em uma
implementação final de melhor qualidade.
Ao explorar mais cenários e escolher soluções mais simples, os desenvolvedores
ajudam a manter o sistema mais simples como um todo. O que ajuda a torná-lo mais
fácil de compreender, manter e modificar ao longo do tempo. Além disso, optar por
soluções mais simples freqüentemente leva a redução no tempo de desenvolvimento das
funcionalidades, o que ajuda a acelerar o progresso da equipe (TELES, 2005).
A programação em par também faz com que os desenvolvedores tenham maior
foco na atividade e por mais tempo, efeito conhecido como pressão do par. Quando em
par os programadores sentem-se intimidados em interromper o trabalho que estão
fazendo, porque se um pára, o outro também acaba sendo prejudicado, sendo assim, o
par torna-se individualmente mais produtivo. A responsabilidade é maior e isso faz com
que o foco também seja, há uma sensação de responsabilidade compartilhada (TELES,
2011b).
Nos projetos XP é defendido que os programadores troquem de par de tempos
em tempos, fazendo que haja um maior compartilhamento de informações, aumentando
assim a capacidade de disseminação de conhecimento ao longo do projeto (TELES,
2011b).
 Desta forma os programadores se tornam aptos a solucionar problemas em
qualquer parte do projeto, aumentando a robustez da equipe. Sendo assim o desfalque
de um desenvolvedor por um motivo qualquer não impede que a equipe siga adiante no
desenvolvimento do projeto. Pode ocorrer uma perda na força de trabalho, mas não
ocorre a situação em que se perde uma pessoa sem a qual o projeto não possa ser
finalizado. Isso é bom para o projeto, mas também é excelente para os desenvolvedores,
que podem tirar férias, visitar médicos ou faltar por qualquer razão que se faça
necessária, com a tranqüilidade de saber que o projeto continuará em execução.
Quando trabalhando em par cada um dos desenvolvedores aprende de forma
rápida e eficiente. Uma prática comum no XP é compor um par formado por um
programador experiente e um menos experiente, de forma que o menos experiente
aprenda com o mais experiente.
Estudos comprovam que a aprendizado é mais eficiente quando existe o
interesse em saber a solução é motivado por necessidades reais. Na programação em
par há um problema real para ser resolvido, há uma contribuição clara para o projeto
caso ele seja resolvido, existe um contexto bem definido no qual aquele problema se
encontra e existe uma pessoa ao seu lado que muitas vezes já conhece a solução. Além
disso, quando uma pessoa sabe que a resolução dele irá contribuir de alguma forma para
outras pessoas costuma se dedicar com mais afinco ao problema. Desta forma, na
programação em par, além da necessidade existe o desejo de contribuir. Além disso,
temos ao nosso lado uma pessoa que talvez saiba resolver o problema e, o que é melhor,
ela pode dialogar conosco e explicar (TELES, 2011b).
Mesmo no caso em que ambos não saibam resolver o problema de imediato,
podem compartilhar idéias, o que geralmente agiliza a descoberta de uma solução
(TELES, 2011b).
Na programação em par a responsabilidade é dividida entre todos os
desenvolvedores do projeto, em especial ao parceiro que ajudou a revisá-lo, diminuindo
o estresse do desenvolvedor (TELES, 2011b).
Segundo Beck (2011c) a programação em par culmina em melhor qualidade de
software sem impactar no tempo de produção. Duas pessoas trabalhando ao mesmo
tempo em um mesmo computador desenvolvem a mesma quantidade de código que
quando trabalhando isoladamente, porém com muito mais qualidade. O aumento de
qualidade resulta em grande economia no futuro.
Aparentemente a programação em par parece desperdício, pois dá a impressão
de que ela irá consumir mais recursos ou irá elevar o tempo do desenvolvimento, mas
na pratica observa-se o contrário (TELES, 2011b). Devido ao conjunto de
características apresentadas anteriormente, a programação em par acelera
significativamente o desenvolvimento do sistema. Em função da redução de erros (e
conseqüente redução no tempo de depuração), pressão do par, maior simplicidade das
soluções, disseminação do conhecimento, maior confiança nas soluções, entre outros
efeitos que a programação em par produz, uma atividade feita em par normalmente é
encerrada mais rapidamente que outra feita por um programador solitário. Existem
inúmeras pesquisas que afirmam que a velocidade de desenvolvimento em par é no
mínimo igual a velocidade de desenvolvimento individual somada. Em problemas
complexos os benefícios da programação em par se mostram ainda mais evidentes.
Segundo Teles (2011b):
“Programação em par não consome mais recursos, não duplica o
número de desenvolvedores necessários ao projeto, nem duplica o
tempo de desenvolvimento. Na verdade, por mais paradoxal e contra-
intuitivo que possa parecer, a programação em par poupa recursos.
Lembre-se, as pessoas erram. Se todos fossem perfeitos, a
programação em par possivelmente só serviria para duplicar
recursos, elevar o tempo e encarecer o projeto. Mas, a questão
fundamental é perceber que as pessoas erram e erram com mais
freqüência do que se imagina. A programação em par ajuda a reduzir
a incidência de problemas e torna os projetos mais produtivos.”
Apesar de seus benefícios, a programação em par pode se revelar problemática.
A presença de programadores com ego excessivamente elevado pode causar competição
entre os membros da equipe. Além disso, fazer par com uma pessoa de ego
excessivamente elevado costuma ser difícil e propenso a conflitos. Sendo assim,
programar em par em ambientes competitivos é pouco viável porque o processo de
ensino e aprendizado fica bloqueado em função da competição (TELES, 2005).

5.3.2 Refatoração
A estrutura dos softwares tende a se degradar medida que novas funcionalidades são
inseridas, modificações são feitas e erros são corrigidos. Desta forma, para evitar que o
código se torne difícil de entender e perca desempenho, deve ser usada uma técnica
conhecida como refatoração. A refatoração consiste na alteração de pequenas partes do
sistema, de forma a torná-la mais simples, eficiente e fácil de ser entendida. Tais
alterações não devem influenciar nas funcionalidades do sistema, devem apenas
melhorar a estrutura do código. Essa prática de forma sistemática e com a maior
freqüência possível (TELES, 2011e).
A refatoração também torna o código mais auto-explicativo, reduzindo a
necessidade de documentação, pratica defendida pelo XP (TELES, 2005).

5.3.3 Integração Contínua

Uma boa prática do XP é que os desenvolvedores integrem seus trechos de código a um
repositório com a maior freqüência possível. Em hipótese alguma deve manter para si o
código por mais de um dia (BECK, 2011, TELES, 2011d). Todos devem trabalhar sobre
a última versão, mudanças não podem ser feitas sobre código obsoleto, pois podem
causar problemas de integração. Desta forma assegura-se que o código se mantenha
atualizado e consistente.
Se a integração contínua não for bem gerenciada pode ocorrer problemas na
integração. Desenvolvedores podem trabalhar com versões desatualizadas, ou até
mesmo trabalhar no mesmo trecho de código ao mesmo tempo. Para evitar esses
problemas, a integração deve ser sincronizada, os desenvolvedores devem integrar seus
códigos em turnos seqüenciais, de forma que o código deve ser integrado somente por
um par de programadores por vez (BECK, 2011; TELES, 2011c).
Deve ser usado um software para gerenciar a integração. Estas ferramentas são
capazes de manter várias versões do sistema a apresentar de forma clara quem efetuou
as atualizações e quando, provendo integração automatizada de forma eficiente e segura
(BECK, 2011).
Muitas versões de código é uma fonte de desperdício e de erros em
desenvolvimento de software. Se existem várias versões do sistema em uso, e um
desenvolvedor faz uma alteração em uma, é necessário que faça em todas as demais
versões. Além de desperdiçar tempo esta prática pode resultar em código inconsistente
em uma das versões, caso o desenvolvedor esqueça-se de atualizá-la (TELES, 2011d).
Sendo assim, se existem várias bases de código, recomenda-se que coloque um
plano em andamento para reduzi-las gradualmente (TELES, 2011d).
Ao invés de criar mais versões do código fonte, os desenvolvedores devem
corrigir o problema de projeto que impede de trabalhar com uma única base de código
(TELES, 2011d).

5.3.4 Propriedade Coletiva

Todos os envolvidos em um projeto XP têm acesso e autorização para editar a qualquer
parte do código em desenvolvimento. Ou seja, a propriedade do código é coletiva e
todos são igualmente responsáveis por todas as partes dele. Isso resulta em aumento de
velocidade de produção, pois os desenvolvedores não precisam esperar a autorização de
um colega para editar um código e há uma maior disseminação de conhecimento. Além
disso, quando várias pessoas olham todo o código as chances de que erros não sejam
corrigidos diminui drasticamente (TELES, 2011f).
Para que esta prática funcione, cada desenvolvedor deve criar os testes unitários
para todas as classes desenvolvidas por ele. Todos os códigos incluídos no repositório
passaram previamente em todos os testes unitários. Desta forma códigos adicionados,
problemas que são corrigidos, mudanças em funcionalidades são cobertas por testes
automáticos (BECK, 2011d).
O princípio de propriedade coletiva encoraja os desenvolvedores a contribuir
com novas idéias em todas as partes do projeto. Qualquer desenvolvedor pode alterar
qualquer linha de código para adicionar uma funcionalidade, corrigir erros, melhorar o
design ou refatorar. Desta forma nenhuma pessoa se torna um “gargalo” para mudanças
(BECK, 2011d).

5.3.5 Ritmo Sustentável

O XP em suas práticas visa à maximização da produtividade. Uma das práticas mais
importantes nesse sentido é a de ritmo sustentável, que defende que desenvolvedores
não façam horas extras e consequentemente trabalhem mais descansados, resultando em
maior produtividade
 Devido a atrasos ocorridos ao longo do desenvolvimento do projeto é comum
que os programadores trabalhem além do horário regular para tentar cumprir o
cronograma estabelecido. Desta forma se desgastam mais e acabam perdendo a
concentração no trabalho que estão fazendo (GONÇALVES, 2008).
A qualidade do código produzido é determinada pela qualidade dos
desenvolvedores e pela capacidade que eles têm de se manter concentrados, atentos e
disposto a solucionar os problemas.
Por esse motivo o XP recomenda que sejam evitadas horas extras, que as
pessoas trabalhem no máximo 40 horas por semana. Esta prática além de melhorar a
velocidade e a qualidade do desenvolvimento demonstra respeito e valorização da
equipe.

5.3.6 Código Padrão

Como em XP todos os programadores podem modificar (refatorar) a qualquer momento
qualquer parte do programa, trocam de pares várias vezes durante o desenvolvimento do
projeto, integram constantemente novos trechos ao código principal e trabalham em
várias partes do sistema é importante que mantenham um padrão de código. Se não for
definido um padrão, as práticas acima citadas se tornam impossíveis de ser realizadas
(BECK, 2011).
Desta forma, todo o código do sistema parece ter sido escrito por um único
programador. O código se mantém consistente e fácil de entender para toda a equipe.
As particularidades do padrão não importam desde que o código pareça familiar a todos
(BONA, 2002).
A adoção de um padrão ajuda a simplificar a comunicação, a programar em par
e a tornar o código coletivo. Da mesma forma, a própria programação em par e a prática
de código coletivo ajudam a assegurar que a equipe irá seguir o padrão adotado.

5.4 Testes
Um dos principais problemas dos sistemas computacionais é sua grande propensão a
falhas, que podem causar desde aborrecimentos até perda de vidas. Levando em
consideração o grande prejuízo causado por estes falhas, os engenheiros de software
vêm buscando meios para minimizar sua incidência através da identificação de erros no
código. Uma das abordagens que tem se mostrado bastante eficiente e muito usada na
maioria dos processos de desenvolvimento de software consiste na aplicação de uma ou
mais fases de teste durante o ciclo de vida do sistema (ENTREGUE, 2011).
Além da Programação em Par o XP se prevê duas abordagem para prover a
diminuição de erros: o teste de unidade (resultante do desenvolvimento dirigido a testes) e o
teste de aceitação. O primeiro tenta assegurar que cada componente do sistema funcione
corretamente. O segundo procura testar a interação entre os componentes, as quais dão
origem às funcionalidades (BECK, 2011).
Os testes de unidade procuram testar cada classe isoladamente. Porém geralmente
as classes de um sistema alcançam seus objetivos com a ajuda de outras. Desta forma, na
construção de um teste de unidade um dos maiores desafios é exatamente isolar a classe
que está sendo testada, para que nenhuma outra classe do sistema seja envolvida no teste
(TELES, 2011a).
Os testes de aceitação (também conhecidos como testes funcionais) são escritos
para assegurar que o sistema como um todo funcione, tratando o sistema inteiro como uma
caixa preta tanto quanto possível. Estes testes são executados pelo cliente ou com a
orientação do cliente, pois ele é a pessoa que conhece o negócio e, portanto, os resultados
que devem ser produzidos pelo sistema.
A maior diferença dos testes no XP com relação aos processos de
desenvolvimento de software tradicionais é a aplicação do desenvolvimento dirigido a
testes apresentado na seção a seguir.

5.4.1 Desenvolvimento Dirigido a Testes

O Desenvolvimento Dirigido a Testes (DDT) é um novo processo de desenvolvimento
que diferencia dos métodos tradicionais por prover a escrita dos testes em código
executável, antes mesmo de escrever um código funcional. (ENTREGUE, 2011).
Segundo Beck (2011) o desenvolvimento orientado a testes consiste em escrever um
mecanismo de teste automatizado antes de codificar cada história e cada método do
sistema.
A aplicação desta abordagem consiste basicamente em desenvolver códigos de
teste embutidos no programa principal antes mesmo de iniciar a implementação das
funcionalidades. Os desenvolvedores devem então implementar as funcionalidades até
que o sistema passe com sucesso em todos os testes.
Para cada funcionalidade deve ser escrito e executado um código de testes que
deve falhar inicialmente, pois a funcionalidade que ele requer ainda não foi
implementada. Em seguida é escrito o código mais simples que faça com que o teste
passe. O teste é mais uma vez executado. Se falhar, significa que o trecho de código
escrito apresenta algum erro funcional e deve ser corrigido até que passe no teste. Após
a aprovação no teste um novo teste deve ser desenvolvido para ampliar as
funcionalidades iniciais ou uma nova funcionalidade deve ser implementada para que o
sistema passe em um outro teste escrito anteriormente (ENTREGUE, 2011).
O DDT pode ser usado em conjunto com os testes de integração, testes de
aceitação do usuário, etc. O DDT é baseado em dois princípios muito importantes,
como apresentado por Kent Beck – o criador destes conceitos:
 Escrever um novo código de negócios se somente um teste automatizado falhar:
Usando este modelo, os requerimentos do negócio/aplicação dirigem os testes e
os testes dirigem os atuais códigos funcionais. Qualquer mudança nos
requerimentos primeiro impactaram os testes (tipicamente algumas pré - e pós
condições) e na seqüência fazer passar o novo teste, o código precisa ser
ajustado. Mas novamente, você não para antes de todos os testes passarem, o
novo código é também um teste unitário e o grau de confiança continua o
mesmo daquele novo código até a correção da função de igualdade. O principio
 acima significa que você não está escrevendo testes para examinar a validade do
código, mas você está escrevendo código para justificar o teste.
 Eliminar duplicação de código: Este princípio impacta na qualidade interna do
código. Um conceito de negócio deve ser implementado uma vez e somente uma
no código da aplicação. Um simples exemplo é um código para a verificação de
disponibilidade de quartos em um hotel que deve ser centralizado para somente
um lugar em todo o código. Eliminando a duplicação de código, o design torna-
se limpo e reutilizável.
Desta forma o DDT é um processo interativo que prove feedbacks não só do
código mais também do design do projeto.
De acordo com Entregue (2011), para que o DTT funcione corretamente as
seguintes condições devem ser obedecidas:

 Um código não deve ser escrito sem um teste.

 Um teste deve ser escrito mesmo que o resto da equipe discorde da necessidade
dele.
 O design interno da aplicação deve ser bem discutido e cada módulo deve ser
testado isoladamente.
 Deve ser usado um framework de teste.

Segundo Benk (2011) a utilização de um framework de testes é fundamental

para a aplicação adequada do desenvolvimento dirigido a testes, pois só é possível
construir com eficiência testes automatizados utilizando essa ferramenta.

Ainda de acordo com Entregue (2011) escrever testes apropriados é um desafio,

e propõe que as seguintes dicas para a fase de produção de testes:

 Os testes devem poder ser executados isoladamente. A ordem dos testes não
deve importar.
 Qualquer duplicação lógica dos testes deve ser eliminada.
 Cada teste deve testar um e somente um negócio. Por exemplo, nunca escreva
um teste para testar a atribuição de um livro e o registro de um membro.
 Todas as pré-condições, pós-condições e exceções devem ser testadas.

Segundo Beck (2011), escrever um teste antes de cada história também representa
uma forma de aprimorar a análise sobre as características dela. Pois a necessidade de
implementar um teste força o desenvolvedor a buscar maiores detalhes sobre o
comportamento da funcionalidade.

Intuitivamente o desenvolvimento orientado a testes aparenta resultar em redução da

velocidade de desenvolvimento, pois, a maioria dos projetos de software que são
produzidos sem o desenvolvimento de testes automáticos atrasam, magine o que
aconteceria se tivessem também que criá-los. A prática, entretanto, revela que a adoção de
testes automatizados acelera o processo de desenvolvimento e o torna mais previsível, além
de gerar um produto de melhor qualidade (TELES, 2005).
 Devido aos prazos de entrega cria-se uma resistência a aplicação dos testes de
unidade automatizados. Porém durante o tempo de vida de um projeto a aplicação de testes
automatizados resulta em ganho de tempo devido a diminuição de tempo gasto na detecção
e correção de erros. Desta forma testes automatizados geralmente recompensam o tempo
gasto com sua construção (BECK, 2011a)

Segundo Beck (2011b) a criação dos testes antes do código funcional facilita a
implementação das funcionalidades. Ainda segundo este autor, o tempo gasto para a criação
de um teste de unidade e da implementação do seu código funcional é o mesmo gasto para
criar o código a partir do zero. Porém, como já se tem o código de testes antes da
implementação da funcionalidade não é necessário fazê-lo depois, resultando em aumento
de velocidade de produção.

Um dos benefícios desta técnica é que o sistema torna-se unitariamente testado.

Desde que o código é unitariamente testado, o grau de confiança em cada módulo
mostrará que a aceitação do usuário é muito alta.

Testes unitários favorecem a prática de propriedade coletiva, pois protege o código

de ser alterado acidentalmente (BECK, 2011a).
Os testes unitários também facilitam a integração contínua, pois, antes de ser
submetido para os demais desenvolvedores, o módulo é testado individualmente. Os testes
automáticos também permitem identificar com maior facilidade os erros de integração, pois
permitem a verificação de todo o código com agilidade (BECK, 2011a).
Os testes unitários também facilitam o refatoramento. Depois de cada pequena
mudança, a unidade pode ser testada para verificar se a mudança na estrutura introduziu
alguma mudança na funcionalidade (BECK, 2011a).

6. Vantagens e Desvantagens
6.1 Vantagens
 XP é ideal em projetos onde o cliente não sabe exatamente o que quer.
 O feedback constante facilita a adaptação do projeto as eventuais mudanças de
requisitos do cliente. Estas alterações nos requisitos são muitas vezes críticas
nas metodologias tradicionais, que não apresentam meios de se adaptar
rapidamente às mudanças.
 Entregas freqüentes de partes funcionais do sistema permitem ao cliente
conhecer e participar com maior intensidade do desenvolvimento do sistema.
Desta forma, o cliente não precisa esperar muito para ver o software
funcionando, como nas metodologias tradicionais.
 A integração e os testes contínuos contribuem, em muito, para a qualidade do
sistema em desenvolvimento.
 As práticas do XP são usadas pelos integrantes da equipe, para facilitar no
desenvolvimento e agregar qualidade no projeto, com isso todos do time devem
estar cientes de cada fase do sistema.
  torna o processo mais ágil e flexível. As práticas do XP são criadas para
funcionarem juntas e fornecer mais valor do que cada uma poderia fornecer
individualmente.
 Análise prévia de tudo que pode acontecer durante o desenvolvimento do
projeto, oferecendo qualidade, confiança, data de entregas e custos promissores.

6.2 Desvantagens
 Eliminação de algumas práticas vinculadas ao desenvolvimento de software -
como a análise do problema por meio de diagramas. O que ele retrata como
importante auxílio no entendimento do problema.
 A informalidade na análise de requisitos pode provocar desconforto aos clientes.
Fazendo com que esses não acreditem fielmente no sucesso do sistema proposto
e se sintam inseguros quanto ao bom funcionamento do sistema.
 Falta da análise e planejamento de riscos – uma vez que riscos acontecem
freqüentemente em projetos de desenvolvimento de software. Deve-se, então,
implementar uma análise e estratégias que buscam diminuir os erros.
 É freqüente acontecer bugs em todos os projetos de desenvolvimento de
software.
 Refatoração do código pode ser vista como irresponsabilidade e incompetência,
pois, não existe uma preocupação formal na utilização do código.
 A falta de documentação é característica do processo XP, pois, o mesmo não dá
muita ênfase em burocracias (documentos, formulários, processos, controles
rígidos, etc.). Sendo, portanto, importante a elaboração de documentos e
diagramas que facilitem no entendimento e identificação do problema.

6.3 Quando o XP não deve ser usado

 A maior barreira para o sucesso de um projeto XP é a cultura empresarial.
Qualquer negócio que gerencie projetos tentando apontar o carro para a direção
certa logo de cara terá conflitos com o time que insiste em ir acertando a direção
continuamente.
 Outra cultura que não contribui para o 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 o 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 o XP não é a solução.
Uma outra barreira tecnológica para o 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.
7. Estudo de Caso
O estudo de caso foi iniciado com a fase de exploração, cujo objetivo foi compreender
o que o sistema precisava fazer a partir das primeiras histórias escritas pelo cliente. Em
paralelo as histórias dos clientes, foram avaliadas as diferentes tecnologias e exploradas
as possibilidades para a arquitetura do sistema.
Durante a fase de planejamento, foi especificado o projeto, as iterações e o dia-
a-dia. Foi elaborada uma estimativa com base nos cartões de história, na metáfora e em
uma solução simples. O objetivo desta fase foi estimar o menor tempo e o maior
número de histórias para a primeira versão.

7.1 Composição e tarefas do time

Todos os contribuintes do projeto sentavam-se juntos como membros de um time. O
time incluiu um especialista de domínio - “o cliente” – que definia os requisitos, fixava
as prioridades e guiava o projeto. O time possuía uma dupla de programadores, os quais
também absorveram a tarefa de ajudar o cliente a definir os testes de aceitação e os
requisitos.
Além destes, existia um gerente que provia recursos, mantinha a comunicação
externa e coordenar as atividades. Nenhum destes papéis foi necessariamente de
propriedade exclusiva de um só indivíduo. Todos os membros do time contribuíram de
todas as formas que puderam, conforme suas capacidades.

7.2 Descrição do sistema

O aplicativo foi construído para calcular a Gratificação de Incentivo a Docência (GID)
e teve como base o regulamento elaborado pelo Comitê de Avaliação Docente do
CEFET/SC. Este regulamento estabelece os critérios e procedimentos de avaliação e
desempenho docente para a implementação da GID.
O sistema mantém uma lista de todos os docentes de carreira de 1º e 2º Graus
que ministram aulas nos cursos regulares do CEFET/SC ou que desempenham outras
atividades previstas no regulamento. Uma lista simples de atividades também é
mantida.
Para efeito de pontuação, os professores são classificados em grupos. Conforme
o grupo, existe um critério para avaliação, ou seja, uma seqüência de procedimentos e
cálculos que o sistema executa. O centro do sistema é o gerenciamento dos pontos
obtidos pelo professor, que é proporcional ao seu desempenho docente. A principal
finalidade do sistema foi gerar informações para os recursos humanos.
Neste momento, identificou-se a necessidade de um diagrama que mostrasse de
forma genérica o fluxo do negócio. Neste sentido, foi escolhido o diagrama de
atividades da UML (Unified Modeling Language) que ilustra o fluxo de atividades,
representado na Figura 10.
 Figura 10. Diagrama de atividades da GID.
7.3 Metáfora
A metáfora foi usada para superar os problemas de conceituação e comunicação inicial
com o cliente. Este em determinado momento, da fase de exploração, comentou:
“Pensei inicialmente em utilizar uma planilha do Excel para realizar os
cálculos.Pois, a entrada dos dados é facilitada e consigo visualizar os critérios de
avaliação e, rapidamente tenho o resultado”.
Então, este comentário passou a ser a metáfora para o sistema da GID. A
principal vantagem da metáfora foi que o time conseguiu, rapidamente, pensar em uma
interface para o usuário. Além disso, o formulário para coletar as informações nas
gerências dos cursos foi exibido em formato tabular (ver Figura 11).
 Figura 11. Planilha para coleta e simulação da GID.

7.4 Histórias do usuário

Todas as histórias de interesse foram anotadas e discutidas pelo time. Inicialmente,
houve uma pequena dificuldade do cliente em elaborar uma história. Entretanto, não
existiu resistência. Partiu-se com as histórias centrais e, posteriormente, foram
adicionados detalhes.
A primeira história, representada pela Figura 12, está em seu formato original.
As demais histórias, representadas pela Figura 13, foram resumidas por Bona (2002).

Figura 12. Cartão de história e tarefas.

 Figura 13. Cartão de história e tarefas resumido.

7.5 Estimativa, priorização e planejamento

Após a coleta das histórias, o cliente as classificou por prioridade: alta, média, baixa.
Em seguida, o time de programação estimou as histórias pontuando em semanas, se
uma história consumisse mais de três semanas o programador retornava a história para
que o cliente a dividisse em histórias menores. Definidas as estimativas e prioridades,
foram designadas as iterações. Decidiu-se por duas iterações (ver Tabela 1).

Tabela 1. Dados dos cartões de história.

Depois da realização das estimativas, as histórias foram divididas em tarefas.

Com o objetivo de maximizar o trabalho, foi elaborada uma lista simplificada de tarefas
para os cartões de história (ver Tabela 2).
Tabela 2. Divisão das histórias em tarefas.

7.6 Teste de aceitação

Para validar cada característica desejada, o cliente realizou os testes de aceitação
manualmente por meio da interface gráfica do usuário (GUI – Graphical User
Interface). Além disso, um teste de simulação da GID foi construído na planilha do
Microsoft Excel, cujo objetivo era mostrar que os resultados esperados estavam
corretamente implementados.

7.7 Desenvolvimento orientado por teste

O time realizou o “desenvolvimento orientado por teste”, trabalhando em ciclos muito
pequenos, onde foram acrescentados os testes. Primeiramente, se escreveu o teste que
especificou e validou o comportamento desejado e, em seguida, foi criado e
desenvolvido o código que o implementou. Desta forma, o time produziu o código com
grande parte dos testes cobertos, o que foi um grande avanço.
A construção dos testes foi iniciada com a definição de “procedures”. O objetivo
do primeiro teste foi examinar a pontuação docente obtida através da fórmula para
calcular à carga horária. O teste seguinte foi modelado para validar os pontos obtidos
através da relação de responsabilidades docentes, conforme o número de alunos.
Um terceiro teste foi elaborado para a avaliação quantitativa das aulas
ministradas, limitando pontos por assiduidade e atribuições didático-pedagógicas. O
último teste realizado para atender a história “001 – Calcular GID”, foi atribuir pontos
pela participação em projetos de pesquisa utilizando a fórmula conforme o grupo do
professor.
Cada teste, inclusive o código, foi desenvolvido de forma incremental, incluindo
um teste de cada vez e fazendo com que ele fosse validado. Esse padrão de
desenvolvimento se repetiu em toda a aplicação. Embora, tenham sido realizados testes
somente para as histórias e tarefas que o time considerou como cruciais para o sistema.

7.8 Entrega da versão para produção

O sistema entrou em produção após a execução de todos os testes de aceitação
realizados pelo cliente. Desta forma, um projeto pequeno e simples foi desenvolvido
com o modelo do XP. Parte da interface pode ser visualizada na Figura 14.

Figura 14. Tela de entrada dos dados mensais da GID.

8. Comparação do XP com modelo cascata e Scrum

Tabela 3. Comparação do XP com modelo cascata.

Ciclo de vida do Desenvolvimento ágil Desenvolvimento Tradicional
um Software XP (Extreme Programming)
Definição dos Obrigatório. Os requisitos são Obrigatório. É gerada uma
requisitos atualizados ao longo do versão que servirá de base para
desenvolvimento. todos os itens a seguir.

Projeto de Opcional. Surge informalmente Obrigatório. E só se dá início

software durante o desenvolvimento do ao término da definição dos
Software. Requisitos.
Desenvolvimento Implementa os incrementos Implementa seqüencialmente
(user stories) levantados junto cada funcionalidade que o
ao cliente. projetista especificou no
projeto.
Teste de sistema É feito um plano de teste antes O teste é feito apenas pela
da implementação que vão equipe de desenvolvimento no
sendo executados final do projeto.
freqüentemente.
Implantação Parte do software vai sendo O software só é entregue ao
implantada até concluir todos os usuário quando estiver
requisitos. totalmente pronto.

Tabela 4. Comparação do XP com Scrum.

Atividade Desenvolvimento ágil Scrum
XP (Extreme Programming)
Definição dos É realizada a partir da escrita Os requisitos conhecidos até o
requisitos das user stories pelos Clientes. momento são listados dando
origem ao Product Backlog.

Atribuição dos Equipe técnica e clientes Definição do Sprint Backlog.

Requisitos as definem as user stories que As Sprints (iterações) duram no
Iterações serão desenvolvidas máximo 30 dias.
nas iterações. As iterações
duram de 1 a 4 semanas.
Projeto da Propõe que paralelamente à Sugere que seja feito um
Arquitetura do escrita das user stories, seja projeto geral do sistema
Sistema realizado o projeto da baseado nos itens do Product
arquitetura do sistema. Backlog.

Desenvolver Implementação das user stories Implementação dos requisitos

Incremento do que fazem parte da iteração contemplados no Sprint
Sistema corrente por Backlog para a Sprint corrente.
duplas de programadores.
Validar Os programadores executam os O Scrum não adota nenhum
Incremento testes de unidade e os clientes processo de validação pré-
executam os definindo.
testes de aceitação.
Entrega Final Ocorre quando o Cliente está Ocorre quando todos os itens no
satisfeito com o sistema. Product Backlog foram
desenvolvidos.

9. Ferramentas
Existem ferramentas de suporte de processos ágeis. Este conjunto é composto por
ferramentas ainda algo limitadas e por ferramentas já bastante desenvolvidas, com um
conjunto de funcionalidades bastante rico (PINTO, 2010). As ferramentas abaixo suportam
o XP:
 VersionOne: é uma ferramenta comercial e especificamente desenvolvida para
auxiliar na gestão de projetos com processos ágeis.
http://www.versionone.com/
 RallyDev: é, também, uma ferramenta comercial que possui uma boa interface e
contém um bom conjunto de relatórios e gráficos. O facto de suportar o RUP, XP e
Scrum (PINTO, 2010) funciona como uma grande vantagem desta ferramenta.
http://www.rallydev.com/
 TargetProcess: Trata-se de uma ferramenta altamente configurável, podendo ser
adaptada de forma a corresponder às necessidades do processo de desenvolvimento
escolhido (PINTO, 2010). A ferramenta é muito completa, contendo várias
funcionalidades. No entanto, possui demasiados menus, nem sempre estruturados da
melhor forma.
http://www.targetprocess.com/
 Xplanner: ferramenta de projeto, planejamento e acompanhamento de equipes que
utilizam o XP. Open Source.
http://www.xplanner.org/

Referências
BECK, Kent. Extreme Programming Explained: Embrace Change. Longman Higher
Education, 2000. Disponível em: <http://books.google.com.br>. Acesso em 08 de
março de 2011.
BECK, K. Unit Tests. Disponível em:
<http://www.extremeprogramming.org/rules/unittests.html>. Acesso em: 10 Mar.
2011a.
BECK, K. Code the Unit Test First. Disponível em:
<http://www.extremeprogramming.org/rules/testfirst.html >. Acesso em: 10 Mar.
2011b.
BECK, K. Pair programming. Disponível em:
<http://www.extremeprogramming.org/rules/pair.html>. Acesso em: 10 Mar. 2011c.
BECK, K. Coletive Ownership. Disponível em:
<http://www.extremeprogramming.org/rules/collective.html>. Acesso em: 10 Mar.
2011d.
BONA, Cristina. Avaliação de Processos de Software: Um estudo de caso em XP e
ICONIX. Florianópolis, 2002. Dissertação (Mestrado em Engenharia de Produção) –
Programa de Pós-Graduação em Engenharia de produção, UFSC, 2002.
ENTREGUE seu código com confiança utilizando desenvolvimento dirigido a testes.
Disponível em: <http://javafree.uol.com.br/artigo/871450/Entregue-seu-codigo-com-
confianca-utilizando-desenvolvimento-dirigido-a-testes.html>. Acesso em 10 Mar.
2011.
GONÇALVES, A. e DIAS, V. P. (2008). Extreme Programming (XP): metodologia
ágil de desenvolvimento de software. In 2ª Jornada Integrada de Cursos CTESOP
(Centro Técnico-Educacional Superior do Oeste Paranaense).
PINTO, M. A. P. Gestão de Projectos com Processos Ágeis. Lisboa, 2010. Dissertação
(Mestrado em Engenharia Informática e de Computadores) – Instituto Superior
Técnico, Universidade Técnica de Lisboa, 2010.
PRESSMAN, Roger. Engenharia de Software. 6ª ed. São Paulo: McGraw-Hill, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. Pearson Addison-Wesley, 2007.
TAYLOR, David A. Engenharia de Negócios com Tecnologia de Objetos. Editora
Axcel: 2003.
TELES, Vinícius Manhães. Um Estudo de Caso da Adoção das Práticas e Valores do
Extreme Programming. Rio de Janeiro : UFRJ/IM, 2005. Dissertação (Mestrado em
Informática).
TELES, V. M. Extreme Programming: Testes com Mock Objects. Disponível em:
<http://www.improveit.com.br/xp/praticas/tdd/mock_objects> Acesso em: 10 Mar.
2011a.
TELES, V. M. Extreme Programming: Programação em Par. Disponível em:
<http://improveit.com.br/xp/praticas/programacao_par > Acesso em: 10 Mar. 2011b.
TELES, V. M. Extreme Programming: Integração Contínua. Disponível em:
<http://www.improveit.com.br/xp/praticas/integracao>. Acesso em: 10 Mar. 2011c.
TELES, V. M. Extreme Programming: Padrão de desenvolvimento. Disponível em:
<http://improveit.com.br/xp/praticas/codigo_unificado> Acesso em: 10 Mar. 2011d.
TELES, V. M. Extreme Programming: Refatoração. Disponível em:
<http://improveit.com.br/xp/praticas/refatoracao>. Acesso em: 10 Mar. 2011e.
TELES, V. M. Extreme Programming: Código Coletivo. Disponível em:
<http://improveit.com.br/xp/praticas/codigo_coletivo>. Acesso em: 10 Mar. 2011f.
VIANA, L. M. e Deschamps, A. (2008). XP – Extreme Programming. Disponível em:
<http://www.apicesoft.com/common/articles/Apice> Acessado em: 24/02/2011.
WAKE, William C. Extreme Programming Explored. Reading, Massachusetts: Ed.
Addison-Wesley, 2002.
WELLS, Don. Disponível em: < http://www.extremeprogramming.org >. Acesso em 08
de março de 2011.