Metodologias geis Extreme Programming e

Scrum para o Desenvolvimento de Software

Michel dos Santos Soares1
1

Universidade Presidente Antnio Carlos, BR 482 Km 3, Gigante, Conselheiro Lafaiete, MG, Brasil
michelssoares@yahoo.com.br

Resumo - Este artigo apresenta algumas vantagens das metodologias geis para desenvolver software em
relao s metodologias tradicionais. Em particular so apresentadas as principais caractersticas e as
prticas das metodologias geis Extreme Programming e Scrum. Tambm so feitas comparaes com as
metodologias tradicionais, procurando enfatizar que as metodologias geis so baseadas em pessoas e no
em processos e planejamentos. Finalmente so apresentadas as principais vantagens e desvantagens da
Extreme Programming e da Scrum. Tambm so apresentados alguns resultados empricos do uso de
metodologias geis.
Palavras-chave: Engenharia de Software, Metodologias geis, Extreme Programming, Scrum
Abstract This paper shows some advantages of agile methodologies for software development comparing
with traditional ones. In particular Extreme Programming and Scrum are presented with its characteristics
and practices. Also are done comparisons with traditional methodologies, emphasizing that agile
methodologies are based on people instead of process and planning. Finally the principal advantages and
disadvantages of the use of Extreme Programming and Scrum are presented. Also some empirical results of
the use of agile methodologies are presented.
Key-words: Software Engineering, Agile Methodologies, Extreme Programming, Scrum

Introduo
As
metodologias
geis
para
desenvolvimento de software so uma resposta
s chamadas metodologias pesadas ou
tradicionais. Mesmo com a evoluo dos
computadores, das tcnicas e ferramentas nos
ltimos anos, a produo de software confivel,
correto e entregue dentro dos prazos e custos
estipulados ainda muito difcil. Dados de 1995
[1], usando como base 8380 projetos, mostram
que apenas 16,2% dos projetos foram entregues
respeitando os prazos e os custos e com todas as
funcionalidades especificadas. Aproximadamente
31% dos projetos foram cancelados antes de
estarem completos e 52,7% foram entregues,
porm com prazos maiores, custos maiores ou
com menos funcionalidades do que especificado
no incio do projeto. Dentre os projetos que no
foram finalizados de acordo com os prazos e
custos especificados, a mdia de atrasos foi de
222%, e a mdia de custo foi de 189% a mais do
que o previsto. Considerando todos os projetos
que foram entregues alm do prazo e com custo
maior,
na
mdia,
apenas
61%
das
funcionalidades originais foram includas. Mesmo
os projetos cuja entrega feita respeitando os
limites de prazo e custo possuem qualidade
suspeita, uma vez que provavelmente foram
feitos
com
muita
presso
sobre
os

desenvolvedores, o que pode quadruplicar o

nmero de erros de software, segundo a mesma
pesquisa. As principais razes destas falhas
estavam relacionadas com o processo em
Cascata. A recomendao final foi que o
desenvolvimento de software deveria ser baseado
em modelos incrementais, o que poderia evitar
muitas das falhas reportadas.
Processos orientados a documentao
para o desenvolvimento de software, como o
modelo em Cascata, so de certa forma fatores
limitadores aos desenvolvedores. Alm disso,
muitas organizaes no possuem recursos ou
inclinao para processos pesados de produo
de software. Por esta razo, muitas organizaes,
particularmente as pequenas, acabam por no
usar nenhum processo, o que pode levar a efeitos
desastrosos em termos de qualidade de software.
Torna-se necessrio, ento, utilizar metodologias
geis, que no so orientadas documentao
nem tampouco se preocupam apenas com a
codificao.
A maioria das metodologias geis nada
possuem de novo [2]. O que as diferencia das
metodologias tradicionais so o enfoque e os
valores. A idia das metodologias geis o
enfoque nas pessoas e no em processos ou
algoritmos. Alm disso, existe a preocupao de
gastar menos tempo com documentao e mais
com a implementao. Uma caracterstica das

metodologias geis que elas so adaptativas ao

