Gestão de Projetos com Scrum

Prévia do material em texto

PROPOSTA DE SISTEMÁTICA PARA 
GESTÃO 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 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 DEVELOPMENTMETHODS, 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. 
Highlight
Highlight
Highlight
Highlight
Highlight
Highlight
Highlight
Highlight
Highlight
Highlight
Highlight
Highlight
 
 
 
 
 
 
11 
Scrum– Gestão a Vista
Backlog do Produto Backlog do Sprint
Burndown Chart
Fim do Sprint
A
ti
vi
d
ad
es
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çãoda 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.