Universidade Estadual de Campinas UNICAMP

Faculdade de Tecnologia FT

Mtodos geis

Paula L.O. Libardi,

Vladimir Barbosa

LIMEIRA - SP
JUNHO/2010
Universidade Estadual de Campinas UNICAMP
Faculdade de Tecnologia - FT

Mtodos geis

Autores: Paula L O Libardi,

Vladimir Barbosa
Orientador: Prof. Dr. Marcos A Francisco
Borges

Trabalho apresentado a Faculdade de Tecnologia

FT, como requisito para a concluso da disciplina
FT-027 Tpicos em Computao no curso de ps
graduao.

LIMEIRA - SP
2010
AGRADECIMENTO

Agradecemos ao Professor Dr. Marcos Augusto Francisco Borges, pelo

compartilhamento de informaes e experincias profissionais que muito contribuiram
para o aprimoramento dos conhecimentos sobre o tema.

i
Think you know where you are on your well-formed plan
and discover that you are very wrong, very much later.
Ken Schwaber

ii
RESUMO

Este trabalho apresenta um estudo sobre metodologias geis de

desenvolvimento. um breve estudo das metodologias geis em geral e uma
especificao detalhada dos papeis, regras e prticas da metodologia Scrum e da
linguagem XP. Alm disso, apresenta uma comparao dos processos propostos pelos
mtodos ageis XP, SCRUM, FDD e ASD

iii
ABSTRACT

This work presents a study about software agile methodology. Its a brief study
of general agile methodology and a detailed specification of roles, practices and rules
of Scrum methodology and the XP language. Also, this document presents a
comparison of the processes proposed by the agile methods XP, SCRUM, FDD and
ASD

iv
LISTA DE FIGURAS

Figura 1 Sprint..........................................................................................................7
Figura 2 Ciclo Scrum............................................................................................... 8
Figura 3 Scrum of Scrums...................................................................................... 10
Figura 4 Desenvolvimento Incremental ... ............................................................ 18

v
LISTA DE TABELAS

TABELA 1 Exemplo de Product Backlog................................................................ 11

TABELA 2 Exemplo de Sprint Backlog .................................................................. 12

vi
LISTA DE SIGLAS

PO Product Owner
XP Extreme Programming

vii
SUMRIO

1. INTRODUO......................................................................................................... 1

2. METODOLOGIA GIL DE DESENVOLVIMENTO ......................................... 2

2.1 Histria ..................................................................................................................... 3
2.2 Analisando o Manifesto gil .................................................................................... 4

3. SCRUM ...................................................................................................................... 5
3.1 Sprint Ciclo de desenvolvimento Scrum .................................................... 5
3.2 Papeis Scrum ................................................................................................. 8
3.2.1 Scrum Master.................................................................................. 8
3.2.2 Scrum Team ................................................................................... 9
3.2.3 Product Owner (PO) .................................................................... 10
3.3 Artefatos ...................................................................................................... 11
3.3.1 Product Backlog ........................................................................... 11
3.3.2 Sprint Baclkog .............................................................................. 12
3.3.3 Burn Down Chart ......................................................................... 13
3.4 Cerimnias .................................................................................................. 14
3.4.1 Sprint Planning Meeting .............................................................. 14
3.4.2 Daily Scrum Meeting ................................................................... 14
3.4.3 Sprint Review Meeting ................................................................. 15
3.4.4 Sprint Retrospective Meeting ....................................................... 16

4. COMPARAO ENTRE OS MTODOS GEIS ........................... ................ 17

4.1 Extreme Programming XP ....................................................................... 17
4.2 Critrios Utilizados ......................................................................................18
4.3 Anlise Comparativa ....................................................................................18

viii
5. CONCLUSO ........................................................................................................ 20

6. REFERNCIAS BIBLIOGRFICAS.................................................................. 20

ANEXO 1 ..................................................................................................................... 21
ANEXO 2 ..................................................................................................................... 22

ix
1. INTRODUO

A indstria de desenvolvimento de software tem se tornado uma das mais

