1

ndice
Prefcio por Miguel, Paulo e Francisco...................................................................................................................2
1.

INTRODUO...............................................................................................................................................3

2.

HISTRICO....................................................................................................................................................4

3.

METODOLOGIAS GEIS............................................................................................................................4
3.1 SCRUM..........................................................................................................................................................5

4.

CASO DE SUCESSO......................................................................................................................................6

5.

RUP e XP - Uma viso geral...........................................................................................................................9

5.1 APLICAO DE RUP NO PTROJECTO BASEADO EM SCRUM...........................................................9
5.2 COMPARATIVO ENTRE RUP E XP E SUAS APLICAES.............................................................10
5.3 VANTAGENS E DESVANTAGENS PARA O CASO EM ESTUDO.........................................................12
5.4

6.

NECESSIDADE OU NO DE ADAPTAO DA METODOLOGIA..............................................12

CONSIDERAES FINAIS........................................................................................................................14

BIBIOGRAFIA......................................................................................................................................................15

Prefcio por Miguel, Paulo e Francisco

As equipas de desenvolvimento de software precisam conhecer o bsico
do Scrum. Como criar e estimar um product backlog1? Como transform-lo
num sprint backlog2? Como gerir um grfico burndown e calcular a
velocidade da sua equipa?
Uma boa execuo do Scrum est se tornando mais importante para as
equipas que buscam investimento de fundos externos. Um mentor gil
para um grupo de capital de risco, ajuda a investirem em empresas que
executam as prticas geis com eficincia. As oportunidades futuras de
investimento iro exigir que as equipas de desenvolvimento saibam a sua
velocidade de produo.
Por que isso to importante?
Se as equipas no conhecem a sua prpria velocidade, o product owner3
no pode criar um guia do produto com as datas de entregas com
credibilidade. E sem as datas de entrega interdependentes, a empresa
poder falhar e os investidores podero perder o seu dinheiro!
Esse problema enfrentado por companhias grandes e pequenas, novas
ou antigas, com investimento prprio ou externo.
O desenvolvimento iterativo fundamental no manifesto gil entrega-se
o software funcionando cedo e com frequncia. Depois de anos de
retrospetivas com centenas de equipas de Scrum, por exemplo, a Nokia
desenvolveu alguns requisitos bsicos para o desenvolvimento iterativo:

As iteraes devem ter um tempo fixo com menos de seis semanas

de durao.
Ao final da iterao, o cdigo deve ser testado pela equipa de
qualidade e funcionar corretamente.
Uma equipa de Scrum deve ter um product owner e saber quem ele
.
O product owner deve ter um product backlog com estimativas
criadas pela equipa.
A equipa deve ter um grfico burndown e saber a sua velocidade.
No deve haver nenhuma interferncia externa sobre a equipa
durante um sprint.

Se se seguir as boas prticas, teremos um product backlog, estimativas

para o product backlog, um grfico burndown, e saberemos a velocidade
da nossa equipa, alm de outras prticas fundamentais para um Scrum
1 O Product Backlog uma lista contendo todas as funcionalidades desejadas para um produto.
2 O Sprint Backlog uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint.
3 O Product Owner a pessoa que define os itens que compem o Product Backlog e os prioriza nas
Sprint Planning Meetings.

altamente funcional. Com isso tudo, podemos ser o futuro do

desenvolvimento de software e os criadores da prxima gerao de
produtos lderes de mercado.

1.

INTRODUO
O que se busca na Engenharia de Software o incessante
melhoramento do processo de desenvolvimento de software. Os
prazos e custos estipulados podem no chegar a serem alcanados,
mesmo com a crescente evoluo da tecnologia, metodologias e
recursos. Um dos principais motivos a excessiva formalidade nos
modelos de processos colocados nos ltimos anos. Existe ento a
necessidade de desenvolver software de forma mais rpida, sem
que se perca a qualidade. O novo paradigma em desenvolvimento
d e software que se pode obter esse resultado por meio da
utilizao de metodologias geis.
Embora as metodologias geis tenham sido apontadas como
alternativa s metodologias clssicas para o desenvolvimento de
software, as metodologias clssicas, conhecidas tambm como
rigorosas, pesadas ou orientadas a planeamentos, possuem utilizao
garantida no que diz respeito a situaes em que os requisitos do
sistema so complexos e estveis e requisitos futuros so previsveis.
Este artigo aborda vantagens e desvantagens de metodologias
geis e de metodologias clssicas, pa rticu la rme nte , d a
metodologia g i l SCRUM alm de citar um caso de sucesso da
metodologia gil SCRUM na AG2 uma empresa sediada no Brasil. Na
Seo 2, apresentado o histrico do processo de desenvolvimento
de software, desde o uso restrito das metodologias tradicionais at a
criao do Manifesto gil. Na Seo 3, so apresentados conceitos
bsicos sobre as metodologias geis, alm das suas aplicaes,
focando-se mais na metodologia SCRUM fazendo um descritivo da sua
aplicabilidade na concepo de um projeto de desenvolvimento de
software. Na Seo 4, apresentado um caso de sucesso
relacionados a metodologia SCRUM. Na Seco 5, abordamos um
comparativo entre o mtodo RUP e o XP e, por fim, na seco 6 as
consideraes finais.

