proposta de sistemÁtica para gestÃo de projetos … · enfrentadas?”. o scrum master é aquele...
TRANSCRIPT
PROPOSTA DE SISTEMÁTICA PARA
GESTÃO DE PROJETOS BASEADA NA
METODOLOGIA ÁGIL SCRUM
Tanara Priscilla Ribeiro Rose (UNIFEI)
Carlos Henrique Pereira Mello (UNIFEI)
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 várias metodologias ágeis para gestão de
desenvolvimento de produto como, por exemplo, o Scrum do Ken
Schwaber, Jeff Sutherland e Mike Beedle. Dos princípios defendidos
por essas metodologias, surge o Manifesto Ágil no fim do século XX.
Essas metodologias ágeis foram mais amplamente aplicadas na
indústria de software o que não anula sua aplicabilidade em outro tipo
de desenvolvimento. A literatura que aborda outros contextos de
aplicação do Scrum ainda é bastante incipiente e a proposta desse
trabalho é propor uma sistemática para gestão de projetos baseada no
Scrum.
Palavras-chaves: Scrum, Processo de Desenvolvimento de Produto,
Movimento Ágil.
XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO Maturidade e desafios da Engenharia de Produção: competitividade das empresas, condições de trabalho, meio ambiente.
São Carlos, SP, Brasil, 12 a15 de outubro de 2010.
2
1. Introdução
No atual ambiente ágil de desenvolvimento de produtos onde a velocidade para
lançamento de novos produtos, associada à qualidade e preço acessível são fatores essenciais
para um posicionamento estratégico da empresa no mercado (WHEELWRIGTH E CLARK,
1992), torna-se essencial um bom modelo de gestão. Na indústria de software não é 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 razão para
essa preocupação é que o gasto americano em projetos de aplicações de software chegou a
US$ 275 bilhões somente no ano de 1994.
Nesse estudo, fica comprovada que a taxa de sucesso para projetos acima de US$10
milhões (que envolvem mais de quinhentas pessoas, por pelo menos três anos), é
estatisticamente nula (JOHNSON, 1995). Já para pequenos projetos, de até US$ 750 mil, a
taxa de sucesso é 55%.
Outras informações obtidas nesse estudo (aumento dos custos, atraso na entrega,
funcionalidades implementadas e taxa de sucesso) estão 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 usuário final.
Fonte: Adaptado de Johnson (2001)
Figura 1 – Evolução dos parâmetros de 1994 a 2003
3
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 gestão de desenvolvimento de produtos que
vem ganhando espaço, principalmente na indústria de softwares, onde foi tradicionalmente
empregado, mas já vem sendo usado no desenvolvimento de outros produtos que não 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 aplicação do Scrum no desenvolvimento de produtos de software. Em virtude
disso, o presente trabalho tem por objetivo propor uma sistemática para gestão de projetos por
meio da abordagem do método Scrum para o desenvolvimento de produtos cujo resultado não
seja um software.
2. Fundamentação Teórica
Por décadas o desenvolvimento de software seguiu o modelo clássico de cascata para
desenvolvimento de produtos. Nesse modelo, o projeto passa por diversas etapas (análise,
design, documentação, codificação e testes) antes de ser entregue ao cliente (LOESER, 2006),
diminuindo a flexibilidade do processo e prejudicando a obtenção de repostas rápidas às
exigências de mercado por parte da empresa. Esse enrijecimento do modelo de gestão 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 documentação 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 princípios do
4
desenvolvimento ágil: desenvolvimento de projetos que atendam aos clientes, projetos
flexíveis e indivíduos e iterações ao invés de processos e ferramentas (MANIFESTO AGIL,
2001).
O texto no qual foram expostos os ideais do manifesto conta com dezessete signatários
dentro dos quais se encontra os três 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 obtenção 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 empírica, o Scrum se desenvolveu como uma
abordagem iterativa, incremental de otimização da previsibilidade e controle de riscos. E três
pilares sustentam essa metodologia (SCHWABER, 2009):
-Transparência: garante que todos os aspectos relevantes ao sucesso do processo se
mantenham visíveis e conhecidos de modo a garantir que o resultado obtido seja coerente ao
definido previamente;
- Inspeção: é feita com finalidade de se detectar qualquer não conformidade que possa vir
a prejudicar os resultados da equipe;
- Adaptação: a partir da identificação da irregularidade são feitas adaptações no processo
ou no material em processo, reduzindo a probabilidade de um resultado insatisfatório.
Quanto às características do Scrum, Schwaber (1987) lista seis principais características:
- Entregas flexíveis:o conteúdo das entregas é definido de acordo com as necessidades de
mercado ou do cliente;
- Flexibilidade dos prazos: as entregas podem ser requisitadas antes ou após do
inicialmente planejado;
- Pequenos times: geralmente não é composto por mais de 6 membros;
- Revisões frequentes:revisões são feitas durante todo progresso do time;
- Colaboração: há intra e inter colaboração entre os membros;
- Orientação: cada time irá listar os objetos com interface e comportamento bem
definidos.
Tradicionalmente, o Scrum é usado em empresas que desenvolvem software e propõe a
adoção de alguns papéis, ferramentas e ferramentas auxiliares para a gestão do
desenvolvimento de produtos:
2.1. Papéis:
- 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.
5
- Scrum Master: o Scrum Master é o responsável pelo sucesso do projeto, uma vez que é
aquele que garante que todos os fundamentos da metodologia estão sendo seguidos
(SCHWABER E BEEDLE, 2002).
- Dono do Produto: O Dono do Produto é o representante do cliente na equipe
(AGUANNO, 2005), focando suas ações na maximização do valor do produto para atender às
partes interessadas, clientes e usuários (ADVANCED DEVELOPMENT METHODS, 2003).
2.2. Ferramentas:
- Realease planning meeting: tem como objetivo definir as métricas do projeto. As
definições feitas surgem da pergunta “Como podemos fazer com que a visão em um
produto de sucesso? Como podemos satisfazer às vontades do cliente e ter um retorno de
investimento?”. Segundo Schwaber (2009), nessa reunião são 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 são definidos os itens com compõem o
Backlog do Sprint.
Segundo Schwaber (1987), para a definição dos requisitos do Product Backlog no
desenvolvimento de um software são levadas em consideração seis variáveis:
a) Requisitos do cliente: o que deve ser melhorado no atual sistema para atender aos
clientes?
b) Tempo: qual é o tempo necessário para que o produto desenvolvido tenha
vantagem competitiva?
c) Competidores: onde está a concorrência e o que é preciso para que o produto
desenvolvido os supere?
d) Qualidade: quais são as qualidades exigidas?
e) Visão: o que é preciso mudar e adaptar no sistema para que o desenvolvimento
atinja a visão?
f) Recurso: o que existe disponível de equipe e recursos financeiros para o
desenvolvimento?
Todas essas variáveis são traduzidas em: características, melhorias, eliminação 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, porém como as necessidades mudam no decorrer do
desenvolvimento, altera-se também o Backlog do Produto de modo a adequá-lo as
exigências (SCHWABER e BEEDLE, 2002).
- Sprint: são ciclos de trabalho que tem tipicamente de uma a quatro semanas de duração,
além disso, seja qual for sua duração, essa já deve ser fixada desde o início (SCHWABER
e SUTHERLAND, 2007). As tarefas e funcionalidades que serão realizadas durante esse
período formam o Backlog do Sprint.
- Reunião de planejamento do Sprint: após a elaboração do Backlog do Produto há a
necessidade de se realizar uma reunião conhecida como Reunião 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 farão parte do
Backlog do Sprint
6
- Backlog do Sprint: é o resultado da Reunião de planejamento do Sprint. É uma lista de
funcionalidades e atividades que deverão ser desenvolvidas durante o Sprint. Os itens que
compõem o Backlog do Sprint são selecionados do Backlog do Produto de acordo com
sua prioridade de execução e estimativas (tamanho do time, horas disponíveis e nível de
produtividade do time) (SCHWABER e SUTHERLAND, 2007).
- Daily Scrum: É a reunião que ocorre diariamente após o inicio do primeiro Sprint na
qual o time se encontra com o Scrum Master. O Daily Scrum dura cerca de 15 minutos e é
também 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 reunião?
b) Quais foram os problemas enfrentados?
c) O que será feito até a próxima reunião?
O Daily Scrum ocorre durante toda execução do projeto podendo ser representado por um
ciclo menor que compõe um ciclo maior chamado Sprint (Figura 3).
Fonte: Cohn (2008)
Figura 3 - Visão geral da dinâmica 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 questão abordada durante a reunião: “Quais foram as dificuldades
enfrentadas?”. O Scrum Master é aquele responsável por eliminar todos os impedimentos no
trabalho dos desenvolvedores, ou seja, os elementos do Backlog de Impedimentos são de
responsabilidade do Scrum Master, apenas aqueles que não podem ser resolvidos por ele são
encaminhados para o Dono do Produto ou a alta direção (CARVALHO, 2009).
- Reunião de retrospectiva: após o termino de cada Sprint é realizado uma reunião com o
time com o propósito de que o mesmo reflita sobre seu desempenho e proponha ações para os
futuros Sprints. Segundo Schwaber (2009), esse encontro tem duração de 3 horas.
2.3. Ferramentas auxiliares:
7
- Gráfico Burndown: é utilizado como uma ferramenta de apoio para a equipe por
representar a quantidade restante de esforço necessário para o término o Backlog do Produto.
A unidade de esforço utilizada é qualquer uma decidida pelo time (SCHWABER, 2009).
Além disso, segundo Paulk e Davis (2009), é a partir do Gráfico Burndown que é possível
calcular velocidade ou produtividade do time.
3. Método de Pesquisa
Para o desenvolvimento deste trabalho, foi realizada uma fundamentação teórica sobre
o método Scrum. Esta revisão buscou identificar na literatura científica os trabalhos
científicos cujo tema principal ou secundário fosse o Scrum. Sendo assim, este trabalho pode
ser caracterizado como teórico-conceitual.
A proposta de uma sistemática baseada na metodologia ágil Scrum para o
desenvolvimento de produtos diferentes de software será feita a partir dessa fundamentação
teórica.
A escolha do Scrum ocorreu por ser uma metodologia mais leve quando comparada
com modelos tradicionais de gestão de projetos que, por exigirem documentação e
especificações muito extensas, acabavam não se tornando aplicáveis à realidade de algumas
empresas empresa, especialmente as de micro e pequeno portes. Sendo assim, os objetivos da
proposta de uma nova sistemática para o desenvolvimento de produtos que não sejam
necessariamente softwares é expandir os benefícios 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 sistemática proposta para a gestão de projetos é adaptar a metodologia Scrum para o
desenvolvimento de produtos que não sejam softwares sem, entretanto, comprometer seus
fundamentos.
Para a elaboração da sistemática foram analisados todos os papéis e ferramentas
propostos pela metodologia tradicional e, então, 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
sistemática proposta para outros projetos.
Papéis Software Produto
Time - Multi funcional
- Seus membros trabalham lado a
lado e se ajudam mutuamente
- Trabalham exclusivamente para o
- Multi funcional
- Seus membros se ajudam
mutuamente
- A maioria deve trabalhar
8
projeto
- Possui 3 a 6 colaboradores
exclusivamente para o projeto
- Possui 3 a 6 membros
Scrum Master - É quem tem mais domínio sobre a
metodologia
- Responsável pelo sucesso do
projeto
- Executa os itens do Backlog de
Impedimentos
- É quem tem mais domínio sobre a
metodologia
- Rege o Daily Scrum, agora
chamado de Team Scrum.
- Realiza o controle do Sprint e do
Burndown Chart
Dono do Produto - É o representante do cliente no
projeto
- Elabora o Backlog do produto e
do Sprint
- Rege a reunião de Planejamento e
de planejamento do Sprint
- Elabora o Backlog do produto e
do Sprint
- Insere itens no Backlog de
Impedimentos
Tabela 1 – Papéis existente no Scrum
Ferramentas Software Produto
Realease planning meeting - Reunião na qual é definido como
o objetivo do projeto será alcançado
- Dura certa de 15 a 20% do tempo
que geralmente duraria uma reunião
tradicional de planejamento
- São definidas as estimativas e
prioridade dos itens do Backlog do
Produto
- Regida pelo Dono do Produto
- Scrum Master deve estar presente
- A partir dos requisitos do projeto,
elabora-se o Backlog do Produto
- São feitas as estimativas de tempo
e recursos
- Nesse momento, não são
definidas prioridades
Backlog do Produto - Lista dos incrementos e
funcionalidades que serão
desenvolvidas
- Apresenta estimativa de duração
para cada item
- É elaborada pelo Dono do Produto
- Lista de incrementos,
funcionalidades e atividades
necessárias para desenvolvimento
do produto
- Apresenta a prioridade de
execução de cada item
- É elaborado pelo Dono do
Produto
Sprint - Ciclo de trabalho com uma a
quatro semanas
- Tem duração fixa durante todo
projeto
- As atividades realizadas pelo time
são do Backlog do Sprint
- Ciclo de trabalho com três a seis
semanas
- Tem duração variável durante o
projeto
- As atividades realizadas pelo time
são do Backlog do Sprint e de
Impedimentos
Reunião de planejamento do Sprint - Reunião regida pelo Dono do
Produto
- O time está presente na reunião
- Ocorre após a reunião de
planejamento e antes do início do
Sprint
- É quando será elaborado o
Backlog do Sprint e definida a
- Reunião regida pelo Dono do
Produto
- O time está presente na reunião
- Ocorre após a reunião de
planejamento e antes do início do
Sprint
- É quando será elaborado o
Backlog do Sprint e definidas a
9
duração do Sprint
- São definidas metas para o
Sprint
freqüência do Team Scrum e
duração do Sprint
Backlog do Sprint - É o produto da Reunião de
Planejamento do Sprint
- Tem origem no Backlog do
Produto
- Nele, os itens do Backlog do
Produto são desmembrados em
tarefas menores
- Está claro quais tarefas foram
originadas por cada funcionalidade.
- É o produto da Reunião de
Planejamento do Sprint
- Tem origem no Backlog do
Produto
- Nele, os itens do Backlog do
Produto são desmembrados em
tarefas menores
- Podem ser incluídos itens do
Backlog de Impedimentos durante
o Sprint
- Seu conteúdo é flexível, podendo
acrescentar itens do Backlog do
Produto bem como tirar algum que
não seja mais prioritário
Daily Scrum - Reunião diária do time com o
Scrum Master
- Dura cerca de 15 minutos
- Os itens de discussão são apenas
três (o que foi feito, o que será feito
e quais foram as dificuldades)
- É realizada de uma a duas vezes
por semana, recebendo o nome de
Team Scrum.
- Sua frequência é definida na
Reunião de Planejamento e é
constante durante todo projeto
- Os itens de discussão são
principalmente: o que foi feito, o
que será feito e quais foram as
dificuldades
- São permitidas pequenas
discussões técnicas
- Dura cerca de 45 minutos.
Backlog de impedimentos - Lista de itens para remoção de
algum impedimento
- Os itens são inseridos durante o
Daily Scrum
- Os itens são realizados pelo
Scrum Master
- Lista de itens para a remoção de
algum impedimento
- Compõe o Sprint Backlog
- Os itens são inseridos a cada
Daily Scrum pelo Product Owner
- Os itens podem ser desenvolvidos
pelo time ou partes externas
- Os itens são inseridos no Backlog
do Sprint como itens prioritários
Reunião de retrospectiva - Ela existe ao final de cada Sprint
- Todos participam
- Resulta em sugestões concretas de
melhoria
- Algumas dessas sugestões são
implementadas de fato.
- Ela existe ao final de cada Sprint
- Todos participam
- Resulta em sugestões concretas de
melhoria
- Nela, são revistos itens como:
duração e conteúdo do Sprint
Grafico Burndown - É utilizado como ferramenta de
apoio para o time
- É atualizado diariamente pelo
Scrum Master
- É geralmente elaborado em
função das horas de trabalho
- É utilizado como ferramenta de
apoio para o time
- É atualizado após cada Team
Scrum pelo Scrum Master
- É elaborado em função das horas
de trabalho estimadas para o
10
estimadas
- Representa a necessidade de
recursos necessários para o
cumprimento de todos itens do
Backlog do Produto
cumprimento de todos itens do
Sprint Backlog
- É utilizada uma linha cronológica
abaixo do gráfico que representa
onde o Sprint se encontra em
relação ao prazo de entrega
Figura 2 – Ferramentas utilizadas no Scrum
5. Discussão
Baseando-se nos fundamentos da metodologia ágil Scrum e na realidade de
desenvolvimento de produtos, a proposta de sistemática procura adaptar o modelo tradicional
de modo que seja possível utilizá-lo em desenvolvimento de produtos diversos.
Com relação aos papéis desempenhados dentro de um projeto que utiliza o Scrum, a
sistemática proposta mantém as características de cada um desses papéis com pequenas
alterações feitas de modo a se enquadrar na realidade das empresas, tais alterações podem ser
vistas no Quadro 1.
Dentre as ferramentas, aquelas que mais sofreram modificações foram:
- Daily Scrum: sua freqüência foi aumentada bem como sua duração e conteúdo. Um dos
motivos que gerou essas alterações foi o fato de muitas das atividades realizadas durante o
desenvolvimento de outros produtos necessitarem de um período maior que um dia ou então
de participação de colaboradores externos, prejudicando o controle diário dessas atividades ou
elementos do Backlog do Sprint. Além disso, a reunião que acontecia diariamente recebe
agora o nome de Team Scrum.
- Backlog de Impedimentos: diferentemente do que é tradicionalmente proposto, o
Backlog de Impedimentos compõe o Backlog do Sprint e não é uma lista de atividades de
responsabilidade do Scrum Master para eliminação de problemas enfrentados pela equipe.
Além disso, todo o time trabalha nos itens gerados para correção de algum problema sentido.
- Backlog do Produto: para a sua elaboração, o Dono do Produto se baseia nos requisitos
gerais e nos requisitos técnicos do produto. Requisitos gerais são aqueles formados por
informações de mercado (clientes potenciais) e quais são as funções a desempenhar.
Requisitos técnicos englobam especificações funcionais, operacionais e construtivas.
- Gráfico Burndown: a unidade de medida adotada é o número de tarefas a serem
desenvolvidas. Essas tarefas são aquelas que compõem o Backlog do Sprint e são empilhadas
a cada Team Scrum. Na Figura 4, está representado uma proposta de painel de gestão a vista
para um projeto utilizando o Scrum. No caso no Gráfico Burndown, as atividades em amarelo
são aquelas inseridas no primeiro Scrum, ou seja, aquelas que surgiram da pergunta “O que
será feito até o próximo encontro?”. Em rosa, são atividades inseridas na segunda semana,
desse modo é possível observar também quais e quantas atividades estão atrasadas e podem
ser consideradas prioritárias para o desenvolvimento. Abaixo do gráfico existe uma linha
cronológica que é preenchida após cada reunião (assim como o Gráfico Burndown) e auxilia a
equipe na visualização do prazo final de entrega do produto e em que estágio se encontram.
11
Scrum– Gestão a Vista
Backlog do Produto Backlog do Sprint
Burndown Chart
Fim do Sprint
Ati
vid
ades
Reunião
Linha cronológica
Figura 4 – Modelo de painel de um projeto utilizando Scrum
6. Conclusão
Segundo Carvalho (2009), o Scrum é mais amplamente usado na indústria de
desenvolvimento de software que vem crescendo nos últimos anos, mas a metodologia já foi
aplicada também no desenvolvimento de produtos gerais ou mesmo de grupos de pesquisa.
Entretanto as publicações feitas sobre outros contextos de aplicação da metodologia ainda é
incipiente.
No caso do trabalho proposto, o objetivo da pesquisa foi desenvolver uma sistemática para
que a metodologia possa ser aplicada em empresas nas quais não se desenvolvam softwares,
necessariamente.
A principal contribuição feita por esse trabalho é a sistemática proposta que utiliza uma
abordagem diferente do que é relatado para os produtos de software. A motivação para sua
realização era propiciar os mesmo benefícios do Scrum para empresas que não são da
indústria de software. Dentre os principais benefícios esperados com adoção da metodologia
estão:
a) Melhoria na comunicação e aumento da colaboração entre envolvidos;
b) Aumento da motivação da equipe de desenvolvimento;
c) Diminuição no tempo gasto para terminar o projeto (prazo);
d) Diminuição do risco do projeto (menor possibilidade de insucesso);
e) Diminuição dos custos de produção (mão-de-obra);
f) Aumento de produtividade da equipe.
12
Sendo assim, o trabalho cumpre seu objetivo propondo a sistemática para gestão de
projetos por meio da abordagem do método Scrum para o desenvolvimento de produtos cujo
resultado não seja um software.
Referências
ADVANCED DEVELOPMENT METHODS. Scrum Methodology - incremental, iterative software
development. 2003
AGUANNO, K. Managing Projects. 1. ed. Multi-Media Publications, 2005.
CARVALHO, B. V. Aplicação do método ágil Scrum no desenvolvimento de produtos de softwares em uma
empresa de base tecnológica. Dissertação de Mestrado. Programa de Pós-Graduação em Engenharia de
Produção. Universidade Federal de Itajubá/MG, 2009.
CARVALHO, B. V. ; MELLO, C. H. P. Revisão, análise e classificação da literatura sobre o método de
desenvolvimento de produtos ágil scrum. Anais do XII Simpósio de Administração da Produção, Logística e
Operações Internacionais - SIMPOI, São Paulo/SP, 2009.
COHN, M. Mountain Goat Software. 2008. Disponível 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.
JØRGENSEN, M. MOLØKKEN, K. How large are software cost overruns? Critical Comments on the
Standish Group’s 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. Disponível 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 into Scrum. 2009. Disponivel em
<http://www.scrumalliance.org/>. Acesso em out. 2009.
SCHWABER, K. The enterprise and Scrum. Ed. Microsoft, 2007.
SCHWABER, K. Scrum development process, 1987. Disponível 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.
Disponível em: <http://scrumtraininginstitute.com/>. Acesso em set. 2009.
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p. 137-
146, 1986.