importantes indstrias do nosso tempo. Empregando milhares de trabalhadores em todos
os pases do mundo, essa indstria cria alguns dos produtos mais essenciais que ns
[1]
utilizamos para manter o nosso estilo de vida .

Utilizado para o controle de produo, controle da segurana dos veculos que

ns dirigimos, automao dos nossos negcios e em muitas outras reas de nossas vidas,
o software tem se tornado um dos maiores valores de propriedade intelectual do mundo.

Na intensa competitividade no ambiente de desenvolvimento de software, o que

separar os melhores dos piores, os vencedores dos perdedores? Esta resposta simples:
a sua habilidade de criar e entregar mais rapidamente os produtos de software com mais
qualidade e que melhor reflitam as reais necessidades dos clientes.

Os mtodos geis utilizados para desenvolvimento de software um diferencial

que promete aumentar a satisfao do cliente agregando maior valor ao produto final,
produzindo software alta qualidade e acelerando os prazos de desenvolvimento de
projetos.

Este trabalho visa descrever metodologias de desenvolvimento gil de software,

que est sendo amplamente utilizada em renomadas empresas da rea como Google,
Yahoo, Globo, Ci&T, ....

1
2. METODOLOGIA GIL DE DESENVOLVIMENTO

O desenvolvimento de software precisa ser reconhecido como um processo

imprevisvel e complicado. Reconhecer que um software nunca foi construdo da
mesma forma, com a mesma equipe, sob as mesmas circunstncias antes a grande
mudana do pensamento tradicional de desenvolvimento de software. Mas, o mais
importante reconhec-lo como um processo emprico: que aceita a imprevisibilidade e
tem mecanismos de ao corretiva.

Uma caracterstica das metodologias geis que elas so adaptativas ao invs de

serem preditivas. Dessa forma, elas se adaptam a novos fatores durante o
desenvolvimento do projeto, ao invs de tentar analisar previamente tudo o que pode ou
no acontecer no decorrer do desenvolvimento. Essa anlise prvia sempre difcil e
apresenta alto custo, alm de se tornar um problema quando for necessrio fazer
alteraes nos planejamentos. O problema no a mudana em si, mesmo porque ela
ocorrer de qualquer forma. O problema como receber, avaliar e responder s
mudanas. Numa metodologia clssica pode acontecer de que um software seja
construdo por inteiro e depois se descubra que ele no serve mais para o propsito que
foi desenvolvido porque as regras mudaram e as adaptaes tornem-se complexa demais
para que valha a pena desenvolve-las. As metodologias geis trabalham com constante
feedback, o que permite adaptar rapidamente a eventuais mudanas nos requisitos.
Alteraes essas que so, muitas vezes, crticas nas metodologias tradicionais, que no
apresentam meios de se adaptar rapidamente s mudanas. Um outro ponto positivo das
metodologias geis so as entregas constantes de partes operacionais do software. Desta
forma, o cliente no precisa esperar muito para ver o software funcionando e notar que
no era bem isso que ele esperava [2].

A integrao e o teste contnuo 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.

2
2.1 Histria

O termo Metodologias geis tornou-se popular em 2001 quando um grupo de

dezessete especialistas em processos de desenvolvimento de software decidiu se reunir
nos EUA, para discutir maneiras de melhorar o desempenho de seus projetos.

Embora cada envolvido tivesse suas prprias prticas e teorias sobre como fazer
um projeto de software ter sucesso, utilizando mtodos como Scrum, Extreme
Programming (XP) e outros, cada um com as suas particularidades, todos concordavam
que, em suas experincias prvias, um pequeno conjunto de princpios sempre parecia
ter sido respeitado quando os projetos davam certo.

Foi ento criada a Aliana gil e o estabelecimento do Manifesto gil

[3]
(conforme anexo 1) contento os conceitos e princpios comuns compartilhados por
todos esses mtodos. Desde ento o termo Desenvolvimento gil passou a descrever
abordagens de desenvolvimento que seguissem estes conceitos que implicam em
valorizar:

Indivduos e interao entre eles so mais que processos e ferramentas;

Software em funcionamento mais que documentao abrangente;
Colaborao com o cliente mais que negociao de contratos;
Responder a mudanas mais que seguir um plano.

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 funcionando, com a colaborao com o cliente e as respostas rpidas a
mudanas e alteraes. [2]

3
2.2 Analisando o Manifesto gil 1

muito importante entender que os conceitos do manifesto gil definem

preferncias e no alternativas no desenvolvimento de software, encorajando a focar a
ateno em certos conceitos sem eliminar outros. Assim para seguir os conceitos geis
deve-se valorizar mais a certas coisas do que a outras.

1. Indivduos e interao entre eles mais que processos e ferramentas:

os softwares no so construdos por uma nica pessoa, eles so construdos por uma
equipe, ento elas precisam trabalhar juntas (incluindo programadores, testers,
projetistas e tambm o cliente). Processos e ferramentas so importantes, mas no so
to importantes quanto trabalhar juntos.
2. Software em funcionamento mais que documentao abrangente: a
documentao deve existir para ajudar pessoas a entender como o sistema foi
construdo, mas muito mais fcil entender como o funcionamento vendo o sistema
funcionar do que atravs de diagramas que descrevem o funcionamento ou abstraem o
uso.
3. Colaborao com o cliente mais que negociao de contratos:
somente o cliente pode dizer o que ele espera do software e normalmente eles no
sabem explicar exatamente o que eles esperam e ainda, eles mudam de idia ao longo
do tempo e conforme eles vm o software funcionando. Ter um contrato importante
para definir as responsabilidades e direitos mas no deve substituir a comunicao.
Trabalhos desenvolvidos com sucesso tm constante comunicao com o cliente para
entender suas necessidades e ajuda-los a descobrir a melhor forma de expressa-las.
4. Responder a mudanas mais que seguir um plano: mudanas uma
realidade no ambiente de negcios e elas acontecem por inmeras razes: as regras e
leis sofrem alteraes, as pessoas mudam de idia e a tecnologia evolui. O software
precisa refletir essas mudanas. Um projeto de software certamente deve ter um plano
mas ele deve ser flexvel o suficiente para comportar as mudanas quando elas
aparecerem, seno ele se torna irrelevante.

1
Baseado em [10]

4
3. SCRUM

Scrum trabalha com a complexidade de desenvolvimento de softwares atravs do

controle de inspeo, adaptao e visibilidade de requisitos de um processo emprico
fazendo uso de uma srie de regras e prticas, onde controle no significa controle para
criar o que foi previsto e sim controlar o processo para orientar o trabalho em direo a
um produto com o maior valor agregado possvel [4].

Para atingir esses objetivos o Scrum emprega um estrutura iterativa e

incremental da seguinte maneira: no incio de cada iterao, a equipe analisa o que deve
ser feito e ento seleciona aquilo que acreditam poder se tornar um incremento de valor
ao produto ao final da iterao. A equipe ento faz o seu melhor para realizar o
desenvolvimento daquela iterao e ao final apresenta o incremento de funcionalidade
construdo para que os stakeholders possam verificar e requisitar alteraes no
momento apropriado.

[4]
O corao do Scrum a iterao . A cada iterao a equipe analisa os
requisitos, a tecnologia e suas habilidades e ento se dividem para construir e entregar o
melhor software possvel adaptando-se diariamente conforme surjam as complexidades,
dificuldades e surpresas.

3.1 Sprint Ciclo de desenvolvimento Scrum

No Scrum, um projeto se inicia com uma viso simples do produto que ser
desenvolvido. A viso pode ser vaga a principio e ir tornando-se clara aos poucos. O
Product Owner (PO) ento, transforma essa viso em uma lista de requisitos funcionais
e no-funcionais que quando forem desenvolvidos reflitam essa viso. Essa lista,
chamada de Product Backlog priorizada pelo PO de forma que os itens que gerem
maior valor ao produto tenham maior prioridade.