2.

HISTRICO
Baseadas em mainframes e terminais burros, as metodologias
tradicionais fizeram parte, inicialmente, d e um contexto de
desenvolvimento d e software muito diferente do atual. O custo
para que modificaes fossem feitas era alto, devido s limitaes
dos computadores e falta de ferramentas modernas para apoiar a
criao do software, tais como depuradores e analisadores de cdigo.
Sendo assim, o software era antes planejado e documentado para
ento ser implementado. O modelo clssico caracterizado como
metodologia tradicional utilizado at hoje.
Nos ltimos anos, novas metodologias foram aplicadas, sempre
visando a rapidez no fornecimento aliada qualidade do processo e
do produto. Surgem, ento, as metodologias geis, popularizados
quando Becket et al criaram o Manifesto gil indicando alguns
princpios compartilhados por tais metodologias:
a)Indivduos e interaes so mais importantes que os processos e
ferramentas;
b)S o ft wa re funcionando mais importante do que a documentao
detalhada;
c)Colaborao dos clientes mais importante do que a negociao de
contratos;
d) Ada pt a o s mudanas mais importante do que seguir um
plano.
Nesta nova abordagem a reutilizao de software uma prtica
comum durante o desenvolvimento. Os padres de projeto
contribuem para o reuso em situaes em que preciso um nvel
alto de abstrao, sobretudo na fase de anlise, na definio da
arquitetura do sistema, em questes organizacionais e de otimizao
dos processos, sendo que esses dois ltimos tm por objetivo apoiar
a construo do software e melhorar o seu desenvolvimento. O uso
de componentes outro especto possvel. Deste modo, a integrao
dos padres organizacionais e de processo proporciona rapidez e
qualidade no desenvolvimento.

3.

METODOLOGIAS GEIS
Como foi apresentado no segundo captulo, o termo Metodologias
geis se tornou popular quando dezassete especialistas em
processos de desenvolvimento de software, estabeleceram conceitos
comuns a serem compartilhados por todos essas metodologias. Foi

ento criada por BECK et al. a Aliana gil e instaurado o Manifesto

gil.
O objetivo do Manifesto gil no desconsiderar processos,
ferramentas,
documentao,
negociao
de
contratos
ou
planeamento, mas mostrar o valor secundrio que estes possuem
diante dos indivduos e interaes, do bom funcionamento do
software, da colaborao do cliente e das respostas velozes s
modificaes. Esses conceitos esto mais relacionados forma que
as pequenas e mdias empresas trabalham, de vi d o a estarem
habituadas a mudanas. A mais conhecida dentre as metodologias
geis a Extreme Programming.

3.1 SCRUM
O SCRUM uma metodologia gil de trabalho onde usada para
estabelecer conjuntos de regras e prticas de gesto para conseguir o
sucesso de um projeto. Com o foco no trabalho em equipa, ocorre uma
melhora na comunicao e maximiza o apoio de todos, fazendo com
que todos do time se esforcem e se sintam bem com que esto
fazendo e isso acaba gerando mais para frente um aumento de
produtividade.
Jeff Sutherland colocou em prtica a primeira concepo do SCRUM na
Easel Corporation em 1993 e em 1995, Ken Schwaber pegou essa
metodologia e refinou baseando-se com sua experincia em
desenvolvimento de sistemas e processos.
As principais caractersticas do SCRUM so:

um processo gil para gerenciar e controlar o desenvolvimento

