---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: https://www.projectbuilder.com.br/blog/scrum-o-que-e-sprint-e-como-executa-lo/ (2210 termos)

Termos comuns: 82
Similaridade: 1,04%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: https://www.investopedia.com/terms/s/swot.asp (1253 termos)

Termos comuns: 4
Similaridade: 0,05%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: https://www.ebah.com.br/content/ABAAAgoiAAC/tcc-nathan-peixoto-oliveira?part=8 (140 termos)

Termos comuns: 0
Similaridade: 0%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: http://periodicos.ufes.br/BJPE (183 termos)

Termos comuns: 8
Similaridade: 0,13%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: https://www.culturaagil.com.br/sprint-o-coracao-scrum/ (1582 termos)

Termos comuns: 38
Similaridade: 0,52%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: http://periodicos.ufes.br/BJPE/article/download/v4n2_x/pdf (1006 termos)

Termos comuns: 65
Similaridade: 0,97%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: https://en.wiktionary.org/wiki/make_use (339 termos)

Termos comuns: 0
Similaridade: 0%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: https://www.youtube.com/channel/UClbJJ9d2ipysov4bEpngbOA (14 termos)

Termos comuns: 0
Similaridade: 0%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S

---

Arquivo de entrada: Um Comparativo entre as Práticas em Gestão de Projetos PMBOK e SCRUM para a Criação de um Aplicativo.docx (5709 termos)
Arquivo encontrado: http://www.ucs.br/etc/conferencias/index.php/anpedsul/9anpedsul/paper/viewFile/1259/13 (5357 termos)

Termos comuns: 31
Similaridade: 0,28%


UM COMPARATIVO ENTRE AS PRÁTICAS EM GESTÃO DE PROJETOS PMBOK E SCRUM PARA A CRIAÇÃO DE UM APLICATIVO
A COMPARISON BETWEEN THE PMBOK AND SCRUM PROJECT MANAGEMENT PRACTICES TO CREATE AN APPLICATION
Autor11; Autor22 & Autor33*

1 2 3Xxxxx. *Xxxx@Xxxx


Brazilian Journal of Production Engineering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Brazilian Journal of Production Engeneering, São Mateus, Vol. X, N.º Y, p. aa-bb. (ano). Editora CEUNES/DETEC.
Disponível em: http://periodicos.ufes.br/BJPE
Esta obra está licenciada com uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Brazilian Journal of Production Engineering, São Mateus, Editora UFES/CEUNES/DETEC.
ARTIGO INFO.
Recebido em:
Aprovado em:
Disponibilizado em:
Palavras-chave:
Gestão Ágil; Gestão de Projetos; PMBOK®; Produto; SCRUM.
Keywords:
Agile Management; Project Management; PMBOK®; Product; SCRUM.

*Autor Correspondente: Xxxx

RESUMO
O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações do tempo utilizado no passado e adjunto, há uma vasta quantidade de padrões de gestão muitas vezes mal interpretados, acabando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de comparar e compilar o que há de melhor nas mais bem-conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Para tal, foi aplicado um estudo de caso utilizando bases renomadas, como PMBOK® e a gestão ágil representada pela metodologia SCRUM, para a criação de um aplicativo de venda e negociação de lubrificantes. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira, esta se sobressai com relação aos seus grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equiparam em gestão de custos, de recursos humanos, de risco, de aquisição e conclusão. Através da não sobreposição e imparcialidade dos resultados, o artigo justificou a importância de um uso combinado das práticas para um modelo otimizado de gestão.

ABSTRACT
The competitive globalized system demands an increasing efficiency of models and management tools. Projects should be run as fractions of the time used in the past and adjunct, there are a vast amount of management standards often misinterpreted, leading to a burden of time, costs and labor. This work, therefore, aim to compare and compile the best in the most well-known practices in project management, in order to: unify, untangle and make a more efficient diligence. For this, a case study was applied using renowned bases, such as PMBOK® and the agile management represented by the SCRUM methodology for the creation of a lubricants sale and negotiation application. As a result, when comparing them to eleven subjects, it was verified that, making use of the first, it stands out in relation to its groups of processes and time management. The second, in management of integration, scope, quality and communication. Finally, both are equipped in cost management, human resources, risk, acquisition and completion. Through the non-overlapping and impartiality of the results, the article justified the importance of a combined use of the practices for an optimized management model.