invs de serem preditivas. Com isso, elas se
adaptam a novos fatores decorrentes do
desenvolvimento do projeto, ao invs de procurar
analisar previamente tudo o que pode acontecer
no decorrer do desenvolvimento.
Apesar
do
uso
crescente
das
metodologias geis, ainda falta uma base maior
de projetos para verificar suas vantagens. Mesmo
assim, os resultados iniciais em termos de
qualidade, confiana, datas de entrega e custo
so promissores.
Para ser realmente considerada gil a
metodologia deve aceitar a mudana ao invs de
tentar prever o futuro. O problema no a
mudana em si, mesmo porque ela ocorrer de
qualquer forma. O problema como receber,
avaliar e responder s mudanas.
Enquanto as metodologias geis variam
em termos de prticas e nfases, elas
compartilham algumas caractersticas, como
desenvolvimento
iterativo
e
incremental,
comunicao
e
reduo
de
produtos
intermedirios, como documentao extensiva.
Desta forma existem maiores possibilidades de
atender aos requisitos do cliente, que muitas
vezes so mutveis.
Dentre as vrias metodologias geis
existentes, as mais conhecidas so a Extreme
Programming [3] e a Scrum [4].

que identificaram os problemas gerados ao se

adotar esta viso seqencial de tarefas. Por
exemplo, Fred Brooks em seu famoso artigo No
Silver Bullet: Essence and Accidents of
Software Engineering, descreve que a idia de
especificar totalmente um software antes do incio
de sua implementao impossvel [7]. Outro
pesquisador, Tom Gilb, desencoraja o uso do
modelo em Cascata para grandes softwares,
estimulando o desenvolvimento incremental como
um modelo que apresenta menores riscos e
maiores possibilidades de sucesso [8].
As metodologias pesadas devem ser
aplicadas apenas em situaes em que os
requisitos do software so estveis e requisitos
futuros so previsveis. Estas situaes so
difceis de serem atingidas, uma vez que os
requisitos para o desenvolvimento de um software
so mutveis. Dentre os fatores responsveis por
alteraes nos requisitos esto a dinmica das
organizaes, as alteraes nas leis e as
mudanas pedidas pelos stakeholders, que
geralmente tm dificuldades em definir o escopo
do futuro software.

Metodologia
Um exemplo de uma metodologia
tradicional ou pesada o modelo em Cascata [5],
que composto basicamente por atividades
seqenciais de levantamento de requisitos,
anlise,
projeto,
implementao,
teste,
implantao e manuteno. Este modelo
derivado de outras engenharias tradicionais (Civil,
Eltrica, Naval,...) e foi o primeiro a ser usado
pela Engenharia de Software, na dcada de 70.
O termo Engenharia de Software surgiu em
uma conferncia no final da dcada de 60 [6]. A
proposta inicial era a sistematizao do
desenvolvimento de software, que deveria ser
tratado com engenharia e no como arte. Desta
forma, a idia foi propor a utilizao de mtodos,
ferramentas e tcnicas para a produo de
software confivel, correto e entregue respeitando
os prazos e custos definidos. Apesar de toda
evoluo desde que o termo foi criado, o nmero
de fracassos em projetos de software ainda
alto.
O modelo em Cascata dominou a forma de
desenvolvimento de software at o incio da
dcada de 90, apesar das advertncias dos
pesquisadores da rea e dos desenvolvedores,

Figura 1 - custo de mudana no projeto no

modelo em cascata
O grfico da Figura 1 apresenta o custo de
alterar requisitos de software em vrias fases do
desenvolvimento ao se usar o modelo em
Cascata. Pelo grfico fica claro que o custo de
alteraes no modelo em Cascata cresce de
forma exponencial de acordo com as fases do
projeto. Desta forma, estima-se que caso alguma
alterao tenha como custo 1x quando feita na
fase de requisitos, ela ter um custo de 60x a
100x quando feita na fase de implantao [5].
Portanto, alteraes nos requisitos no modelo em
Cascata no so desejveis.

Extreme Programming
A Extreme Programming (XP) uma
metodologia gil para equipes pequenas e
mdias que desenvolvem software baseado em
requisitos vagos e que se modificam rapidamente
[3]. Dentre as principais diferenas da XP em
relao s outras metodologias esto:

Figura 2 custo de mudanas no projeto

com metodologias geis
Como alteraes em requisitos so
comuns, a curva ideal deveria ser a da Figura 2,
em que o custo no cresce muito mesmo quando
alteraes so feitas em fases avanadas do
desenvolvimento. O grfico da Figura 2 apresenta
o custo de mudanas nas metodologias geis. Na
verdade, as metodologias geis incentivam a
mudana nos requisitos, pois desta forma
possvel realmente entregar ao cliente o produto
que ele precisa.
O termo metodologias geis tornou-se
popular em 2001 quando dezessete especialistas
em processos de desenvolvimento de software
representando os mtodos Extreme Programming
(XP), Scrum, DSDM, Crystal e outros,
estabeleceram princpios comuns compartilhados
por todos esses mtodos. O resultado foi a
criao da Aliana gil e o estabelecimento do
Manifesto gil (Agile Manifesto) [9]. Os
conceitos chave do Manifesto gil so:
Indivduos e interaes ao invs
processos e ferramentas.
Software executvel ao invs
documentao.
Colaborao do cliente ao invs
negociao de contratos.
Respostas rpidas a mudanas
invs de seguir planos.

de
de
de
ao

O Manifesto gil no rejeita os processos

e ferramentas, a documentao, a negociao de
contratos ou o planejamento, mas simplesmente
mostra que eles tm importncia secundria
quando comparado com os indivduos e
interaes, com o software estar executvel, com
a colaborao do cliente e as respostas rpidas a
mudanas e alteraes. Esses conceitos
aproximam-se melhor com a forma que pequenas
companhias de Tecnologia da Informao
trabalham e respondem a mudanas. Entre as
metodologias geis a mais conhecida a
Extreme Programming.

Feedback constante
Abordagem incremental
A comunicao entre as pessoas
encorajada.

O primeiro projeto a usar XP foi o C3, da

Chrysler. Aps anos de fracasso utilizando
metodologias tradicionais, com o uso da XP o
projeto ficou pronto em pouco mais de um ano
[10].
A maioria das regras da XP causa
polmica primeira vista e muitas no fazem
sentido se aplicadas isoladamente. a sinergia
de seu conjunto que sustenta o sucesso de XP,
encabeando uma verdadeira revoluo no
desenvolvimento de software.
A XP enfatiza o desenvolvimento rpido
do projeto e visa garantir a satisfao do cliente,
alm de favorecer o cumprimento das
estimativas. As regras, prticas e valores da XP
proporcionam um agradvel ambiente de
desenvolvimento de software para os seus
seguidores, que so conduzidos por quatro
valores: comunicao, simplicidade, feedback e
coragem [3].
A finalidade do princpio de comunicao
manter o melhor relacionamento possvel entre
clientes e desenvolvedores, preferindo conversas
pessoais a outros meios de comunicao. A
comunicao entre os desenvolvedores e o
gerente do projeto tambm encorajada.
A simplicidade visa permitir a criao de
cdigo simples que no deve possuir funes
desnecessrias. Por cdigo simples entende-se
implementar o software com o menor nmero
possvel de classes e mtodos. Outra idia
importante
da
simplicidade

procurar
implementar apenas requisitos atuais, evitando-se
adicionar funcionalidades que podem ser
importantes no futuro. A aposta da XP que
melhor fazer algo simples hoje e pagar um pouco
mais
amanh
para
fazer
modificaes
necessrias do que implementar algo complicado
hoje que talvez no venha a ser usado, sempre
considerando que requisitos so mutveis.
A prtica do feedback constante significa
que o programador ter informaes constantes
do cdigo e do cliente. A informao do cdigo
dada pelos testes constantes, que indicam os
erros tanto individuais quanto do software
integrado. Em relao ao cliente, o feedback
constante significa que ele ter freqentemente

uma parte do software totalmente funcional para