de projetos;
um invlucro para outras prticas de engenharia de software;
um processo que controla o caos resultante de necessidades e
interesses conflituantes;
uma forma de aumentar a comunicao e maximizar a
cooperao;
uma forma de detetar e remover qualquer impedimento que
atrapalhe o desenvolvimento de um produto;
escalvel desde projetos pequenos at grandes projetos em
toda empresa.

O modo de organizao no SCRUM feito da seguinte forma (Figura 1):

Cria-se o backlog onde tem a lista de todas as funcionalidades que
precisam ser desenvolvidas durante todo o projeto, junto com o
stakeholder, onde precisa ser bem definido e detalhado no comeo,
listado e ordenado por prioridade do que mais importante;

Com o backlog pronto, cria-se o sprint backlog, onde se decide o

tempo necessrio (dentro dos 30 dias) para criar a funcionalidade
requisitada;
Depois de todo o planeamento, os itens do backlog so divididos nas
equipas e entra no sprint que pode durar de 2 a 4 semanas.
A cada 24 horas tem uma reunio com os membros de equipas e
questes devem ser respondias como:
- O que fizeste desde a ltima reunio?
- O que te impede de continuar?
- O que vais fazer at a prxima reunio?
Ao trmino do sprint as funcionalidades requisitadas so
demonstradas.

Figura 1 - Descrio do processo scrum.

O SCRUM, como um mtodo gil, e as metodologias geis acabam
tendo varias semelhanas, contatos ou pontos em comum, ele tem um
forte relacionamento com o XP como por exemplo, eles tem a raiz
fundamentada em um manifesto gil.

4.

CASO DE SUCESSO
A AG2 uma agncia digital com mais de 70 pessoas envolvidas em
desenvolvimento. Recentemente ele resolveram adotar o Scrum. As
suas linhas de servios proporcionam um ciclo de atendimento
completo, tendo capacidade de resposta s necessidades de toda a
cadeia de valor do negcio. A AG2 suporta os seus clientes na

definio de opes estratgicas e tecnolgicas, desenvolve sistemas

web sob medida para as mais diversas aplicaes, bem como aes de
comunicao interativa, provendo ainda toda a gesto operacional da
presena digital. Com mais de 150 colaboradores nas suas bases de
So Paulo, Porto Alegre e Pelotas, a AG2 atende empresas como
Embraer, Bradesco, General Motors, Grupo Silvio Santos, Bunge, C&A e
Vulcabras.
A AG2 conta com aproximadamente 30 colaboradores envolvidos
diretamente no desenvolvimento de sistemas, como codificadores
HTML, analistas de sistemas, DBAs, desenvolvedores. Net e analistas
de testes e 40 nas disciplinas relacionadas a arquitetura de informao
e interface, como analistas e projetistas de interface, diretores de arte,
web designers, programadores Flash, alm de profissionais de anlise
de negcios, criao e gesto de projetos.
Comearam a estudar Scrum pelo facto de ser mais uma metodologia
de desenvolvimento de projetos, inicialmente mais em tom
investigativo e para conhecer os conceitos do que efetivamente
objetivando alterar as suas metodologias. Durante o estudo notou-se
que vrios aspetos dela poderiam se encaixar muito bem no que
fazem, agregando muito com relao a agilidade e velocidade de
desenvolvimento que ela proporciona. Devido principalmente aos
prazos sempre apertados que tm para desenvolver e o teor de alguns
projetos comearam a fazer alguns testes em alguns projetos.
Visando a necessidade da melhoria na gesto dos projetos resolveu-se
aplicar Scrum num projeto e analisar o desempenho de produtividade
do projeto com o emprego desta metodologia.
O projeto na qual foi desenvolvido era para a plataforma de hadrware
Windows XP profissional, a ferramenta de desenvolvimento era o
Microsoft Visual Studio 2008, a ferramenta de banco de dados SQL
Server 2005, a ferramenta de anlise e projeto o Enterprise Architect,
ferramenta de acompanhamento de bugs JIRA, sedo o mesmo
produzido para a plataforma desktop. O projeto possua 221 pontos de
caso de uso tcnicos e era enquadrado na modalidade de Fbrica de
Soluo, na qual so projetos em que a equipa do projeto trabalha com
a equipa do cliente desde a etapa inicial de avaliao de necessidades
e concepo de requisitos, ajudando o cliente a gerar uma soluo de
alto valor agregado para seu negcio.
Aplicar Scrum traz vrias mudanas, principalmente culturais na
empresa. Para o incio da utilizao do Scrum, como primeiro passo
aplicou-se um treinamento para todos os colaboradores para que todos
pudessem conhecer as atividades a serem desempenhadas na nova
metodologia de gerncia de projeto e assim nivelar o conhecimento
adquirido.

