APLICAÇÃO DA METODOLOGIA SCRUM EM UMA ÁREA DE ENGENHARIA DE PROCESSOS DE UMA EMPRESA DO VAREJO Luísa dos Prazeres Lopes Rio de Janeiro Fevereiro de 2017 Projeto de Graduação apresentado ao Curso de Engenharia de Produção da Escola Politécnica, da Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientador: Renato Flórido Cameira
98
Embed
APLICAÇÃO DA METODOLOGIA SCRUM EM UMA …monografias.poli.ufrj.br/monografias/monopoli10020157.pdf · clarify the agile project management methodologies in counterpoint of the traditional
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
APLICAÇÃO DA METODOLOGIA SCRUM EM UMA ÁREA DE ENGENHARIA
DE PROCESSOS DE UMA EMPRESA DO VAREJO
Luísa dos Prazeres Lopes
Rio de Janeiro
Fevereiro de 2017
Projeto de Graduação apresentado ao Curso de
Engenharia de Produção da Escola Politécnica, da
Universidade Federal do Rio de Janeiro, como
parte dos requisitos necessários à obtenção do
título de Engenheiro.
Orientador: Renato Flórido Cameira
iii
Lopes, Luísa
Aplicação da Metodologia Scrum em uma Área de
Engenharia de Processos/ Luísa dos Prazeres Lopes – Rio
de janeiro: UFRJ/ Escola Politécnica, 2017.
XI, 94p.: il.; 29,7cm
Orientador: Renato Flórido Cameira
Projeto de Graduação – UFRJ/Escola Politécnica/ Curso
de Engenharia Produção, 2017.
Referências Bibliográficas: p. 62 - 65.
1. Scrum. 2.Gerenciamento de projetos 3. Gerenciamento de
projetos Ágil I. Cameira, Renato Flórido II. Universidade
Federal do Rio de Janeiro, Escola Politécnica, Curso de
Engenharia de Produção. III. Aplicação da Metodologia
Scrum em uma Área de Engenharia de Processos.
iv
Agradecimentos
Agradeço imensamente aos meus pais, cujo apoio e dedicação me permitiram chegar até
aqui. Obrigada pela motivação e amor de sempre. À minha irmã Beatriz, agradeço por
fazer meus dias mais felizes.
Agradeço ao meu namorado Gabriel cujo companheirismo foi fundamental para mim,
nesse projeto e na vida. Obrigada por dividir esses momentos comigo, pela
compreensão e carinho.
Agradeço também ao professor Cameira pelo incentivo e atenção durante todo o
processo.
Agradeço aos meus amigos do curso de Engenharia de Produção por partilharem
comigo tantos momentos de alegria que já deixam saudades e que levarei sempre
comigo.
Por fim, agradeço à UFRJ, instituição que me proporcionou as melhores e mais
enriquecedoras experiências que vivi até hoje. Espero um dia ser capaz de retribur ao
menos um pouco tudo aquilo que recebi.
v
Resumo do Projeto de Graduação apresentado à Escola Politécnica/ UFRJ como parte
dos requisitos necessários para a obtenção do grau de engenheiro de Produção.
APLICAÇÃO DA METODOLOGIA SCRUM EM UMA ÁREA DE
ENGENHARIA DE PROCESSOS DE UMA EMPRESA DO VAREJO
Luísa dos Prazeres Lopes
Fevereiro/2017
Orientador: Renato Flórido Cameira
Curso: Engenharia de Produção
Resumo: O trabalho tem como objetivo analisar a aplicação da metodologia
Scrum, normalmente utilizada para o desenvolvimento de software, na gestão do
trabalho em uma área empresarial do varejo brasileiro. Para tal, esse projeto pretende
apresentar as metodologias de gerenciamento de projetos ágil em contraponto ao
gerenciamento tradicional. A partir dessas definições o caso de estudo será explorado
para se chegar a conclusões sobre os impactos, benefícios e possíveis deficiências
encontradas com a utilização do Scrum em tal cenário.
Palavras-chave: Scrum, Gerenciamento de Projetos, Gerenciamento de Projetos Ágil
vi
Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of
the requirements for the degree of Industrial Engineer
APPLICATION OF THE SCRUM METHODOLOGY IN A PROCESS
ENGINEERING AREA OF A RETAIL COMPANY
Luísa dos Prazeres Lopes
February/2017
Advisor: Renato Flórido Cameira
Course: Industrial Engineering
Abstract: This Project aims to analyze the application of the Scrum
methodology, usually used to develop software, in the management of the work of a
team in a retail Brazilian company. In order to achieve that, this project intends to
clarify the agile project management methodologies in counterpoint of the traditional
project management methodology. Based on such definitions, the case of study will be
explored so that conclusions can be made about the impacts, benefits e possible gaps
found in the application of Scrum in such scenario.
Tabela 5 - Termos utilizados na pesquisa. ...................................................................... 71
Tabela 6 - Seleção do artigo selecionado. ...................................................................... 73
Tabela 7 - Seleção dos livros, sites e dissertações segundo critérios de inclusão. ......... 74
Tabela 8 - Tabela resumo da lteratura selecionada......................................................... 74
Tabela 9 - Comparativo PMBOK x Scrum. ................................................................... 93
xi
Lista de Abreviaturas e Siglas
PMI – Project Management Institute
PMBOK – Project Management Body of Knowledge
OOPSLA – Object-Oriented Programming Systems, Languages and Applications
TI – Tecnologia da Informação
PDV – Ponto de Venda
MMCI – Modelo de Maturidade em Capacitação - Integração
9
1 INTRODUÇÃO
No atual cenário empresarial, agilidade tornou-se uma característica essencial
para a sobrevivência de uma companhia. Dessa forma, as empresas cada vez mais
demandam sistemas que constantemente atendam às suas necessidades de mudança
(DUANE ET AL., 1999). Assim, a velocidade de entrega dos projetos torna-se crucial
para seu sucesso. Além da rapidez, a flexibilidade para atender às contínuas
modificações também se transforma em atributo necessário para a efetividade de um
projeto na empresa. Nesse contexto, metodologias tradicionais de gerenciamento de
projeto podem não ser adequadas para que diversos produtos finais sejam satisfatórios.
Dessa forma, esse projeto tem a intenção de estudar o caso da aplicação de uma
metodologia de gerenciamento ágil em uma área de processos, envolvido em diversos
projetos interdepartamentais de uma grande empresa do varejo brasileiro que
anteriormente utilizava métodos do gerenciamento de projetos tradicional para conduzir
suas iniciativas.
A área em questão foi criada com o objetivo de compreender as carências nos
processos nas lojas da empresa e, assim, ser capaz de selecionar e implementar projetos
com melhorias adequadas alinhadas ao negócio da organização. A partir do
mapeamento dos processos de negócio da empresa, a área busca encontrar os pontos
críticos e melhora-los.
Buscando uma fundamentação teórica, o primeiro capítulo desse projeto buscará
definir e entender o método tradicional de gerenciamento de projetos a partir da
literatura existente sobre o assunto e aos materiais comumente utilizados pelos
profissionais desse ramo. Em seguida, o segundo capítulo tem o objetivo de fazer o
mesmo com o método ágil. No Apêndice A é possível encontrar um mapeamento
sistemático da literatura que explicita os critérios de seleção da literatura para tal
embasamento teórico.
À luz desses esclarecimentos, no capítulo três serão apontadas as similaridades e
diferenças entre tais metodologias, além de seus pontos positivos e negativos. Após esse
embasamento, será descrita a aplicação da metodologia Scrum no cenário do estudo de
caso. Após tal análise, serão então obtidas conclusões sobre a aplicação do Scrum em
um cenário empresarial contemporâneo.
10
Após examinar os resultados através de um ponto de vista teórico - pela análise
a partir de um modelo de maturidade - e outro prático - através de pesquisas de
percepção com os envolvidos - serão então estipuladas metas com o propósito de sanar
os principais pontos falhos encontrados.
1.1 Metodologia
Metodologia é o estudo da organização dos caminhos a serem percorridos, para
se realizar uma pesquisa ou um estudo, ou para se fazer ciência (GERHARDT,
SILVEIRA, 2009). Ou seja, o caminho escolhido deve ser válido para que o projeto seja
consistente e atinja seu objetivo final. Dessa forma, será utilizada a pesquisa
bibliográfica para se obter o conhecimento teórico atual (estado da arte) e as
ferramentas, técnicas e métodos atuais (estado da técnica). Ademais, será investigada a
forma como as empresas habitualmente se comportam em relação ao tema (estado da
prática) e para tal será utilizada o recurso do estudo de caso. Essa foi a estratégia
escolhida, pois é utilizada ao se examinar acontecimentos contemporâneos, mas quando
não é possível manipular comportamentos relevantes. Também devido ao fato de o
poder diferenciador do estudo ser a sua capacidade de lidar com uma ampla variedade
de evidências - documentos, artefatos, entrevistas e observações (YIN, 2001) – essa
tática foi a selecionada.
Além disso, foi utilizada a técnica da pesquisa-ação. A pesquisa-ação consiste na
“identificação de estratégias de ação planejada que são implementadas e, a seguir,
sistematicamente submetidas à observação, reflexão e mudança” (GRUNDY,
KEMMIS, 1982). O primeiro passo para a pesquisa-ação é o reconhecimento, através de
uma análise situacional que busca produzir uma visão geral do contexto do caso. O
passo seguinte é, então, mudanças para a melhora da prática a partir da análise feita. Por
último é realizado o monitoramento das mudanças. A figura 1 descreve a metodologia:
11
Figura 1: Ciclo de pesquisa-ação.
Fonte: TRIPP D. (2005, p. 446).
No caso desse trabalho, foram realizados os passos de investigação e
planejamento da melhora da prática devido à falta de autonomia para aplicação das
etapas seguintes.
1.2 Objetivo Geral
A essência de um estudo de caso é tentar esclarecer uma decisão ou um conjunto
de decisões: o motivo pelo qual foram tomadas, como foram implementadas e com
quais resultados (SCHRAMM, 1971). Essa é também a natureza desse trabalho:
Compreender por quê o Scrum está sendo escolhido como uma nova metodologia de
gerenciamento de projetos, decifrar a forma como a técnica é implantada em um cenário
empresarial e, por fim, investigar suas consequências, pontos positivos e suas possíveis
deficiências.
1.3 Objetivos Específicos
O projeto tem o objetivo específico de examinar a aplicação da metodologia
Scrum na área do estudo de caso e, a partir da análise da maturidade da metodologia no
caso analisado, da percepção dos envolvidos no caso e das melhores práticas
encontradas na literatura.
Além disso, o estudo tem o objetivo de propor um plano de ação de melhorias
atravésda estipulação de métricas e metas com o objetivo de propor uma melhor
12
utilização da metodologia Scrum para o gerenciamento das atividades no cenário
estudado.
1.4 Limites e Limitações
O projeto tem por limitação não aplicar, no âmbito do presente estudo, as
melhorias propostas para verificação de seus efetivos impactos. Esse ponto, mesmo
considerando que traria ganhos importantes ao estudo, não pode ser alcançado devido à
falta de autonomia e de abertura para a introdução de tais recomendações, nos tempos
disponíveis a consecução. Portanto, constadada essa limitação, atentou-se para que os
limites do trabalho fossem tais que não dependessem dessa aplicação para o alcance de
seus objetivos.
Além disso, também seria interessante que a produtividade da equipe fosse
medida antes da aplicação do Scrum, durante a utilização inicial da metodologia e após
a introdução das sugestões de melhoria. Essa comparação não foi feita porque antes do
Scrum não havia a medição de entregas da equipe, impossibilitando então tal
contraponto.
Caso tais dados estivessem disponíveis, os impactos da metodologia ágil
poderiam ser quantificados o que possibilitaria a fundamentação de futuras decisões
sobre qual metodologia de gerenciamento utilizar.
13
2 O GERENCIAMENTO DE PROJETOS TRADICIONAL
Uma das definições mais tradicionais de projeto é: um esforço temporário
empreendido com um objetivo pré-estabelecido, definido e claro, seja criar um novo
produto, serviço, processo. Deve ter início, meio e fim definidos, duração e recursos
limitados, em uma sequência de atividades relacionadas (PMBOK Guide, 2013). Além
disso, segundo Dinsmore P. e Cabanis-Brewin J. (2006), um projeto deve ter algumas
características como ser um empreendimento único, ser compostos por atividades
interdependentes, criar entregáveis de qualidade, envolver recursos múltiplos e ser
impulsionado pela restrição tripla (tempo, recursos e qualidade). Por exemplo, para
aumentar o escopo de um projeto os custos e/ou o prazo do mesmo deverão ser
aumentados, ou então, a qualidade final do projeto provavelmente será negativamente
afetada.
Dado esse contexto que pode atingir altos níveis de complexidade, foi sentida a
necessidade da criação de uma disciplina relacionada ao gerenciamento de projetos por
aqueles envolvidos em tais empreendimentos. Segundo o dicionário Webster, a palavra
disciplina possui os dois seguintes significados: “as regras utilizadas para manter o
controle” e “um ramo de conhecimento apoiado por treinamento mental, moral ou
físico”. Dessa forma, o gerenciamento de projetos é uma disciplina que exige disciplina
(DINSMORE, CABANIS-BREWIN, 2006, p. 5) e estuda o ramo do planejamento,
monitoramento e controle de tais iniciativas únicas.
2.1 Metodologias de Gerenciamento de Projetos
Uma metodologia é um conjunto de orientações e princípios que podem ser
adaptados e aplicados em uma situação específica (CHARVAT, 2003). Dada a
existência de uma disciplina que estuda o gerenciamento de projetos, a metodologia
seria a direção a ser seguida a partir de tal base de conhecimento. Assim, no que diz
respeito ao gerenciamento de projetos, a metodologia seria o conjunto de diretrizes e
práticas a serem seguidas em todas as fases do ciclo de vida do projeto. Para H. Kerzner
(1999), o alcance da excelência em gerenciamento de projetos não é possível sem um
processo repetitivo que possa ser utilizado em cada projeto, além disso, segundo ele
uma metodologia de gestão de projetos deve ter também as seguintes características:
1. Um nível recomendado de detalhes;
14
2. Uso de modelos;
3. Técnicas padronizadas de planejamento, programação e controle;
4. Formato padronizado de relato de desempenho;
5. Flexibilidade na aplicação nos projetos;
6. Flexibilidade para melhorias, quando necessário;
7. Facilidade de entendimento e aplicação;
8. Ser aceita e aplicada em toda a Organização.
Joslin e Müller (2015) definem os elementos de uma metodologia de
gerenciamento de projeto como processos, ferramentas, técnicas, áreas de conhecimento
e perfis de capacidade compreensiva. Esse último elemento diz respeito à flexibilidade
da metodologia em se adaptar às possíveis limitações. Estudos mostram que as
metodologias de gerenciamento de projetos não são completamente adequadas às
organizações sendo elas desenvolvidas in-house (customizadas) ou soluções off-the-
shelf (prontas) (FORTUNE ET AL., 2011; WHITE, FORTUNE, 2002). Quando isso
ocorre, os próprios gerentes de projeto customizam os métodos para que eles se
encaixem melhor em seus cenários (WELLS, 2013).
2.2 O Gerenciamento de Projetos Segundo o PMI
Tendo em mente a variabilidade e a complexidade que projetos podem atingir,
em 1969 foi fundado o Project Management Institute (PMI). O PMI é uma instituição
internacional sem fins lucrativos cujos principais objetivos são: formular padrões
profissionais de gestão de projetos, gerar conhecimento por intermédio da investigação
e promover a gestão de projetos como profissão através de seus programas de
certificação.
Com o objetivo de documentar e padronizar as práticas comumente utilizadas e
aceitas no âmbito da gestão de projetos, o PMI criou o Guia do Conhecimento em
Gerenciamento de Projetos, em inglês, Project Management Body of Knowledge (Guia
PMBOK). Segundo o guia PMBOK (2013), o gerenciamento de projetos é a aplicação
do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para
atender aos seus requisitos. Ele é realizado pela aplicação e integração apropriadas dos
47 processos de gerenciamento de projetos, logicamente agrupados em cinco fases de
15
processos sendo eles processos de início, planejamento, execução, monitoramento e
controle e encerramento.
Além disso, o guia afirma que o gerenciamento de um projeto normalmente
inclui, mas não se limita a: Identificação dos requisitos; Abordagem das diferentes
necessidades, preocupações e expectativas das partes interessadas no planejamento e
execução do projeto; Estabelecimento, manutenção e execução de comunicações ativas,
eficazes e colaborativas entre as partes interessadas; Gerenciamento das partes
interessadas visando o atendimento aos requisitos do projeto e a criação das suas
entregas; Equilíbrio das restrições conflitantes do projeto que incluem, mas não se
limitam, a: Escopo, qualidade, cronograma, orçamento, recursos e riscos.
Assim, cada um desses processos ocorre em cada ponto do ciclo de vida do
projeto e se relacionam entre si, alguns ocorrem apenas uma vez como a inicialização e
outros formam ciclos repetitivos como os processos de monitoramento e controle. De
maneira sintética, os processos se desenvolvem ao decorrer do projeto como
demonstrado na figura a seguir:
Figura 2: Relações entre grupos de processos de gerenciamento de projetos segundo.
PMBOK.
Fonte: Baseado em PMBOK (2013, p.69).
16
Segundo as boas práticas descritas no PMBOK, são sugeridas as ações e
documentações necessárias em cada um desses processos. Eles estão definidos da
seguinte forma:
Processos de iniciação: Realizados para obter autorização para iniciar
projeto ou uma nova fase do mesmo. Nesses processos, o escopo inicial e as
partes interessadas no projeto devem ser definidos. Uma vez escolhido, o
gerente de projeto deve fazer o termo de abertura, documento que quando
aprovado marca a autorização para o início do empreendimento.
Processos de planejamento: Processos executados para limitar e depurar os
objetivos do projeto e desenvolver o plano de ação para que tais propósitos
sejam alcançados. Os documentos do projeto desenvolvidos nesses
processos devem percorrer todos os aspectos do escopo, tempo, qualidade,
comunicação, recursos humanos, riscos, aquisições e gerenciamento das
partes interessada. Alguns exemplos dessa documentação são: cronograma,
plano de comunicação do projeto e plano do projeto.
Processos de execução: Processos realizados para alcançar as especificações
do projeto definidas no plano de gerenciamento do projeto. Através desses
métodos, deve ser feita a coordenação das pessoas e recursos, gerenciadas
as expectativas das partes interessadas, e também integradas e executadas as
atividades do projeto. Caso seja identificada a necessidade de alguma
mudança no curso planejado inicialmente, é preciso que os documentos
originais sejam alterados através de solicitações de mudança.
Processos de monitoramento e controle: Processos utilizados para
acompanhar e analisar o andamento e o desempenho do projeto; identificar
pontos nos quais são requisitadas mudanças no plano original.
Processos de encerramento: Processos executados para finalizar todas as
atividades de todos os grupos de processos de gerenciamento do projeto.
Deve-se concluir formalmente o projeto ou a fase.
O ciclo de vida do projeto define as fases que conectam o início de um projeto
ao seu final (PMBOK, 2013). Para Vargas (2005, p. 38), as fases do ciclo de vida do
projeto dependem, intimamente, da natureza do mesmo. A linha pontilhada demonstra a
17
instensidadeda execução do projeto. Na figura a seguir é possível ver o ciclo de vida de
um projeto tradicional:
Figura 3: Ciclo de Vida de um Projeto Clássico.
Fonte: VARGAS (2005, p. 35).
Como descrito anteriormente, segundo as boas práticas há uma distribuição ideal
dos processos a serem seguidos ao longo de todo esse ciclo de vida. A seguir, a figura 4
descreve resumidamente a distribuição dos processos e da documentação normalmente
requerida ao longo de um projeto.
18
Fonte: Baseado em PMBOK (2013, p. 53).
Pode-se dizer que as boas práticas apresentadas no PMI são as diretrizes mais
comumente utilizadas no gerenciamento de projetos tradicional. É evidente o fato de o
fluxo do projeto ser unilateral. Uma vez cuidadosamente planejado, o projeto segue o
caminho da execução. Assim, é possível afirmar que as metodologias tradicionais de
gerenciamento de projetos possuem uma abordagem intolerante a mudanças
(WYSOCKI R., 2007). Isso não ocorre devido a falta de ciclos de feedback já que eles
são existentes mas sim devido ao tempo e esforço necessários para as mudanças. Esse
modelo, também denominado “cascata” é exibido na imagem a seguir:
Figura 4: Processos ao longo do ciclo de vida de um projeto.
19
Figura 5: Abordagem linear para o gerenciamento de projetos: O modelo cascata.
Fonte: Baseado em WYSOCKI R. (2007, p. 49).
Após analisar o modelo clássico descrito fica claro que ele requer que o cliente
tenha seus requisitos o mais definidos e claros o possível antes que o planejamento
comece a ocorrer.
2.3 A Maturidade do Gerenciamento de Projetos nas Organizações
Com a crescente utilização do gerenciamento de projetos no cenário empresarial,
como descrito anteriormente, modelos com objetivo de sofisticar e otimizar esse
gerenciamento também têm ganhado importância (ALBRECHT e SPANG, 2014).
Modelos de maturidade tem o objetivo de guiar e encorajar organizações
buscarem melhorias contínuas em seus processos através de um método. O Modelo de
Maturidade em Capacitação1 - Integração (MMCI, em inglês, Capability Maturity
Model - Integration ou CMMI) tem seu foco em uma abordagem de melhoria de
processo que auxiliam organizações em adotar o melhor tipo de prática de cada área de
processo e, assim, melhorar o seu desempenho (CHRISSIS ET AL., 2003) (MENEZES,
2002).
Um nível de maturidade é caracterizado por um conjunto de áreas de processos
pré-definidos, julgados pela capacidade de atender às metas específicas e gerais
aplicáveis às várias áreas. (THESTANDISHGROUP, 2010). Essa abordagem é 1 Capacitação traduzido do termo Capability em inglês tem o sentido de “ser capaz de” e “estar apto a”.
Nesse caso, significa a avaliação sobre a organização ser capaz de aplicar as melhores präticas do modelo.
20
altamente bem-sucedida em empresas ao redor do mundo que buscam utilizar as
melhores práticas de gerenciamento (YIN, 2011).
O CMMI possui dois tipos de representação a "contínua" e a "por estágios". A
primeira possibilita à organização utilizar a ordem de melhoria que melhor atende os
objetivos de negócio da empresa e é caracterizado pelos níveis de capacidade abaixo:
Nível 1: Processo é executado de modo a completar o trabalho necessário para a
execução de um processo.
Nível 2: É possível planejar a execução e comparar o executado com o que foi
planejado.
Nível 3: Processo é construído sobre as diretrizes do processo existente. É mantida
uma descrição documentada do processo.
Nível 4: Processo é gerenciado quantitativamente através de estatísticas e outras
técnicas.
Nível 5: Processo gerido quantitativamente é alterado e adaptado para atender às
necessidades negociais/estratégicas da empresa.
Dessa forma, a capacidade é medida por processos separadamente, onde é
possível ter um processo com um nível um e outro processo com outro.
Na outra maneira, a por estágios, é descrita uma sequência pré-determinada para
melhoria baseada em estágios, onde um estágio depende do anterior. Esse tipo é
caracterizado por Níveis de Maturidade:
Nível 1 – Inicial: Processos imprevisíveis, pobremente controlados e reativos.
Nível 2 – Gerenciado: Processos caracterizados por projetos e, na maioria dos casos
reativos.
Nível 3 – Definido: Processos proativos definidos e caracterizados pela organização.
Nível 4 – Quantitativamente Gerenciável: Processos medidos e controláveis.
Nível 5 – Otimização: Foco na melhora contínua dos processos.
Esta representação é projetada para dar a empresa uma sequência lógica de
melhorias. Além disso, também permite que a maturidade entre diferentes projetos e
21
entre distintas organizações tenham uma mesma base de avaliação e, assim, possam ter
suas maturidades comparadas.
Levando esse conceito para a esfera do gerenciamento de projetos o PMI dá a
seguinte definição para maturidade de gerenciamento de projetos: "A maturidade de
gerenciamento de projetos organizacionais descreve a capacidade geral de uma
organização para selecionar, gerenciar e executar projetos de uma forma a suportar seus
objetivos estratégicos".
Kerzner (1999) propôs um modelo de maturidade de gerenciamento de projetos
e sugeriu que, para uma empresa atingir a excelência em gerenciamento de projetos, é
preciso percorrer cinco níveis assim como ocorre no CMMI. Nesse modelo o primeiro
nível é encontrado uma linguagem comum de gerenciamento de projetos permeia toda a
organização. O segundo nível diz respeito ao desenvolvimento de processos padrões a
serem utilizados e repetidos em todos os empreendimentos da organização. O nível três
é alcançado quando a organização é capaz de perceber a possibilidade de combinar
diversas metodologias de gerenciamento com o objetivo final de melhor gerenciar seus
projetos. O quarto nível é atingido quando a empresa é capaz de realizar benchmarking
– comparação de boas práticas do mercado com suas próprias práticas. O quinto e
último nível nada mais é do que a melhoria continua dos processos através das
descobertas obtidas através do benchmarking.
Além disso, tanto para medir o grau de maturidade do gerenciamento de projetos
de uma organização quanto para mensurar o sucesso da aplicação de alguma
metodologia, ou do próprio projeto em si, podem ser criados critérios e métricas.
Métricas trazem consistência e formalidade à gestão de projetos. Com métricas,
decisões importantes de projeto podem ser tomadas com base em informações. Em
essência, métricas trazem objetividade às ferramentas para o monitoramento de projetos
(PATAH, CARVALHO, 2012, p. 6). Ou seja, é possível estabelecer critérios e para
melhor examinar o grau de maturidade do gerenciamento de projetos em uma
organização e a partir desses dados sólidos traçar um caminho de melhoria.
22
3 METODOLOGIAS DE GERENCIAMENTO DE PROJETOS ÁGEIS E A
METODOLOGIA SCRUM
O gerenciamento de projetos tradicional descrito no capítulo anterior teve sua
origem em indústrias clássicas da engenharia como a civil e a automotiva. Nesses
cenários, é possível estimar o fluxo de trabalho e visualizar de forma concreta o
progresso do projeto. Hoje em dia, como desenvolvimento tecnológico, as companhias
dependem cada vez mais no desempenho de seus sistemas informacionais, e assim,
projetos de desenvolvimento e aprimoramento de software se tornam cada vez mais
comuns no cotidiano empresarial.
Segundo Nardi (2009), administrar projetos de qualquer natureza tem sido uma
tarefa árdua, em especial na área de Engenharia de Software, em função da velocidade
com que as mudanças e as inovações acontecem. Os projetos de software, geralmente,
são marcados por fracassos em decorrência dos prazos e orçamentos não cumpridos,
além de clientes insatisfeitos com o resultado do projeto. O desenvolvimento de
software é um processo “inovativo” em contraponto ao processo preditivo da produção
tradicional de bens físicos e, dessa forma, o gerenciamento clássico se mostra muitas
vezes incapaz de atender às necessidades desses novos tipos de projeto.
Na década de 70, Winston Royce descreveu um método serial para o
desenvolvimento de software. O modelo waterfall é não iterativo composto pelas
seguintes fases em sequência: reunião das especificações para definir como o software
será, análise detalhada das especificações e design, desenvolvimento do software de
acordo com o plano, teste e, em seguida, implementação. Apesar do desenvolvimento de
novos modelos, até alguns anos atrás o modelo cascata era o método
predominantemente utilizado por mais de um terço dos desenvolvedores de software
(LAPLANTE, NEILL, 2004). A adoção desse padrão pode até auxiliar o
desenvolvimento de software, mas, em 70% dos casos que o utilizam, as entregas não
alcançam um ou mais objetivos iniciais do projeto (SOUMYADIPTA, SINGH, 2005).
Segundo o Dicionário Online da língua portuguesa, a definição de ágil é: “Que
se move de maneira rápida, veloz. Que se comporta ou trabalha de maneira eficaz e
26. SERRADOR P., PINTO J., 2015, Does Agile work? — A quantitative analysis
of agile project success, International Journal of Project Management, v. 33,
n. 5, p. 1040-1051.
27. SOUMYADIPTA P., SINGH J., 2012, Be Agile: Project Development with
Scrum framework, Journal of Theoretical and Applied Information
Technology, v. 40 n.1.
28. SUTHERLAND J., 2014, Scrum - A arte de fazer o dobro de trabalho na
metade do tempo. 1 ed. São Paulo, Basil, LeYa Brasil.
29. TAKEUCHI, HIROTAKA e NONAKA, 1986, “The New New Product
Development Game." Harvard Business Review 64, no. 1 (January–February
1986).
30. TRIPP D., 2005, Pesquisa-ação: uma introdução metodológica, Educação e
Pesquisa, São Paulo, v. 31, n. 3, p. 443-466. Disponível em:
http://www.scielo.br/pdf/ep/v31n3/a09v31n3. Acesso em 03/12/2016.
69
31. VARGAS, R. V., 2005, Gerenciamento de projetos: estabelecendo
diferenciais competitivos. Rio de Janeiro, Brasport.
32. WESLEY A., 2010, Adaptative Project Framework: managing complexity
in the face of uncertainty. 1 ed. Boston EUA. Addison Wesley.
33. WELLS, H., 2013. An exploratory examination into the implications of
typeagnostic selection and application of project management methodologies
(PMMs) for managing and delivering IT/IS projects. Proceedings IRNOP
Conference, June 17–19, 2013, Oslo, Norway, p. 1–27.
34. WYSOCKI R., 2007, Effective Project Management - Traditional, Adaptive,
Extreme. 4 ed.
35. YEN, H., LI, E., NIEHOFF, B., 2008, Do organizational citizenship behaviors
lead to information system success? Testing the mediation effects of integration
climate and project management. Information and Management, Journal
Elsevier, v.45 n.6, p. 394–402.
36. YIN A., 2011, Scrum Maturity Model, M.S.c., Universidade Técnica de Lisboa,
Lisboa, Portugal.
37. YIN R. E GRASSI, 2001. Estudo de caso: planejamento e métodos. 2.ed.-
Porto Alegre: Bookman.
38. A Guide to the Project Management Body of Knowledge (PMBOK®
Guide), 2013. 5 Ed. Pensilvânia, EUA, Project Management Institute Inc.
70
9 Apêndice A: Mapeamento Sistemático da Literatura
9.1 Introdução
Um mapeamento sistemático é uma forma de identificar, avaliar e interpretar
todas as pesquisas disponíveis relevantes para uma questão de pesquisa particular.
Umas das razões para a realização de revisões sistemáticas é que esta resume as
Evidências existentes em relação a um tratamento ou tecnologia (KITCHENHAM,
2004).
9.2 Protocolo do Mapeamento
Segundo Kitchenham (2004) o protocolo de mapeamento tem o objetivo de
definir os métodos do mapeamento sistemático o que diminui a possibilidade de a
pesquisa se tornar tendenciosa.
9.3 Objetivo
A descrição do objetivo se encontra descrita segundo a abordagem Goal-
Question-Metric (GQM). A abordagem abrange informações necessárias para a
realização das tarefas de análise segundo o paradigma da avaliação orientada por metas,
tendo como componentes elementares os objetivos, as questões e as métricas (ABIB,
1998b). Ou seja, definir questões a serem respondidas baseadas em um objetivo e pode
ser observado na Tabela abaixo:
Dimensão Definição
Objeto de Estudo Aplicação da metodologia Scrum.
Propósito Explorar dificuldades, ganhos e perdas da
aplicação da metodologia.
Foco Explorar maneiras de como melhor aplicar a
metodologia.
Ponto de Vista Equipe do projeto.
Contexto Área empresarial de uma grande empresa do
varejo brasileiro.
Tabela 4 - Tabela Goal-Question-Metric.
Fonte: Elaboração própria.
71
9.4 Estratégias utilizadas para pesquisa dos estudos primários
Nesta seção serão descritos: o escopo da pesquisa, o idioma considerado, os
termos utilizados e os critérios de seleção de artigos.
9.5 Escopos da Pesquisa
A fonte escolhida como base principal do escopo da pesquisa deste projeto foi a
base de periódicos da CAPES. Livros comumente utilizados por profissionais da área
foram consultados. Além disso, sites também foram pesquisados através de pesquisas
nas máquinas de busca Google e Scholar Google. Nessa revisão, o foco será nos artigos
pesquisados na Base Capes.
9.6 Idiomas dos Artigos
O idioma escolhido foi o inglês e português, pois são adotados pela grande
maioria das conferências e periódicos nacionais e internacionais relacionados com tema
de pesquisa.
9.7 Termos utilizados na pesquisa (palavras-chave)
Os termos que foram utilizados neste mapeamento foram agrupados em dois
grupos os em português e os em inglês. Na tabela abaixo, são exibidos os termos de
busca utilizados para este projeto:
Termos em português Termos em inglês
Scrum Scrum
Métodos Ágeis Agile Method
Gerenciamento de Projetos Ágil Agile project Management
Gerenciamento de Projetos Tradicional Traditional Project Management
Gerenciamento de Projetos Project Management
Tabela 5 - Termos utilizados na pesquisa.
Fonte: Elaboração própria
72
9.8 Critérios para Inclusão de Artigos
Os critérios de inclusão foram os seguintes:
CI1: Podem ser selecionadas publicações que apresentam conceitos, técnicas
ou métodos aplicados do Scrum;
CI2: Podem ser selecionadas publicações que apresentam conceitos, técnicas
ou métodos aplicados de Métodos ágeis;
CI3: Podem ser selecionadas publicações que apresentam conceitos, técnicas
ou métodos aplicados de Gerenciamento de Projetos ágil;
CI4: Podem ser selecionadas publicações que apresentam conceitos, técnicas
ou métodos aplicados de Gerenciamento de Projetos.
CI5: Podem ser selecionadas publicações que apresentam conceitos, técnicas
ou métodos aplicados de Modelos de maturidade de projetos.
Além desses critérios, a data de publicação dos também foi levada em
consideração, os artigos mais recentes tiveram prioridade sobre os mais antigos.
Critérios para Exclusão de Artigos
Os critérios de inclusão foram os seguintes:
CE1: Não serão selecionadas publicações que não satisfaçam a nenhum
critério de inclusão;
CE2: Não serão selecionadas publicações em que o idioma seja diferente do
exigido
CE4: Não serão selecionadas publicações que não estejam no escopo de
gerenciamento de projetos e ou metodologias de desenvolvimento de
software.
73
9.9 Extração de Dados
Após a utilização dos filtros supracitados, as seguintes fontes foram
selecionadas:
Artigo Critério
MENEZES W., 2009, To CMMI or Not to CMMI: Issues to Think About CrossTalk. The Journal of Defense Software Engineering. p.
9-11.
CI5
Tabela 6 - Seleção do artigo selecionado.
Fonte: Elaboração própria.
Livros, sites e dissertações Critério
BASS J., 2002, The New Project Management: tools for an age of rapid change, complexity and other business realities. 2ed.
Virginia, EUA, Wiley. CI1
BECK, K., BEEDLE, M., VAN BENNEKUM, A., COCKBURN, A., CUNNINGHAM, W.,FOWLER, M., GRENNING, J.,
HIGHSMITH, J., HUNT, A., JEFFRIES, R., KERN, J.,MARICK, B., MARTIN, R., MELLOR, S., SCHWABER, K.,
SUTHERLAND, J. AND THOMAS, D.,2001. Manifesto for Agile Software Development. Disponível em:<http://AgileManifesto.org.
/>. Acesso em: 10 de nov. 2016.
CI2
CHARVAT, J., 2003. Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects. 1 ed. Nova Jérsei, EUA. John Wiley &
Sons.
CI4
CHRISSIS, M. B., KONRAD, M., AND SHRUM, S., 2003, CMMI Guidlines for Process Integration and Product Improvement. Boston, USA. Addison-Wesley Longman
Publishing Co.
CI5
CRUZ F., 2013, Scrum e PMBOK unidos no Gerenciamento de Projetos. 1 ed. Brasport.
CI1, CI4
DINSMORE P. e CABANIS-BREWIN J., 2006, The AMA Handbook of Project Management. 2 ed. America Management
Association. CI4
JOHANSEN, T., ULDAHL, A, 2012, Measuring the Impact of the Implementation of the Project Management Method Scrum. MSc
Thesis. Copenhagen Business School, Copenhagen, Denmark. CI1, CI3
74
KERZNER, H., 1999, Strategic planning for project management using a project management maturity model. New
York, John Wiley & Sons. CI5
REIS R., 2012, PMBOK vs Scrum. Disponível em: <https://www.oficinadanet.com.br/artigo/gerencia/pmbok-x-
scrum>. Acesso em 09/11/2016.
RODRIGUES E., Comparativo PMBOK x Scrum. Disponível em: <http://www.elirodrigues.com/2012/04/02/comparativo-pmbok-x-
scrum/>. Acesso em 09/10/2016. CI1, C14
SCHWABER K. E SUTHERLAND J., 2016, The Scrum Guide: The Definitive Guide To Scrum - The Rules Of The Game.
YIN A., 2011, Scrum Maturity Model, M.S.c., Universidade Técnica de Lisboa, Lisboa, Portugal.
CI5
A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 2013. 5 Ed. Pensilvânia, EUA, Project
Management Institute Inc. CI4
Tabela 7 - Seleção dos livros, sites e dissertações segundo critérios de inclusão.
Fonte: Elaboração própria.
Abaixo, tabela resumo da literatura utilizada após pesquisas na Base Capes:
Palavra-chave Resultado Total após filtro
Scrum 955 3 Métodos Ágeis/ Agile Method 1436 5
Gerenciamento de Projetos Ágil / Agile project Management
954 4
Gerenciamento de Projetos / Project Management 17462 5 Maturidade de Gerenciamento de Projetos /
Project Management Maturity 1172 1
Tabela 8 - Tabela resumo da lteratura selecionada.
Fonte: Elaboração própria.
75
10 Apêndice B: Quadro Scrum utilizado no estudo de caso
No apêndice, podem ser vistas as imagens do quadro Scrum com as colunas:
“Backlog”, “To Do”, “Doing”, “Approval” e “Done”. As tarefas eram coladas nas suas
respectivas colunas e caminhavam por elas de acordo com a mudança de seus status.
76
77
78
11 Apêndice C: Pesquisa de percepção da equipe envolvida na aplicação do
Scrum
A pesquisa dos envolvidos foi desenvolvida baseada os tópicos essenciais do
Scrum como explicitado no capítulo 4. O questionário abaixo foi composto por nove
perguntas objetivas com o intuito de obter a percepção da equipe acerca do nível de
dificuldade em implantar a abordagem e consumo de tempo nos projetos com Scrum
(Alto, médio ou baixo). E também para entender como ocorreu a percepção a cerca da
modificação do consumo do tempo a partir da utilização da metodologia ágil.
Questionário: PARTE 1: Para responder as questões abaixo considere os critérios descritos
abaixo e seus respectivas escalas: Implementação da abordagem: Baixa: A implementação da abordagem não enfrentou resistência. Não é necessário que a equipe tenha qualquer experiência com Scrum. Média: A implementação da abordagem enfrentou pelo menos uma resistência. É necessário que a equipe tenha alguma experiência com Scrum. Alta: A implementação da abordagem enfrentou resistências. É necessário que a equipe tenha experiência e maturidade com Scrum. Consumo do tempo nos projetos Ganho: Pôde ser observado ganho na velocidade das tarefas dos projetos quando a metodologia foi aplicada. Sem modificação: Não houveram modificações na velocidade das tarefas dos projetos se comparado a execução sem o Scrum. Perda: As tarefas dos projetos consumiram mais tempo com a aplicação do Scrum. Selecione para cada técnica abaixo um dos critérios apresentados anteriormente:
1. Técnica: Seleção de um Product Owner (O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings).
(a) Critério: dificuldade em implentar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
79
2. Técnica: Seleção de um Scrum Master (O Scrum Master tem o papel de
garantir que equipe cumpra as práticas do Scrum e respeite seus valores). (a) Critério: dificuldade em implentar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
3. Técnica: Sprints com duração de 2 semanas (a) Critério: dificuldade em implementar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
4. Técnica: Criação do backlog dos projetos, do sprint e priorização das
tarefas. (a) Critério: dificuldade em implentar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
5. Técnica: Reunião de planejamento do Sprint (Reunião na qual se planeja o trabalho a ser realizado no próprio Sprint).
(a) Critério: dificuldade em implementar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
6. Técnica: Reuniões de Scrum diárias. a) Critério: dificuldade em implementar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
7. Técnica: Quadro de atividades visível (Quadro Scrum). a) Critério: dificuldade em implementar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda.
80
8. Técnica: Reunião de revisão dos Sprints (Reunião para a equipe demonstrar para todas as partes interessados do projeto o que foi realizado durante o ciclo de execução).
a) Critério: dificuldade em implementar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
9. Técnica: Reunião de retrospectiva dos Sprints (Reunião para análise do
feedback das partes interessadas para identificar possíveis falhas e corrigi-las nos Sprints futuros).
a) Critério: dificuldade em implementar a técnica: ( ) Baixa; ( ) Média ; ( ) Alta; ( ) Técnica não aplicada. (b) Critério: Consumo do tempo nos projetos ( ) Ganho; ( ) Sem modificação; ( ) Perda; ( ) Técnica não aplicada.
10. Você acha que a velocidade das entregas do (s) projeto (s) no qual estava
envolvido aumentou com o Scrum?
( ) Sim; () Não
11. Qual foi a maior dificuldade para a aplicação do Scrum na área?
12. Qual foi o maior benefício da aplicação do Scrum na área?
81
12 Apêndice D: Resultados da Pesquisa de percepção da equipe envolvida na
aplicação do Scrum
Abaixo, estão dispostos os resultados em forma de gráfico pizza das respostas
consolidadas da do questionário respondido pela equipe da área.
82
83
84
85
86
87
88
13 Anexo A: Tabela de comparação entre PMBOK e SCRUM
Nesse apêndice, é possível ver na íntegra a tabela na qual Eli Rodrigues (2013)
mapeou processos que aparecem no PMBOK e os confrontou com os que são abordados
pelo Scrum.
Disciplina Grupo do Processo
Ação Abordado
no Scrum?
Observação
Integração Iniciação
Desenvolver o termo de abertura do
projeto
Sim
Considera-se o processo de definição de
VISÃO do projeto e a atribuição dos
papéis como equivalente ao
termo de abertura.
Integração Planejamento
Desenvolver o plano de
gerenciamento do projeto
Sim
O Scrum determina como vai gerenciar o projeto, embora não atenda a todas
as áreas.
Integração Execução
Orientar e gerenciar a
execução do projeto
Sim Orienta e
acompanha em detalhes a execução
Integração Monitoramento
& Controle
Monitorar e controlar o trabalho do
projeto
Sim
Monitora o trabalho nas extremidades das sprints, como
um pacote de trabalho. Dentro da sprint é feito pela
equipe.
Integração Monitoramento
& Controle
Realizar o controle
integrado de mudanças
Sim
Realiza o controle de mudanças
atraves do realinhamento de
prioridades entre os sprints, verifica
impactos antes de aceitar mudanças e replaneja o sprint.
89
Disciplina Grupo do Processo
Ação Abordado
no Scrum?
Observação
Integração Encerramento Encerrar o projeto ou
fase Sim
Controla o andamento do
projeto, mas não determina em detalhes como
encerrar o projeto, como resolver pendencias,
encerrar contratos etc.
Escopo Planejamento Coletar os requisitos
Sim
Parcial, porque não determina técnicas
e ferramentas, apenas diz que é
responsabilidade do PO.
Escopo Planejamento Definir o escopo
Sim
Considerando o "PRE-GAME",
deixa bem claro os objetivos e limites
do projeto. Além de determinar o que faz ou não parte
dele.
Escopo Planejamento Criar a EAP Não
O Scrum não tem nenhuma
ferramenta equivalente a
Estrutura Analítica do Projeto
Escopo Monitoramento
& Controle Verificar o
escopo Sim
É o ponto mais forte do Scrum,
realizado na REVIEW
MEETING.
Escopo Monitoramento
& Controle Controlar o
escopo Sim
Controla escopo tanto por
prioridade, quanto por completude
usando o sprint x product.
90
Disciplina Grupo do Processo
Ação Abordado
no Scrum?
Observação
Tempo Planejamento Definir as atividades
Sim A equipe define as
atividades no Sprint backlog
Tempo Planejamento Sequenciar as
atividades Sim
Atende parcialmente. Deixa a criterio da equipe o sequenciamento,
mas não pre-determina ligacoes
logicas
Tempo Planejamento Estimar os
recursos das atividades
Sim
Faz o contrário do PMBOK. A partir
dos recursos disponiveis x
tempo, determina o trabalho que a
equipe é capaz de fazer.
Tempo Planejamento Estimar as
durações das atividades
Sim
Estima quantos itens do backlog cabem no Sprint.
Deste modo entendo que atende parcialmente, pois
indiretamente mostra a duração das atividades.
Tempo Planejamento Desenvolver o cronograma
Sim
Não desenvolve cronograma, mas mostra os itens do
backlog e atividades dentro de
um Sprint.
Tempo Monitoramento
& Controle Controlar o cronograma
Sim
Controla a execução das
atividades do Sprint e gerencia prazo. Mas tem poucas
ferramentas comparado ao
PMBOK.
91
Disciplina Grupo do Processo
Ação Abordado
no Scrum?
Observação
Custos Planejamento Estimar custos
Não Não mapeia este
item
Custos Planejamento Determinar orçamento
Não Não mapeia este
item
Custos Monitoramento
& Controle Controlar os
custos Não
Não mapeia este item
Qualidade Planejamento Planejar a qualidade
Sim Planeja usando os
conceitos de DONE e READY
Qualidade Execução Realizar a garantia da qualidade
Não
Não prevê claramente
atividades de garantia da qualidade.
Qualidade Monitoramento
& Controle
Realizar o controle da qualidade
Sim
Verifica a qualidade (e o escopo) nas REVIEW
MEETING.
Recursos Planejamento
Desenvolver o plano de recursos humanos
Sim
Define claramente quem são os
recursos, papéis e responsabilidade,
embora não aborde a capacitação dos recursos, nem o
estabelecimento de um plano
Recursos Execução Mobilizar a equipe do
projeto Não
Não mapeia este item
Recursos Execução Desenvolver a equipe do
projeto Sim
Prevê o desenvolvimento da equipe no dia-a-dia
e nas RETROSPECTIVE
MEETING.
92
Disciplina Grupo do Processo
Ação Abordado
no Scrum?
Observação
Recursos Execução Gerenciar a equipe do
projeto Sim
Não define como PO e SM devem se portar na gestão de