5
 O ponto de partida dividir o Product Backlog em releases e esperado que o
contedo, a prioridade e agrupamento do Product Backlog sofram mudanas a partir do
momento que o projeto comea. Essas mudanas refletem mudanas nas regras e
requisitos de negcios e no quo rapidamente a equipe pode transform-lo em produto
[4]
.

Todo o trabalho feito em Sprints que so iteraes de 2 a 4 semanas. Scrum

exige que o Scrum Team desenvolva um incremento de produto a cada Sprint. Esse
incremento de produto precisa ser potencialmente entregvel para o PO escolhe-lo para
ser desenvolvido. Cada incremento deve ser bem estruturado, codificado e testado.

Cada Sprint inicia-se com uma reunio chamada Sprint Planning Meeting na
qual o PO e a equipe decidem o que ser desenvolvido neste Sprint. Nesta reunio o PO
apresenta os itens de maior prioridade e o Scrum team seleciona os itens que sero
entregues ao final do Sprint e os dividem em tarefas que compem ento o Sprint
Backlog. Nessa reunio fica determinado o que fazer no Sprint. A equipe se
compromete a executar essas tarefas no Sprint e o Product Owner se compromete a no
trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e
mudanas so encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a
trabalhar em um Sprint, ela permanece concentrada no objetivo traado para o Sprint e
novos requisitos no so aceitos. [6]

Todos os dias o Scrum Team se rene numa reunio de 15 minutos numa reunio
chamada Daily Scrum para sincronizar o trabalho da equipe toda e informar o Scrum
Master de eventuais impedimentos no trabalho.

6
 Figura 1 Sprint

No final do Sprint ocorre a Sprint Review Meeting, reunio na qual o Scrum

Team apresenta para o PO o que foi desenvolvido durante o Sprint.

Depois da Sprint Review Meeting e antes do prximo Sprint o Scrum Master se

rene com o Scrum Team numa ltima reunio: a Retrospective Meeting. O Scrum
Master encoraja o Scrum Team a revisar as prticas do Scrum e refletir sobre o que
precisa ser feito para melhorar no prximo Sprint.

Juntas, a Sprint Planning Meeting, a Daily Scrum Meeting, a Sprint Review

Meeting e a Sprint Retrospective Meeting implementam as prticas de inspeo e
adaptao empricas. [4]

7
 Figura 2 Ciclo Scrum (adaptada de [7] )

3.2 Papis Scrum

Scrum implementa sua estrutura iterativa e incremental atravs de trs papis: o

Product Owner, o Team, e o ScrumMaster. Toda responsabilidade no projeto dividida
entre esses trs papis. [4]

3.2.1 Scrum Master

O Scrum Master responsvel pelo processo Scrum, por ensin-lo a todas as

pessoas envolvidas no projeto, por implement-lo, fazendo dele uma cultura na
organizao e ainda por garantir que toda a equipe siga as regras e as prticas do
Scrum.[4]

Ele tambm protege a equipe assegurando que ela no se comprometa

excessivamente com relao quilo que capaz de realizar durante um Sprint.

8
 O Scrum Master atua como facilitador na Daily Scrum Meeting e torna-se
responsvel por remover quaisquer obstculos que sejam levantados pela equipe durante
essas reunies. [6]

O papel de Scrum Master pode ser exercido por qualquer pessoa da equipe,
entretanto tipicamente exercido por um gerente de projeto ou um lder tcnico.

3.2.2 Scrum Team

O Scrum Team a equipe de desenvolvimento.

Um Scrum Team tpico tem de 6 a 10 pessoas auto-organizveis, auto-

gerenciveis e multifuncional[6]. Nela, no existe necessariamente uma diviso
funcional atravs de papis tradicionais, tais como programador, designer, analista de
testes ou arquiteto. Todos no projeto trabalham juntos e so responsveis por completar
o conjunto de trabalho com o qual se comprometem a cada iterao. A equipe no pode
ser alterada durante o Sprint.

Quando necessrio uma equipe maior no Scrum usando o conceito de Scrum

