XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO

Maturidade e desafios da Engenharia de Produo: competitividade das empresas, condies de trabalho, meio ambiente.

So Carlos, SP, Brasil, 12 a15 de outubro de 2010.

PROPOSTA DE SISTEMTICA PARA

GESTO DE PROJETOS BASEADA NA
METODOLOGIA GIL SCRUM
Tanara Priscilla Ribeiro Rose (UNIFEI)
tanara.rose@gmail.com
Carlos Henrique Pereira Mello (UNIFEI)
chp.mello@yahoo.com.br

A necessidade constante de um desenvolvimento gil fator que

movimenta muitas empresas, dos mais variados ramos. E nesse
contexto de agilidade e fluidez do mercado que acarretou no
surgimento de vrias metodologias geis para gesto de
desenvolvimento de produto como, por exemplo, o Scrum do Ken
Schwaber, Jeff Sutherland e Mike Beedle. Dos princpios defendidos
por essas metodologias, surge o Manifesto gil no fim do sculo XX.
Essas metodologias geis foram mais amplamente aplicadas na
indstria de software o que no anula sua aplicabilidade em outro tipo
de desenvolvimento. A literatura que aborda outros contextos de
aplicao do Scrum ainda bastante incipiente e a proposta desse
trabalho propor uma sistemtica para gesto de projetos baseada no
Scrum.
Palavras-chaves: Scrum, Processo de Desenvolvimento de Produto,
Movimento gil.

1. Introduo
No atual ambiente gil de desenvolvimento de produtos onde a velocidade para
lanamento de novos produtos, associada qualidade e preo acessvel so fatores essenciais
para um posicionamento estratgico da empresa no mercado (WHEELWRIGTH E CLARK,
1992), torna-se essencial um bom modelo de gesto. Na indstria de software no diferente.
Um estudo da Standish Group (1995) com mais de 30 mil projetos de desenvolvimento de
produtos de software desde 1994, revelou que, embora tenha havido melhorias com o passar
do tempo, ainda h um grande problema no setor (JOHNSON, 1995). Uma boa razo para
essa preocupao que o gasto americano em projetos de aplicaes de software chegou a
US$ 275 bilhes somente no ano de 1994.
Nesse estudo, fica comprovada que a taxa de sucesso para projetos acima de US$10
milhes (que envolvem mais de quinhentas pessoas, por pelo menos trs anos),
estatisticamente nula (JOHNSON, 1995). J para pequenos projetos, de at US$ 750 mil, a
taxa de sucesso 55%.
Outras informaes obtidas nesse estudo (aumento dos custos, atraso na entrega,
funcionalidades implementadas e taxa de sucesso) esto presentes nas Figuras 1 e 2. A taxa de
sucesso a que se refere, aos projetos que resultaram em produtos de softwares que realmente
foram utilizados pelo usurio final.

Fonte: Adaptado de Johnson (2001)

Figura 1 Evoluo dos parmetros de 1994 a 2003

Fonte: Adaptado de Johnson (2001)

Figura 2 Taxa de Sucesso no desenvolvimento de softwares

Em resposta a essas taxas, surgem as metodologias geis dentre as quais se pode destacar
o Scrum. Atualmente, o Scrum um modelo de gesto de desenvolvimento de produtos que
vem ganhando espao, principalmente na indstria de softwares, onde foi tradicionalmente
empregado, mas j vem sendo usado no desenvolvimento de outros produtos que no sejam
softwares (CARVALHO, 2009).
Apesar da literatura sobre o tema estar crescendo gradativamente ao longo dos ltimos
anos, essa , ainda, bastante incipiente (CARVALHO e MELLO, 2009). Esses trabalhos
mostram a aplicao do Scrum no desenvolvimento de produtos de software. Em virtude
disso, o presente trabalho tem por objetivo propor uma sistemtica para gesto de projetos por
meio da abordagem do mtodo Scrum para o desenvolvimento de produtos cujo resultado no
seja um software.
2. Fundamentao Terica
Por dcadas o desenvolvimento de software seguiu o modelo clssico de cascata para
desenvolvimento de produtos. Nesse modelo, o projeto passa por diversas etapas (anlise,
design, documentao, codificao e testes) antes de ser entregue ao cliente (LOESER, 2006),
diminuindo a flexibilidade do processo e prejudicando a obteno de repostas rpidas s
exigncias de mercado por parte da empresa. Esse enrijecimento do modelo de gesto adotado
garantiu que as taxas de sucesso das entregas dos softwares desenvolvidos fossem baixas.
Nesse contexto, surgem as metodologias geis as quais podem ser caracterizadas pela
informalidade e documentao reduzida (LOESER, 2006). O Scrum um exemplo dessas
metodologias.
O Scrum, juntamente com as outras metodologias que surgiram a partir das mesmas
necessidades de agilizar o processo de desenvolvimento de software, acarretaram no
surgimento do Manifesto gil (2001) no qual foram expostos os princpios do