8

6
- 2 -
Citação (APA): SECCHIM, A. B., FREITAS, R. R. de, & GONCALVES, W. (2018). Mapeamento e análise bibliométrica da utilização da análise envoltória de dados (DEA) em estudos de engenharia de produção. Brazilian Journal of Production Engineering, 4(1): 116-128.


1. Introdução
Com ciclos de vida cada vez mais curtos, a engenharia, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentas e modelos sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos.
Pode-se notar a existência de práticas mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível verificação.
Para compor o primeiro caso, o PMI® apresenta um guia conhecido mundialmente: o PMBOK®. Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto (PMI®, 2004).
No segundo caso, com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al., 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. O modelo prioriza tomar decisões rápidas reduzindo drasticamente a quantidade de material produzido. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004). Todavia, essa diminuição de registros a fim de obter velocidade, pode dificultar processos comprobatórios ou de auditoria.
O intuito deste trabalho consiste em comparar duas referências em gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar.
Através de um estudo de caso, pretende-se atestar que, ao ter um maior conhecimento sobre as práticas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra.
Este material pretende responder as seguintes questões:
Como é feita uma gestão pelo PMBOK® e pelo SCRUM e quais são suas diferenças?
Quais as vantagens e desvantagens em ambos os padrões?
Como deveria ser feita uma gestão otimizada e quais são seus benefícios?
2. Gerenciamento de Projetos
O gerenciamento de projetos é definido e dividido no PMBOK® da seguinte forma:
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8).

Já Braga (2003), trata o gerenciar projetos como diligenciar os seguintes temas:
Qualidade, custo, escopo e tempo;
Expectativas e exigências dos stakeholders (partes interessadas) e
Atender aos requisitos identificados ou não.
Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto.
Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e complexas, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente.
2.1 Gestão Eficiente de Projetos
Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo e as facilidades da gestão eficiente de projetos são:
a) Gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contingenciais mitigantes. Correções são feitas a tempo e fracassos são severamente reduzidos;
b) Integridade da equipe e boa fluência de informações, ideias, documentos etc.;
c) O risco é controlado e a qualidade é assegurada e
d) O projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido.
O Standish Group realizou uma pesquisa de 1994 a 2010, onde nesse período, se pôde constatar (figura 1) uma melhora no nível de sucesso e uma redução de fracasso ou falha em projetos.

FIGURA 1 – Grau de acerto em projetos. Fonte: The Standish Group (2011)
Sotille (2014) diz que o êxito do projeto depende de agir conforme planejado. Mesmo a utilização de recursos aquém do previsto, que pode soar como economia, significa que insumos foram superavaliados, logo, houve falha no planejamento. Assim, o bom conhecimento de gestão é cada vez mais apreciado, assim como seus certificados. A figura 2 mostra a evolução de profissionais com certificação PMP® desde 2008 até o ano de 2018.

FIGURA 2 – Nº de profissionais ligados ao PMBOK®. Fonte: PMI® (2019)

PMP® – Project Management Professional – é a certificação de qualificação segundo o PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. Uma das grandes vantagens do gerenciamento de projetos diz respeito a sua complexidade. Vargas (2007) relata a indiferença com relação ao tamanho do projeto. O formato é prevalecido e pode ser aplicado em empreendimentos de ampla diversidade.
2.2 PMBOK®
O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute® e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O mesmo deve ser empregado como um acompanhador, logo, não deve ser interpretado como um roteiro de mão única, mas sim adequado a diferentes tipos de projetos.
O PMBOK® (2004) delimitas seus processos em grupos principais: iniciação, planejamento, execução, monitoramento e controle e encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH – recursos humanos, comunicação, risco e aquisição. Na figura 3, esses grupos e áreas são vistos abreviadamente. Deve-se salientar que a forma de fluxograma não traduz necessariamente a obrigação de seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como a simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos.


