aplicaÇÃo da metodologia scrum em uma...
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.
Keywords: Scrum, Project Management, Agile Project Management
vii
Sumário
1 INTRODUÇÃO ........................................................................................................ 9
1.1 Metodologia ..................................................................................................... 10
1.2 Objetivo Geral .................................................................................................. 11
1.3 Objetivos Específicos ...................................................................................... 11
1.4 Limites e Limitações ........................................................................................ 12
2 O GERENCIAMENTO DE PROJETOS TRADICIONAL ................................... 13
2.1 Metodologias de Gerenciamento de Projetos .................................................. 13
2.2 O Gerenciamento de Projetos Segundo o PMI ................................................ 14
2.3 A Maturidade do Gerenciamento de Projetos nas Organizações ..................... 19
3 METODOLOGIAS DE GERENCIAMENTO DE PROJETOS ÁGEIS E A
METODOLOGIA SCRUM ............................................................................................ 22
3.1 Maturidade no Scrum ....................................................................................... 28
4 SCRUM VERSUS GERENCIAMENTO DE PROJETOS TRADICIONAL ........ 31
5 ESTUDO DE CASO ............................................................................................... 37
5.1 Apresentação da Área de Engenharia de Processos ......................................... 37
5.2 Exemplos de Projetos nos Quais a Área se Envolve ........................................ 39
5.2.1 Projeto Onda de Devolução ...................................................................... 40
5.2.2 Solicitação de Baixa de Preço Centralizada ............................................. 40
5.3 Como o Scrum Entrou na Área ........................................................................ 41
5.4 Discussão Sobre a Aplicação do Scrum ........................................................... 45
5.5 Resultados Encontrados ................................................................................... 52
6 PROPOSTAS .......................................................................................................... 55
6.1 Percepção da Equipe Envolvida....................................................................... 55
6.2 Análise do Grau de Maturidade do Scrum na Área ......................................... 58
6.3 Orientações Futuras ......................................................................................... 58
6.3.1 Clara definição do projeto ........................................................................ 59
6.3.2 Reuniões de planejamento do Sprint ........................................................ 59
viii
6.3.3 Gerenciamento do Backlog do Produto .................................................... 60
6.3.4 Reunião de Revisão do Sprint .................................................................. 60
6.3.5 Reunião de Retrospectiva do Sprint ......................................................... 60
6.3.6 Reunião diária ........................................................................................... 61
6.3.7 Metas e Melhorias Resumidas .................................................................. 61
6.4 Estudos Posteriores .......................................................................................... 63
7 CONCLUSÃO ........................................................................................................ 64
8 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 66
9 Apêndice A: Mapeamento Sistemático da Literatura ............................................. 70
10 Apêndice B: Quadro Scrum utilizado no estudo de caso ........................................ 75
11 Apêndice C: Pesquisa de percepção da equipe envolvida na aplicação do Scrum . 78
12 Apêndice D: Resultados da Pesquisa de percepção da equipe envolvida na
aplicação do Scrum ......................................................................................................... 81
13 Anexo A: Tabela de comparação entre PMBOK e SCRUM .................................. 88
14 Anexo B: Tradução do questionário para avaliação do nível de maturidade do
Scrum em uma organização ............................................................................................ 94
ix
Lista de Figuras
Figura 1: Ciclo de pesquisa-ação. ................................................................................... 11
Figura 2: Relações entre grupos de processos de gerenciamento de projetos segundo.
PMBOK. ......................................................................................................................... 15
Figura 3: Ciclo de Vida de um Projeto Clássico. ........................................................... 17
Figura 4: Processos ao longo do ciclo de vida de um projeto. ....................................... 18
Figura 5: Abordagem linear para o gerenciamento de projetos: O modelo cascata. ...... 19
Figura 6: Workflow de um desenvolvimento de projeto ágil genérico. ......................... 24
Figura 7: Replicação de uma rodada de Planning Poker. ............................................... 27
Figura 8: Resumo do Modelo de Maturidade Ágil. ........................................................ 29
Figura 9: Ciclo de vida do projeto segundo metodologia Scrum. .................................. 32
Figura 10: Comparação entre as ações abordadas no Scrum e no PMBOK separadas
pelo grupo de processos de um projeto. ......................................................................... 35
Figura 11: Espectro de complexidade de projetos: SCRUM ou PMBOK? .................... 36
Figura 12: Metodologia de trabalho da área estudada. ................................................... 38
Figura 13: Organograma das frentes da área de engenharia de processos. .................... 39
Figura 14: Modelo de cartas utilizadas durante o planning poker. ................................. 43
Figura 15: Exemplo de quadro Scrum radicional. .......................................................... 44
Figura 16: Exemplo do post it do quadro Scrum do estudo de caso. ............................. 44
Figura 17: Gráfico Resumo - Percepção do Nível de Dificuldade de Aplicação das
Técnicas Segundo Equipe. .............................................................................................. 56
Figura 18: Gráfico resumo - Percepção Sobre Impacto no Consumo de Tempo nos
Projetos. .......................................................................................................................... 57
x
Lista de Tabelas
Tabela 1 - Aderência do Scrum aos processos tradicionais descritos no PMBOK. ....... 34
Tabela 2 - Processos realizados antes da aplicação da metodologia e os equivalentes
adotados a partir do Scrum. ............................................................................................ 52
Tabela 3 - Quadro resumo de sugestões e impactos esperados ...................................... 62
Tabela 4 - Tabela Goal-Question-Metric........................................................................ 70
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
rápida” (Disponível em: < https://www.dicio.com.br/agil >. Acesso em: 07/01/2017.).
Essa é uma característica cada vez mais necessária aos processos empresariais. A
criação de métodos de desenvolvimento de software ágil nada mais é do que uma
23
resposta às novas necessidades do mercado, pois busca oferecer processos mais “leves”
e rápidos no desenvolvimento de tais produtos.
O movimento ágil teve seu início quando um grupo de desenvolvedores de
software e consultores da área publicou o “Manifesto de desenvolvimento de software
ágil” em 2001 (BECK ET AL. 2001, COCKBURN, 2002). Os valores focais descritos
no manifesto são: Indivíduos e interações sobre processos e ferramentas; Software que
funcione sobre documentação abrangente; Colaboração com o cliente sobre negociação
de contratos e responder a mudanças sobre seguir um plano.
Ou seja, os primeiros valores são considerados mais valiosos do que os
segundos. Dessa forma a prioridade é satisfazer o cliente através da entrega contínua e
veloz de software com valor agregado. Possíveis mudanças nos requisitos, com o
objetivo de tornar o software melhor, não são mal vistas mesmo ocorrendo tardiamente
no desenvolvimento. Isso ocorre, pois, os processos ágeis buscam tirar vantagem das
mudanças que possam trazer benefícios para o cliente.
Outro ponto realçado pelo manifesto é a entrega frequente, de poucas semanas a
poucos meses, de software funcional. Além disso, pessoas do negócio para qual o
software está sendo feito e os desenvolvedores devem trabalhar diariamente em
conjunto por todo o projeto. Por outro lado, os processos ágeis promovem
desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser
capazes de manter uma velocidade constante de entregas de maneira sustentável.
A motivação da equipe também é destacada, o manifesto afirma que o projeto
deve ser construído em torno de indivíduos motivados, e capazes de se auto gerir, que
são confiados para fazer o trabalho necessário e devem encontrar um ambiente
adequado assim como o suporte necessário.
Sobre comunicação, o manifesto declara que o método mais eficiente de
transmitir informações dentro de uma equipe de projeto é ao vivo, através de conversa
face a face. No que diz respeito a medidas de desempenho, o software funcionando é a
medida primária de progresso. E, por último o manifesto aconselha que em intervalos
regulares, a equipe reflita sobre como se tornar mais eficaz e então deve refinar e ajustar
seu comportamento de acordo com as descobertas.
A corrente do gerenciamento de projeto ágil é uma derivação do movimento de
desenvolvimento de software ágil já que tem suas raízes nos princípios descritos acima.
24
A primeira vez na qual a ideia do gerenciamento de projetos ágil foi levantada
ocorreu em 1986, em um artigo escrito por Takeuchi e Nonaka publicado na Harvard
Business Review. O gerenciamento de projetos ágil utiliza principalmente dois
conceitos importantes: Minimização de riscos baseada em iterações curtas com
entregáveis claramente descritos e comunicação direta com os envolvidos no
desenvolvimento do projeto no lugar de documentação abundante (CERVONE, 2011
p.5). Ambas as características buscam ajudar o time do projeto em situações onde
mudanças imprevisíveis e rápidas precisam ser feitas.
Assim como existem diversos tipos de projetos, há também diversos métodos
ágeis. Alguns deles são: Scrum, gerenciamento de projetos extremo, gerenciamento de
projetos adaptativo e gerenciamento de projetos dinâmico. Todas essas metodologias
possuem em comum os princípios ágeis descritos acima e o Scrum é o mais amplamente
utilizado dentre esses. A ideia geral de todos eles é subdividir o projeto em pedaços
iterativos e incrementais menores. A figura abaixo demonstra o workflow de uma
abordagem iterativa para o gerenciamento de projetos genérico segundo Robert K.
Wysocki (2007):
Figura 6: Workflow de um desenvolvimento de projeto ágil genérico.
Fonte: Baseado em WYSOCKI (2007, p. 51).
O Scrum foi introduzido como uma técnica de desenvolvimento de software
ágil em 1995 (SCHWABER, SUTHERLAND, 1995). Nesse mesmo ano os autores
realizaram um workshop sobre o tema na OOPSLA (Object-Oriented Programming
25
Systems, Languages and Applications), conferência anual em orientação a objetos,
programação, sistemas, linguagens e aplicações. Após esse momento, a metodologia foi
alavancada e passou a ser adotada por desenvolvedores de software ao redor do mundo.
Hoje, o Scrum é descrito como um framework que permite a abordagem de
processos adaptativos complexos ao mesmo tempo em que entregam de forma produtiva
e criativa produtos com o maior valor possível (SCHWABER, SUTHERLAND, 2016).
A capacidade de se adaptar às necessidades do cliente do projeto é, desta forma, um dos
critérios que influenciam no sucesso final de um projeto (WYSOCKI, 2007) já que hoje
em dia existe uma grande variabilidade nos requisitos dos projetos ao longo do curso do
mesmo.
De forma prática, a ideia central do Scrum é quebrar o projeto em várias
interações de tempos relativamente curtos. Em cada um desses períodos denominados
Sprints, que devem durar menos do que um mês, a equipe do projeto planeja, analisa os
requisitos do projeto, executa, testa o que foi feito e ao final apresenta para o cliente
para obter feedback. Não é esperado que o produto seja completamente entregue, mas
sim que ele seja incrementado a cada fase até que atinja sua completude. Dessa forma, o
projeto se torna o resultado dessas múltiplas interações. Isso minimiza o risco de a
entrega final ser inadequada, já que é possível identificar o desenvolvimento do produto
passo a passo (SOUMYADIPTA, SINGH, 2005).
Em seu livro “Scrum: A Arte de fazer o dobro do trabalho na metade do tempo”,
Jeff Sutherland, “co criador” do Scrum, resume nos seguintes passos como aplicar a
metodologia:
1. Escolher um Product Owner: Essa será a pessoa é quem tem a visão do
que a equipe do projeto fará, produzirá ou realizará e deve levar em
consideração os riscos, recompensas envolvidas nas escolhas de
priorização durante o projeto.
2. Selecionar a equipe do projeto: A equipe é a responsável por concretizar a
visão do Product Owner e por isso, deve ter as habilidades necessárias
para tal. Os grupos devem ser relativamente pequenos, de três a nove
pessoas.
26
3. Definir um Scrum Master: Esse é o responsável por treinar a equipe na
estrutura do Scrum. O Scrum Master tem também o papel de garantir que
equipe cumpra as práticas da metodologia e respeite seus valores.
4. Criar um backlog do produto e priorizá-lo: O backlog é o mapa do produto
e contém visão de “tudo que a equipe poderia realizar” em ordem de
prioridade. É papel de o Product Owner escolher como priorizar as tarefas
durante todo o projeto. Para tal, devem ser consultadas todas as partes
interessadas e equilibrar o que deve ser feito com o que é possível ser
feito. Cada atividade tem um grau de dificuldade definido pelo Planning
Poker. O Planning Poker se baseia na ideia de estimar o esforço de cada
tarefa a ser realizada no projeto através de um jogo de cartas. No jogo cada
envolvido no processo estima, de acordo com a opinião e a experiência
pessoal, o nível de dificuldade das tarefas do backlog. No Scrum, a escala
convencional de pontos é a sequência de Fibonacci (0,1,2,3,5,8,13 etc.).
Para estimar os pontos de cada tarefa, é atribuído um ponto para a tarefa
mais simples de todas e pontua as demais a partir dela. Ao pontuar as
atividades, passará a existir uma referência do esforço para concluir o
projeto. O objetivo é que haja um consenso através de uma discussão
rápida caso haja divergências de opinião. Dessa forma, cada atividade do
projeto é pontuada com um grau de dificuldade como descrito na imagem
a seguir:
27
Figura 7: Replicação de uma rodada de Planning Poker.
Fonte: http://blog.acelerato.com/agile/utilizando-planning-poker-para-
estimar-seu-backlog/ em 09/10/2016.
5. Redefinir e estimar o backlog do produto: Os itens a serem desenvolvidos
na lista do backlog devem estar em constante análise. Só deve permanecer
o que de fato trouxer valor para o projeto e for factível de ser realizado. De
acordo com a experiência a equipe deve também modificar a graduação de
dificuldade de cada atividade.
6. Planejar o Sprint: O planejamento do primeiro Sprint é a reunião inicial do
Scrum. Nela, a equipe o Product Owner e o Scrum Master devem
consultar o backlog e prever quantas atividades será capaz de fazer no
tempo determinado para o Sprint. Após a realização de alguns ciclos, o
grupo deve verificar o número de pontos que realizou no Sprint anterior.
Essa pontuação é a velocidade do time e esse número, o objetivo é que ela
aumente a cada fase.
7. Tornar o trabalho visível: A maneira mais utilizada é a criação de um
“Quadro Scrum” que deixe visível as três colunas: A fazer, fazendo e feito.
28
8. Realizar a reunião diária ou Scrum diário: Todo dia deve ser realizada uma
reunião com no máximo quinze minutos onde a equipe e o Scrum Master
se reúnem e respondem a três perguntas: “O que você fez ontem para
ajudar a equipe a concluir o Sprint? ”, “O que você fará hoje para ajudar a
equipe a concluir o Sprint? ” E “Há algum obstáculo impedindo o alcance
da meta do Sprint? ”
9. Revisar o Sprint: Reunião para a equipe demonstrar para todas as partes
interessados do projeto o que foi realizado durante o ciclo de execução.
10. Retrospectiva do Sprint: Análise do feedback das partes interessadas para
identificar possíveis falhas e corrigi-las nos Sprints futuros.
Com essa estrutura, o processo de desenvolvimento se torna capaz de lidar
melhor com todas as variáveis envolvidas no progresso do projeto já que incorcora
naturalmente os feedbacks e mudanças. Elas podem ser tanto ambientais quanto técnicas
como requisitos, prazos, recursos e tecnologia e provavelmente sofrerão modificações
com o passar do tempo. A utilização desta metodologia torna o processo de
desenvolvimento tão imprevisível e flexível quanto o cenário exigir. Como resultado, o
sistema desenvolvido torna-se capaz de alterar-se de acordo com as mudanças do
projeto e, dessa forma, se faz útil uma vez que é entregue (SCHWABER, 1995).
3.1 Maturidade no Scrum
Inspirados no CMMI descrito no capítulo anterior, Patel e Ramachandran (2009)
propuseram o Modelo de Maturidade Ágil (Agile Maturity Model). A figura 8 a seguir
resume o modelo:
29
Figura 8: Resumo do Modelo de Maturidade Ágil.
Fonte: Baseado em PATEL C., RAMACHANDRAN M. (2009, p. 6).
O nível 1 caracteriza organizações que não possuem processos ágeis claramente
definidos, ou seja, opera-se a através de uma abordagem própria e pouco estabelecida.
Nesse caso, o sucesso depende totalmente nos indivíduos. Os principais problemas
enfrentados por empresas que se encontram nesse patamar é a dificuldade de cumprir o
planejamento no prazo, o orçamento e atingir a qualidade definida.
O nível 2 diz respeito a organizações que apresentam estruturas mais completas
e estruturadas de metodologia ágil. Apesar de apresentarem menos empecilhos do que
as de nível 1, ainda enfrentam alguns desafios comunicacionais. As empresas nível 2
dão particular foco aos processos de planejamento e mapeamento dos requisitos do
projeto através da utilização do jogo de cartas, Planning Poker no Scrum.
O terceiro nível, definido, foca nas práticas relacionadas a relacionamento com
cliente, entregas frequentes, comunicação e testes de qualidade. O relacionamento com
o cliente é mantido através da garantia de alta efetividade das entregas através do
profundo conhecimento de suas necessidades. Por outro lado, o desafio desse patamar é
manter a alta velocidade das entregas de maneira sustentável. Além disso, não há
gerenciamento de riscos.
30
O nível 4 tem o foco exatamente na velocidade sustentável das entregas do
projeto. As principais metas são gerenciamento do projeto, agenda de trabalho definida
e cumprida, uma equipe capaz de se auto-organizar e gerenciamento de riscos. Além
disso, as organizações nesse grau medem o desempenho de seus projetos e a qualidade
do produto entregue, tanto a prática quanto a entrega são medidas quantitativamente.
O último nível diz respeito a capacidade de gerenciar o desempenho dos projetos
com o objetivo de melhorá-los continuamente. Isso é alcançado através de feedback
quantitativo dos projetos cujos resultados são efetivamente utilizados para geri-los. Esse
nível de maturidade aborda problemas relativos ao nível de satisfação tanto do cliente
quanto da equipe interna, portanto, pretende melhorar o desempenho dos projetos e
evitar possíveis falhas.
31
4 SCRUM VERSUS GERENCIAMENTO DE PROJETOS TRADICIONAL
Após definir a examinar as metodologias tradicionais e ágeis é possível entender
as principais semelhanças e diferenças entre elas. Pode-se dizer que o movimento ágil
surgiu em reação aos métodos clássicos de desenvolvimento de software exatamente por
eles possuírem pontos considerados deficientes para suas necessidades. As
metodologias ágeis se apresentam como uma alternativa para o desenvolvimento de
software e guiado por documentação (ILIEVA S., IVANOV, STEFANOVA E., 2004).
Além disso, o método tradicional pode funcionar para empreendimentos palpáveis ou
definidos na fase de planejamento. Quando os requisitos são inconstantes, essa
abordagem talvez se mostre “engessada”.
Outro ponto abordado na literatura como sendo um ponto fraco do
gerenciamento de projetos tradicionais é o fato de seu foco não ser o cliente do projeto.
A maior parte da energia é direcionada para satisfazer a restrição tripla e a satisfação do
cliente acaba ficando em segundo plano. Sucesso e fracasso são tipicamente avaliadas
em agendas de reunião, orçamentos e especificações, mas não em função de alcançar
satisfação plena do cliente (FRAME J., 2002).
De forma geral, pode-se perceber que o método tradicional traz consigo
uma grande carga de documentação e “burocracia” durante todo o ciclo de vida do
projeto. Isso pode ser bom, pois aumenta a chance que todos os processos e métodos
sejam seguidos, mas, por outro lado, exige um tempo maior para que as formalidades
sejam aprovadas e os documentos elaborados.
O próprio PMBOK (2008) cita ciclos de vida de projeto adaptativos. Segundo o
guia, os métodos adaptativos geralmente são preferidos quando se lida com um
ambiente em rápida mutação, quando os requisitos e escopo são difíceis de definir
antecipadamente, e quando é possível definir pequenas melhorias incrementais que
entregarão valor às partes interessadas. No entanto, posteriores sugestões em relação a
como gerir tais ciclos de vida não são esquematizadas.
32
Pode-se perceber no ciclo de vida tradicional, não há loops iterativos para
modificação do escopo das entregas do projeto. Já no ciclo de vida do Scrum, como
pode ser visto abaixo na figura 9, a mudança é intrínseca ao método através da
iteratividade.
Figura 9: Ciclo de vida do projeto segundo metodologia Scrum.
Fonte: Elaboração própria
Rodrigues (2013) mapeou os processos que aparecem no PMBOK e os
confrontou com os que são abordados pelo Scrum. Dessa forma, sua tabela original
presente no Anexo 1 foi modificada chegando a tabela comparativa a seguir onde é
possível ver quais grupos de processos tradicionais são abordados no Scrum.
Disciplina Grupo do Processo Ação Abordado no Scrum?
Integração Iniciação Desenvolver o termo de abertura do projeto Sim
Integração Planejamento Desenvolver o plano de gerenciamento do projeto Sim
Integração Execução Orientar e gerenciar a execução do projeto Sim
Integração Monitoramento & Controle
Monitorar e controlar o trabalho do projeto Sim
Integração Monitoramento & Controle
Realizar o controle integrado de mudanças Sim
Integração Encerramento Encerrar o projeto ou fase Sim
Escopo Planejamento Coletar os requisitos Sim
Escopo Planejamento Definir o escopo Sim
Escopo Planejamento Criar a EAP Não
33
Disciplina Grupo do Processo Ação Abordado no Scrum?
Escopo Monitoramento & Controle
Verificar o escopo Sim
Escopo Monitoramento & Controle
Controlar o escopo Sim
Tempo Planejamento Definir as atividades Sim
Tempo Planejamento Sequenciar as atividades Sim
Tempo Planejamento Estimar os recursos das atividades Sim
Tempo Planejamento Estimar as durações das atividades Sim
Tempo Planejamento Desenvolver o cronograma Sim
Tempo Monitoramento & Controle
Controlar o cronograma Sim
Custos Planejamento Estimar custos Não
Custos Planejamento Determinar orçamento Não
Custos Monitoramento & Controle
Controlar os custos Não
Qualidade Planejamento Planejar a qualidade Sim
Qualidade Execução Realizar a garantia da qualidade Não
Qualidade Monitoramento & Controle
Realizar o controle da qualidade Sim
Recursos Planejamento Desenvolver o plano de recursos humanos Sim
Recursos Execução Mobilizar a equipe do projeto Não
Recursos Execução Desenvolver a equipe do projeto Sim
Recursos Execução Gerenciar a equipe do projeto Sim
Comunicação Iniciação Identificar as partes interessadas Não
Comunicação Planejamento Planejar as comunicações Sim
Comunicação Execução Distribuir as informações Sim
Comunicação Execução Gerenciar as expectativas das partes interessadas Sim
Comunicação Monitoramento & Controle
Reportar o desempenho Sim
Riscos Planejamento Planejar o gerenciamento dos riscos Não
Riscos Planejamento Identificar os riscos Sim
Riscos Planejamento Realizar a análise qualitativa dos riscos Não
Riscos Planejamento Realizar a análise quantitativa dos riscos Não
Riscos Planejamento Planejar respostas aos riscos Não
Riscos Monitoramento & Controle
Monitorar e controlar os riscos Não
Aquisições Planejamento Planejar as aquisições Não
Aquisições Execução Conduzir as aquisições Não
34
Disciplina Grupo do Processo Ação Abordado no Scrum?
Aquisições Monitoramento & Controle
Administrar as aquisições Não
Aquisições Encerramento Encerrar as aquisições Não
Tabela 1 - Aderência do Scrum aos processos tradicionais descritos no PMBOK.
Fonte: Baseado em RODRIGUES E (2016).
Examinando a comparação conclui-se que de maneira geral, o Scrum aborda
62% dos processos descritos na metodologia tradicional. Tal abordagem pode ocorrer de
forma diferente do proposto no método clássico. Por exemplo, o desenvolvimento do
termo de abertura do projeto tem sua equivalência no Scrum através do processo de
definição de visão do projeto e a atribuição dos papéis como equivalente ao termo de
abertura. No que diz respeito ao gerenciamento do tempo, sai o tradicional controle do
cronograma e entra o controle da execução das atividades do Sprint e gerenciamento do
prazo do mesmo. Nesse sentido, o Scrum apresenta poucas ferramentas se comparado ao
PMBOK.
Agrupando os processos acordo com seus grupos como visto abaixo, pode-se
perceber que os grupos de iniciação e controle recebem menos atenção no framework do
Scrum se comparadas aos de planejamento monitoramento e controle e execução. Isso
ocorre, pois, o Scrum não possui uma fase de planejamento anterior intensa. Além disso,
controla o andamento do projeto, o encerramento de cada fase e as lições aprendidas,
mas não determina em detalhes como encerrar um projeto.
35
Figura 10: Comparação entre as ações abordadas no Scrum e no PMBOK separadas pelo grupo de processos de um projeto.
Fonte: Elaboração própria.
O Scrum acaba não abordando algumas das áreas que antecedem, sucedem e
permeiam o desenvolvimento de um projeto justamente pela busca da agilidade e a
entrega de valor no menor tempo possível. Com o grande foco nos processos da etapa
de execução o método não contempla áreas que, dependendo da complexidade ou
segmento de um projeto, podem ser tão importantes quanto a entrega do produto final
(CRUZ F., 2015).
De forma geral, cada uma das abordagens apresentadas possui pontos fortes e
fracos. Assim, a metodologia deve ser escolhida de acordo com as características do
projeto. Wesley A. em 2010 propôs um caminho para a decidir as técnicas mais
apropriadas para a gestão do projeto, dependendo das especificidades do mesmo como
exibido na figura 11.
36
Figura 11: Espectro de complexidade de projetos: SCRUM ou PMBOK?
Fonte: http://www.inovagp.com/2012/01/scrum-vs-pmbok-como-definir-em-qual-seu-
projeto-se-encaixa-melhor/. Acesso em 11/10/2016.
A classificação da complexidade do projeto, apesar de um tanto subjetiva, é feita
através da análise dos requisitos e da tecnologia envolvida. Os requisitos são
classificados como certos ou incertos e a tecnologia encaixada em uma escala de
conhecida a desconhecida.
De maneira conclusiva, o Scrum é mais apropriado para projetos complexos
onde é difícil definir a priori o escopo total do trabalho. Já a metodologia apresentada
pelas práticas do PMBOK é mais apropriada para projetos que caem no espectro
simples já que essa metodologia abrange uma série de processos que tem funcionado
para projetos onde os requisitos e a tecnologia são bem conhecidos no início do
empreendimento.
37
5 ESTUDO DE CASO
Nesse capitulo será aprofundado o caso da implantação da metodologia Scrum
no gerenciamento nos projetos de uma área de negócios de uma grande empresa do
varejo brasileiro.
5.1 Apresentação da Área de Engenharia de Processos
A área a ser estudada faz parte de uma grande empresa brasileira do segmento de
varejo. A companhia possui mais de mil lojas em 410 cidades no país e apresenta um
sortimento de aproximadamente 60 mil itens que são comprados de mais de 4 mil
fornecedores. Em um dia de eventos especiais como Natal, Páscoa e Black Friday pode
atender até 2 milhões de clientes em suas lojas.
Além disso, a empresa apresenta uma cultura dinâmica onde mudança,
velocidade e resultado são fatores presentes na rotina de todos os funcionários. Como
exemplo dessa cultura, um dos princípios da empresa é “Entender velocidade, urgência
e complacência zero como fatores de vantagem competitiva duradoura”.
A partir de uma demanda não atendida dentro da companhia, havia uma carência
no suporte das demandas da diretoria de operações da empresa, foi criada a área de
engenharia de processos que será analisada. Uma das insuficiências era a baixa
integração entre as diversas áreas e departamentos da empresa. Ademais, ocorria uma
falta de conhecimento sobre a real cadeia de valor do negócio em loja e,
consequentemente, não existia a priorização para a entrada de projetos nas filiais. Por
último, também era necessária a padronização dos processos de loja através de
documentos formais. Nesse cenário foi proposta a estruturação de um departamento
focado no entendimento das carências das lojas da empresa, com o objetivo de
selecionar e implementar projetos com melhorias adequadas alinhadas ao negócio da
organização.
Assim, foi definido como propósito da área alcançar uma mudança de patamar
na operação das lojas da companhia. Foi estipulado que esse objetivo deveria ser
alcançado através de quatro princípios básicos:
Padronização: Padronizar processos;
Inovação: Ampliar os ganhos obtidos com projetos de inovação;
38
Redesenho: Eliminar, simplificar e automatizar os processos de loja;
Controle: Melhorar o controle e gestão das lojas solucionando problemas.
A formação da área foi dividida em duas fases visando um melhor entendimento
das necessidades prioritárias das lojas. A primeira fase foi composta pelo levantamento
do cenário na época, ou seja, os processos, padrões, sistemas, canais e projetos vigentes.
Em seguida foi feita a validação do cenário levantado, a análise de maturidade da
operação de loja, priorização dos pontos carentes a serem trabalhados na segunda fase e
metodologia de trabalho que seria adotada. Após tais análises a área foi efetivamente
estruturada. A fase dois foi composta pelos seguintes passos e é replicada para todos os
projetos da área: Levantamento de melhorias para os processos (análise do processo
atual, benchmarking e alinhamento com a equipe de TI caso o projeto envolva sistemas
informacionais); Priorização das melhorias levantadas e projetos externos caso já
existam algum sobre o mesmo tema; Adaptação dos projetos estratégicos na
priorização; Realização de homologações e pilotos; implantação das melhorias e, por
último, treinamento da equipe de loja para a implantação do projeto.
Figura 12: Metodologia de trabalho da área estudada.
Fonte: Elaboração própria.
A área foi subdividida em duas frentes: projetos externos e redesenho de
processos.
A primeira tem as seguintes atribuições:
● Atender as demandas de mapeamentos emergenciais
● Alterar padrões existentes conforme demanda
39
● Prestar suporte às demais frentes quanto ao funcionamento dos processos
● Atender Lojas para esclarecer dúvidas dos processos
Já a equipe de redesenho de processos tem as funções de:
● Priorizar projetos junto a TI e áreas envolvidas
● Acompanhar execução dos projetos:
Avaliar e aprovar escopo de abertura dos projetos;
Definir cenários de testes;
Realizar testes nas fases de homologação e Piloto;
Validar comunicados dos projetos para as Lojas;
Atender Lojas para esclarecer dúvidas dos processos.
Ambas as frentes possuem o seguinte organograma, além disso, acima dos
analistas plenos encontra-se o gestor da área:
Figura 13: Organograma das frentes da área de engenharia de processos.
Fonte: Elaboração própria.
5.2 Exemplos de Projetos nos Quais a Área se Envolve
Para entender a área e as circunstâncias no qual o Scrum foi aplicado, alguns
projetos em que o departamento estudado tipicamente se envolve serão descritos abaixo.
40
Esses projetos foram selecionados por serem os realizados mais recentemente. Ambos
os projetos se encaixam nos quesitos onde o Scrum pode trazer benefícios.
5.2.1 Projeto Onda de Devolução
A onda de devolução é um processo realizado pelas lojas para devolver para os
centros de distribuição itens que devem ser devolvidos aos seus fornecedores. Isso
ocorre muitas vezes para produtos sazonais, para os quais perde o sentido mantê-los
expostos para venda quando sua época é passada e para CDs e DVDs que também já
não se apresentam mais atrativos para os clientes. Foi diagnosticado que o processo de
devolução era lento, levando em média 14 semanas. Além disso, havia um baixo
atingimento do valor devolvido – 75% (20, 5 MM pendentes).
Tendo em vista essas falhas, foi criada uma nova ferramenta para coleta de itens
através de um aparelho de Radiofrequência (móvel). Foram desenvolvidos também
funções de Atualização de estoque dos itens em background, identificação de saldo e
fornecedor do item no ato do escaneamento além da Criação de relatório de
acompanhamento do coletado pelas Lojas e da automatização do relatório dos valores
devolvidos.
O projeto sofreu diversas modificações ao longo do seu curso devido a
mudanças dos requisitos do sistema. O piloto inicialmente desenvolvido teve que sofrer
várias modificações até que se adequasse de fato à realidade da Loja. Por exemplo, o
modelo e a marca do aparelho de rádio frequência precisou ser trocado no meio do
projeto, pois não funcionava em diversas Lojas da CIA.
As áreas envolvidas no projeto eram a equipe de Tecnologia da Informação (TI)
e a equipe da área estudada em conjunto com a área responsável pela devolução. A
primeira era responsável pelo desenvolvimento da ferramenta e das suas interfaces e as
outras tinham o papel de definir quais funcionalidades a especificidades da entrega
final. Apesar do relativo sucesso final do projeto, seu prazo foi estourado devido às
mudanças que tiveram que ser feitas ao longo de seu curso.
5.2.2 Solicitação de Baixa de Preço Centralizada
Um processo comum no dia a dia da loja é a solicitação de baixa de preço, isto é,
quando um produto se encontra próximo da data de validade, o gerente pode solicitar a
permissão para que seu preço seja diminuído. No entanto, não havia na companhia um
41
canal padrão para as solicitações de baixa que acabavam se perdendo em trocas de e-
mails. Isso demandava um alto tempo da equipe da loja, e da área responsável por
analisar tais pedidos. Muitas vezes as validades dos itens eram expiradas sem que
pudesse haver uma promoção, causando perdas de venda para a empresa.
O projeto tinha o objetivo, então, de criar uma ferramenta que funcionasse como
canal centralizado de pedidos, assim, além de ganhar agilidade o controle sobre as
modificações também aumentou, pois foram padronizados motivos para solicitações e
criados alertas para itens com alta incidência de vencimento.
Esse projeto apresentava um baixo nível de dificuldade e, apesar disso,
demourou um tempo substancial para que entrasse no ar (28 semanas). Isso pode ter
ocorrido devido ao alto nível burocrático encontrado durante sua execução.
5.3 Como o Scrum Entrou na Área
Como é possível perceber, a área envolve-se em muitos projetos nos quais
sistemas são desenvolvidos ou melhorados. Como na maioria das grandes empresas, a
dependência tecnológica faz com que a área da tecnologia da informação tenha grande
papel no sucesso de tais projetos e, assim, o compartilhamento e a “cooperatividade”
com equipe de TI é essencial para o atingimento de bons resultados.
A área costumava utilizar alguns artefatos do gerenciamento de projetos
tradicional. Dos processos de iniciação, para cada projeto da área era elaborado pelos
funcionários da área um Termo de Abertura que deveria ser aprovado pelos envolvidos
no projeto. Já no que diz respeito aos processos de planejamento clássicos, era feito um
Plano de Projeto que também deveria receber o aval dos envolvidos. Não havia um
processo definido de execução e nem de planejamento e controle. Ficava a escolha do
responsável pelo projeto na área desenvolver tais processos. Em alguns casos, eram
enviados relatórios de status semanais, por exemplo. O mesmo ocorria com o
encerramento dos projetos, não havia um fluxo oficial definido para tal.
Um dos projetos no qual a área foi envolvida durante o ano de 2016 consiste em
um grande empreendimento para empresa. Ele consiste em modificar todo o sistema de
PDVs (Pontos de Venda) em todas as lojas da empresa. Essa necessidade foi sentida,
pois o fornecedor do sistema vigente tornava qualquer processo de modificação moroso
42
e de alto custo. A partir de tal demanda, uma grande empresa de tecnologia, líder em
comércio eletrônico na América Latina, foi contratada para desenvolver o novo sistema.
O papel da Área de Engenharia De Processos no projeto foi o de definir as
regras de negócio, ou seja, todas as normas definidas pela Cia. deveriam ser seguidas
pelo sistema. Para a definição dos Casos de Uso de cada funcionalidade foram
realizadas diversas análises junto a outras áreas da empresa como financeiro, logística
reversa, jurídico e outros.
Outra atribuição era a de melhorar os processos existentes, assim, foi feito um
mapeamento de todos os processos do sistema anterior e investigados seus pontos
críticos. Dessa forma, foram desenvolvidos casos de uso que incorporaram as regras da
Cia. e buscavam otimizar os pontos falhos para cada função do novo programa. Tal
definição de cada funcionalidade era feita em reuniões entre a equipe da área de
processos e a equipe desenvolvedora que, em conjunto, chegavam a um consenso de
como cada uma delas seria concebida no sistema.
Esse foi o momento no qual o Scrum foi apresentado à área, já que era a
metodologia utilizada pela equipe de desenvolvimento do novo software. A rapidez do
desenvolvimento do projeto e a facilidade com a qual o projeto atendia às mudanças
solicitadas agradou a equipe que estava acostumada com o gerenciamento de projetos
tradicional normalmente aplicado.
A partir desse primeiro contato, gestor da área se interessou pela nova forma de
gerir projetos e em conversas informais com os gestores da equipe de TI negociou um
treinamento de Scrum para a equipe de engenharia de processos. Algum tempo depois, o
gerente do projeto passou uma manhã explicando para os funcionários da área como o
Scrum funciona.
Após essa passagem de conhecimento, foi marcada uma data para a reunião de
planejamento do Sprint para que assim fosse iniciada a efetiva aplicação da metodologia
na área.
O primeiro passo para a aplicação foi a solicitação às para que as duas analistas
plenas listassem todas as atividades dos membros de suas respectivas equipes. Foram
incluídas na lista de tarefas tanto as atividades rotineiras do grupo, como o envio diário
de relatórios, por exemplo, até as incumbências de cada um nos projetos no qual
estavam envolvidos.
43
Uma vez definidas os afazeres individuais, foi iniciado o Planning Poker. As
analistas plenas descreviam a atividade mapeada para a equipe inteira e cada um
selecionava uma das cartas mostrada na figura abaixo. As pessoas efetivamente
responsáveis pela tarefa muitas vezes interrompiam a explicação das analistas plenas
para melhor esclarecer as especificidades da incumbência. Todos então mostravam
simultaneamente a carta escolhida. Caso houvesse divergência, a pessoa que tivesse
escolhido a carta com o maior valor explicava suas razões para a decisão. O mesmo
fazia quem havia escolhido a carta de menor número. Após tais esclarecimentos cada
integrante da equipe selecionava novamente uma carta e as mostrava para todos em uma
segunda rodada. Isso era repetido até que todos tivessem escolhido cartas de mesmo
valor. O máximo de rodadas que ocorreram no jogo foram quatro. Em média, o valor da
tarefa era decidido em duas rodadas. Após uma reunião com duração de cinco horas,
todos os participantes tinham definidas as suas atividades e seus relativos pontos de
forma completa.
Figura 14: Modelo de cartas utilizadas durante o planning poker.
Fonte: <http://www.luiztools.com.br/post/planning-poker-como-estimar-tempo-de-
desenvolvimento-de-software/> Acesso em 23/10/2016.
Foi definido que o Sprint teria duração de duas semanas e teria o valor de vinte
pontos, já que essa era a configuração utilizada pela equipe de TI em seu projeto. Além
disso, a priorização das atividades foi feita inteiramente pelo gestor da área, ele decidiu
44
o que entraria na fila Backlog e na fila To Do, ou seja, que deveria ser entregue nas duas
semanas seguintes e o que deveria aguardar.
Após essas definições, foi montado em uma das paredes da área o quadro Scrum
com as seguintes divisões: “Backlog”, “To Do”, “Doing”, “Approval” e “Done”. Essa
organização se diferencia do Quadro Scrum original que não possui a última divisão
relacionada à aprovação. As imagens do quadro Scrum real utilizado encontram-se no
Apêndice B.
Figura 15: Exemplo de quadro Scrum radicional.
Fonte: <http://scrumbook.com.br/help/pt-br/> Acesso em 23/10/2016.
Foi definido que cada post it teria o lay out apresentado abaixo:
Figura 16: Exemplo do post it do quadro Scrum do estudo de caso.
Fonte: Elaboração própria
45
Uma vez feitos os post its, foi acordado que a cada atualização na tarefa, a
organização da parede deveria ser também refeita. Ou seja, os papéis deveriam estar
sempre no seu estágio vigente: “Backlog”, “To Do”, “Doing”, “Approval” ou “Done”.
Foi combinado também que ocorreriam as reuniões diárias do Scrum todo início de dia
além das reuniões de revisão dos Sprints a cada duas semanas.
5.4 Discussão Sobre a Aplicação do Scrum
Pode-se discutir que a reunião inicial de planejamento do Sprint somado à
preparação do quadro Scrum demandou da equipe da área um longo tempo que poderia
ter sido utilizado nas atividades efetivas do projeto. No entanto, toda mudança exige um
investimento inicial e possui uma curva de aprendizado. Dessa forma, espera-se que
tempo gasto será provavelmente recompensado após a implantação do novo método.
De fato, a clareza do que cada membro da equipe deveria fazer fez com que as
ações de tornassem mais objetivas. Por outro lado, algumas das atividades ficaram sob a
responsabilidade de “todos” diminuindo o grau de responsabilidade individual dos
membros da equipe. De qualquer maneira, diminuíram as dúvidas sobre o que deveria
ser feito nem sobre a ordem na qual as tarefas deveriam ser executadas. Além disso, a
“pressão” visual das tarefas na parede fez com que a equipe se esforçasse mais do que
na semana anterior para conseguir atingir os prazos.
Por outro lado, a empresa estudada possui conhecidamente uma cultura muito
acelerada, na qual decisões são tomadas rotineiramente de forma emergencial. Isso
ocorre muitas vezes de maneira top down, e dessa maneira, algumas outras atividades
foram “repriorizadas” durante o andamento da semana. Durante a primeira semana da
nova prática, por exemplo, toda a equipe foi obrigada a pausar as atividades dos projetos
para atender a uma demanda urgente vinda da diretoria. Além disso, ao longo do Sprint
surgiram outras demandas dos projetos que não haviam sido mapeadas inicialmente.
Dessa forma, a parede Scrum ficou desatualizada no que diz respeito a novas tarefas,
mas as que foram mapeadas tinham seus status atualizados constantemente no quadro.
Além disso, as reuniões de status diárias não foram implementadas. Isso se deu
principalmente pelo fato de o gestor no comando não privilegiar a atividade em relação
a outras tarefas.
46
Abaixo uma descrição sobre como cada passo da aplicação da metodologia
ocorreu na área:
1. Escolher um Product Owner: Os projetos nos quais a área estava
envolvida já estavam em andamento e, a maioria deles, têm o
envolvimento de outras diversas áreas que não foram envolvidas no
processo de aplicação do Scrum. Em alguns desses projetos, não é claro
qual área é de fato “dona” do empreendimento e esse ponto não foi
tocado ao longo da utilização da metodologia.
2. Selecionar a equipe do projeto: A equipe já estava definida e não foi
modificada no processo de aplicação. Como já explicado, os projetos
tinham envolvidas outras pessoas de áreas distintas à estudada que não
foram incluídas na aplicação. Dessa forma, a equipe da área respeitava a
regra do Scrum, de 3 a 9 pessoas, mas o projeto como um todo não.
3. Definir um Scrum Master: Pode-se dizer que não houve um responsável
por garantir que equipe cumprisse as práticas da metodologia. O gestor
da área foi a pessoa que mais se aproximou a esse papel pois os
resultados dos Sprints deveriam ser apresentados a ele. No entanto, não
houveram cobranças em relação a ocorrência das reuniões diárias e nem
mesmo da reunião de aplicação dos Sprints.
4. Criar um backlog do produto e priorizá-lo: Esse foi passo que recebeu a
maior parte dos esforços e atenção no caso estudado. O backlog das
tarefas da área foi cuidadosamente feito pela equipe e priorizado pelo
gestor. No entanto, novas atividades que surgiram durante o Sprint não
foram incluídas no backlog e nem “repriorizadas” oficialmente.
5. Planejar o Sprint: Como explicado anteriormente, a pontuação do Sprint
foi baseada na utilizada pela equipe de TI que inspirou a utilização do
Scrum e não levou em consideração possíveis diferenças e
especificidades da área estudada.
6. Tornar o trabalho visível: O Quadro Scrum” que deixava visível as três
colunas: “A fazer”, “Fazendo” e “Feito” foi montado incluindo mais uma
coluna “Aprovação” já que para algumas tarefas era necessária a
aprovação do gestor para que a mesma fosse considerada feita. As tarefas
47
colocadas no quadro tinham seus status atualizados mas novas atividades
que surgiram ao longo do Sprint não foram incluídas.
7. Realizar a reunião diária ou Scrum diário: Não foi realizada.
8. Revisar o Sprint: A reunião de revisão do primeiro Sprint acabou sendo
realizada com duas semanas de atraso.
9. Retrospectiva do Sprint: Não realizada.
Como mostrado anteriormente e presente no Anexo, Rodrigues E. (2016) fez
uma comparação entre os processos da metodologia tradicional e os abordados na
metodologia Scrum. Dessa forma, a tabela abaixo resume os processos realizados no
caso estudado antes da aplicação da metodologia e os equivalentes adotados a partir da
aplicação do Scrum:
Grupo do Processo
Metodologia Tradicional
Abordado antes?
Equivalência no Scrum Abordado
após Scrum?
Iniciação
Desenvolver o termo de
abertura do projeto
✓Sim Definição da visão do projeto e a atribuição
dos papéis ✓Sim
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.
✓Sim
Planejamento Coletar os requisitos ✓Sim
Parcial, porque não determina técnicas e
ferramentas, apenas diz que é responsabilidade
do Product Owner.
✓Sim
Planejamento Definir o escopo ✓Sim
Considerando o Planning Poker deixa
bem claro os objetivos e limites do projeto.
✓Sim
Planejamento Criar a EAP X Não
O Scrum não tem nenhuma ferramenta
equivalente a Estrutura Analítica do Projeto.
X Não
48
Grupo do Processo
Metodologia Tradicional
Abordado antes? Equivalência no Scrum
Abordado após
Scrum?
Planejamento Definir as atividades ✓Sim
A equipe define as atividades no Sprint
backlog. ✓Sim
Planejamento Estimar os
recursos das atividades
X Não
Faz o contrário do PMBOK. A partir dos recursos disponíveis x
tempo, determina o trabalho que a equipe é
capaz de fazer.
✓Sim
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.
✓Sim
Planejamento Desenvolver o
cronograma X Não
Não desenvolve cronograma, mas mostra
os itens do backlog e atividades dentro de um
Sprint.
✓Sim
Planejamento Estimar custos X Não Não mapeia este item. X Não
Planejamento Determinar orçamento X Não Não mapeia este item. X Não
Planejamento Planejar a qualidade X Não Planeja usando os
conceitos de “Feito”. ✓Sim
Planejamento Planejar as
comunicações X Não
As comunicações já estão planejadas pelo processo (Cerimônias, artefatos e reuniões),
mas não envolvem todos os stakeholders.
✓Sim
Planejamento Identificar os
riscos X Não Não mapeia riscos, apenas impedimentos.
✓Sim
49
Grupo do Processo
Metodologia Tradicional
Abordado antes? Equivalência no Scrum
Abordado após
Scrum?
Planejamento
Realizar a análise
qualitativa dos riscos
X Não Não mapeia este item. X Não
Planejamento
Realizar a análise
quantitativa dos riscos
X Não Não mapeia este item. X Não
Planejamento Planejar
respostas aos riscos
X Não Não mapeia este item. X Não
Planejamento Planejar as aquisições X Não Não mapeia este item. X Não
Execução
Orientar e gerenciar a
execução do projeto
✓ Sim Orienta e acompanha em detalhes a execução. ✓Sim
Execução Realizar a garantia da qualidade
X Não Não prevê claramente
atividades de garantia da qualidade.
X Não
Execução Mobilizar a equipe do
projeto ✓Sim Não mapeia este item. ✓Sim
Execução Desenvolver a
equipe do projeto
X Não
Prevê o desenvolvimento da
equipe no dia-a-dia e nas Reuniões de
Retrospectiva do Sprint.
X Não
Execução
Gerenciar a
equipe do
projeto
✓Sim
Não define deve ser feita
a gestão de conflitos e
avaliações de
desempenho, trabalha
com times
autogerenciáveis.
✓Sim
50
Grupo do Processo
Metodologia Tradicional
Abordado antes? Equivalência no Scrum
Abordado após
Scrum?
Execução
Gerenciar as expectativas das partes
interessadas
✓Sim
Gerencia as expectativas apenas do Product
Owner e deixa a este a responsabilidade de
gerenciar expectativas de outros stakeholders.
✓Sim
Execução Conduzir as aquisições X Não Não mapeia este item. X Não
Monitoramento & Controle
Utilização de ferramentas
de monitoramento e controle
definidas
X Não
Monitora o trabalho nas extremidades dos
Sprints, como um pacote de trabalho através das Reuniões de Revisão do
Sprint.
✓Sim (Feito com
atraso)
Monitoramento & Controle
Realizar o controle
integrado de mudanças
X Não
Realiza o controle de mudanças através do
realinhamento de prioridades entre os
Sprints, verifica impactos antes de aceitar mudanças e replaneja o
Sprint.
✓Sim
Monitoramento & Controle
Verificar o escopo X Não
É o ponto mais forte do Scrum, realizado na
Reunião de Revisão do Sprint.
✓Sim (Feito com
atraso)
51
Grupo do Processo
Metodologia Tradicional
Abordado antes? Equivalência no Scrum
Abordado após
Scrum?
Monitoramento & Controle
Controlar o escopo X Não
Controla escopo tanto por prioridade, quanto por completude usando
o Sprint x produto.
✓Sim
Monitoramento & Controle
Controlar o cronograma X Não
Controla a execução das atividades do Sprint e
gerencia prazo. Mas tem poucas ferramentas
comparado ao PMBOK.
✓Sim
Monitoramento & Controle
Controlar os custos X Não Não mapeia este item. X Não
Monitoramento & Controle
Realizar o controle da qualidade
X Não Verifica a qualidade (e o escopo) nas Reuniões de
Revisão do Sprint.
✓Sim (Feito com
atraso)
Monitoramento & Controle
Reportar o desempenho X Não
Reporta o desempenho de forma bem transparente.
✓Sim
Monitoramento & Controle
Monitorar e controlar os
riscos X Não Não mapeia este item. X Não
Monitoramento & Controle
Administrar as aquisições X Não Não mapeia este item. X Não
Encerramento Encerrar o projeto ou
fase X Não
Controla o andamento do projeto, mas não
determina em detalhes como encerrar o projeto,
como resolver pendencias, encerrar
contratos etc.
X Não
52
Grupo do Processo
Metodologia Tradicional
Abordado antes? Equivalência no Scrum
Abordado após
Scrum?
Encerramento Encerrar as aquisições X Não Não mapeia este item. X Não
Tabela 2 - Processos realizados antes da aplicação da metodologia e os equivalentes adotados a partir do Scrum.
Fonte: Elaboração própria, baseado em Rodrigues E. (2016).
É possível perceber que nenhum ponto incluído na metodologia tradicional
utilizada pela área anteriormente com a metodologia tradicional deixou de ser abordado
com o Scrum. Pelo contrário, alguns processos que antes não eram alcançados passaram
a ser utilizados como: Estimar os recursos das atividades: Desenvolver o cronograma
(controle do tempo); Planejar a qualidade; Planejar as comunicações; Identificar os
riscos; Utilização de ferramentas de monitoramento e controle definidas; Realizar o
controle integrado de mudanças; Verificar o escopo; Controlar o escopo; Controlar o
cronograma: Realizar o controle da qualidade e reportar o desempenho.
De fato, alguns desses processos foram feitos fora do prazo inicialmente
estipulado devido ao atraso da realização da Reunião de Revisão do Sprint como
explicado anteriormente. No entanto, de maneira geral, é possível dizer que a aplicação
do Scrum aumentou o escopo do gerenciamento na área já que abordou mais processos
e métodos definidos do o que era utilizado no passado.
5.5 Resultados Encontrados
Adotar um novo conceito de trabalho muitas vezes é mais complexo do que o
imaginado inicialmente e isso não é diferente para a adoção do Scrum. É uma realidade
que diversas organizações têm adotado as novas práticas das metodologias ágeis. No
entanto, um estudo de 2012 sobre produtividade de equipes feto pela Actuation
Consulting, indicou que apenas 13% das empresas utilizadoras do Scrum aplicavam
todas as suas práticas no dia a dia e isso não foi diferente na área estudada.
A aderência à metodologia não foi forte principalmente devido ao fato que os
pontos ignorados na experiência serem essenciais para o engajamento da equipe e
consequente sucesso da aplicação.
53
Em primeiro lugar, o fato de não ocorrerem reuniões Scrum diárias deixou os
envolvidos incertos sobre o real engajamento da gerência na mudança de conceito de
trabalho. Além disso, como o objetivo da reunião é o de deixar todos cientes sobre o
andamento do trabalho e engajados com as entregas do Sprint, tal propósito não foi
alcançado.
Em segundo lugar, o fato de a reunião de revisão de Sprint no prazo, onde
deveriam ter sido apresentados os resultados das duas semanas intensas de trabalho,
desmotivou o time a continuar empenhado no ritmo acelerado exigido para a finalização
de tais tarefas. Além disso, a incerteza sobre a ocorrência da reunião de priorização do
Sprint seguinte fez com que, após passado o período das duas primeiras semanas, a
equipe voltasse a rotina de trabalho anterior. Sem uma nova reunião, não houve outra
definição nem priorização das tarefas mais recentes.
Outro ponto crucial não estava no escopo da aplicação. O envolvimento na
metodologia de todos os participantes no projeto fez com que o método servisse apenas
como uma forma de gerir as tarefas individuais das pessoas da área. Para que o projeto
tenha sucesso e seja entregue mais rapidamente é necessário que todos os envolvidos
consigam caminhar na mesma velocidade acelerada.
Por último, a inexistência de uma pessoa que garantisse o seguimento da
metodologia deixou que a mesma caísse no esquecimento. O próprio comando da área
acabou por priorizar outras atividades e não dar muita importância ao prosseguimento
da implementação do Scrum.
Por outro lado, nas duas primeiras semanas onde o primeiro Sprint havia sido
definido, o fato de as tarefas a serem realizadas estarem claras e visíveis para todos
impulsionou a produtividade da equipe. Não eram necessários questionamentos sobre o
que deveria ser feito e o foco nas atividades prioritárias fomentou que elas fossem
finalizadas.
De fato, o ideal para que fosse medido o verdadeiro impacto do Scrum na área
seria a comparação da produtividade da equipe antes e depois de sua aplicação. Como
não havia medidas sobre o número de tarefas finalizadas anteriormente, em um período
comparativo ao Sprint, não é possível medir quantitativamente a modificação da
velocidade das entregas da equipe.
54
Recorrendo a literatura, apesar de escassa nesse assunto, é possível perceber que
são reportados ganhos de produtividade e de qualidade nos projetos onde o Scrum é
utilizado. Pedro Serrador e Jeffrey K. Pinto, em 2014, utilizaram uma amostra de 1002
projetos provenientes de múltiplas indústrias e países para testar o efeito da aplicação
das metodologias ágeis. Após a análise dos dados, foi descoberto que a utilização de tais
métodos teve de fato um impacto positivo estatisticamente relevante no sucesso do
projeto. Tal resultado foi medido e percebido em três dimensões de sucesso dos
projetos: eficiência, satisfação dos stakeholders e percepção do desempenho do projeto
como um todo.
Karlheinz Kautz, Thomas Heide Johansen e Andreas Uldahl em 2014, também
realizaram um estudo sobre o impacto da utilização do Scrum na produtividade de
projetos e através da utilização de questionários. Com a resposta dos gerentes, foi
constatado que o desempenho da equipe aumentou significativamente. Essa conclusão
foi defendida a partir de dois diferentes pilares: transparência iterações curtas. O
primeiro diz respeito à visibilidade das tarefas, isso, segundo os gerentes, tornava
compulsório que as pessoas apresentassem publicamente seus trabalhos e por isso se
comprometessem com seus afazeres independentes do desafio encontrado. Já o segundo
está relacionado ao fato de as pequenas interações através dos Sprints o não
cumprimento de prazos dos projetos. Com a diluição das entregas, foi percebido pelos
entrevistados que os limites de tempo foram mais cumpridos.
Esses resultados favoráveis estão em linha com os resultados dos outros
conceitos e dos seus indicadores, os quais foram todos muito positivos (JOHANSEN,
ULDAHL, 2012). Por outro lado, por se tratar de um estudo qualitativo, é preciso ser
cauteloso ao analisar os resultados, pois eles são embebidos de opiniões e expectativas
pessoais.
55
6 PROPOSTAS
6.1 Percepção da Equipe Envolvida
Como descrito na sessão anterior, devido a impossibilidade de medir
quantitativamente o resultado do Scrum no estudo de caso, será feita uma abordagem
qualitativa para se obter o efeito da metodologia ágil na área.
O desenvolvimento dos projetos depende significativamente no desempenho da
equipe assim como todos os processos que exigem interações humanas. Segundo Nils
Brede Moe e Torgeir Dingsøyr, Tore Dybå (2009), uma definição comumente utilizada
para equipes Scrum é: Um pequeno número de pessoas com habilidades
complementares que estão comprometidos em um propósito igual e definem conjunto
de metas de desempenho e se responsabilizam mutuamente por atingi-las.
Considerando a importância da percepção da equipe perante a experiência da
aplicação e a inexistência de dados para melhor apurar impacto do Scrum na
produtividade do time, essa seção busca, através do olhar dos envolvidos, examinar os
resultados da aplicação da metodologia.
Foi então realizado um questionário 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). Os
pontos analisados são descritos abaixo e estão alinhados com os anteriormente
explicados no capítulo 4 como sendo os tópicos essenciais do Scrum:
• Seleção de um Product Owner;
• Seleção de um Scrum Master;
• Sprints com duração de 2 semanas;
• Criação do backlog dos projetos, do Sprint e priorização das tarefas;
• Reunião de planejamento do Sprint;
• Reuniões de Scrum diárias;
• Quadro de atividades visível (Quadro Scrum);
• Reunião de revisão dos Sprints;
• Reunião de retrospectiva dos Sprints.
56
Além disso, duas perguntas abertas tinham o intuito de obter impressões mais
amplas da equipe em relação a maior dificuldade e ao maior ganho da utilização do
Scrum na área. Os resultados estão apresentados na integra nos Apêndices C e D.
Segundo os entrevistados, a técnica com o maior nível de dificuldade de
implantação foi a 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 técnica considerada a mais fácil de ser utilizada foi a elaboração do
quadro de atividades visível (Quadro Scrum com os status "Backlog", "To Do", "Doing"
e "Done"). De maneira geral, como é possível perceber no gráfico resumo abaixo, a
percepção do nível de dificuldade da aplicação como um todo pode ser considerado
como moderado.
Figura 17: Gráfico Resumo - Percepção do Nível de Dificuldade de Aplicação das Técnicas Segundo Equipe.
Fonte: Elaboração própria
No que diz respeito ao consumo do tempo nos projetos, duas técnicas foram
unanimemente consideradas como positivas para os prazos a 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) e a implantação de Sprints com duração de 2 semanas.
Nível de Dificuldade de Aplicação das Técnicas Segundo Equipe
Alto
Médio
Baixo
57
Por outro lado, um pequeno percentual de respondentes (14%) considerou que a
utilização da reunião de revisão dos Sprints e a reunião de retrospectiva dos Sprints
trouxeram impactos negativos no tempo dos projetos, ou seja, perdas.
Figura 18: Gráfico resumo - Percepção Sobre Impacto no Consumo de Tempo nos Projetos.
Fonte: Elaboração própria.
Como é possível visualizar no gráfico acima, a percepção é que no geral a
aplicação do Scrum trouxe benefícios para a velocidade do andamento dos projetos na
área já que a maioria das técnicas trouxe ganhos de consumo de tempo segundo os
participantes.
Quando abertamente perguntados qual o maior desafio da aplicação do Scrum,
as respostas foram predominantemente sobre a dificuldade de conseguir fazer com que a
aplicação do Scrum não se perdesse e nem fosse esquecida. Alguns também apontaram
dificuldades mais pontuais como a dificuldade de selecionar pequenas tarefas para
Percepção Sobre Impacto no Consumo de Tempo nos Projetos
Ganho Sem modificação Perda
58
serem executadas até o fim do projeto para a montagem do backlog e o estabelecimento
da reunião diária.
Por outro lado, quando o questionamento foi “Qual foi o maior benefício da
aplicação do Scrum na área?”, a maioria dos respondentes encontrou na visibilidade e
definição das tarefas o ponto mais positivo da aplicação. Além disso, também foi dito
que “a melhor definição das entregas e dos esforços de cada tarefa permitiu medir
melhor o tempo de entrega de cada projeto” e o aumento da velocidade das entregas
também foi ressaltado por alguns.
6.2 Análise do Grau de Maturidade do Scrum na Área
Foi desenvolvido um questionário para avaliar qual o grau de maturidade do
Scrum em uma organização (YIN, 2011). Caso a empresa obtenha uma pontuação a
partir de 75% do questionário de certo nível isso significa que ela se encontra nele. Caso
contrário, se encaixa no nível anterior. Foi solicitado ao chefe da área que respondesse o
questionário presente no Anexo 2 relacionado ao nível 2 de maturidade Scrum, o caso
estudado pontou apenas 53%, demonstrando que ainda se encontra no primeiro nível de
maturidade da metodologia.
De fato, o nível mais baixo de maturidade é dado para qualquer organização que
utiliza o Scrum em algum nível já que não apresenta metas de definição de tais projetos
nem melhorias. Nesse patamar, as principais questões encontradas são não cumprimento
dos prazos e orçamento, baixa comunicação entre os envolvida no projeto e, finalmente,
baixa qualidade do produto entregue.
Após essa análise, pode-se perceber, que as impressões da equipe estavam de
fato alinhadas ao nível de maturidade do Scrum apresentado na área.
6.3 Orientações Futuras
Dada a análise dos processos abordados na aplicação do Scrum no caso, da
análise da maturidade e os resultados da pesquisa de percepção dos envolvidos no
projeto, algumas orientações serão dadas para que aplicação da metodologia apresente
melhores resultados. Elas estão separadas pelas esferas do Scrum e possuem um
objetivo de melhorar cada uma delas.
59
6.3.1 Clara definição do projeto
a. Práticas a serem aplicadas
1. Definir um Product Owner para todos os projetos.
2. Product Owner deve ter contato direto com o usuário final (cliente) do
projeto.
3. Product Owner deve ter a visão do projeto.
b. Métrica para medir desempenho
1. % de reuniões do Scrum nas quais o Product Owner participou.
c. Meta para caso estudado
Dado que no caso de estudo, muitas vezes um Product Owner não estava
claramente definido, o primeiro passo é designar o responsável por cada um dos
projetos da área. Após tal definição, a meta para que ele esteja envolvido na aplicação
da metodologia e, assim, no andamento do projeto é que ele compareça em pelo menos
70% das reuniões de planejamento, revisão e retrospectiva do Sprint.
6.3.2 Reuniões de planejamento do Sprint
a. Práticas a serem aplicadas
1. Product Owner apresenta Backlog do produto priorizado
2. Product Owner colabora ativamente na reunião
3. Toda a equipe participa ativamente da reunião
4. Toda a equipe acredita que o planejado para o Sprint é possível de ser
realizado
b. Métricas para medir desempenho
1. % de consenso que o plano pode ser atingido
c. Meta para caso estudado
Dado o sucesso da reunião de planejamento de Sprint que ocorreu na área, a
meta definida para o percentual de consenso para que o plano possa ser atingido pode
ser definida como 90%. Caso o valor encontrado seja menor do que esse é muito
60
provável que durante o Planning Poker os pontos de cada tarefa tenham sido
superestimados.
6.3.3 Gerenciamento do Backlog do Produto
a. Práticas a serem aplicadas
1. Backlog do produto devem estar sincronizados com a visão do Product Owner
2. Backlog do produto deve ser priorizado pelo Product Owner
3. Backlog do produto deve ser priorizado pelo Product Owner de acordo com
valor que agrega ao negócio
b. Métrica para medir desempenho
1. % de prioridades definidas pelo Product Owner.
c. Meta para caso estudado
Como no exemplo estudado, o Product Owner não estava envolvido no processo
e as prioridades eram definidas pelo gestor da área. Dessa forma, uma boa meta inicial é
que 70% do Backlog do produto seja priorizado por ele.
6.3.4 Reunião de Revisão do Sprint
a. Práticas a serem aplicadas
1. Equipe apresenta resultados do Sprint
b. Métrica para medir desempenho
1. % de reuniões de revisão de realizadas por Sprint no prazo
c. Meta para caso estudado
A não realização da reunião de revisão de Sprint no caso estudado levou ao
baixo engajamento da equipe e ao atraso do planejamento dos posteriores Sprints. Além
disso, expôs o baixo engajamento da gerência em relação à metodologia. Dessa forma, é
considerado de extrema importância que 100% das reuniões de revisão de Sprint sejam
realizadas no período determinado para o sucesso da aplicação.
6.3.5 Reunião de Retrospectiva do Sprint
a. Práticas a serem aplicadas
61
1. Equipe apresenta resultados do Sprint para partes interessadas
2. Partes interessadas dão feedback a respeito do Sprint
b. Métrica para medir desempenho
1. % de reuniões de retrospectiva realizadas por Sprint
c. Meta para caso estudado
No caso estudado, não houve reuniões de retrospectiva de Sprint. Esse ponto
também é considerado de extrema importância para a futura aplicação do Scrum na área
já que será capaz de diagnosticar possíveis falhas e assim corrigi-las. Dessa forma, a
meta para essa métrica é a de realização de 100% das reuniões de retrospectiva dos
Sprints.
6.3.6 Reunião diária
a. Práticas a serem aplicadas
1. Equipe se reúne e responde às perguntas: “O que você fez para ajudar a
equipe a concluir o Sprint? ”, “ O que você fará para ajudar a equipe a concluir o
Sprint? ” E “Há algum obstáculo impedindo o alcance da meta do Sprint? ”
2. Reunião deve durar no máximo quinze minutos
b. Métrica para medir desempenho
1. Quantidade de reuniões diárias realizadas por semana
c. Meta para caso estudado
Para que seja mantido ritmo e o engajamento com o Scrum, uma meta de
realização de reuniões diárias ao menos duas vezes na semana ajudaria o time a
continuar fixado na metodologia.
6.3.7 Metas e Melhorias Resumidas
Dadas todas as sugestões de melhoria baseadas nos pontos falhos da implantação
da metodologia ágil, a tabela a seguir descreve as práticas e metas estipuladas com o
objetivo de aprimorar a aplicação do Scrum no caso estudado.
62
Práticas a serem
aplicadas Meta Estipulada Melhoria desejada
Clara definição do projeto
Definir um Product Owner para todos os
projetos.
Product Owner comparecer em pelo
menos 70% das reuniões de
planejamento, revisão e retrospectiva do
Sprint.
Melhorar definições do projeto e manter
alinhamento constante com o Product Owner.
Reuniões de planejamento
do Sprint
Product Owner apresenta Backlog do produto priorizado e
equipe entra em consenso sobre
entregas do Sprint.
90% de consenso da equipe de que o plano
é alcançável
Gerenciar melhor expectativas da
equipe e do Product Owner.
Gerenciamento do Backlog do
Produto
Backlog do Produto priorizado
corretamente.
70% do Backlog do produto seja
priorizado pelo Product Owner.
Definir de forma mais assertiva as prioridades do projeto com a inclusão da
perspectiva do Product Owner.
Reunião de Revisão do
Sprint
Equipe apresenta resultados do Sprint.
100% das reuniões de Revisão de Sprint
realizadas no prazo determinado.
Manter equipe engajada na
metodologia e garantir que as entregas estão
caminhando como desejado.
Reunião de Retrospectiva
do Sprint
Apresentação do resultado do Sprint e feedback das partes
interessadas.
100% das reuniões de Retrospectiva de
Sprint realizadas no prazo determinado.
Verificar se entregas foram efetivas e,
através de feedback, melhorar os processos
continuamente.
Reunião diária Realizar reunião
diária.
Realização da reunião durante quinze
minutos ao menos duas vezes na semana para manter aderência
à metodologia.
Manter equipe engajada
diariamente e com foco definido de maneira clara.
Tabela 3 - Quadro resumo de sugestões e impactos esperados
Fonte: Elaboração própria.
Dessa forma, se de fato as melhorias esperadas fossem alcançadas com
implantação das sugestões, os pontos falhos encontrados através do diagnóstico da
maturidade da metodologia e da análise das entrevistas dos participantes seriam
sanados.
63
6.4 Estudos Posteriores
Como explicado na seção de metodologia de pesquisa, nesse trabalho foi
utilizada a técnica da pesquisa-ação. No entanto, devido à falta de autonomia, as
sugestões de melhoria não foram implantadas. Dessa forma, posteriores estudos a
respeito da efetiva melhoria da aplicação da metodologia com as métricas e metas
propostas precisam ser feitos para que seu real impacto seja contabilizado.
Além disso, a para que sejam estudados os reais ganhos da utilização de
metodologias ágeis no gerenciamento de projetos, é necessário que seja medida a
produtividade da equipe antes e depois da utilização de tais metodologias de
gerenciamento.
64
7 CONCLUSÃO
A maior vantagem de se implementar um gerenciamento de projetos ágil, e
principalmente o Scrum, é a simplicidade. Em um projeto gerenciado de maneira ágil,
os papéis são claramente definidos e, além disso, partes do produto final podem ser
entregues em ciclos rápidos de iteração e assim, funciona bem para cenários onde são
necessárias rapidez e flexibilidade.
Além disso, como cada membro do time possui uma responsabilidade particular
a propriedade do projeto permeia a equipe como um todo. Cada um tem seu papel
definido e concretizado visualmente no quadro Scrum. Sem cada uma dessas
contribuições pessoais, o produto final não alcança sua completude. Todos esses pontos,
em conjunto, tem o potencial de levar a uma maior produtividade de todos os
envolvidos.
Por outro lado, antes de embarcar em um projeto gerido com o método Scrum
são necessárias algumas precauções. Adotar um novo conceito pode ser mais difícil do
que aparenta em um primeiro momento e esse também é o caso das metodologias ágeis.
Para que os benéficos do Scrum sejam de fato alcançados é necessário que a aderência
metodologia seja mantida. Dessa forma, o apoio da gerência com o objetivo de manter a
disciplina a metodologia é essencial para o sucesso do novo gerenciamento.
De fato, foi possível perceber que o Scrum trouxe ganhos para a área, o que
ficou claro a partir a pesquisa de opinião dos envolvidos e com a comparação entre os
processos abordados na área com metodologia tradicional e os novos após a aplicação
do Scrum. Diversos novos pontos que antes não eram abordados passaram a ser tratados
no dia-a-dia. Isso talvez tenha sido verdadeiro no caso porque a metodologia tradicional
de gerenciamento de projetos não era totalmente incorporada na área.
Como descrito anteriormente, as metodologias tradicionais são melhor
aplicáveis quando o escopo do projeto é bem definido no início do projeto e não são
necessárias muitas mudanças ao longo do mesmo. A não aderência da área às
metodologias tradicionais se dava exatamente pela rotina de mudanças de requisitos
constantes. Assim, mesmo que não implantado completamente, o Scrum foi mais
adequado à realidade inconstante da área trazendo então benefícios como a percepção
da diminuição do tempo de consumo nos projetos.
65
Com os benefícios encontrados em mente, a aplicação das sugestões de melhoria
tem o objetivo de sanar as falhas encontradas durante a aplicação, como a não
realização das reuniões diárias e o atraso da realização da análise do desempenho do
Sprint, e assim promover uma maior adesão ao Scrum o que provavelmente alavancaria
as vantagens da metodologia ágil na área estudada.
Assim, o objetivo especifico de examinar a aplicação do Scrum na área, a partir
da análise da maturidade da metodologia no caso analisado, percepção dos envolvidos e
as melhores práticas encontradas na literatura, estipular métricas e metas com o objetivo
de melhor utilizar a metodologia ágil para o gerenciamento das atividades no cenário
estudado também foi atingida.
66
8 REFERÊNCIAS BIBLIOGRÁFICAS
1. ABIB, J.C.; KIRNER, T.G. GQM-PLAN: Ferramenta para Apoiar
Avaliações de Qualidade de Software. IX Conferência Internacional De
Tecnologia De Software, 1998, Curitiba. Anais da IX Conferência Internacional
de Tecnologia de Software. Curitiba, 1998. v.1, p. 119-130.
2. ALBRECHT J., SPANG K., 2014, Linking the benefits of project management
maturity to project complexity: Insights from a multiple case study.
International Journal of Managing Projects in Business, v. 7, n. 2, p. 285-
301.
3. BASS J., 2002, The New Project Management: tools for an age of rapid
change, complexity and other business realities. 2ed. Virginia, EUA, Wiley.
4. 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.
5. CERVONE, H. F., 2011, Understanding agile project management methods
using Scrum. OCLC Systems & Services: International digital library
perspectives, v. 27, n. 1, p. 18–22.
6. CHARVAT, J., 2003. Project Management Methodologies: Selecting,
Implementing, and Supporting Methodologies and Processes for Projects. 1
ed. Nova Jérsei, EUA. John Wiley & Sons.
7. CHRISSIS, M. B., KONRAD, M., AND SHRUM, S., 2003, CMMI Guidlines
for Process Integration and Product Improvement. Boston, USA. Addison-
Wesley Longman Publishing Co.
8. CRUZ F., 2013, Scrum e PMBOK unidos no Gerenciamento de Projetos. 1
ed. Brasport.
9. DINSMORE P. e CABANIS-BREWIN J., 2006, The AMA Handbook of
Project Management. 2 ed. America Management Association.
10. FORTUNE, J., WHITE, D., 2006. Framing of project critical success factors by
a systems model. International Journal of Project Management, v24, n.1, p.
53–65.
67
11. GERHARDT E SILVEIRA, 2009, Métodos de pesquisa, coordenado pela
Universidade Aberta do e pelo Curso Brasil – UAB/UFRGSe Graduação
Tecnológica – Planejamento e Gestão para o Desenvolvimento Rural da
SEAD/UFRGS. Porto Alegre, Editora da UFRGS.
12. GRUNDY, S. J., Kemmis, S., 1982, Educational action research in Australia:
the state of the art. Geelong: Deakin University Press.
13. HOOGVELD M., KOSTER J., 2016, “Measuring the Agility of Omnichannel
Operations: an Agile Marketing Maturity Model.” Disponível em:
<https://www.researchgate.net/publication/310466971_Measuring_the_Agility_
of_Omnichannel_Operations_an_Agile_Marketing_Maturity_Model>. Acesso
em 27/11/2016.
14. JOHANSEN, T., ULDAHL, A, 2012, Measuring the Impact of the
Implementation of the Project Management Method Scrum. MSc Thesis.
Copenhagen Business School, Copenhagen, Denmark.
15. JOSLIN R., MÜLLER R., 2015. Relationships between a project management
methodology and project success in different project governance contexts,
International Journal of Project Management, v. 33, n. 6, p. 1377-1392.
16. KAUTZ K., JOHANSON H., ULDAHL A., 2014, The Perceived Impact of the
Agile Development and Project Management Method Scrum on Information
Systems and Software Development Productivity. Australasian Journal of
Information Systems, v. 18, n. 3. Disponível em:
<http://journal.acs.org.au/index.php/ajis/article/view/1095>. Acesso em:
20/11/2016.
17. KERZNER, H., 1999, Strategic planning for project management using a
project management maturity model. New York, John Wiley & Sons.
18. LAPLANTE P., NEILL C., 2004, The Demise of the Waterfall Model Is
Imminent - ACM Queue", v.1, n. 10. Penn State University.
19. MENEZES W., 2009, To CMMI or Not to CMMI: Issues to Think About
CrossTalk. The Journal of Defense Software Engineering. p. 9-11.
20. PATAH, L., CARVALHO M., 2012, Métodos de Gestão de Projetos e Sucesso
dos Projetos: Um Estudo Quantitativo do Relacionamento entre estes
Conceitos. Revista de Gestão e Projetos - GeP, v. 3, n. 2, p. 178-206.
Disponível em:
68
<http://www.revistagep.org/ojs/index.php/gep/article/view/94/292>. Acesso em:
27 nov. 2016.
21. PATEL, C., RAMACHANDRAN, M., 2009. Agile maturity model (AMM): A
Software Process Improvement framework for Agile Software Development
Practices. International Journal of Software Engineering, IJSE, v.2, n.1, p. 3–
28. Disponível em: <http://dx.doi.org/10.5585/10.5585. >. Acesso em: 27 nov.
2016.
22. REIS R., 2012, PMBOK vs Scrum. Disponível em:
<https://www.oficinadanet.com.br/artigo/gerencia/pmbok-x-scrum>. Acesso em
09/11/2016.
23. 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.
24. SCHRAMM, W., 1971, Notes on case studies of instructional media projects.
Working paper, the Academy for Educational Development, Washington, OC.
25. SCHWABER K. E SUTHERLAND J., 2016, The Scrum Guide: The
Definitive Guide To Scrum - The Rules Of The Game. Disponível em: <
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf>. Acesso
em 02/10/2016.
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.
Disponível em: < http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-
us.pdf>. Acesso em 02/10/2016.
CI1
SUTHERLAND J., 2014, Scrum - A arte de fazer o dobro de trabalho na metade do tempo. 1 ed. São Paulo, Basil, LeYa
Brasil. CI1, CI2
WYSOCKI R., 2007, Effective Project Management - Traditional, Adaptive, Extreme. 4 ed.
C14
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
conflitos e avaliações de desempenho,
trabalha com times autogerenciáveis.
Comunicação Iniciação Identificar as
partes interessadas
Não Não mapeia este
item
Comunicação Planejamento Planejar as
comunicações
Sim
As comunicações já estão planejadas
pelo processo (Cerimônias,
artefatos e reuniões), mas não envolvem todos os
stakeholders
Comunicação Execução Distribuir as informações
Sim
Distribui informações
conforme suas cerimônias, não
avalia meio, canal e tecnologia
Comunicação Execução
Gerenciar as expectativas das partes
interessadas
Sim
Gerencia as expectativas apenas
do PO e deixa a este a
responsabilidade de gerenciar
expectativas de outros stakeholders.
Comunicação Monitoramento
& Controle Reportar o
desempenho Sim
Reporta o desempenho de
forma bem transparente, mas apenas para SM e
PO.
Riscos Planejamento Planejar o
gerenciamento dos riscos
Não Não mapeia este
item
93
Disciplina Grupo do Processo
Ação Abordado
no Scrum?
Observação
Riscos Planejamento Identificar os
riscos Sim
Não mapeia riscos, apenas
impedimentos.
Riscos Planejamento
Realizar a análise
qualitativa dos riscos
Não Não mapeia este
item
Riscos Planejamento
Realizar a análise
quantitativa dos riscos
Não Não mapeia este
item
Riscos Planejamento Planejar
respostas aos riscos
Não Não mapeia este
item
Riscos Monitoramento
& Controle
Monitorar e controlar os
riscos Não
Não mapeia este item
Aquisições Planejamento Planejar as aquisições
Não Não mapeia este
item
Aquisições Execução Conduzir as aquisições
Não Não mapeia este
item
Aquisições Monitoramento
& Controle Administrar as aquisições
Não Não mapeia este
item
Aquisições Encerramento Encerrar as aquisições
Não Não mapeia este
item
Tabela 9 - Comparativo PMBOK x Scrum.
Fonte:<http://www.elirodrigues.com/2012/04/02/comparativo-pmbok-x-scrum/>.
Acesso em 09/10/2016.
94
14 Anexo B: Tradução do questionário para avaliação do nível de maturidade
do Scrum em uma organização
Questionário de Alexandre Yin (2011) respondido pela chefe da área para
identificar o nível de maturidade do Scrum.
Papéis do Scrum Existem
Questão 1: Existe um indivíduo definido como Product Owner definido pelo cliente ?
( ) Sim ( x ) Não
Questão 2: Existe um indivíduo com a designação de Scrum Master ?
( ) Sim ( x ) Não
Questão 3: Existe uma equipe designada pra desenvolver o projeto com a metodologia
Scrum ?
( x ) Sim ( ) Não
Questão 4: Existe o artefato backlog do produto?
( x ) Sim ( ) Não
Artefatos do Scrum
Questão 5: Existe o backlog do sprint do produto ?
( x ) Sim ( ) Não
Questão 6: O backlog do sprint do produto é atualizado pela equipe do projeto?
( x ) Sim ( ) Não
Questão 7: O backlog do sprint do produto é atualizado após cliente ser avisado?
( ) Sim ( x ) Não
Questão 8: O backlog do sprint do produto é atualizado após cliente ser avisado?
( ) Sim ( x ) Não
Questão 9: Existe o artefato Quadro Scrum?
( x ) Sim ( ) Não
95
Questão 10: O artefato Quadro Scrum é atualizado de acordo com o andamento do
projeto?
( x ) Sim ( ) Não
Reuniões Scrum
Questão 11: Existe a reunião de planejamento do Sprint?
( x ) Sim ( ) Não
Questão 12: Existe a reunião de Scrum diária?
( ) Sim ( x ) Não
Questão 13: Existe a reunião de revisão do Sprint?
( ) Sim ( x ) Não
Questão 14: Existe a reunião de retrospectiva do Sprint?
( ) Sim ( x ) Não
Usabilidade do Sprint
Questão 15: O Sprint é um conceito seguido no dia a dia?
( x ) Sim ( ) Não
Questão 16: Duração do Sprint é menor ou igual a 4 semanas?
( x ) Sim ( ) Não
Padronização
Questão17: Todos os projetos dos últimos 6 meses respondem positivamente às
perguntas anteriores?
( ) Sim ( x ) Não