desenvolvimento gil: desenvolvimento de projetos que atendam aos clientes, projetos

flexveis e indivduos e iteraes ao invs de processos e ferramentas (MANIFESTO AGIL,
2001).
O texto no qual foram expostos os ideais do manifesto conta com dezessete signatrios
dentro dos quais se encontra os trs criadores do Scrum: Jeff Sutherland, Mike Beedle e Ken
Schwaber (CARVALHO, 2009).
A partir de um artigo de Nonaka e Takeuchi (1986) no qual eram destacadas as vantagens
de pequenos times multifuncionais na obteno de resultados, Jeff Sutherland, Mike Beedle e
Ken Schwaber criaram em 1993 a metodologia de desenvolvimento de produtos chamada
Scrum (CARVALHO, 2009). Segundo Sutherland e Schwaber (2007), o primeiro
desenvolvimento com o Scrum ocorreu na Easel Corporation em 1993 e, em 1995, a
metodologia foi formalizada por Ken Schwaber, Jeff Sutherland e Mike Beedle.
Baseada em uma teoria de controle emprica, o Scrum se desenvolveu como uma
abordagem iterativa, incremental de otimizao da previsibilidade e controle de riscos. E trs
pilares sustentam essa metodologia (SCHWABER, 2009):
-Transparncia: garante que todos os aspectos relevantes ao sucesso do processo se
mantenham visveis e conhecidos de modo a garantir que o resultado obtido seja coerente ao
definido previamente;
- Inspeo: feita com finalidade de se detectar qualquer no conformidade que possa vir
a prejudicar os resultados da equipe;
- Adaptao: a partir da identificao da irregularidade so feitas adaptaes no processo
ou no material em processo, reduzindo a probabilidade de um resultado insatisfatrio.
Quanto s caractersticas do Scrum, Schwaber (1987) lista seis principais caractersticas:
- Entregas flexveis:o contedo das entregas definido de acordo com as necessidades de
mercado ou do cliente;
- Flexibilidade dos prazos: as entregas podem ser requisitadas antes ou aps do
inicialmente planejado;
- Pequenos times: geralmente no composto por mais de 6 membros;
- Revises frequentes:revises so feitas durante todo progresso do time;
- Colaborao: h intra e inter colaborao entre os membros;
- Orientao: cada time ir listar os objetos com interface e comportamento bem
definidos.
Tradicionalmente, o Scrum usado em empresas que desenvolvem software e prope a
adoo de alguns papis, ferramentas e ferramentas auxiliares para a gesto do
desenvolvimento de produtos:
2.1. Papis:
- Time: composto de 3 a 6 desenvolvedores em tempo integral e partes externas
(marketing, vendas e consumidores) (SCHWABER, 1996). Segundo Carvalho (2009), o Time
Scrum trabalha lado a lado em busca de um objetivo em comum que, no caso, realizar todos
os itens do Sprint Backlog.