avaliar. O cliente ento constantemente sugere
novas caractersticas e informaes aos
desenvolvedores. Eventuais erros e no
conformidades so rapidamente identificados e
corrigidos nas prximas verses. Desta forma, a
tendncia que o produto final esteja de acordo
com as expectativas reais do cliente.
necessrio coragem para implantar os
trs valores anteriores. Por exemplo, no so
todas as pessoas que possuem facilidade de
comunicao e tm bom relacionamento. A
coragem tambm d suporte simplicidade, pois
assim que a oportunidade de simplificar o
software

percebida,
a
equipe
pode
experimentar. Alm disso, preciso coragem
para obter feedback constante do cliente.
A XP baseia-se nas 12 prticas [3] a
seguir:

Planejamento: consiste em decidir o que

necessrio ser feito e o que pode ser
adiado no projeto. A XP baseia-se em
requisitos atuais para desenvolvimento de
software, no em requisitos futuros. Alm
disso, a XP procura evitar os problemas
de relacionamento entre a rea de
negcios (clientes) e a rea de
desenvolvimento. As duas reas devem
cooperar para o sucesso do projeto, e
cada uma deve focar em partes
especficas do projeto. Desta forma,
enquanto a rea de negcios deve decidir
sobre o escopo, a composio das
verses e as datas de entrega, os
desenvolvedores devem decidir sobre as
estimativas de prazo, o processo de
desenvolvimento
e
o
cronograma
detalhado para que o software seja
entregue nas datas especificadas.
Entregas freqentes: visa construo
de um software simples, e conforme os
requisitos surgem, h a atualizao do
software. Cada verso entregue deve ter
o menor tamanho possvel, contendo os
requisitos de maior valor para o negcio.
Idealmente devem ser entregues verses
a cada ms, ou no mximo a cada dois
meses, aumentando a possibilidade de
feedback rpido do cliente. Isto evita
surpresas caso o software seja entregue
aps muito tempo, melhora as avaliaes
e o feedback do cliente, aumentando a
probabilidade do software final estar de
acordo com os requisitos do cliente.
Metfora: so as descries de um
software sem a utilizao de termos
tcnicos, com o intuito de guiar o
desenvolvimento do software.
Projeto simples: o programa desenvolvido
pelo mtodo XP deve ser o mais simples

possvel e satisfazer os requisitos atuais,

sem a preocupao de requisitos futuros.
Eventuais requisitos futuros devem ser
adicionados assim que eles realmente
existirem. Esta forma de raciocnio se
ope ao implemente para hoje e projete
para amanh.
Testes: a XP focaliza a validao do
projeto durante todo o processo de
desenvolvimento. Os programadores
desenvolvem
o
software
criando
primeiramente os testes.
Refatorao: focaliza o aperfeioamento
do projeto do software e est presente
em
todo
o
desenvolvimento.
A
refatorao deve ser feita apenas quando
necessrio, ou seja, quando um
desenvolvedor da dupla, ou os dois,
percebe que possvel simplificar o
mdulo atual sem perder nenhuma
funcionalidade.
Programao em pares: a implementao
do cdigo feita em dupla, ou seja, dois
desenvolvedores trabalham em um nico
computador. O desenvolvedor que est
com o controle do teclado e do mouse
implementa o cdigo, enquanto o outro
observa continuamente o trabalho que
est sendo feito, procurando identificar
erros sintticos e semnticos e pensando
estrategicamente em como melhorar o
cdigo que est sendo implementado.
Esses papis podem e devem ser
alterados continuamente. Uma grande
vantagem da programao em dupla a
possibilidade
dos
desenvolvedores
estarem continuamente aprendendo um
com o outro.
Propriedade coletiva: o cdigo do projeto
pertence a todos os membros da equipe.
Isto significa que qualquer pessoa que
percebe que pode adicionar valor a um
cdigo, mesmo que ele prprio no o
tenha desenvolvido, pode faz-lo, desde
que faa a bateria de testes necessria.
Isto possvel porque na XP todos so
responsveis pelo software inteiro. Uma
grande vantagem desta prtica que,
caso um membro da equipe deixe o
projeto antes do fim, a equipe consegue
continuar o projeto com poucas
dificuldades, pois todos conhecem todas
as partes do software, mesmo que no
seja de forma detalhada.
Integrao contnua: interagir e construir
o sistema de software vrias vezes por
dia, mantendo os programadores em
sintonia, alm de possibilitar processos
rpidos. Integrar apenas um conjunto de
modificaes de cada vez uma prtica
que funciona bem porque fica bvio quem

