UNIP Universidade Paulista

CST Anlise e Desenvolvimento de Sistemas

Modelos geis de processos

Disciplina: Engenharia de Software I

Professor: Jos Carlos Lorandi

Vinicius Brumatti

RA:C206AI-4

William Galdino

RA:C03DGD-9

Leandro Fernandes RA:C17EGE-0

So Paulo SP
2014

NDICE
1. INTRODUO.............................................................................................................. 1
2. Resumo....................................................................................................................... 2
3. O que um processo gil de desenvolvimento de software.......................................... 3
4. Scrum.......................................................................................................................... 4
4.1 Product Backlog......................................................................................................... 5
4.2 Sprint Planning Meeting............................................................ 6
4.3 Sprint Owner.......................................................................................................... 6
4.4 Sprint Backlog............................................................................................. 7
4.5 Daily Scrum.............................................................................................. 7
4.6 Sprint Review Meeting............................................................................................ 8
4.7 Sprint Retrospective..............................................................................................8
5 XP (Extreme Programming).....................................................................9
5.1 Valores.......................................................................9
5.2 Princpios Bsicos....................................................................................9
5.3 Processos / Atividades Metodolgicas.........................................................................9
5.4 Prticas...................................................................................................10
6 Crystal......................................................................11
6.1 Figura Modelo ASD.................................................................. 12
7 DSDM Dynamic Systems Development Method...........................................................13
7.1 Pricpios....................................................................13
7.2 Pr-Requisitos para utlizar o DSDM................................................................. 14
8 FDD Feature Driven Development.................................................................. 15
9 ASD - Adaptive Software Development ...................................................................... 16
9.1 Figura ASD ................................................................... .17
10 Concluso.....................................................................18
10 Referncias Bibliogrficas............................................................................19

1. Introduo
Existem inmeros frameworks de processos para desenvolvimento de software. A maioria dos
mtodos geis tenta minimizar o risco pelo desenvolvimento do software em curtos perodos,
chamados de iterao, os quais gastam tipicamente menos de uma semana a at quatro. Cada
iterao como um projeto de software em miniatura de seu prprio, e inclui todas as tarefas
necessrias para implantar o mini-incremento da nova funcionalidade: planejamento, anlise
de requisitos, projeto, codificao, teste e documentao. Enquanto em um processo
convencional, cada iterao no est necessariamente focada em adicionar um novo conjunto
significativo de funcionalidades, um projecto de software gil busca a capacidade de implantar
uma nova verso do software ao fim de cada iterao, etapa a qual a equipe responsvel
reavalia as prioridades do projecto.

Mtodos geis enfatizam comunicaes em tempo real, preferencialmente cara a cara, a

documentos escritos. A maioria dos componentes de um grupo gil deve estar agrupada em
uma sala. Isso inclui todas as pessoas necessrias para terminar o software: no mnimo, os
programadores e seus clientes (clientes so as pessoas que definem o produto, eles podem ser
os gerentes, analistas de negcio, ou realmente os clientes). Nesta sala devem tambm se
encontrar os testadores, projectistas de iterao,redactores tcnicos e gerentes.

Mtodos geis tambm enfatizam trabalho no software como uma medida primria de
progresso. Combinado com a comunicao cara-a-cara, mtodos geis produzem pouca
documentao em relao a outros mtodos, sendo este um dos pontos que podem ser
considerados negativos. recomendada a produo de documentao que realmente ser til.

2. 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 de cada uma delas.

3. O que um processo gil de desenvolvimento de software?

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.