- Scrum Master: o Scrum Master o responsvel pelo sucesso do projeto, uma vez que
aquele que garante que todos os fundamentos da metodologia esto sendo seguidos
(SCHWABER E BEEDLE, 2002).
- Dono do Produto: O Dono do Produto o representante do cliente na equipe
(AGUANNO, 2005), focando suas aes na maximizao do valor do produto para atender s
partes interessadas, clientes e usurios (ADVANCED DEVELOPMENT METHODS, 2003).
2.2. Ferramentas:
- Realease planning meeting: tem como objetivo definir as mtricas do projeto. As
definies feitas surgem da pergunta Como podemos fazer com que a viso em um
produto de sucesso? Como podemos satisfazer s vontades do cliente e ter um retorno de
investimento?. Segundo Schwaber (2009), nessa reunio so definidas as prioridades do
itens do Backlog do Produto e as estimativas pelo time.
- Backlog do produto: uma lista de tudo que deve ser desenvolvido no projeto. A partir
dessa lista de incrementos ou funcionalidades so definidos os itens com compem o
Backlog do Sprint.
Segundo Schwaber (1987), para a definio dos requisitos do Product Backlog no
desenvolvimento de um software so levadas em considerao seis variveis:
a) Requisitos do cliente: o que deve ser melhorado no atual sistema para atender aos
clientes?
b) Tempo: qual o tempo necessrio para que o produto desenvolvido tenha
vantagem competitiva?
c) Competidores: onde est a concorrncia e o que preciso para que o produto
desenvolvido os supere?
d) Qualidade: quais so as qualidades exigidas?
e) Viso: o que preciso mudar e adaptar no sistema para que o desenvolvimento
atinja a viso?
f) Recurso: o que existe disponvel de equipe e recursos financeiros para o
desenvolvimento?
Todas essas variveis so traduzidas em: caractersticas, melhorias, eliminao de bugs,
funcionalidades e tecnologias. Inicialmente, o Product Baklog pode ser considerado
incompleto, pois representa uma primeira lista do que o produto necessita para atender as
necessidades de mercado, porm como as necessidades mudam no decorrer do
desenvolvimento, altera-se tambm o Backlog do Produto de modo a adequ-lo as
exigncias (SCHWABER e BEEDLE, 2002).
- Sprint: so ciclos de trabalho que tem tipicamente de uma a quatro semanas de durao,
alm disso, seja qual for sua durao, essa j deve ser fixada desde o incio (SCHWABER
e SUTHERLAND, 2007). As tarefas e funcionalidades que sero realizadas durante esse
perodo formam o Backlog do Sprint.
- Reunio de planejamento do Sprint: aps a elaborao do Backlog do Produto h a
necessidade de se realizar uma reunio conhecida como Reunio de Planejamento do
Sprint (SCHWABER e SUTHERLAND, 2007). regida pelo Dono do Produto que rev
junto com o time todo Product Backlog e seleciona quais atividades faro parte do
Backlog do Sprint

- Backlog do Sprint: o resultado da Reunio de planejamento do Sprint. uma lista de

funcionalidades e atividades que devero ser desenvolvidas durante o Sprint. Os itens que
compem o Backlog do Sprint so selecionados do Backlog do Produto de acordo com
sua prioridade de execuo e estimativas (tamanho do time, horas disponveis e nvel de
produtividade do time) (SCHWABER e SUTHERLAND, 2007).
- Daily Scrum: a reunio que ocorre diariamente aps o inicio do primeiro Sprint na
qual o time se encontra com o Scrum Master. O Daily Scrum dura cerca de 15 minutos e
tambm conhecido por Stand-up Meeting por ser realizado de p (CARVALHO, 2009).
Nesse encontro, os desenvolvedores responder, um a um, a tres perguntas:
a) O que foi feito desde a ltima reunio?
b) Quais foram os problemas enfrentados?
c) O que ser feito at a prxima reunio?
O Daily Scrum ocorre durante toda execuo do projeto podendo ser representado por um
ciclo menor que compe um ciclo maior chamado Sprint (Figura 3).

Fonte: Cohn (2008)

Figura 3 - Viso geral da dinmica de processo Scrum

- Backlog de impedimentos: a lista de todos os impedimentos sentidos pelo time durante