No treinamento foram repassados os conhecimentos a cerca do ciclo

do Scrum e mostrado em detalhes cada evento a ser executado com o
emprego da metodologia gil, assim como as vantagens e facilidades
proporcionadas pelo Scrum.
O segundo passo foi realizar o planeamento inicial do projeto. Cada
Sprint teve sua durao definida em trs semanas, assim a cada
rodada tinha que ser entregue uma parte incremental do produto
testado e funcionando. No total, foram definidas cinco Sprints para a
concluso do projeto.
A princpio, foram definidas as seguintes atividades a serem realizados
no projeto e estas foram enquadradas no Backlog:

Levantamento dos requisitos.

Especificao dos requisitos.
Anlise e Projeto.
Especificao de testes.
Reviso tcnica.
Implementao.
Testes.
Correo.
Entrega.

Em seguida, o plano do projecto foi montado e apresentado ao cliente.

O cliente foi envolvido inicialmente com participao ativa de forma
remota para a definio das prioridades das atividades. Para cada
Sprint realizou-se um Sprint Planning Meeting, ou seja, uma reunio
para planeamento da Sprint, de modo que pudesse definir dentre as
atividades do Backlog aqueles que seriam executadas na Sprint. Alm
disso, a cada incio do dia o gerente do projeto realizava a Daily
Meeting, ou seja, a reunio diria para acompanhamento das
atividades do projeto (atividades a fazer, atividades finalizadas,
atividades em andamento), assim como para a identificao dos
impedimentos ocorridos no dia anterior para que fossem resolvidos o
mais rpido possvel. Estas reunies tinham durao de no mximo 15
minutos.
O prximo passo foi executar cada Sprint. A cada entrega, ou seja,
decorridos trs semanas, o time realizou a reunio de reviso (Sprint
Review) para apresentao do produto realizado na Sprint. Aps esta
reunio fazia-se uma reunio de retrospetiva (Sprint Retrospective)
para demonstrar as lies aprendidas. Nestas reunies, foi possvel
identificar os principais desafios enfrentados pela equipa. Alm disso,
ao final de cada Sprint, o gerente realizou as medies dos indicadores
de desempenho de produtividade do projeto.

10

As equipas que montaram tinham em mdia 9 integrantes. Para cada

equipa optou-se por colocar diferentes disciplinas de desenvolvimento,
de forma que uma equipa tenha capacidade de desenvolver qualquer
tipo de demanda e seja auto-gerencivel. Ou seja, tinham
desenvolvedores. Net junto com Diretores de Arte, sentados lado a
lado em locais fsicos especficos para a equipa. Com relao a
sintonia fina das equipas, outra coisa que fizeram na montagem das
equipas foi agrup-las por cliente. Isso faz com que a cultura de cada
um dos clientes seja absorvida de forma mais visceral pela equipa,
resultando em projetos bem mais aderentes aos objetivos das suas
contratantes.
Os resultados forma satisfatrios obteve-se uma satisfao por todos
os integrantes do projeto na aplicabilidade do Scrum. O projeto foi
entregue dentro do prazo e do oramento melhor do que os previstos.
Constatou-se uma maior participao do cliente no processo de
desenvolvimento do software proporcionando um acompanhamento
em alto nvel do andamento das atividades realizadas. Alm disso,
observou-se a satisfao do cliente na solicitao das modificaes
dentro de prazo hbil para realiz-las, alm do recebimento de
funcionalidades totalmente implementadas no final das Sprints. Um
fator caracterstico do Scrum que apresentou-se satisfatrio para o
cliente trata-se do tempo fixo estimado para as Sprints.
A equipa evoluiu profissionalmente se tornando mais segura com
relao capacidade de estimativa e auto gerenciamento,
descartando a necessidade de atribuio de tarefas pelo gerente. Esse
crescimento foi gradativo no decorrer das Sprints.
Aumentou tambm a segurana no que estava desenvolvendo e no
conhecimento dos requisitos. Isto proporcionou um menor retrabalho
por no desperdiar tempo no desenvolvimento de requisito confuso. O
aumento da segurana aumentou o comprometimento e o foco com o
projeto. Alm do mais, a equipa, depois de experimentar o Scrum, quer
sempre que possvel, seguir esta prtica nos novos projetos.
O gerente apontou a facilidade em solucionar os impedimentos do
projeto, haja vista que os mesmos eram identificados precocemente e
no apresentava impactos nas demais atividades. Todos os integrantes
tinham conhecimento do impedimento e atravs de uma ao em
conjunto o impedimento era solucionado o mais rpido possvel. Alm
disso, o gerente relatou a facilidade de extrair informaes gerenciais
do projeto atravs dos quadros adotados pela metodologia gil. Isto
permite aos participantes do Scrum saber exatamente o que est
acontecendo e fazer no local os ajustes para manter o projeto na
direo dos objetivos desejados.