of Scrums. Cada Scrum Team trabalha normalmente, mas cada equipe tambm contribui
com uma pessoa que dever freqentar o Scrum of Scrums Meeting para coordenar o
trabalho de mltiplas equipes Scrum. Esses encontros so anlogos aos Daily Scrum,
mas no acontecem necessariamente todos os dias. Fazer essa reunio duas ou trs
[6]
vezes por semana tende a ser suficiente na maioria das organizaes.

9
 Figura 3 Scrum of Scrums

3.2.3 Product Owner (PO)

O Product Owner responsvel por representar os interesses dos stakeholders

no projeto. O Product Owner a pessoa que define todos os itens de requisito do
projeto numa lista chamada Product Backlog. Utilizando essa lista ele responsvel por
garantir que as funcionalidades que agreguem maior valor ao produto sejam
desenvolvidas primeiro. Isto feito atravs da freqente priorizao do Product
Backlog para que os itens de maior valor agregado sejam entregues a cada iterao. [4]

10
3.3 Artefatos

3.3.1 Product Backlog

O Product Backlog uma lista contendo todas as funcionalidades desejadas para

um produto. O contedo desta lista definido e priorizado pelo Product Owner. O
Product Backlog totalmente dinmico, ele modificado toda vez que se identifica
[4]
algo que o produto precisa para ser mais apropriado, competitivo ou proveitoso , por
isso ele nunca est completo, ele sempre contm os requisitos mais conhecidos e
melhores entendidos.

Um exemplo de um Product Backlog pode ser visto na tabela 1. Note que os

itens so escritos da seguinte maneira: como um <sujeito> eu gostaria de <ao>, esse
template chamado de user story e utilizado para descrever os itens do backlog.

Backlog item Estimativa

Como um visitante do site eu gostaria de mandar um e- 8
mail de contato

Como um cliente eu gostaria de buscar por um produto 11

Como um cliente eu gostaria de colocar um produto no 15

carrinho de compras
Como um cliente eu gostaria de pagar a compra com o 38
carto de crdito

... ...
... ...

Tabela 1 Exemplo de Product Backlog

11
 3.3.2 Sprint Baclkog

O Sprint Backlog uma lista de tarefas que o Scrum Team se compromete a

fazer em um Sprint como um potencial incremento de produto entregvel[4]. Os itens do
Sprint Backlog so extrados do Product Backlog, pela equipe, com base nas prioridades
definidas pelo Product Owner e a percepo da equipe sobre o tempo que ser
necessrio para completar as vrias funcionalidades. A quantidade de itens do Product
Backlog que sero trazidos para o Sprint Backlog definida pelo Scrum Team que se
compromete a implement-los durante o Sprint.

Os itens do Sprint Backlog so divididos em tarefas com detalhes suficientes

para que possam ser executadas em at 16 horas [4].

Um exemplo de Sprint Backlog mostrado na Tabela 2.

Tarefas Responsvel Estimativa Status Dia 1 Dia 2 Dia 3 Dia 4

Criar servio de email Paula 5 Complete 5 2 0 0
In
Implementar envio de email de contato Marcos 2 progress 2 2 1 0
Not
Testar o envio de e-mail de contato Mirian 1 Started 1 1 0 0
Not
Criar classe de produto 2 Started 2 2 2 2
Not
Criar servio de busca 4 Started 4 4 4 4
...

Tabela 2 Exemplo de Sprint Backlog

Durante um Sprint, o Scrum Master mantm o Sprint Backlog atualizando-o para

refletir que tarefas so completadas e quanto tempo a equipe acredita que ser
necessrio para completar aquelas que ainda no esto prontas. A estimativa do trabalho
que ainda resta a ser feito no Sprint calculada diariamente e colocada em um grfico,
resultando em um Sprint Burndown Chart.[6]

12
3.3.3 Burn Down Chart

O monitoramento do progresso do projeto realizado atravs de dois grficos