deve fazer as correes quando os testes

falham: a ltima equipe que integrou
cdigo novo ao software. Esta prtica
facilitada com o uso de apenas uma
mquina de integrao, que deve ter livre
acesso a todos os membros da equipe.
40 horas de trabalho semanal: a XP
assume que no se deve fazer horas
extras constantemente. Caso seja
necessrio trabalhar mais de 40 horas
pela segunda semana consecutiva, existe
um problema srio no projeto que deve
ser resolvido no com aumento de horas
trabalhadas,
mas
com
melhor
planejamento, por exemplo. Esta prtica
procura ratificar o foco nas pessoas e no
em processos e planejamentos. Caso
seja necessrio, os planos devem ser
alterados, ao invs de sobrecarregar as
pessoas.
Cliente presente: fundamental a
participao do cliente durante todo o
desenvolvimento do projeto. O cliente
deve estar sempre disponvel para sanar
todas as dvidas de requisitos, evitando
atrasos e at mesmo construes
erradas. Uma idia interessante manter
o cliente como parte integrante da equipe
de desenvolvimento.
Cdigo
padro:
padronizao
na
arquitetura do cdigo, para que este
possa ser compartilhado entre todos os
programadores.

Scrum
Outra metodologia gil que apresenta
uma comunidade grande de usurios a Scrum
[4]. Seu objetivo fornecer um processo
conveniente para projeto e desenvolvimento
orientado a objeto. A Scrum apresenta uma
abordagem emprica que aplica algumas idias
da teoria de controle de processos industriais
para
o
desenvolvimento
de
softwares,
reintroduzindo as idias de flexibilidade,
adaptabilidade e produtividade. O foco da
metodologia encontrar uma forma de trabalho
dos membros da equipe para produzir o software
de forma flexvel e em um ambiente em constante
mudana.
A idia principal da Scrum que o
desenvolvimento de softwares envolve muitas
variveis tcnicas e do ambiente, como
requisitos, recursos e tecnologia, que podem
mudar durante o processo. Isto torna o processo
de desenvolvimento imprevisvel e complexo,
requerendo flexibilidade para acompanhar as
mudanas. O resultado do processo deve ser um
software que realmente til para o cliente [11].
A metodologia baseada em princpios
semelhantes aos da XP: equipes pequenas,

requisitos pouco estveis ou desconhecidos e

iteraes curtas para promover visibilidade para o
desenvolvimento. No entanto, as dimenses em
Scrum diferem de XP.
A Scrum divide o desenvolvimento em
iteraes (sprints) de trinta dias. Equipes
pequenas, de at dez pessoas, so formadas por
projetistas, programadores, engenheiros e
gerentes de qualidade. Estas equipes trabalham
em cima de funcionalidades (os requisitos, em
outras palavras) definidas no incio de cada sprint.
A equipe responsvel pelo desenvolvimento
desta funcionalidade.
Na
Scrum
existem
reunies
de
acompanhamento dirias. Nessas reunies, que
so preferencialmente de curta durao
(aproximadamente
quinze
minutos),
so
discutidos pontos como o que foi feito desde a
ltima reunio e o que precisa ser feito at a
prxima. As dificuldades encontradas e os fatores
de impedimento (bottlenecks) so identificados e
resolvidos.
O ciclo de vida da Scrum baseado em
trs fases principais, divididas em sub-fases:
1. Pr-planejamento (Pre-game phase): os
requisitos
so
descritos
em
um
documento
chamado
backlog.
Posteriormente eles so priorizados e so
feitas estimativas de esforo para o
desenvolvimento de cada requisito. O
planejamento inclui tambm, entre outras
atividades, a definio da equipe de
desenvolvimento, as ferramentas a serem
usadas, os possveis riscos do projeto e
as
necessidades
de
treinamento.
Finalmente proposta uma arquitetura de
desenvolvimento. Eventuais alteraes
nos requisitos descritos no backlog so
identificadas, assim como seus possveis
riscos.
2. Desenvolvimento (game phase): as
muitas variveis tcnicas e do ambiente
identificadas previamente so observadas
e controladas durante o desenvolvimento.
Ao invs de considerar essas variveis
apenas no incio do projeto, como no
caso das metodologias tradicionais, na
Scrum o controle feito continuamente, o
que aumenta a flexibilidade para
acompanhar as mudanas. Nesta fase o
software desenvolvido em ciclos
(sprints) em que novas funcionalidades
so adicionadas. Cada um desses ciclos
desenvolvido de forma tradicional, ou
seja, primeiramente faz-se a anlise, em
seguida o projeto, implementao e
testes. Cada um desses ciclos
planejado para durar de uma semana a
um ms.
3. Ps-planejamento (post-game phase):
aps a fase de desenvolvimento so