FIGURA 3 – Mapeamento do fluxo de projeto. Fonte: Autor.
O guia do PMBOK® (2004), assim descreve os processos e seus grupos:
a) Grupo de iniciação: são descritas as etapas e permite-se a execução do projeto;
b) Grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis;
c) Grupo de execução: gerenciam-se insumos e pessoas para a realização do projeto;
d) Grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e
e) Grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado.
2.3 SCRUM
O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o modelo se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos.
O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos, tendo como característica a seguinte nomenclatura (SCHWABER, 2004):
Product backlog: conjunto de atividades a serem desempenhadas no projeto;
Sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final;
Sprint planning meeting: reunião na qual é feito o planejamento da sprint;
Sprint review meeting: reunião onde é feito a revisão do realizado na sprint;
Sprint retrospective: reunião de inspeção própria e de proposta de melhorias;
Sprint backlog: conjunto de tarefas da sprint para criar um resultado;
Daily SCRUM: reunião diária;
Development team: time que gera incremento por sprint no produto final;
SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe;
Product owner: dono do produto (ou serviço) e
SCRUM team: reunião do development team, SCRUM master e product owner.
Na Figura 4, mostra-se o ciclo de vida do SCRUM.

FIGURA 4 – Etapas da gestão ágil - SCRUM. Fonte: Autor.
Na sprint planning meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007).
Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente.
No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007).
A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PEREIRA et al., 2007).
3. Estudo de Caso
Segundo Bressan (2000) e Yin (1994), o estudo de caso é um processo investigativo empírico a respeito de um assunto contemporâneo em uma conjuntura real, onde é possível se fazer observações diretas. Com este intuito, fora analisada a gestão de um projeto para a criação de um aplicativo para a venda de lubrificantes, aplicando-se duas práticas: PMBOK® e SCRUM. A concepção do mesmo não foi pauta deste artigo, sendo então terceirizado.
A criação do aplicativo tem o intuito de ser uma ferramenta para a venda indireta (distribuidores) de uma destacada empresa de óleo e gás para que possam ter a informação na palma da mão, facilitar a negociação e a venda de lubrificantes, melhorar seus processos e reduzir as desistências de compra motivadas pela demora na efetivação da venda.
3. 1 Quanto aos grupos de processos
Conforme figura 5, em cada grupo de processos foram identificados tarefas e artefatos gerados:








FIGURA 5 – Grupos de Processos do estudo de caso. Fonte: Autor.
1. Iniciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da delimitação das partes interessadas.
2. Planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, modelo das atas de reunião e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT.
3. Execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas.
4. Monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal.
5. Encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo.
Já seguindo na metodologia SCRUM, os seguintes grupos foram criados:
1. Planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopo referente a um mês de trabalho cada;
2. Execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog.
3. Monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um “feito” ou “não feito” para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes era acompanhada pelo burndown chart. Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint review e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso.
4. Entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto.
3.2 Quanto à integração
Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Como forma de auxiliá-lo, foi criado um documento mais detalhado chamado “identidade do projeto”, onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe.
O plano de gerenciamento do projeto, conforme figura 6, envolveu uma ferramenta em excel® que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos: as propostas que culminaram na escolha do projeto, a identidade do projeto (conforme mencionado), o cronograma do projeto, as apresentações do projetos para stakeholders como forma de comunicação e report, o escopo do projeto, orçamento, processos mapeados, pesquisas, análise de risco (S.W.O.T.) e as minutas das reuniões.

FIGURA 6 – Plano de Gerenciamento do Projeto. Fonte: Autor.
O encerramento do projeto se deu por meio de uma apresentação em videoconferência com todos os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo.
Já no SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadas as tarefas realizadas e as perspectivas para a próxima semana. As duas seguintes foram geridas principalmente pelo documento de product & sprint backlog (anexo A) e pelo burndown chart (figura 7).

FIGURA 7 – Gráfico Burndown. Fonte: Autor.
Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x), onde cada mês correspondia a uma sprint. A linha em vermelho mede o desempenho planejado do projeto, enquanto a azul, o real. A existência de um lapso de atividades entre outubro e fevereiro foi previamente definida pela empresa de estudo. A conclusão do projeto, assim como na primeira prática, foi realizada por meio de uma videoconferência com todos os participantes, apresentando-se o product & sprint backlog, burndown chart.
3.3 Quanto ao escopo
Seguindo a referência que consta no PMBOK® (2004), o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos, um conjunto de tarefas que, de forma macro, iria compor a EAP – Estrutura Analítica de Projeto – conforme figura 8.