principais: Product Burndown Chart e Sprint Burndown Chart. Estes grficos mostram
ao longo do tempo a quantidade de trabalho que ainda resta ser feito, sendo um
excelente mecanismo para visualizar a correlao entre a quantidade de trabalho que
falta ser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este
trabalho [8].

Burndown Chart

140
120
100
Horas

80 ideal
60 realizada
40
20
0
1 2 3 4 5 6
Dia

Figura 3 Burndown Chart

13
3.4 Cerimnias

3.4.1 Sprint Planning Meeting

A Sprint Planning Meeting uma reunio na qual esto presentes o PO, o Scrum
Master e o Scrum Team. Durante esta reunio o PO descreve as funcionalidades de
maior prioridade para a equipe [6].

Essa reunio, que deve ser de o horas, dividida em duas partes [4]:

nas primeiras 4 horas o PO apresenta os itens de maior prioridade

do Product Backlog para a equipe. O Scrum Team faz perguntas para entender
melhor as funcionalidades e ser capaz de quebrar as funcionalidades em tarefas
[6]
tcnicas que iro dar origem ao Sprint Backlog e ento definem
colaborativamente o que poder entrar no desenvolvimento do prximo Sprint,
considerando o tamanho da equipe, a quantidade de horas disponveis e a
produtividade do Scrum Team [5].

durante as prximas 4 horas o Scrum Team planeja seu trabalho,

definindo o Sprint Backlog, que so as tarefas necessrias para implementar as
[5]
funcionalidades selecionadas no Product Backlog .

3.4.2 Daily Scrum Meeting

A cada dia do Sprint o Scrum Master realiza uma reunio de 15 minutos com o
Scrum Team. Essa reunio, chamada Daily Scrum Meeting, tem como objetivo
[5]
disseminar informaes sobre o estado do projeto .

As Daily Scrum Meetings devem ser realizadas no mesmo lugar, na mesma hora
do dia. Idealmente so realizados na parte da manh, para ajudar a estabelecer as
[6]
prioridades do novo dia de trabalho . Embora qualquer pessoa possa participar da
reunio, somente os membros do Scrum Team esto autorizados a falar [5].

14
 Cada membro do Scrum Team deve ento responder cada uma destas trs
perguntas:

O que voc fez ontem?

O que voc far hoje?
H algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela ir fazer hoje, a
equipe ganha uma excelente compreenso sobre que trabalho foi feito e que trabalho
ainda precisa ser feito. A Daily Scrum Meeting no uma reunio de status na qual um
chefe fica coletando informaes sobre quem est atrasado. Ao invs disso, uma
reunio na qual os membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados na Daily Scrum Meeting devem ser tratados pelo

Scrum Master o mais rapidamente possvel.

O Daily Scrum no deve ser usado como uma reunio para resoluo de
problemas. Questes levantadas devem ser levadas para fora da reunio e normalmente
tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema
ou possam contribuir para solucion-lo.

3.4.3 Sprint Review Meeting

No final do Sprint a Sprint Review Meeting realizada. Essa reunio planejada

para ser realizada em no mximo 4 horas [5]. Nesta reunio o Scrum Team mostra o que
foi desenvolvido durante o Sprint. Tipicamente, isso tem o formato de uma
demonstrao das novas funcionalidades.

Durante a Sprint Review Meeting, o projeto avaliado em relao aos objetivos

do Sprint, determinados durante a Sprint Planning Meeting. Idealmente, a equipe
completou cada um dos itens do Sprint Backlog. [6]

15
3.4.4 Sprint Retrospective Meeting

[4]
A Sprint Retrospective Meeting uma reunio de 3 horas que ocorre ao final
de um Sprint depois da Sprint Review Meeting e serve para identificar o que funcionou
bem, o que pode ser melhorado e que aes sero tomadas para melhorar.

16
4. COMPARAAO ENTRE OS MTODOS GEIS

Algumas outras metodologias geis de desenvolvimento de software so:

Extreme Programming (XP)
Feature Driven Development (FDD)
Adaptive Software Development (ASD)

4.1 Extreme Programming XP