5.

RUP e XP - Uma viso geral

11

Atualmente nas empresas necessrio que se tenha algum nvel de

processo, visando como objetivo a qualidade no desenvolvimento de
software. Os processos Rational Unified Process (RUP) e eXtreme
Programming (XP) so ferramentas muito conhecidas e utilizadas na
comunidade de desenvolvimento de software atual.
O Rational Unified Process um framework j difundido e utilizado no
mercado nacional e internacional de desenvolvimento, que pode ser
adaptado a vrios tipos de projetos. Podem ser derivados do RUP
processos para todos os tamanhos de projetos, pois este framework
define uma vasta lista de papis, mecanismos, atividades e fluxos.
Contudo, o Rational Unified Process muito complexo por conter uma
srie de atividades, papis e mecanismos e costuma ser visto como
um processo pesado e burocrtico, e identificar que elementos devem
ser usados em cada projeto uma tarefa difcil.
Em contrapartida, o eXtreme Programming aparece como uma
alternativa mais leve para equipas de tamanho pequeno e mdio
porte, que desenvolvem software em um contexto de requisitos vagos
e rapidamente modificados. O eXtreme Programming enfatiza a
codificao e os testes de cdigos, e tambm considera uma presena
constante dos clientes no desenvolvimento. Pela caracterstica de
simplicidade que esta tcnica apresenta, poucos mecanismos, papis e
atividades so definidos. O eXtreme Programming tem obtido
reconhecimento atravs de sucessos alcanados por pequenos
projetos em contextos de grandes mudanas de requisitos. Entretanto,
a leveza deste mtodo e o foco em cdigo tornam outros aspetos
importantes de um projeto, como a gesto de requisitos e a construo
da arquitetura, que so pouco enfatizados.

5.1 APLICAO DE RUP NO PTROJECTO BASEADO EM

SCRUM
Como soluo alternativa poderamos adotar o Rational Unified
Process, personalizando para as necessidades especficas. Tambm
pode-se implantar um programa para prover treinamento e servir
como guia para equipas do projeto. Durante o processo, os instrutores
ensinaro equipa de desenvolvimento os primeiros passos para usar
a nova metodologia. Depois que os membros das equipas adquirirem
experincia com um ou dois projetos com a ajuda dos instrutores, eles
j se tornam preparados para desenvolver sem acompanhamento.
Sendo assim o RUP dever ser personalizado de acordo com as
necessidades especficas, usamos a metodologia RUP com gestores de

12

projetos, times de servio e experts para personaliz-la e adequ-la s

necessidades da empresa.
Para lidar com os riscos de projeto deve ser criada uma ferramenta
para o mapeamento de caso de uso para os riscos. Dirigindo-se a
riscos precocemente no ciclo de vida do desenvolvimento, e dando
prioridade aos casos do uso baseados no retorno no investimento, as
equipas do desenvolvimento devero estabelecer uma arquitetura
estvel, dando mais prioridade entrega das funcionalidades crticas.
Com isso, a empresa passa a identificar e enderear os riscos de
projeto com mais rapidez no processo de desenvolvimento e as
equipas passaram a entregar as solues a tempo e atingir os padres
de qualidade.
Mostramos um diagrama de fluxo para o planeamento e gesto com
RUP do projeto implementado com SCRUM pela AG2.

5.2 COMPARATIVO ENTRE RUP E XP E SUAS