FIGURA 8 – Estrutura analítica de projeto. Fonte: Autor.
A verificação das entregas e a justificativa pela não entrega foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning, baseando-se no máximo de atividades por sprint (em um mês). Em seguida, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective.
3.4 Quanto ao tempo
A gestão do tempo segundo a visão tradicional se deu por um cronograma, conforme anexo B. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. Na gestão ágil, a gestão temporal foi feita através do burndown chart (figura 7), onde o andamento do projeto era visto de forma rápida e linear.
3.5 Quanto ao custo
Após estudo de mercado sobre o custo para o desenvolvimento de um aplicativo de baixa complexidade, decidiu-se por realiza-lo através de uma empresa parceira que, ao analisar o escopo apresentado, julgou ser um projeto de baixo custo, aquém do orçado no mercado. Assim, o projeto foi alocado internamente no centro de custo da área de gestão da informação.
3.6 Quanto à qualidade
Durante o planejamento da qualidade e, segundo a prática considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia de qualidade foi realizada através de pesquisas realizadas com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo diligenciamento do escopo e cronograma.
Segundo a metodologia ágil, a qualidade foi definida pelo cumprimento do product backlog no tempo previsto, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint review e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento do nível de execução do escopo.
3.7 Quanto ao rh
Independente do guia adotado, segundo a empresa, os projetos possuem um corpo de funcionários previamente definido, assim como o ponto focal de RH. A contratação de equipe não foi necessária, pela utilização dos próprios empregados da contratante e da contratada que, por sua vez, já desempenha de forma ordinária projetos por meio de contratos de prestação de serviços. Não houve também necessidade de desenvolvimento da equipe, já que os participantes possuíam os requisitos necessários para o projeto.
3.8 Quanto à comunicação
A comunicação com os stakeholders, para ambos os modelos, se deu através de reuniões presenciais de acompanhamento. A única exceção se tratava dos distribuidores que são alocados em diversas regiões representando os diversos estados brasileiros, feita então por videoconferência. Com relação a formalização das partes interessadas, o guia PMBOK® exige documentação (conforme figura 9) e o SCRUM não a necessita, valendo o acordo verbal a fim de comprovação.
FIGURA 9 – Partes interessadas do estudo de caso. Fonte: Autor.
As partes interessadas, seguindo o guia PMBOK®, foram ordenadas pela proximidade com a área gestora do projeto, conforme quadro 1. Desta forma, serão:
QUADRO 1 – Partes interessadas segundo o PMBOK®
Fonte: Autor.
Já no caso do SCRUM as partes interessadas são resumidas em três:
1. Development team: é a equipe do projeto, aqui caracterizada na área de pricing, excelência operacional, a contratada, os assessores de venda e os consultores do projeto;
2. SCRUM master: o facilitador do projeto, funcionário alocado na área de pricing;
3. Product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor.
Vale ressaltar que a fábrica de lubrificantes, que terá como impacto o incremento no volume de produzido, não faz parte do SCRUM team, pois não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável.
3.9 Quanto ao risco
Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 10, com o auxílio da análise SWOT – Strengths, Weaknesses, Opportunities and Threats. Esta por sua vez contempla fatores internos (forças e fraquezas) e externos (oportunidades e ameaças).













FIGURA 10 – Análise de risco do estudo de caso. Fonte: Autor.
Foram ditos como forças, a melhoria no processo de venda e do respectivo faturamento, fruta da eficiência dos seus processos e redução da desistência de compra. Como oportunidade, foi considerada a autonomia dada aos vendedores, já que poderiam simular no aplicativo, propostas de preços e um aumento na margem de vendas. A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos aliada a dependência da empresa terceirizada. Como ameaça, existe a dificuldade de aderência de alguns distribuidores à inovação e uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos com a contratante.
Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes é inexistente, pois o ganho em venda com o aplicativo foi contemplado na capacidade produtiva.
Os processos de risco, segundo a modelo do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas reuniões, já que a comunicação gera comprovação.
3.10 Quanto à aquisição
Independente da prática adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações. Além disso, o projeto foi considerado de baixo custo e seu orçamento junto a empresa contratada ficou posicionada muito abaixo da cotação do mercado.
3.11 Quanto à conclusão
Tanto no guia PMBOK® quanto no SCRUM, o projeto foi dado como concluído após reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das etapas do projeto.
4. Resultados
O gerente de projeto, SCRUM master e o autor são a mesma pessoa que, buscando mensurar o desempenho das práticas em onze assuntos relevantes em projetos, através de observação do estudo de caso e de apontamentos construiu um quadro comparativo que será visto mais a frente.
4.1 Quanto aos grupos de processos
No SCRUM, as reuniões de sprint planning alocam atividades do product backlog para o sprint backlog. Além disso, como é visto na figura 11, a sprint planning está disposta em linha com as iterações da sprint e qualquer replanejamento acordável entre as partes interessadas foi feito apenas no término da sprint (após um mês). Já de acordo com o guia PMBOK®, o grupo de processos de planejamento se permearam ao longo do projeto (conforme figura 12), tendo, portanto, o melhor desempenho.