4. SCRUM
=> Processo de desenvolvimento iterativo e incremental para o desenvolvimento de software
gil.
Scrum uma metodologia gil para gesto e planejamento de projetos de software.
No Scrum, os projetos so divididos em ciclos (tipicamente mensais) chamados de Sprints.
O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser
executado. Metodologias geis de desenvolvimento de software so iterativas, ou seja, o
trabalho dividido em iteraes, que so chamadas de Sprints no caso do Scrum.
As funcionalidades a serem implementadas em um projeto so mantidas em uma lista que
conhecida como Product Backlog. No incio de cada Sprint, faz-se um Sprint Planning Meeting,
ou seja, uma reunio de planejamento na qual o Product Owner prioriza os itens do Product
Backlog e a equipe seleciona as atividades que ela ser capaz de implementar durante o Sprint
que se inicia. As tarefas alocadas em um Sprint so transferidas do Product Backlog para
o Sprint Backlog.
A cada dia de uma Sprint, a equipe faz uma breve reunio (normalmente de manh),
chamada Daily Scrum. O objetivo disseminar conhecimento sobre o que foi feito no dia
anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint
Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o
planejamento do prximo Sprint. Assim reinicia-se o ciclo. Veja a ilustrao abaixo:

4.1 Product Backlog

O Product Backlog uma lista contendo todas as funcionalidades desejadas para um produto.
O contedo desta lista definido pelo Product Owner. O Product Backlog no precisa estar
completo no incio de um projeto. Pode-se comear com tudo aquilo que mais bvio em um
primeiro momento. Com o tempo, o Product Backlog cresce e muda medida que se aprende
mais sobre o produto e seus usurios.
Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os
descreve para a equipe. A equipe ento determina que itens ser capaz de completar durante
a Sprint que est por comear. Tais itens so, ento, transferidos do Product Backlog para
o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais
tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem
fazer parte do Product Backlog tarefas tcnicas ou atividades diretamente relacionadas s
funcionalidades solicitadas.

4.2 Sprint Planning Meeting

O Sprint Planning Meeting uma reunio na qual esto presentes o Product Owner, o Scrum
Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja
representando a gerncia ou o cliente.
Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior
prioridade para a equipe. A equipe faz perguntas durante a reunio de modo que seja capaz de
quebrar as funcionalidades em tarefas tcnicas, aps a reunio. Essas tarefas iro dar origem
ao Sprint Backlog.
O Product Owner no precisa descrever todos os itens que esto no Product Backlog.
Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente
descrever apenas os itens de maior prioridade, deixando a discusso dos itens de menor
prioridade para o prximo Sprint Planning Meeting.
Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que
uma breve descrio daquilo que se tentar alcanar no Sprint. O sucesso do Sprint ser
avaliado mais adiante no Sprint Review Meeting em relao ao objetivo traado para o Sprint.
Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para
conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no
Sprint que ser iniciado. Em alguns casos, haver negociao com o Product Owner, mas ser
sempre responsabilidade da equipe determinar o quanto ela ser capaz de se comprometer a
fazer.

4.3 Product Owner

O Product Owner a pessoa que define os itens que compem o Product Backlog e os prioriza
nas Sprint Planning Meetings.
O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritrios e se
compromete a entreg-los ao final de um Sprint (iterao). Estes itens transformam-se
no Sprint Backlog.
A equipe se compromete a executar um conjunto de atividades 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.

4.4 Sprint Backlog

O Sprint Backlog uma lista de tarefas que o Scrum Team se compromete a fazer em um
Sprint. 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.
Cabe a equipe determinar a quantidade de itens do Product Backlog que sero trazidos para o
Sprint Backlog, j que ela quem ir se comprometer a implement-los.
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.

4.5 Daily Scrum

A cada dia do Sprint a equipe faz uma reunio diria, chamada Daily Scrum. Ela tem como
objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar
impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
Os Daily Scrums normalmente so realizadas no mesmo lugar, na mesma hora do dia.
Idealmente so realizados na parte da manh, para ajudar a estabelecer as prioridades do
novo dia de trabalho.
Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas tambm
podem estar presentes, mas s podero escutar. Isso torna os Daily Scrums uma excelente
forma para uma equipe disseminar informaes sobre o estado do projeto.
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. Durante o Daily Scrum, cada membro da equipe prov respostas para 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. O Daily Scrum no uma reunio de status report na qual um chefe fica coletando
informaes sobre quem est atrasado. Ao invs disso, uma reunio na qual membros da
equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais
rapidamente possvel.