o desenvolvimento do produto. elaborado durante o Daily Scrum, pois seus itens tem
origem na segunda questo abordada durante a reunio: Quais foram as dificuldades
enfrentadas?. O Scrum Master aquele responsvel por eliminar todos os impedimentos no
trabalho dos desenvolvedores, ou seja, os elementos do Backlog de Impedimentos so de
responsabilidade do Scrum Master, apenas aqueles que no podem ser resolvidos por ele so
encaminhados para o Dono do Produto ou a alta direo (CARVALHO, 2009).
- Reunio de retrospectiva: aps o termino de cada Sprint realizado uma reunio com o
time com o propsito de que o mesmo reflita sobre seu desempenho e proponha aes para os
futuros Sprints. Segundo Schwaber (2009), esse encontro tem durao de 3 horas.
2.3. Ferramentas auxiliares:

- Grfico Burndown: utilizado como uma ferramenta de apoio para a equipe por
representar a quantidade restante de esforo necessrio para o trmino o Backlog do Produto.
A unidade de esforo utilizada qualquer uma decidida pelo time (SCHWABER, 2009).
Alm disso, segundo Paulk e Davis (2009), a partir do Grfico Burndown que possvel
calcular velocidade ou produtividade do time.
3. Mtodo de Pesquisa
Para o desenvolvimento deste trabalho, foi realizada uma fundamentao terica sobre
o mtodo Scrum. Esta reviso buscou identificar na literatura cientfica os trabalhos
cientficos cujo tema principal ou secundrio fosse o Scrum. Sendo assim, este trabalho pode
ser caracterizado como terico-conceitual.
A proposta de uma sistemtica baseada na metodologia gil Scrum para o
desenvolvimento de produtos diferentes de software ser feita a partir dessa fundamentao
terica.
A escolha do Scrum ocorreu por ser uma metodologia mais leve quando comparada
com modelos tradicionais de gesto de projetos que, por exigirem documentao e
especificaes muito extensas, acabavam no se tornando aplicveis realidade de algumas
empresas empresa, especialmente as de micro e pequeno portes. Sendo assim, os objetivos da
proposta de uma nova sistemtica para o desenvolvimento de produtos que no sejam
necessariamente softwares expandir os benefcios do Scrum para outros ramos, ou seja:
a) reduzir o excesso de burocracia do PDP;
b) aumentar a agilidade do desenvolvimento;
c) reduzir o retrabalho durante o processo de desenvolvimento e, consequentemente, reduzir
custos;
d) minimizar atrasos;
e) aumentar a taxa de sucesso dos produtos desenvolvidos;
f) aumentar o controle e melhorar o acompanhamento no andamento do projeto pelo Product
Owner.
4. Proposta de Scrum para produtos
A sistemtica proposta para a gesto de projetos adaptar a metodologia Scrum para o
desenvolvimento de produtos que no sejam softwares sem, entretanto, comprometer seus
fundamentos.
Para a elaborao da sistemtica foram analisados todos os papis e ferramentas
propostos pela metodologia tradicional e, ento, proposta uma nova abordagem que
satisfizesse melhor s necessidades existentes no desenvolvimento de produtos de um modo
geral. Nos Quadros 1 e 2 estabelecido um paralelo entre o uso do Scrum em softwares e a
sistemtica proposta para outros projetos.
Papis
Time

Software
- Multi funcional
- Seus membros trabalham lado a
lado e se ajudam mutuamente
- Trabalham exclusivamente para o

Produto
- Multi funcional
- Seus membros se ajudam
mutuamente
- A maioria deve trabalhar

Scrum Master

Dono do Produto

projeto
- Possui 3 a 6 colaboradores
- quem tem mais domnio sobre a
metodologia
- Responsvel pelo sucesso do
projeto
- Executa os itens do Backlog de
Impedimentos
- o representante do cliente no
projeto
- Elabora o Backlog do produto e
do Sprint

exclusivamente para o projeto