feitas reunies para analisar o progresso

do projeto e demonstrar o software atual
para os clientes. Nesta fase so feitas as
etapas de integrao, testes finais e
documentao.
Ferramentas de apoio
Por serem metodologias relativamente
novas, existem poucas ferramentas disponveis
que
suportem
o
processo
gil
de
desenvolvimento. Dentre as existentes, a maioria
suporta apenas a Extreme Programming e ainda
esto em fase de pesquisa e desenvolvimento. A
mais conhecida a XPlanner [12], que uma
ferramenta de cdigo livre usada para auxiliar o
planejamento da Extreme Programming. O
desenvolvimento desta ferramenta ainda est em
progresso, mas j existe uma verso estvel para
o gerenciamento de estrias do usurio,
gerenciamento de tarefas, verificao de
progresso do projeto e gerenciamento das
mtricas individuais e da equipe. Atualmente
existe suporte para vrios idiomas, dentre eles o
francs, o espanhol, o chins, o italiano, o alemo
e o portugus. Dentre as funcionalidades futuras
da ferramenta esto a integrao com outras
metodologias geis, em especial a Scrum.
Resultados
As metodologias geis ainda esto em
sua infncia, mas j apresentam resultados
efetivos. Por exemplo, um artigo [13] comparando
mtodos geis com as metodologias tradicionais
pesadas mostrou que os projetos usando os
mtodos geis obtiveram melhores resultados em
termos de cumprimento de prazos, de custos e
padres de qualidade. Alm disso, o mesmo
estudo mostra que o tamanho dos projetos e das
equipes que utilizam as metodologias geis tm
crescido. Apesar de serem propostas idealmente
para serem utilizadas por equipes pequenas e
mdias
(at
12
desenvolvedores),
aproximadamente 15% dos projetos que usam
metodologias geis esto sendo desenvolvidos
por equipes de 21 a 50 pessoas, e 10% dos
projetos so desenvolvidos por equipes com mais
de 50 pessoas, considerando um universo de 200
empresas usado no estudo.
Em relao qualidade do software, de
acordo com [14] e [15] o uso correto da XP pode
levar a organizao a atingir os nveis CMM [16] 2
e 3, apesar do CMM ser orientado a metodologias
tradicionais e ter como foco o qu fazer,
enquanto a XP enfoca o como fazer. Juntos
estes mtodos formam um framework para
estruturar o desenvolvimento de software de uma
organizao. Na Boeing a XP foi usada antes de
serem implementadas as idias de CMM.
Verificou-se que no foram necessrias muitas

alteraes nos processos para que a Boeing

fosse certificada com o nvel 5 da CMM [17].
A XP ideal para ser usada em projetos
em que os stakeholders no sabem exatamente o
que desejam e podem mudar muito de opinio
durante o desenvolvimento do projeto. Com
feedback
constante,