4.6 Sprint Review Meeting

Ao final de cada Sprint feito um Sprint Review Meeting. Durante esta reunio, o Scrum
Team mostra o que foi alcanado durante o Sprint. Tipicamente, isso tem o formato de um
demo das novas funcionalidades.
Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team,
o Scrum Master, gerncia, clientes e engenheiros de outros projetos.
Durante o Sprint Review, o projeto avaliado em relao aos objetivos do Sprint,
determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um
dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo
que a equipe atinja o objetivo geral do Sprint.

4.7 Sprint Retrospective

O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou
bem, o que pode ser melhorado e que aes sero tomadas para melhorar.

5. XP (Extreme Programming) - Programao Extrema

1- Metodologia gil para pequenas e mdias equipes.
2- Desenvolvimento de software com requisitos vagos e em constante mudana.
3- Adota a estratgia de constante acompanhamento e realizao de vrios ajustes
durante o desenvolvimento do software.

5.1 Valores

Comunicao
Simplicidade
Feedback
Coragem
Respeito

5.2 Princpios Bsicos

Feedback rpido
Presumir simplicidade
Mudanas incrementais
Abraar mudanas
Trabalho de alta qualidade

5.3 Processo / Atividades metodolgicas

O XP prefere uma abordagem orientada a objeto como paradigma de desenvolvimento e

envolve 4 atividades metodolgicas:

Planejamento
Projeto
Codificao
Testes

5.4 Prticas

Jogo de planejamento
Fases pequenas
Metfora
Design Simples
Time coeso
Testes de aceitao
Semana 40 horas
Reunies em p
Propriedade coletiva
Programao pareada
Padronizao do cdigo

10

6. Crystal
Metodologia Crystal
No ano de 2000 Cockburn criou a metodologia Crystal ou Familia de Metodologias Crystal, que
possui uma abordagem voltada a gesto de pessoas. Seu foco a interao, comunidade,
habilidades, talentos e comunicaes, com a crena de que estes so os que tm o efeito de
primeira ordem no desempenho, no descartando os outros fatores mas os colocando como
secundrio. Os membros que compem as equipes tem um conjunto diferente de talentos e
habilidades, ou seja, fundamental utilizar um processo exclusivo feito sob medida para ela.
Caractersticas:
A metodologia Crystal na verdade uma Famlia de Metodologias que so consideradas e
descritas como "metodologias leves", foram criadas para atender s equipes de diferentes
tamanhos que necessitam de diferentes estratgias para resolver problemas diversos.
A famlia de metodologia Crystal dividida em cores, alguns deles citados a seguir:
Crystal Clear
Crystal Yellow
Crystal Orange
Crystal Red
Crystal Maroon

Propriedades comuns:

Entrega Frequente: O modelo Desenvolvimento Incremental utilizado na Crystal, onde cada

incremento deve ter durao mxima de 4 meses, mas o recomendado at 3 meses;
Oficinas Reflexivas: Deve ser realizadas reunies para reflexes sobre o projeto, a ideia
que a equipe possa analisar o projeto como todo e verificar se tudo est dentro do que foi
estabelecido e sempre procurando maneiras de melhorar seus processos
Comunicao Osmtica: Se os integrantes da equipe de desenvolvimento trabalharem na
mesma isso pode facilitar a transao das informaes. Com relao s equipes maiores (mais
de 8 ou algo assim), onde podem surgir distrao, ento necessrio ter cuidado para no
perder o foco do projeto, faz-se ento um controle mais rgido

11

 Convico Pessoal: ideal que todos tenham confiana j que isto melhorar o seu