APLICAES
As metodologias RUP e XP tm o seu funcionamento baseado em
iteraes, so orientadas ao cliente e baseadas em papel. Uma
anlise superficial nos diria que tratam a dinmica de
desenvolvimento de software da mesma forma. Porm atravs da
anlise dos tpicos descritos pelo presente captulo as diferenas
sero verificadas por aspetos como a forma e frequncia que os
mecanismos so gerados, quantidade de papis, etc.

13

O ciclo de vida de um projeto eXtreme Programming uma das

abordagens ainda muito discutidas por grupos que adotam esta
metodologia. O ciclo de vida eXtreme Programming bastante curto
e, primeira vista, difere dos padres dos modelos de processos
convencionais. No entanto, esta abordagem pode fazer sentido em
um ambiente onde as mudanas de requisitos do sistema so fatores
dominantes.
O ciclo de vida da XP est basicamente dividido em quatro fases,
planeamento, testes, codificao e projeto. Na fase de
planeamento, os requisitos do cliente so cuidadosamente coletados
medida que so fornecidos. A seguir, os testes so elaborados a
partir das especificaes do cliente, e a fase de codificao
realizada visando atender esses testes. E, por fim, o sistema
novamente projetado (ou reconstrudo) medida que novas
funcionalidades so incorporadas.
O ciclo de vida do RUP apresenta-se dividido em duas dimenses, as
quais refletem as duas vises em que um sistema pode ser descrito:
componentes dinmicos, que representam o tempo e mostram os
aspetos dinmicos, como ciclos, fases, iteraes e marcos, e
componentes estticos, que representam os aspetos estticos,
como: trabalhadores, atividades, mecanismos e fluxos.
O RUP iterativo e incremental, cada fase dividida em iteraes

Inception

Preliminary

iteration

Elaboration

Construction

Architect.

Architect.

Devel..

Devel..

iteration

iteration

iteration

iteration

Devel..
iteration

Concepo (define o escopo do projeto)

Elaborao (detalha os requisitos e a arquitetura)
Construo (desenvolve o sistema)
Transio (implanta o sistema)

Transition

Transition

Transition

iteration

iteration

14

5.3 VANTAGENS E DESVANTAGENS PARA O CASO EM

ESTUDO
VANTAGENS:

1. Motivao Os programadores se sentem muito mais motivados

devido ao seu interesse de entregar o Sprint no prazo.
2. O projeto pode ser visualizado Dentro da organizao o projeto
pode ser observado por todos. Em outras metodologias esta
possibilidade no existia.
3. Ausncia significante de bugs Como a qualidade mais
importante do que o prazo de entrega, o produto apresenta uma
diminuio significativa de erros.
4. Alterar as prioridades Os programadores podem manejar as
prioridades sem problemas, garantindo assim que sprints que
ainda no foram finalizados possam ser alterados sem
problemas.
DESVANTAGENS:
1. Prazo Como a qualidade mais importante do que o
pode ser que os prazos no sejam estipulados
coerente, levando a um atraso do resultado final, o
deixar os clientes com uma certa raiva, mas isso
ajustado em equipa.

resultado,
de forma
que pode
pode ser

2. Desordem nas funes a presena de papis indefinidos nas

funes presentes no projeto podem dar alguns problemas
relacionados a comunicao interna e deixar os programadores
confusos quanto as suas tarefas.
3. Ausncia de documentao A falta de documentaes sobre o
andamento do projeto pode ser um grande problema. Por isso
importante documentar os aspetos que sejam verdadeiramente
importantes, mas no deixar de lado a documentao de tudo o
que est acontecendo. Porque depois pode ficar difcil voltar num
determinado instante do projeto e lidar com a situao de no
ter aquele momento documentado.

5.4 NECESSIDADE OU NO DE ADAPTAO DA

METODOLOGIA

15

Muito se fala sobre a adaptao de metodologias geis em ambientes