possvel
adaptar
rapidamente eventuais mudanas nos requisitos.
Um outro ponto positivo so as entregas
constantes de partes operacionais do software.
Desta forma, o cliente no precisa esperar muito
para ver o software funcionando, como nas
metodologias tradicionais.
A integrao e o teste contnuos tambm
possibilitam a melhora na qualidade do software.
No mais necessrio existir uma fase de
integrao de mdulos, uma vez que eles so
continuamente integrados e eventuais problemas
so resolvidos constantemente.
A XP apresenta algumas desvantagens e
problemas identificados, e tem recebido algumas
crticas. Muitos acreditam que a XP a volta ao
processo catico de desenvolvimento de
software, conhecido tambm como codificaremenda [5]. Este modelo catico existe
principalmente
em
pequenas
e
mdias
organizaes que no podem suportar os altos
custos de desenvolvimento ao se usar
metodologias tradicionais.
A XP possui a tendncia de eliminar
vrias boas prticas que existiram durante vrios
anos do desenvolvimento de software. Por
exemplo, a anlise do problema por meio de
diagramas. Obviamente no se deve projetar
vrios diagramas, muitos dos quais nunca sero
consultados. Mas importante projetar alguns
modelos que ajudaro no entendimento do
problema.
A anlise de requisitos parece ser muito
informal, e em alguns casos dificilmente
funcionaria assim. A informalidade na captura de
requisitos pode no ser bem vista pelos clientes,
que podem se sentir inseguros. Outra
possibilidade de insegurana a refatorao de
cdigo, que pode ser vista pelos clientes como
amadorismo e incompetncia.
Na XP no existe a preocupao formal
em fazer a anlise e o planejamento de riscos.
Como riscos acontecem normalmente em
projetos de desenvolvimento de software, este
um ponto negativo da XP. Deve-se, portanto,
procurar implementar uma estratgia de gesto
de riscos sem tornar a metodologia muito
complexa.
De forma geral, as 12 prticas da XP
apiam-se mutuamente. Portanto, deve-se
procurar aplic-las totalmente, ou a maior parte
possvel. Por exemplo, no usar a programao
em dupla pode atrapalhar a prtica do cdigo ser
de propriedade coletiva. Apesar disso, elas
podem ser de certa forma adaptadas realidade
das organizaes. A implantao de todas as

prticas pode ser confusa, levando ao abandono

prematuro da XP. Segundo Beck [3], as prticas
da XP podem ser implantadas uma a uma para
que sejam evitadas confuses, desentendimentos
e presses, pois a equipe sobre presso tem a
tendncia de voltar a aplicar as prticas
anteriores.
Em relao metodologia Scrum,
existem vrios casos de sucesso relatados [18].
Segundo Schwaber e Beedle [4], a Scrum
deve ser usada em equipes de at 10 pessoas.
Em projetos que precisam de equipes maiores,
deve-se dividir as pessoas em equipes de at 10
pessoas. Isto necessrio para melhorar a
comunicao entre as pessoas da equipe.
Discusso e Concluses
As Metodologias geis tm sido bem
aceitas pela indstria de software e por
pesquisadores da Engenharia de Software.
Apesar de no haver ainda uma grande base de
comparaes os primeiros resultados tm sido
satisfatrios.
De certa forma, apesar da XP ser uma
metodologia nova e ser considerada por muitos
como uma revoluo, ela no apresenta muitos
pontos revolucionrios. Na verdade, a XP agrupa
uma srie de prticas que tm sido usadas desde
o incio da computao eletrnica, como a
programao em duplas e a propriedade coletiva
do cdigo.
possvel fazer uma analogia do futuro
das metodologias geis com as metodologias
para desenvolvimento de software orientadas a
objeto. Da mesma forma que vrias metodologias
de desenvolvimento orientadas a objeto surgiram
e competiram entre si, surgiram tambm vrias
metodologias geis. No caso da orientao a
objetos houve um esforo de padronizao que
resultou na notao UML [19], que atualmente
um padro na indstria de software mundial. Da
mesma forma, futuramente possvel que as
vrias
metodologias
geis
unam-se,
principalmente em torno da XP, por ser a mais
aceita. Existe, por exemplo, um movimento para o
uso conjunto da XP com a Scrum. A XP seria
usada para a fase de desenvolvimento e a Scrum
para o planejamento e gerenciamento do projeto.
A integrao das duas metodologias seria
relativamente simples, uma vez que elas
compartilham algumas caractersticas, como a
necessidade da presena do cliente, pequenas
liberaes e o encorajamento em fazer as
mudanas necessrias para atender requisitos
reais dos stakeholders. Existe inclusive a
proposta da metodologia hbrida XP@Scrum [20].
Apesar de no existirem estudos empricos
suficientes, alguns autores recomendam o uso
em conjunto da Scrum e da XP para grandes
projetos [20].