desempenho, as habilidades especificas de cada um devem ser focadas na hora da diviso das
tarefas, e quanto mais o projeto avanar mais confiana a equipe ter;
Foco: Concentrao fundamental. Em cristal ele indica q todos tenham dois focos
principais: primeiro lugar, concentrao na sua tarefa individual dentro de um projeto e em
segundo lugar, ao projeto como todo, sempre verificar se o projeto est seguindo em direo
aos objetivos propostos
Ambiente Tcnico com Testes Automatizados: Deve haver integrao total, se em testes for
necessrio alguma alterao isso deve ser feito de forma rpida e todos devem saber o que foi
modificado.

METODOLOGIA CRYSTAL

12

7. DSDM
Metodologia de Desenvolvimento de Sistemas Dinmicos (Dynamic Systems Development
Method) uma metodologia de desenvolvimento de software baseada em "Desenvolvimento
Rpido de Aplicao" . DSDM uma metodologia de desenvolvimento iterativo e
incremental que enfatiza o envolvimento constante do usurio.
o DSDM aplicado em projetos de Sistemas caracterizados pelos cronogramas e custos
limitados. Aponta falhas de informao mais comuns destes projetos, incluindo custos
excedentes, perda de prazos, falta de envolvimento de usurios e acompanhamento da alta
gerncia. Atravs do uso do RAD, contudo, sem os devidos cuidados com o DSDM pode
aumentar ainda mais o risco em outros quesitos. DSDM consiste em:

3 fases: pr-projeto, ciclo de vida, e ps-projeto.

A fase ciclo de vida subdividida em 5 estgios: anlise de viabilidade, anlise de negcio,

Iterao do Modelo Funcional, iterao de elaborao e construo e, por fim,
implantao.

7.1 Princpios:
Existem 9 princpios formados por 4 sries e 5 pontos-chave.

Envolvimento: o envolvimento do usurio o ponto principal para eficincia e eficcia do

projeto. Onde usurios e desenvolvedores dividem o mesmo espao, as decises podem ser
feitas com mais preciso.

Autonomia: o time deve estar empenhado em tomar decises que sejam importantes ao
progresso do projeto sem que necessitem de aprovao dos superiores.

Entregas: o foco na entrega frequente de produtos, assumindo que entregar algo bom logo
melhor que entregar algo perfeito somente no fim. Iniciando a entrega do produto desde os
primeiros estgios do projeto, o produto pode ser testado e revisado e a evidncia do teste e
reviso da documentao pode ser utilizados na prxima iterao ou fase.

Eficcia: o critrio principal para ser considerado "entregvel" entregar um sistema que
demonstre auxiliar nas necessidades e negcio atuais. Mais importante que um sistema que
corresponda todas as necessidades de negcio menos importante do que o foco nas
funcionalidades.

Feedback: o desenvolvimento iterativo e incremental controlado por feedbacks de usurios,

a fim de tornar a soluo eficaz ao negcio.

13

Reversibilidade: todas as alteraes feitas no desenvolvimento so reversveis.

Previsibilidade: o escopo e requisitos de alto nvel devem ser definidos antes que o projeto se
inicie.

Ausncia de Testes no escopo: testes so tratados fora do ciclo de vida do projeto.

(Veja Desenvolvimento orientado a testes para uma comparao).

Comunicao: necessria excelente comunicao e cooperao de todos os envolvidos para

obter maior eficcia e eficincia no projeto.

7.2 Pr-requisitos para utilizar o DSDM:

Para obter sucesso com o DSDM, um nmero de pr-requisitos deve ser alcanado. Inicialmente,
deve haver interao entre o time do projeto, futuros usurios e o alto-escalo. Isto permite
identificar futuras falhas no sistema acarretadas pela falta de acompanhamento da gerncia ou
envolvimento de usurio. O segundo requisito para um projeto DSDM que ele possa
ser fracionado em pequenas partes permitindo um maior detalhamento em cada iterao