corporativos com o objetivo de agilizar e simplificar processos
existentes no ambiente organizacional de trabalho. Porm, antes de
adaptar necessrio refletir sobre alguns problemas que certamente
sero enfrentados durante esse processo. As metodologias clssicas
esto focadas em seguir o plano inicial, construir uma documentao
detalhada, dar mais valor a ferramentas e processos, bem como
negociao de contratos. Por outro lado, os mtodos geis buscam a
adaptao rpida a mudanas, colaborao com o cliente, alm de
dar mais valor a indivduos e interaes, bem como ao progresso do
produto ou servio sendo desenvolvido.
Diante desse cenrio conflituoso, os mtodos geis enfrentam
diversas barreiras para penetrar em ambientes culturalmente
clssicas. Talvez seja esse o maior desafio, a mudana cultural. Em
outras palavras, preciso conhecer bem o ambiente que dever
sofrer as mudanas e saber claramente quais so os objetivos dessa
transformao. A mudana exige desaprender valores, premissas e
comportamentos antigos antes que se possa aprender os novos. Os
elementos mais importantes dessa mudana cultural so: apoio
executivo e treinamento. Eis aqui outro grande problema enfrentado
pelos mtodos geis durante sua implantao. difcil obter o apoio
das altas instncias da organizao, porm fundamental. Os
executivos devem liderar a transformao pela mudana de seus
prprios comportamentos e assim inspirar os demais colaboradores.
A gesto das equipas, tema de grande estudo nos dias de hoje,
tambm visto como outra imensa barreira. o trabalho mais rduo
e complexo de se realizar nesse processo. de conhecimento geral
que as pessoas representam uma grande fonte de problemas. Diante
desse cenrio, deve figurar o papel do lder agregador e conciliador
que motiva e inspira seus liderados a formar equipes homogneas e
com um objetivo comum bem definido.
Interagir com outros departamentos da organizao outra tarefa
complicada. Por isso, a mudana cultural da organizao apoiada pela
alta cpula fundamental. Criar uma linguagem e atitudes comuns
que sejam compreendidas por todos facilita as interaes entre
indivduos de naturezas diferentes. Isso ajuda a criar um clima de
harmonia e cooperao em prol de um objetivo comum traado no
planeamento estratgico da empresa.
Outro ponto fundamental a interao com clientes, pois so eles
quem mantm a empresa viva! No a empresa que define o
mercado. o cliente. (Peter Drucker). Os clientes devem participar
ativamente do processo de construo de produtos, servios ou
resultados, fornecendo feedback constante. Assim como no
relacionamento com os funcionrios internos, a relao deve ser de
cooperao no sentido de produzir os resultados desejados. Evitar

16

conflitos e buscar solues conjuntas so pontos relevantes dessa

relao.
vlido ressaltar que esses so os principais, no nicos, problemas
enfrentados pelos mtodos geis durante sua implantao. Sendo
assim, cabe queles que pretendem aplicar esses mtodos no seu
ambiente de trabalho estarem preparados para as diversas situaes
conflituosas que iro surgir durante esse processo transitrio e ser
persistente e determinado.

6.

CONSIDERAES FINAIS
O objetivo deste trabalho no apontar um mtodo nem mostrar que
um anula o outro, visto que suas caractersticas devem ser adotadas
em situaes de desenvolvimento diversas. importante para o
desenvolvedor conhecer o que h de melhor nos dois mundos e suas
limitaes a fim de que a adoo de um mtodo possa atender suas
expectativas de gerenciamento, custo e prazo.
Para que surja interesse nas grandes organizaes pela abordagem
dos mtodos geis muitas respostas ainda devem ser obtidas como
por exemplo: como gerir o risco, como viabilizar a comunicao em
locais dispersos, como garantir a certificao, dentre outras. Todo
novo paradigma exige um tempo de maturao, em que os pioneiros
acreditam na ideia e quebram barreiras no intuito de adquirir a
confiana do mercado.

17

BIBIOGRAFIA
BECK, K. et al. Manifesto for Agile Software Development. 2001.
Disponvel em: http://www.agilemanifesto.org/ Acesso em: 7/06/15.
KRUCHTEN, Philippe. The Rational Unified
Introdution. Massachusetts, Addison Wesley, 2000.

Process

An

MAGALHES, A.P.F. RUXP: Integrando o RUP e o XP em uma

metodologia para o desenvolvimento de software. Monografia
de Especializao. 2003.
SOARES, M. S. Metodologias geis Extreme Programming e
Scrum para o Desenvolvimento de Software. Revista Eletrnica
de Sistemas de Informao, 2004.
SOARES, Michel dos Santos. Comparao entre Metodologias
geis e Tradicionais para o Desenvolvimento de Software.
Revista Eletrnica de Sistemas de Informao,2009.
SOMMERVILLE, I. Engenharia de Software. Editora Addison-Wesley.
2003.
XP.
Extreme
Programming.Disponvel
em:
http://www.extremeprogramming.org/ Acesso em: 07/06/15.