Atualmente o autor est coordenando um

projeto de pesquisa em que a XP usada para o
desenvolvimento de softwares baseados em
Web. Como a Web um ambiente de
desenvolvimento dinmico e com mudanas
constantes,
as
metodologias
tradicionais
orientadas a documentao so menos
adequadas que as metodologias geis. Uma idia
a ser implantada futuramente neste projeto de
pesquisa a integrao da XP com outras
metodologias geis, como a Scrum. Neste caso
os aspectos de gerenciamento de projetos da
Scrum sero integrados com as prticas da XP.
O desafio futuro das Metodologias geis
encontrar meios de eliminar alguns de seus
pontos fracos, como a falta de anlise de riscos,
sem torn-las metodologias pesadas. Outro
desafio como usar essas metodologias em
grandes empresas e equipes, uma vez que
normalmente essas metodologias so baseadas
em equipes pequenas. Neste caso, pelo menos
necessrio
resolver
os
problemas
de
comunicao internos na equipe, uma vez que
comum em grandes empresas os funcionrios
estarem separados geograficamente. Apesar do
interesse nas metodologias geis, ainda faltam
casos de sucesso de seu uso em projetos
grandes e crticos.
Referncias
1.

Standish Group, CHAOS report,

586 Olde Kings Highway, Dennis,
MA 02638, USA, (1995)

2. Cockburn, A. e Highsmith, J. "Agile

Software Development: The Business of
Innovation", IEEE Computer, Sept.,
(2001), pp. 120-122
3. Beck,
K.,
Programao
Extrema
Explicada , Bookman, (1999)
4. Schwaber, K. e Beedle, M. "Agile
Software Development with SCRUM",
Prentice-Hall, (2002)
5. Pressman, R. Engenharia de Software
McGraw-Hill, (2001)
6. Naur, P. e Randell, B. Software
Engineering: Report on a Conference
sponsored by the NATO science
committee. 7-11 October, Garmisch,
Germany, (1968)
7. Brooks, F., No Silver Bullet: Essence

and
Accidents
of
Software
Engineering Proc. IFIP, IEEE CS
Press, 1987, pp. 1069-1076; reprinted
in IEEE Computer, Apr, (1987), pp.
10-19
8. Gilb,
T.,
Principles
of
Engineering
Management,
Wesley, (1988)

Software
Addison-

9. Agile Manifesto, http://agilemanifesto.org/,

acessado em 25 de Setembro de 2004
10. Highsmith, J. Orr, K. Cockburn, A.
"Extreme Programming", E-Business
Application Delivery, Feb., (2000), pp. 417
11. Schwaber, K. "Scrum Development
Process", OOPSLA'95 Workshop on
Business
Object
Design
and
Implementation. Springer-Verlag. (1995)
12. XPlanner,http://www.xplanner.org/,
acessado em 24 de Setembro de 2004
13. Charette, R. Fair Fight? Agile Versus
Heavy Methodologies Cutter Consortium
E-project Management Advisory Service,
2, 13, (2001)
14. Paulk, M. C. Extreme Programming from
a CMM perspective, IEEE Software, vol.
18, n. 6, (2001), pp 19-26
15. Glazer, H. Dispelling the process myth:
having a process does not mean
sacrificing agility or creativity, Crosstalk
(2001)
16. The
Capability
Maturity
Model:
Guidelines for Improving the Software
Process, Addison-Wesley, (1995)
17. Abrhamsson, P., Salo, O., Ronkainen, J.,
Agile software development methods review and analysis, VTT (2002)
18. Rising, L. e Janof, N.S. "The Scrum
software development process for small
teams". IEEE Software 17(4): (2002), pp.
26-32
19. Booch, G., Jacobson, I., Rumbaugh, J.
UML - Guia do Usurio. Campus, So
Paulo, 476p, (2000)
20. XP@Scrum,
http://controlchaos.com/about/xp.php
acessado em 24 de Setembro de 2004