- Possui 3 a 6 membros
- quem tem mais domnio sobre a
metodologia
- Rege o Daily Scrum, agora
chamado de Team Scrum.
- Realiza o controle do Sprint e do
Burndown Chart
- Rege a reunio de Planejamento e
de planejamento do Sprint
- Elabora o Backlog do produto e
do Sprint
- Insere itens no Backlog de
Impedimentos

Tabela 1 Papis existente no Scrum

Ferramentas
Realease planning meeting

Backlog do Produto

Software

Produto

- Reunio na qual definido como

o objetivo do projeto ser alcanado
- Dura certa de 15 a 20% do tempo
que geralmente duraria uma reunio
tradicional de planejamento
- So definidas as estimativas e
prioridade dos itens do Backlog do
Produto
- Lista dos incrementos e
funcionalidades que sero
desenvolvidas
- Apresenta estimativa de durao
para cada item
- elaborada pelo Dono do Produto

- Regida pelo Dono do Produto

- Scrum Master deve estar presente
- A partir dos requisitos do projeto,
elabora-se o Backlog do Produto
- So feitas as estimativas de tempo
e recursos
- Nesse momento, no so
definidas prioridades
- Lista de incrementos,
funcionalidades e atividades
necessrias para desenvolvimento
do produto
- Apresenta a prioridade de
execuo de cada item
- elaborado pelo Dono do
Produto
- Ciclo de trabalho com trs a seis
semanas
- Tem durao varivel durante o
projeto
- As atividades realizadas pelo time
so do Backlog do Sprint e de
Impedimentos
- Reunio regida pelo Dono do
Produto
- O time est presente na reunio
- Ocorre aps a reunio de
planejamento e antes do incio do
Sprint
- quando ser elaborado o
Backlog do Sprint e definidas a

Sprint

- Ciclo de trabalho com uma a

quatro semanas
- Tem durao fixa durante todo
projeto
- As atividades realizadas pelo time
so do Backlog do Sprint

Reunio de planejamento do Sprint

- Reunio regida pelo Dono do

Produto
- O time est presente na reunio
- Ocorre aps a reunio de
planejamento e antes do incio do
Sprint
- quando ser elaborado o
Backlog do Sprint e definida a

Backlog do Sprint

durao do Sprint
- So definidas metas para o
Sprint
- o produto da Reunio de
Planejamento do Sprint
- Tem origem no Backlog do
Produto
- Nele, os itens do Backlog do
Produto so desmembrados em
tarefas menores
- Est claro quais tarefas foram
originadas por cada funcionalidade.

Daily Scrum

- Reunio diria do time com o

Scrum Master
- Dura cerca de 15 minutos
- Os itens de discusso so apenas
trs (o que foi feito, o que ser feito
e quais foram as dificuldades)

Backlog de impedimentos

- Lista de itens para remoo de

algum impedimento
- Os itens so inseridos durante o
Daily Scrum
- Os itens so realizados pelo
Scrum Master

Reunio de retrospectiva

- Ela existe ao final de cada Sprint

- Todos participam
- Resulta em sugestes concretas de
melhoria
- Algumas dessas sugestes so
implementadas de fato.
- utilizado como ferramenta de
apoio para o time
- atualizado diariamente pelo
Scrum Master
- geralmente elaborado em
funo das horas de trabalho

Grafico Burndown

freqncia do Team Scrum e

durao do Sprint
- o produto da Reunio de
Planejamento do Sprint
- Tem origem no Backlog do
Produto
- Nele, os itens do Backlog do
Produto so desmembrados em
tarefas menores
- Podem ser includos itens do
Backlog de Impedimentos durante
o Sprint
- Seu contedo flexvel, podendo
acrescentar itens do Backlog do
Produto bem como tirar algum que
no seja mais prioritrio
- realizada de uma a duas vezes
por semana, recebendo o nome de
Team Scrum.
- Sua frequncia definida na
Reunio de Planejamento e
constante durante todo projeto
- Os itens de discusso so
principalmente: o que foi feito, o
que ser feito e quais foram as
dificuldades
- So permitidas pequenas
discusses tcnicas
- Dura cerca de 45 minutos.
- Lista de itens para a remoo de
algum impedimento
- Compe o Sprint Backlog
- Os itens so inseridos a cada
Daily Scrum pelo Product Owner
- Os itens podem ser desenvolvidos
pelo time ou partes externas
- Os itens so inseridos no Backlog
do Sprint como itens prioritrios
- Ela existe ao final de cada Sprint
- Todos participam
- Resulta em sugestes concretas de
melhoria
- Nela, so revistos itens como:
durao e contedo do Sprint
- utilizado como ferramenta de
apoio para o time
- atualizado aps cada Team
Scrum pelo Scrum Master
- elaborado em funo das horas
de trabalho estimadas para o