FIGURA 11 – Reuniões do SCRUM. Fonte: Autor.

FIGURA 12 – Interação de grupos de processos em um projeto. Fonte: PMBOK®, 2004, p. 68.
4.2 Quanto à integração
Embora existam estreitas relações entre ambos (conforme quadro 2 e figura 13), a gestão segundo o PMI® é feita lentamente, com processos de certa forma repetitivos. Enquanto na segunda, esses eram realizados de modo dinâmico em reuniões de curta duração.
QUADRO 2 –Processos de integração – Estudo de caso
Fonte: Autor.

FIGURA 13 – Diagrama dos processos de integração. Fonte: Autor.
A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o seu tempo de elaboração. Como parâmetro, o formulário do projeto e sua descrição levaram cerca de 2 horas para serem planejados e produzidos.
No modelo tradicional é fundamental a criação do escopo preliminar (cerca de uma hora gasta), já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado, portanto, esse espaço de tempo.
Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito.
4.3 Quanto ao escopo
Embora ambas apresentam similaridade (conforme quadro 3 e figura 14), no guia PMBOK® o escopo segue conforme planejamento e premissas do projeto, já no SCRUM é conforme conversado, e o cliente (product owner) é parte integrante deste diálogo. Este acompanha o projeto, seus resultados por cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento.
No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adicionais etc. Sendo assim, esse modelo não foi preferido.
QUADRO 3 –Processos de escopo – Estudo de caso.
Fonte: Autor.

FIGURA 14 – Diagrama dos processos de escopo – Estudo de caso. Fonte: Autor.
4.4 Quanto ao tempo
Na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde à periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato do quadro product & sprint backlog (anexo A), estando aquém ao cronograma da opositora.
Este garante não só o detalhamento cronológico semanal, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme é visto de forma abreviada na figura 15 e completo no anexo B. Tais características não foram possíveis de serem encontradas no burndown chart, desta forma, esse método foi preterido por ser menos assertivo neste assunto.


Figura 15: Cronograma abreviado – Estudo de Caso. Fonte: Autor

4.5 Quanto ao custo
Em ambos os métodos foi possível encontrar processos de estimativa, orçamento e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma delas. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação, logo, ambas são equiparáveis.
4.6 Quanto à qualidade
Para o PMBOK®, a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confeccionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo).
Já para o SCRUM, bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. E pela simplicidade e facilidade de gestão, optou-se pelo segundo.
4.7 Quanto ao RH
A etapa de contratação e treinamento não sofreu diferença entre as práticas, todavia, em projetos há uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa à percepção de bom desempenho para este quesito, pois reflete o objetivo buscado (conforme planejado ou especificado pelo cliente), ambas foram consideradas válidas para esse quesito.
4.8 Quanto à comunicação
A gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos suscetíveis a discussões pela sua objetividade. Houve um número reduzido de documentos e complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos.
Já no padrão do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião e relatórios de acompanhamento semanais (cerca de 30 minutos para cada). Além do tempo de confecção, existem ainda o de leitura e resposta em comparação a comunicação verbal e dinâmica das weekly SCRUM, sendo decisivo para o primeiro não ser adotado nesta temática.
4.9 Quanto ao risco
Para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foram percebidas semelhanças conforme é possível observar no quadro 4 e figura 10.
QUADRO 4 –Processos de risco – Estudo de caso.
Fonte: Autor.