A metodologia Extreme Programming (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. 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
forma de comunicao um fator chave na XP: procura-se o mximo possvel
comunicar-se pessoalmente, evitando se o uso de telefone e o envio de mensagens por
correio eletrnico. 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 [2].
Uma caracterstica que podemos destacar nesta metodologia a programao em
pares.

17
4.2 CRITRIOS UTILIZADOS

Os critrios adotados para servirem de base para a identificao das atividades

propostas pelos Mtodos geis so as atividades sugeridas pelo Desenvolvimento
Incremental. Sommerville (2003) afirma que os mtodos geis so fundamentados no
Desenvolvimento Incremental. E conforme puderam ser observado, as atividades
sugeridas durante o seu processo de desenvolvimento so bastante semelhantes aos
Princpios geis.
No Desenvolvimento Incremental (Figura 4) os clientes inicialmente
identificam, em um esboo, os requisitos do sistema e selecionam quais so os mais e os
menos importantes. Em seguida definida uma srie de iteraes de entrega, onde em
cada uma fornecido um subconjunto de funcionalidades executveis, dependendo das
suas prioridades.

Figura 4 Desenvolvimento Incremental

Fonte: Adaptado de Sommerville (2003)

4.3 Anlise Comparativa

Para facilitar o entedimento da anlise comprativa, cada atividade do

desenvolvimento incremental e um resumo da atividade correspondente em
cada um dos mtodos analisados esto elencados na tabela abaixo

18
19
5. CONCLUSO

A intensiva competitividade na rea de desenvolvimento de software faz com

que as empresas busquem sempre o aperfeioamento de seus servios para poder
vencer a concorrncia. Prazo e qualidade, alm claro de melhor aceitao e adaptao
a mudanas so importantes diferenciais que podem ser atingidos utilizando-se
metodologias geis de desenvolvimento. Embora no seja a soluo para todos os
problemas, a metodologia gil mostra uma maneira de trabalhar bastante organizada e
iterativa, podendo inclusive contribuir para um ambiente de trabalho mais amigvel,
portanto uma boa opo para se obter os diferencias desejados.
No que diz respeito a anlise comparativa de mtodos ageis, podemos concluir
que existe bastante semelhanas entre si, entretanto, algumas particularidades foram
notadas como dupla de programadores, user stories e escrita dos testes antes da
implementao no XP, reunies de planejamento, dirias e de reviso no SCRUM,
inspees de cdigo no FDD e sesses de JAD no ASD.

20
6. REFERNCIAS BIBLIOGRFICAS

[1] LEFFINGWELL, Dean and MUIRHEAD, Dave, Tactical Management of Agile

Development: Achieving Competitive Advantage. 2004. Boulder, Colorado

[2] SOARES, Michel dos Santos, Comparao entre Metodologias geis e

Tradicionais para o Desenvolvimento de Software. Unipac - Universidade Presidente
Antnio Carlos, Faculdade de Tecnologia e Cincias de Conselheiro Lafaiete

[3] Agile Manifesto, Disponvel em http://agilemanifesto.org/,

[4] SCHWABER , Ken, What Is Scrum?

[5] www.scrumalliance.org

[6] www.improveit.com.br

[7] GLOGER, Boris, Scrum Checklists.

[8] Ana Sofia Cysneiros Maral et all, Estendendo o SCRUM segundo as reas de
Processo de Gerenciamento de Projetos do CMMI

[9] Bob Galen Spring, SCRUM Product Ownership: From the Inside Out. 2009.
v1.4

[10] AMBLEW, Scott W., Examining the Agile Manifesto. 2009.

[11] Fagundes, Priscila Basto; Santos, Sandro da Silva dos e Deters, Janice Ins,
Comparao entre os processos dos mtodos geis, E-Tech: Atualidades
Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1, n. 1, p. 37-46, 1.
sem., 2008.

21
ANEXO 1 - Manifesto for Agile Software Development

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

22
ANEXO 2 - Principles behind the Agile Manifesto

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.

23
 At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

24