estimadas
- Representa a necessidade de
recursos necessrios para o
cumprimento de todos itens do
Backlog do Produto

cumprimento de todos itens do

Sprint Backlog
- utilizada uma linha cronolgica
abaixo do grfico que representa
onde o Sprint se encontra em
relao ao prazo de entrega

Figura 2 Ferramentas utilizadas no Scrum

5. Discusso
Baseando-se nos fundamentos da metodologia gil Scrum e na realidade de
desenvolvimento de produtos, a proposta de sistemtica procura adaptar o modelo tradicional
de modo que seja possvel utiliz-lo em desenvolvimento de produtos diversos.
Com relao aos papis desempenhados dentro de um projeto que utiliza o Scrum, a
sistemtica proposta mantm as caractersticas de cada um desses papis com pequenas
alteraes feitas de modo a se enquadrar na realidade das empresas, tais alteraes podem ser
vistas no Quadro 1.
Dentre as ferramentas, aquelas que mais sofreram modificaes foram:
- Daily Scrum: sua freqncia foi aumentada bem como sua durao e contedo. Um dos
motivos que gerou essas alteraes foi o fato de muitas das atividades realizadas durante o
desenvolvimento de outros produtos necessitarem de um perodo maior que um dia ou ento
de participao de colaboradores externos, prejudicando o controle dirio dessas atividades ou
elementos do Backlog do Sprint. Alm disso, a reunio que acontecia diariamente recebe
agora o nome de Team Scrum.
- Backlog de Impedimentos: diferentemente do que tradicionalmente proposto, o
Backlog de Impedimentos compe o Backlog do Sprint e no uma lista de atividades de
responsabilidade do Scrum Master para eliminao de problemas enfrentados pela equipe.
Alm disso, todo o time trabalha nos itens gerados para correo de algum problema sentido.
- Backlog do Produto: para a sua elaborao, o Dono do Produto se baseia nos requisitos
gerais e nos requisitos tcnicos do produto. Requisitos gerais so aqueles formados por
informaes de mercado (clientes potenciais) e quais so as funes a desempenhar.
Requisitos tcnicos englobam especificaes funcionais, operacionais e construtivas.
- Grfico Burndown: a unidade de medida adotada o nmero de tarefas a serem
desenvolvidas. Essas tarefas so aquelas que compem o Backlog do Sprint e so empilhadas
a cada Team Scrum. Na Figura 4, est representado uma proposta de painel de gesto a vista
para um projeto utilizando o Scrum. No caso no Grfico Burndown, as atividades em amarelo
so aquelas inseridas no primeiro Scrum, ou seja, aquelas que surgiram da pergunta O que
ser feito at o prximo encontro?. Em rosa, so atividades inseridas na segunda semana,
desse modo possvel observar tambm quais e quantas atividades esto atrasadas e podem
ser consideradas prioritrias para o desenvolvimento. Abaixo do grfico existe uma linha
cronolgica que preenchida aps cada reunio (assim como o Grfico Burndown) e auxilia a
equipe na visualizao do prazo final de entrega do produto e em que estgio se encontram.

10

Scrum Gesto a Vista

Backlog do Produto

Backlog do Sprint

Atividades

Burndown Chart

Fim do Sprint

Reunio

Linha cronolgica
Figura 4 Modelo de painel de um projeto utilizando Scrum