Figura 15: Diagrama dos Processos de Risco – Estudo de Caso. Fonte: Autor.
No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias, logo, ambas equivalem-se.
4.10 Quanto à aquisição
Embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a representante mais tradicional.
4.11 Quanto à conclusão
Em ambas os modelos, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo, portanto, de igual valia.
5. Conclusão
O presente trabalho buscou comparar práticas de gerenciamento de projetos, em especial, duas de grande importância, para que se pudesse obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, sua gestão, equipe, stakeholders, cliente e suas possíveis facilidades. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens.
Foi possível, através de um estudo de caso, observar que nenhuma se sobressaiu preponderantemente sobre a outra, conforme quadro 5. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta.
QUADRO 5 – Comparativo entre as práticas.
Fonte: Autor.

Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processos e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: integração, escopo, qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambos em: custo, RH, risco, aquisição e conclusão, somando cinco abordagens.
Portanto, uma forma otimizada de gestão deve considerar os méritos e deméritos de ambas, para que em um determinado projeto, seja possível alcançar uma melhor performance ao longo dos onze temas levantados, justificando assim a relevância do estudo.
Referências
BRAGA, A. R. (2003). Gerência de Projetos: Preparação para a Certificação PMP. Disponível em: <http://www.ebah.com.br/content/ABAAAAXXQAH/gerencia-projetos>. Acesso em: 09 set. 2014.
BRESSAN, F. (2000). O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP.
MARÇAL, A. S. et al. (2007). Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI.
MARTINS, L. V. (2003). Gestão Profissional de Projetos. Disponível em: < http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/83 >. Acesso em: 12 abr. 2019.
NARDI, K. (2009). PMBOK x SCRUM: Como Gerenciar um Projeto de Software?
PMI® - Project Management Institute ®. (2004). Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. GuiaPMBOK. 3.ed.
PMI® - Project Management Institute®. (2019). PMI® Today – Compilação de dados feito pelo autor. 2019. Disponível em: < http://www.pmitoday-digital.com>. Acesso em: 9 abr. 2019.
PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. (2007). Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 05 abr. 2019.
SCHWABER, K. (2004). Agile Project Management with SCRUM. Washington: Microsoft Press/
THE STANDISH GROUP. (2011). The Chaos Report. Disponível em: < https://www.standishgroup.com>. Acesso em: 05 abr. 2019.
VARGAS, R. (2007). Manual prático do plano do projeto. 3.ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em:<http://issuu.com/ricardo.vargas/docs/manualprat>. Acesso em 07 abr. 2019.
VARGAS, R. (2009). Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport.
YIN, R. (1994). Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications.

ANEXO A – Product & Sprint Backlog

ANEXO B – CRONOGRAMA


1 Definição do Projeto
2 Identidade do Projeto, Escopo, Cronograma e Kickoff
3 Processo atual e Ideal, Orçamento e Apresentação para os Distribuidores
4 Pesquisas (vendedores, assessores e interna) e Acompanhamento do Projeto
5 Entrega do Aplicativo e Apresentação de Encerramento

1. Pricing Área responsável pelo projeto;
2. Excelência operacional Área responsável pela gestão da informação, cujo centro de custo cobrirá os custos do projeto;
3. Contratada Empresa terceira responsável pelo desenvolvimento do aplicativo
4. Distribuidores: Empresas responsáveis pela venda indireta de lubrificantes via vendedores, que serão os usuários finais do aplicativo
5. Assessores de venda: Responsáveis na empresa contratante pela venda aos distribuidores
6. Consultores do projeto: Especialistas internos a empresa com vasta experiência
7. Fábrica: Já que a agilidade no processo de venda resultará em incremento de venda, a fábrica de lubrificantes deve estar a par do projeto.

Processos de Integração
  PMBOK®   SCRUM
I) Termo de abertura formalizado
Justificativa do projeto e
Necessidade dos stakeholders
II) Declaração de escopo preliminar
III) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares)
IV) Execução do plano de gerenciamento
V) Monitoramento e controle do plano de gerenciamento
VI) Controle de mudanças
VII) Encerramento projeto I) Sprint Planning
Abertura do projeto
Criação do escopo e
Criação do plano de gerenciamento
II) Weekly SCRUM
Garantia da execução
Monitoramento do plano
III) Sprint Review: monitoramento do plano
IV) Sprint Retrospective
Monitoramento e controle do plano
Controlar mudanças
Encerrar projeto

Processos de Escopo
  PMBOK®   SCRUM