MODELO DSDM

14

8. FDD Feature Driven Development

Feature Driven
Development (Desenvolvimento Guiado por
Funcionalidades) uma metodologia gil para
gerenciamento e desenvolvimento de
software. Ela combina as melhores prticas do
gerenciamento gil de projetos com uma
abordagem completa para Engenharia de
Software orientada por objetos, conquistando
os trs principais pblicos de um projeto de
software: clientes, gerentes e
desenvolvedores.
Seus princpios e prticas proporcionam um equilbrio entre as filosofias tradicionais e
as mais extremas, proporcionando uma transio mais suave para organizaes mais
conservadoras, e a retomada da responsabilidade para as organizaes que se
desiludiram com as propostas mais radicais.
O lema da FDD : "Resultados freqentes, tangveis e funcionais."
possvel notar como o FDD pode atuar em conjunto com outras metodologias,
principalmente com o Scrum, encaixando-se perfeitamente como metodologia de
engenharia gil de software com projeto gil de software.
Alm disso, possvel notar que as boas prticas do FDD podem entrar em embate
com o XP, na forma em que o cdigo tratado por cada uma das metodologias.
Lembrando que as metodologias possuem caractersticas que podem ser adaptadas
necessidade de cada empresa, se notarmos o foco principal em todas as metodologias,
temos o desenvolvimento por incremento, a comunicao constante com o cliente e a
integrao continua.

15

9. Adaptive Software Development (ASD)

Como Surgiu:
Foi proposta por Jim Highsmith como uma tcnica para construo de software
complexos. O apoio filosfico do ASD concentra-se na colaborao humana e na autoorganizao. A auto-organizao aparece quando agentes individuais independentes
cooperam para criar resultados emergentes. OASD uma metodologia gil, tal como o
XP e o SCRUM; Segundo Pressman (2006), o ASD ( Adaptive Software Development )
foi proposto por Jim Highismith como uma tcnica para construo de sistemas e
software complexos. O ASD possui como filosofia a concentrao na colaborao
humana e na auto-organizao da equipe. Alm do ASD prover o desenvolvimento de
software complexos e de grande porte, ele tambm possui uma cultura adaptativa
onde h colaborao, desenvolvimento iterativo e incremental baseado em
componentes que fazem parte do ciclo adaptativo.
A filosofia ASD preocupa-se mais com os conceitos e cultura organizacional que com
prticas de software (ABRAHAMSSON, 2002).A nfase do ASD est na dinmica de
equipes auto organizadas, na colaborao interpessoal e no aprendizado individual e
em capacitar equipes de projeto de software que tenha uma probabilidade de sucesso
muito maior (PRESSMAN, 2006).
Como Funciona:
O Adaptive Software Development (ASD) tem como base principal um mtodo RAD
(Rapid Application Development), o RADical Software Development, evoluindo-o ao
incorporar conceitos da teoria de sistemas adaptativos complexos. Sob esse
panorama, o ASD prope atualizar o ciclo de desenvolvimento baseado em planejar,
projetar e construir, trocando-o por um com as fases de especular, colaborar e
aprender. Essa mudana seria necessria devido ao enfoque diferente dos dois ciclos:
o primeiro considera a estabilidade no ambiente de negcios, enquanto o segundo
foca em ambientes de incerteza e de grande mudana, viso comum a todos os
mtodos geis.

16

9.1 Figura: Modelo ASD

17

10. 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

18

11. REFERNCIAS BIBLIOGRFICAS

http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
http://desenvolvimentoagil.com.br/scrum/
http://www.trabalhosfeitos.com/ensaios/Desenvolvimento-%C3%81gil-DeSoftware/107847.html?_p=2
http://www.ft.unicamp.br/liag/Gerenciamento/monografias/monogafia_metodos_ageis.pdf
[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

19