6. Concluso
Segundo Carvalho (2009), o Scrum mais amplamente usado na indstria de
desenvolvimento de software que vem crescendo nos ltimos anos, mas a metodologia j foi
aplicada tambm no desenvolvimento de produtos gerais ou mesmo de grupos de pesquisa.
Entretanto as publicaes feitas sobre outros contextos de aplicao da metodologia ainda
incipiente.
No caso do trabalho proposto, o objetivo da pesquisa foi desenvolver uma sistemtica para
que a metodologia possa ser aplicada em empresas nas quais no se desenvolvam softwares,
necessariamente.
A principal contribuio feita por esse trabalho a sistemtica proposta que utiliza uma
abordagem diferente do que relatado para os produtos de software. A motivao para sua
realizao era propiciar os mesmo benefcios do Scrum para empresas que no so da
indstria de software. Dentre os principais benefcios esperados com adoo da metodologia
esto:
a)

Melhoria na comunicao e aumento da colaborao entre envolvidos;

b)

Aumento da motivao da equipe de desenvolvimento;

c)

Diminuio no tempo gasto para terminar o projeto (prazo);

d)

Diminuio do risco do projeto (menor possibilidade de insucesso);

e)

Diminuio dos custos de produo (mo-de-obra);

f)

Aumento de produtividade da equipe.

11

Sendo assim, o trabalho cumpre seu objetivo propondo a sistemtica para gesto de
projetos por meio da abordagem do mtodo Scrum para o desenvolvimento de produtos cujo
resultado no seja um software.
Referncias
ADVANCED DEVELOPMENT METHODS. Scrum Methodology - incremental, iterative software
development. 2003
AGUANNO, K. Managing Projects. 1. ed. Multi-Media Publications, 2005.
CARVALHO, B. V. Aplicao do mtodo gil Scrum no desenvolvimento de produtos de softwares em uma
empresa de base tecnolgica. Dissertao de Mestrado. Programa de Ps-Graduao em Engenharia de
Produo. Universidade Federal de Itajub/MG, 2009.
CARVALHO, B. V. ; MELLO, C. H. P. Reviso, anlise e classificao da literatura sobre o mtodo de
desenvolvimento de produtos gil scrum. Anais do XII Simpsio de Administrao da Produo, Logstica e
Operaes Internacionais - SIMPOI, So Paulo/SP, 2009.
COHN, M. Mountain Goat Software. 2008. Disponvel em: <http://www.mountaingoatsoftware.com/>. Acesso
em 15 nov. 2009.
COUGHLAN, P.; COGHLAN, D. Action Research for operations management. International Journal of
Operations & Production Management, v. 22, n. 2, p. 220-240, 2002.
JOHNSON, J. The Chaos Report. The Standish Group International, Inc. West Yarmouth, MA, 1995.
JOHNSON, J. The Chaos Report. The Standish Group International, Inc. West Yarmouth, MA, 2001.
JRGENSEN, M. MOLKKEN, K. How large are software cost overruns? Critical Comments on the
Standish Groups CHAOS Reports. Information and Software Technology. Volume 48, Issue 4, p. 297-301.
2006.
LOESER, A. Project Management and Scrum a side by side comparison. 2006
MANIFESTO GIL, 2001. Disponvel em: <http://www.manifestoagil.com.br/>. Acesso em: mar. 2010.
MARCHESI, M.; MANNARO, K.; URAS, S.; LOCCI, M. Distributed Scrum in research project
management. 2007.
PAULK, M.C.; DAVIS, N. On empirical research
<http://www.scrumalliance.org/>. Acesso em out. 2009.

into

Scrum.

2009.

Disponivel

em

SCHWABER, K. The enterprise and Scrum. Ed. Microsoft, 2007.

SCHWABER, K. Scrum development process, 1987. Disponvel em: <http://scholar.google.com.br>. Acesso:
set. 2009.
SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. Prentice Hall, 2002.
SUTHERLAND, J.; SCHWABER, K. The Scrum papers: nuts, bolts, and origin of an agile process, 2007.
Disponvel em: <http://scrumtraininginstitute.com/>. Acesso em set. 2009.
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p. 137146, 1986.

12