1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo
Definição do escopo
II) Weekly SCRUM
III) Sprint Review Verificação do escopo
IV) Sprint Retrospective Controle do escopo

Cronograma do Projeto Setembro 2017 Outubro 2017 Fevereiro 2018
Escopo Semana 4 Semana 5 Semana 1 Semana 2 Semana 1
Iniciação
1. Criar propostas do projeto        
2. Entregar propostas do projeto        
3. Criar descrição do projeto        
4. Criar formulário do projeto        

Processos de Risco
  PMBOK®   SCRUM
1) Planejamento do gerenciamento de riscos
2) Identificação de riscos
3) Análise qualitativa de riscos
4) Análise quantitativa de riscos
5) Planejamento de respostas a riscos
6) Monitoramento e controle de riscos I) Sprint Planning
Planejamento do gerenciamento de riscos
Planejamento de respostas a riscos
Identificação de riscos
Análise quantitativa e qualitativa de riscos
II) Weekly SCRUM
Monitoramento de riscos
III) Sprint Review
Monitoramento de riscos
IV) Sprint Retrospective
Monitoramento e controle de riscos

Quanto Práticas Melhor desempenho
à(ao) PMBOK® SCRUM
Grupos de processos Fases simultâneas Fases em linha PMBOK®
Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM
Escopo Ausência do cliente Participação do cliente SCRUM
Tempo Cronograma Product & sprint backlog e burndown chart PMBOK®
Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos
Qualidade Parametrização complexa Parametrização simples SCRUM
RH Voltada aos processos Voltado ao produto Ambos
Comunicação Lenta Dinâmica SCRUM
Risco Documentado Comunicado Ambos
Aquisição Documentada Comunicada Ambos
Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos

ID Nome Feita? (S/N) Importância - Sprint (1-12) Importância - Backlog (1-39)
  Sprint 1 – Setembro 2017      
1 Criar propostas do projeto S 12 39
  Sprint 2 – Outubro 2017      
2 Criar propostas do projeto S 12 38
3 Apresentar propostas de projeto S 11 37
  Sprint 3 – Fevereiro 2018      
4 Criar descrição do projeto S 12 36
5 Criar formulário do projeto S 11 35
6 Definições do Projeto: Reunião 1 S 10 34
7 Criar documento de identidade do projeto S 9 33
8 Criar crongrama do projeto S 8 32
9 Criar análise S.W.O.T. do projeto S 7 31
10 Criar escopo do projeto S 6 30
  Sprint 4 – Março 2018      
11 Criar crongrama do projeto S 12 29
12 Criar apresentação de kickoff S 11 28
13 Criar escopo do projeto S 10 27
14 Reunião 1 com fornecedor do aplicativo S 9 26
15 Definições do Projeto: Reunião 2 S 8 25
  Sprint 5 – Abril 2018      
16 Mapear o processo atual de venda S 12 24
17 Mapear o procedimento atual de venda S 11 23
  Sprint 6 – Maio 2018      
18 Criar pesquisa para vendedores S 12 22
19 Criar pesquisa para assessores de venda S 11 21
20 Criar pesquisa interna S 10 20
21 Criar pesquisa de feedback S 9 19
  Sprint 7 – Junho 2018      
22 Entregar pesquisas S 12 18
23 Coletar pesquisas S 11 17
24 Propor melhorias baseado nas pesquisas S 10 16
  Sprint 8 – Julho 2018      
25 Propor melhorias baseado nas pesquisas S 12 15
26 Mapear o processo ideal de venda S 11 14
27 Mapear o procedimento ideal de venda S 10 13
  Sprint 8 – Agosto 2018      
28 Reunião 2 com fornecedor do aplicativo S 12 12
29 Avaliar orçamento do fornecedor do Aplicativo S 11 11
30 Fechar orçamento do projeto S 10 10
31 Brainstorming com distribuidores S 9 9
32 Formalizar sugestões dos distribuidores S 8 8
33 Acompanhar criação e entrega do aplicativo S 7 7
34 Criar processo final de venda S 6 6
35 Criar procedimento final de venda S 5 5
36 Criar apresentação de encerramento S 4 4
37 Apresentar encerramento do projeto S 3 3
38 Criar apresentação para o sponsor S 2 2
39 Apresentação ao sponsor S