Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Universidade Federal do Rio de Janeiro
Escola Politécnica
MBA em Engenharia de Computação e Sistemas
(MBCA)
METODOLOGIA HÍBRIDA: ANÁLISE DE
GERENCIAMENTO DE PROJETOS UTILIZANDO OS
MÉTODOS WATERFALL E SCRUM
Autor:
_________________________________________________
Luciano Passos
Orientador:
_________________________________________________
Manoel Villas Bôas Júnior, M.Sc.
Coorientador:
_________________________________________________
Prof Edilberto Strauss, Ph.D.
Examinador:
_________________________________________________
Flávio Luis de Mello, D.Sc.
Examinador:
_________________________________________________
José Airton Chaves Cavalcante Junior, D.Sc.
Examinador:
_________________________________________________
Maximiano Correia Martins, D.Sc.
MBCA
Janeiro de 2019
Declaração de Autoria e de Direitos
Eu, Luciano Passos CPF 137.601.937-06, autor da monografia ESTUDO D
IMPLEMENTAÇÃO DE METODOLOGIA HÍBRIDA DE GERENCIAMENTO DE
PROJETOS UTILIZANDO MÉTODOS WATERFALL E SCRUM, subscrevo para os devidos fins, as seguintes informações:
1. O autor declara que o trabalho apresentado na defesa da monografia do curso de Pós-Graduação da Escola Politécnica da UFRJ é de sua autoria, sendo original em forma e conteúdo.
2. Excetuam-se do item 1 eventuais transcrições de texto, figuras, tabelas, conceitos e idéias, que identifiquem claramente a fonte original, explicitando as autorizações obtidas dos respectivos proprietários, quando necessárias.
3. O autor permite que a UFRJ, por um prazo indeterminado, efetue em qualquer mídia de divulgação, a publicação do trabalho acadêmico em sua totalidade, ou em parte. Essa autorização não envolve ônus de qualquer natureza à UFRJ, ou aos seus representantes.
4. O autor declara, ainda, ter a capacidade jurídica para a prática do presente ato, assim como ter conhecimento do teor da presente Declaração, estando ciente das sanções e punições legais, no que tange a cópia parcial, ou total, de obra intelectual, o que se configura como violação do direito autoral previsto no Código Penal Brasileiro no art.184 e art.299, bem como na Lei 9.610.
5. O autor é o único responsável pelo conteúdo apresentado nos trabalhos acadêmicos publicados, não cabendo à UFRJ, aos seus representantes, ou ao(s) orientador(es), qualquer responsabilização/ indenização nesse sentido.
6. Por ser verdade, firmo a presente declaração.
_________________________________________
Luciano Passos
ii
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de
Computação Centro de Tecnologia, bloco H, sala H-217, Cidade
Universitária Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas
deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha
a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
iii
Dedico este trabalho a todos que contribuíram
direta ou indiretamente.
iv
AGRADECIMENTO
Agradeço ao povo brasileiro que contribuiu de forma significativa à minha
formação e estada nesta Universidade. Este projeto é uma pequena forma de retribuir o
investimento e confiança em mim depositados. Ao mestre e orientador Manoel Villas
Bôas Júnior pelo apoio e dedicação ao desenvolvimento deste trabalho. À minha amiga e
companheira, Gabrielle Cunha, que sempre me apoiou em todas as escolhas que eu fiz.
v
RESUMO
As formas híbridas de gerenciamento visam principalmente atender as
particularidades de um determinado projeto e ambiente de negócio à cada organização. Um
dos principais objetivos do presente trabalho é avaliar a implementação de uma metodologia
híbrida de gerenciamento de projetos de Tecnologia da Informação e verificar os ganhos
obtidos se comparados com um modelo mais tradicional de gestão em um determinado
período de tempo. Foram apresentados conceitos abrangentes para embasar todo referencial
teórico do método de gerencialmento tradicional, Waterfall e o método híbrido, utilizando
Scrum na fase de implementação. Após a contextualização teórica do tema, foi executado um
estudo para definição, de forma quantitativa, das diferenças observadas entre as duas formas
de gerenciamento de projeto.
Palavras-Chave: Tecnologia da Informação, Métodos Ágeis, Metodologia Tradicional,
Gerenciamento de Projetos, Gerenciamento híbrido.
vi
ABSTRACT
The Hybrid forms of management aims primarily to address the particularities of a project
and business environment from each organization. One of the main objectives of the present
work is to evaluate the implementation of a hybrid methodology for Information Technology
projects and to verify the gains obtained when compared to a more traditional management
model in a certain period of time. Comprehensive concepts were presented to support all
theoretical references of the traditional management method, Waterfall and the hybrid
method, using Scrum in the implementation phase. After the theoretical contextualization of
the theme, a study was carried out to quantitatively define the differences observed between
the two forms of project management.
Keywords: Information Technology, agile methods, traditional methodology, Project
Management, Hybrid Management.
xii
SIGLAS
EAP – Estrutura analítica de Projeto
UFRJ – Universidade Federal do Rio de Janeiro
TI – Tecnologia da Informação
GP – Gestão de Projetos
PMBOK – Project Management Body of Knowledge
viii
Sumário
Capítulo 1 14
Capítulo 2 14
2.1 – Projeto 16
2.2 – Gestão de Projetos 17
2.3 – Método Waterfall 19
2.4 – Método SCRUM 20
Capítulo 3 22
Metodologia Híbrida 23
3.1 Waterfall associado ao Scrum 23
Tabela 1: Fases 23
3.2 Definição da métrica de desempenho 23
Capítulo 4 24
Resultados Obtidos 26
4.1 – Análise dos dados de projetos no método tradicional 26
Tabela 2: Dados Projeto A 26
Tabela 3: Dados Projeto B 27
4.2 – Análise de dados de projetos no método híbrido 29
4.3 – Cálculo dos indicadores 32
4.4 – Análise do resultado 34
Capítulo 5 38
Conclusão 38
Bibliografia 39
ix
Lista de Figuras
1 – EAP 17
2 – Ciclo de vida Gestão Projeto 18
3 – Processos / Área de conhecimento Gestão Projeto 19
4 – Ciclo de vida Projeto 20
5 – SCRUM 22
x
Lista de Tabelas
Tabela 1 – Fases 23
Tabela 2 – Dados Projeto A 25
Tabela 3 – Dados Projeto B 25
Tabela 4 – Dados Projeto C 26
Tabela 5 – Dados Projeto D 26
Tabela 6 – Dados Projeto E 27
Tabela 7 – Síntese de dados projetos A, B, C, D e E 27
Tabela 8 – Dados Projeto X 28
Tabela 9 – Dados Projeto Y 28
Tabela 10 – Dados Projetos Z 28
Tabela 11 – Síntese de dados projetos X, Y e Z 29
Tabela 12 – Valores de Velocidade 29
Tabela 13 – Valores de Capacidade de Trabalho 30
Tabela 14 – Valores de Fator de Foco 30
Tabela 15 – Valores de Precisão da estimativa 30
xii
Lista de gráficos
Gráfico 1 – Metodologia de desenvolvimento de software 21
Gráfico 2 – Indicador de Velocidade 31
Gráfico 3 – Indicador de Capacidade de Trabalho 31
Gráfico 4 – Indicador de Fator de Foco 32
Gráfico 5 – Indicador de Precisão da Estimativa 33
xiii
14
Capítulo 1
Introdução
Com o crescimento exponencial dos adventos tecnológicos e complexidade dos projetos ao
redor do mundo, cada vez mais processos, metodologias e frameworks de gerenciamento são
desenvolvidos para que sirvam de subsídio para exercer uma gestão eficiente, o que resulta em certa
dificuldade de escolha da metodologia mais apropriada para se obter melhores resultados em projetos,
seja qual for sua natureza. O conceito de metodologia híbrida surgiu como solução para atender
naturezas específicas de projetos que demandam um estilo de gestão tradicional associado a um
modelo ágil. Nos setores gerais da economia, associado ao contexto de corporações que baseiam suas
atividades em produtos e serviços de Tecnologia da Informação, assim como outros setores
comerciais [1], identifica que uma abordagem tradicional de gerenciamento de projetos apresenta
algumas limitações, fazendo com que novas metodologias se complementem.
Muitas empresas não conseguem adotar metodologia estritamente ágil ou unicamente
tradicional para toda sua área de desenvolvimento, TI ou qualquer outra área de negócios, este fato
ocorre devido a crescente demanda de projetos críticos para o pleno funcionamento das atividades
corporativas que não possuem métodos de gestão que compactuam com sua realidade.
O presente estudo visa descrever uma aplicação conceitual da junção dos métodos Waterfall
(em cascata) e SCRUM, para prover maior flexibilidade em projetos que demandam um cenário
criterioso em sua fase de planejamento – por isso se justifica o uso da metodologia em castata -
associada a agilidade da metodologia SCRUM de entregas interativas na fase de implementação.
Desta forma, foi demonstrado que é possível mesclar metodologias tradicionais com
metodologias ágeis de gerenciamento de projetos, tendo como aplicação conceitual os métodos
Waterfall e SCRUM, de forma que exemplifique de maneira quantitativa os possíveis ganhos na
clareza de requisitos, escopo, tempo ou custo em um determinado projeto.
A metodologia utilizada se baseia em pesquisa bibliográfica e estudo de campo qualitativo, de
caráter conceitual e exploratório que visa identificar as principais dificuldades de Gestão de Projetos
15
que fazem uso de metodologias estritamente tradicionais ou ágeis, posteriormente analisando
viabilidade de implementação da metodologia híbrida.
Este trabalho está estruturado da seguinte forma:
O capítulo 2 visa apresentar toda a contextualização teórica do tema abordado, onde
são aprofundadas as informações dos assuntos de maior relevância da pesquisa em questão.
O capítulo 3 aborda a proposta de metodologia para que os pontos cegos levantados
nos capítulos anteriores venham a ser estudados.
O capítulo 4 apresenta os resultados obtidos durante a pesquisa do trabalho.
O capítulo final explicita a conclusão do trabalho e dos possíveis pontos a serem
explorados em trabalhos futuros.
16
Capítulo 2
Embasamento Teórico
2.1 – Projeto
Segundo o PMBOK: “Um projeto é um esforço temporário empreendido para criar um
produto, serviço ou resultado exclusivo. Os projetos e as operações diferem, principalmente, no fato
de que os projetos são temporários e exclusivos, enquanto as operações são contínuas e repetitivas.”
Tendo em vista a unicidade da natureza de projetos, a identificação de atividades de rotinas,
tanto mapeadas quanto inéditas para uma organização, forma um critério fundamental para as chances
de sucesso de um projeto. É necessário então a criação de uma EAP (Estrutura Analítica de Projeto),
mostrado na figura 1, que se trata de um diagrama que possui classes hierárquicas, formado por
pacotes de trabalho que fazem parte de um projeto [6].
Figura 1 – Estrutura EAP
Desenvolvido pelo autor
17
Embora um projeto possua sua devida particularidade, todos possuem em algum nível
operacional elementos que se repetem, onde podem se encontrar em entregas e(ou) atividades. Essa
repetição não muda necessariamente as características do trabalho a ser realizado no projeto. Em
virtude da natureza exclusiva de alguns projetos, riscos, incertezas ou diferenças de produtos e
serviços podem ser identificados nos resultados de um projeto [6].
2.2 – Gestão de Projetos
Sob a ótica do PMBOK, um projeto terá maior chances de sucesso ao seguir as boas práticas que
ajudam na elaboração de uma estrutura sólida. Em uma visão macroscópica, pode ser observada uma
estrutura segmentada, com diversas fases evolutivas de desenvolvimento que constituem um ciclo de
vida desde sua iniciação até o encerramento. Durante este ciclo, mostrado na figura 2, é recomendável
que seja realizada uma categorização de processos, agrupadas por cinco principais conceitos:
iniciação, planejamento, execução, monitoramento/controle e encerramento. A função destes
processos relaciona-se com o gerenciamento das seguintes áreas de conhecimento, como mostrado na
figura 3: escopo, custos, tempo, qualidade, recursos humanos, comunicações, aquisições, risco e
integração [9].
Figura 2 – Ciclo de vida projeto
Fonte: http://movimentoimpactoglobal.com.br
18
Figura 3 – Processos / Áreas de conhecimento
Fonte: PMBOK
19
2.3 – Método Waterfall
A metodologia Waterfall, que significa cascata em inglês, é uma das formas mais tradicionais de
gerenciamento de projetos. Esse método tem característica sequencial, ou seja, a próxima ação só é
iniciada quando a fase anterior se encontra em sua completude. Não é permitido saltar etapas, voltar
ou substituir atividades. Além disso, no Waterfall os requisitos são totalmente definidos no início do
projeto e geralmente sofrem pouca ou nenhuma alteração durante sua execução. As fases, mostrado na
figura 4, mais comuns sob uma ótica tradicional são: definição de requisitos, planejamento, execução
e validação, tendo comportamento e organização diferente dependendo do tipo de projeto [13].
Figura 4 – Ciclo de vida projeto
Fonte: SOMMERVILLE, 2004
Apesar da robustez em sua estrutura, este método possui muita aderência em algumas naturezas de
projeto, como o desenvolvimento de software. Em uma pesquisa realizada em 153 fábricas de
software nos Estados Unidos no ano de 2015, foi verificado que a maioria dos gerentes de projetos
optam pela utilização do modelo em cascata para gerenciar projetos, conforme mostrado no gráfico 1.
20
Gráfico 1. Metodologias de Desenvolvimento de Software utilizadas (Vijayasarathy e Butler, 2016).
A metodologia Waterfall pode não trazer bons resultados quando o projeto é muito complexo
ou de longa duração. Caso se perceba que a probabilidade dos requisitos mudarem é média ou grande,
o ideal é adotar métodos mais flexíveis de gerenciamento, que permitam mudanças a cada etapa sem
grandes impactos no custo, prazo e qualidade. No entanto, os projetos em que os requisitos são muito
claros e que dificilmente serão modificados no tempo podem fazer um bom uso da metodologia. Essa
prática é comum em empresas da indústria e da construção civil, quando os ambientes são muito
controlados e estruturados e as mudanças após as entregas do projeto serão muito caras ou difíceis de
serem implementadas.
2.4 – Método SCRUM
O método básico do SCRUM, mostrado na figura 5, é um ciclo que consiste em uma série de
iterações bem definidas, que nomeiam-se sprints, cada uma podendo ter a duração de duas a quatro
semanas, denominado Time-box. Antes de cada sprint, é realizada uma reunião de planejamento
(Sprint Planning meeting) na qual o time de desenvolvedores tem contato com o cliente (Product
Owner) para priorização de atividades a serem realizadas, seleção e orçamento das tarefas, em pontos
21
de história, que o time pode realizar dentro da Sprint. Após isso, vem a etapa de execução da sprint
[8].
Figura 5 – SCRUM
Fonte: http://www.mindmaster.com.br/scrum/
Durante a execução da Sprint, a equipe controla o andamento das atividades por meio das
Reuniões Diárias (Daily Meetings) – que são reuniões que não duram mais do que 15 minutos – e
observando o seu progresso usando um gráfico chamado Sprint Burndown. Ao final de cada Sprint, é
feita uma revisão do produto entregue para verificar se tudo foi executado como estava planificado.
Ao fim da Sprint, é realizada uma Reunião de Revisão (Sprint Review), na qual a equipe
demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Em seguida, realiza-se a
Reunião de Retrospectiva (Sprint Review), uma reunião de lições aprendidas, com o propósito de
propor melhorias ao processo, ao time ou ao produto na próxima Sprint ou próximo projeto.
A equipe deve possuir um quadro para organizar as atividades – auxiliando no progresso da
Sprint – separadas em quatros estados: Para fazer; Em andamento; Para verificar; e Concluído [8].
As ações realizadas em uma Sprint são levadas para a próxima, melhorando o processo ou o
produto e, assim, o ciclo do Scrum é repetido até que todos os itens tenham sido finalizados, atendidos
e/ou o produto final tenha sido entregue e aceito pelo cliente [8].
De acordo com Martins (2007), a metodologia SCRUM é indicada para projetos com natureza
dinâmica e suscetíveis a mudanças de requisitos, sejam eles requisitos novos ou apenas modificados.
Entretanto, para aplicação deste método, faz-se necessário entender antes os seus papéis,
responsabilidades, conceitos e técnicas das fases de seu ciclo.
22
23
Capítulo 3
Metodologia Híbrida
3.1 Waterfall associado ao Scrum
A proposta atual considera as 5 grandes fases de um projeto [?]: Iniciação, planejamento,
execução/monitoramento, controle e encerramento. Tendo como premissa que a fase mais dispendiosa
de esforço operacional em um projeto se evidencia na fase de execução, paralelizada ao
monitoramento e controle.
A proposta consiste em implementar o método SCRUM nesta etapa com o objetivo de obter
resultados mais ágeis e interativos com as partes interessadas do projeto, garantindo eficiência da
camada de operação. As demais fases serão abordadas da forma tradicional de gerenciamento de
projetos, onde o detalhamento e validação das regras e requisitos são consolidados.
A metodologia híbrida do presente estudo, conforme tabela 1, se consolida da seguinte forma:
Tabela 1: Fases
Fase do projeto Estratégia
1. Iniciação
1. Definição das premissas e propósito do projeto 2. Análise de riscos e definição de requisitos em uma
visão macroscópica 3. Envio para aceite das partes interessadas
2. Planejamento
1. Análise detalhada dos requisitos e informações para
o andamento do projeto 2. Definição de modelo com a devida mensuração dos
objetivos e requisitos necessários para êxito do projeto, desde valores monetários à esforço de horas de trabalho estimadas
Elaboração da estrutura análitica de projeto (EAP) 3. Alinhamento prévio com a equipe responsável para
definição de atividades e responsabilidades de cada profissional atuante
3. Execução / Monitoramento e controle
1. Implementação do método SCRUM para definição,
implementação, acompanhamento e garantia da qualidade dos entregáveis
24
4. Finalização
1. Elaboração de documento de encerramento do
projeto 2. Validação do término do projeto
Elaborado pelo autor
A primeira fase tem como objetivo iniciar de forma robusta a visão estratégica do projeto, a
fim de reconhecer as reais exigências e necessidades. Todas informações relevantes do projeto serão
definidas e consolidadas pelas partes interessadas de forma que esta etapa servirá de subsídio para que
as demais decisões, provenientes das fases seguintes, sejam realizadas com assertividade.
A segunda fase visa descrever os processos necessários para elaborar uma definição detalhada
de escopo, onde deverá ser construído de forma progressiva a estruturação das tarefas em um
determinado intervalo de tempo e suas dependências no âmbito financeiro. É aconselhável para maior
garantia de sucesso de projeto um estudo de risco e impactos quanto as mudanças e ajustes levantados
pelas partes interessadas forem demandados.
A terceira fase consiste na implementação das práticas do método SCRUM para execução do
trabalho definido nas fases anteriores, onde as pessoas e recursos serão reunidos para a concretização
das ideias definidas em escopo de projeto tendo seu manifesto através de ação. Dentro da metodologia
do SCRUM, visa constituir processos que implementarão o trabalho definido em um plano de ação
envolvendo pessoas e recursos sejam eles materiais, financeiros ou humanos.
A quarta e última fase tem como objetivo a formalização do encerramento do projeto onde se
encontram os processos necessários para finalização das atividades de todas as partes interessadas.
3.2 Definição da métrica de desempenho
Para definir os indicadores a serem utilizados, verificou-se em estudo literário de quais
indicadores poderiam ser compartilhados pelas metodologias analisadas no presente estudo. Um
aspecto relevante, é a necessidade de criar métricas que avaliem a precisão do planejamento,
analisando não só o desempenho da equipe desenvolvedora, mas também da equipe de gestão. Com
isso, o indicador de Precisão de Estimativa foi usado [2], determinado pela fórmula abaixo:
𝑃𝑟𝑒𝑐𝑖𝑠ã𝑜 𝑑𝑎 𝑒𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎 = ∑ ( tem𝑝𝑜 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜 − 𝑡𝑒𝑚𝑝𝑜 𝑟𝑒𝑎𝑙𝑖𝑧𝑎𝑑𝑜) / ∑ 𝑇𝑒𝑚𝑝𝑜 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜
Segundo Moura et al. (2015) para se verificar se um projeto está seguindo o desenvolvimento
desejado e garantindo o alinhamento entre as partes interessadas, indicadores de produtividade e
eficiência devem ser definidos. Bajwa (2016), descreve os indicadores de Capacidade de Trabalho e
Velocidade, ambos utilizados para entender o nível de produtividade desempenhado pela equipe,
através da fórmula abaixo:
25
𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑𝑒 = ∑ 𝑇𝑟𝑎𝑏𝑎𝑙h𝑜 𝑎𝑐𝑒𝑖𝑡𝑜
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑𝑒 𝑑𝑒 𝑡𝑟𝑎𝑏𝑎𝑙h𝑜 = ∑ 𝑇𝑟𝑎𝑏𝑎𝑙h𝑜 𝑟𝑒𝑎𝑙𝑖𝑧𝑎𝑑𝑜
Os valores de trabalho planejado e trabalho realizado são expressos em Pontos de História,
como descrito no tópico 2.4, os Pontos de História classificam as atividades em grau de
complexidade, ou seja, atividades complexas recebem valores altos, enquanto atividades simples,
valores baixos. Analisando as literaturas de Bajwa (2016) e Downey e Sutherland (2013), foi possível
definir o indicador de Fator de foco, correspondente à fórmula abaixo:
𝐹𝑎𝑡𝑜𝑟 𝑑𝑒 𝑓𝑜𝑐𝑜 = Ve𝑙𝑜𝑐𝑖𝑑𝑎𝑑𝑒 / 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑𝑒 𝑑𝑒 𝑇𝑟𝑎𝑏𝑎𝑙h𝑜
Esses quatro indicadores foram definidos para servir como base da comparação de desempenho
entre o cenário dos projetos que usaram a metodologias Híbrida e tradicional (PMBOK). Isolado os
indicadores, os mesmos são: Velocidade, Capacidade de Trabalho, Foco de Trabalho e Precisão da
Estimativa.
26
Capítulo 4
Resultados Obtidos
4.1 – Análise dos dados de projetos no método tradicional
Para realizar a coleta e análise dos dados dos projetos que utilizaram a metodologia
tradicional (PMBOK), realizou-se uma adequação das informações documentadas em cronogramas
anteriores ao estudo. Isso se deve ao fato de que esses os projetos não foram pensados e planejados
através dos indicadores determinados no presente trabalho. Desta forma, para ser possível a análise
dos valores relativos a Trabalho Realizado e Trabalho Aceito, foi necessário estipular os ciclos de
Sprint dos antigos cronogramas. Para isso, os Subprodutos dos projetos foram divididos em Sprints
de 5 dias, mesma duração de Sprints de projetos executados com metodologia híbrida. Os valores
de Tempo Realizado e Tempo Estimado não precisaram ser adequados para a inserção nos
indicadores, já que esses valores estavam disponíveis nos cronogramas de forma semelhante aos
projetos executados com a forma híbrida. Seguem os dados coletados:
Tabela 2: Dados Projeto A
Projeto A
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 5 9 5 6
2 5 10 5 8
3 7 11 5 7
4 7 10 5 10
5 8 10 5 7
Elaborado pelo autor
27
O Projeto A teve duração de 5 Sprints (25 dias úteis), os valores de Tempo estimado de cada
Sprint serão os mesmos para todos os projetos, como já descrito anteriormente, já que os ciclos de
Sprint devem ter duração igual.
Tabela 3: Dados Projeto B
Projeto B
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 6 10 5 6
2 7 10 5 7
3 8 11 5 7
4 10 11 5 8
5 7 13 5 8
6 7 12 5 10
7 7 11 5 10
Elaborado pelo autor
O Projeto B teve duração de 7 Sprints (35 dias úteis), sendo um dos maiores projetos dentre
os executados utilizando a metodologia tradicional. A coluna “Trabalho aceito” ilustra que no
início do projeto poucas demandas estavam sendo considerados aceitas pelo gerente de projetos, de
10 Pontos de História desenvolvidos em atividades realizadas, apenas 6 foram de atividades que
realmente atendiam às necessidades dos usuários.
Tabela 4: Dados Projeto C
Projeto C
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 5 7 5 6
2 6 6 5 4
3 7 8 5 4
28
4 6 6 5 4
5 6 6 5 5
Elaborado pelo autor
O Projeto C teve duração de 5 Sprints (25 dias úteis), tendo sua duração estimada de forma
desproporcional, como a tabela ilustra através da última coluna. Ao todo 3 Sprints foram
concluídos antes do prazo.
Tabela 5: Dados Projeto D
Projeto D
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 6 8 5 3
2 6 7 5 3
3 7 7 5 5
4 5 6 5 5
5 7 7 5 4
6 6 7 5 6
Elaborado pelo autor
O Projeto D teve duração de 6 Sprints (30 dias úteis), executado com rendimento inferior aos
outros projetos, como ilustra a coluna de Trabalho realizado. Por outro lado, todos as demandas
foram entregues antes do prazo, como pode ser observado através da comparação entre Tempo
Estimado e Tempo Realizado. Esses dados demonstram inconsistência de planejamento sob a ótica
de tempo e escopo.
Tabela 6: Dados Projeto E
Projeto E
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 8 9 5 6
29
2 10 11 5 6
3 9 11 5 7
4 7 12 5 8
5 7 12 5 6
Elaborado pelo autor
O Projeto E foi caracterizado por alto Trabalho realizado, mas com um grau mediano de
Trabalho aceito. Além disso, ele excedeu o prazo em todos os 5 Sprints.
Tabela 7: Síntese de dados Projetos A, B, C, D, E.
Projetos Média do
trabalho aceito
(em pontos)
Média do
trabalho
realizado
(em pontos)
Tempo
estimado
(em dias)
Tempo total
realizado
(dias)
Projeto A 6 10 25 38
Projeto B 6 11 35 56
Projeto C 6 11 25 23
Projeto D 7 7 30 26
Projeto E 8 11 25 33
Elaborado pelo autor
A média dos dois primeiros parâmetros e o somatório dos dois últimos, como mostra a Tabela
7, foram calculadas para inserir nos indicadores de desempenho. Esses indicadores foram
utilizados no presente estudo para comparar ambas metodologias de gerenciamento.
4.2 – Análise de dados de projetos no método híbrido
As métricas definidas precisaram de informações sobre a duração planejada, a duração real, a
quantidade de atividades planejadas e a quantidade de atividades desenvolvidas por Sprint. Desta
forma, para a aplicação do método foram coletadas informações no tocante de cada um dos
parâmetros citados acima. As duas primeiras variáveis, duração planejada e real, foram coletadas
nos campos “Duração estimada” e “Duração real” contidas no Jira Software™. Os dados relativos
a atividades planejadas e desenvolvidas por Sprint foram coletados no início dos Sprints e nas
reuniões de revisão do Sprint. No início de um Sprint, o Product Owner documentava quantas
30
atividades foram planejadas e no término dele, as atividades concluídas trocavam de status “Em
progresso” para “Resolvido”, fornecendo a quantidade de atividades desenvolvidas. Os dados
coletados são mostrados na tabela 5.
Tabela 8: Dados Projeto X
Projeto E
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 9 10 5 5
2 9 11 5 6
3 10 12 5 5
4 12 12 5 7
5 11 11 5 6
Elaborado pelo autor
O projeto X foi curto em número de Sprint, porém extenso na quantidade de
desenvolvimentos. Com duração de apenas 5 Sprints (25 dias úteis), o projeto contou com 51
Pontos de História ao todo. Os valores de trabalho aceito por Sprint foram altos e por isso os
prazos não foram tão afetados, como pode ser observado na última coluna. A coluna “Tempo
Estimado” informa a quantidade de dias que duram os Sprints, e por definição do Scrum, essa
quantidade não pode ser alterada depois de definida. Como informado anteriormente, a equipe de
gestão definiu Sprints de 5 dias úteis.
Tabela 9: Dados Projeto Y
Projeto E
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 7 8 5 6
2 10 10 5 6
3 8 9 5 5
4 8 10 5 5
5 7 7 5 6
31
Elaborado pelo autor
Outro pequeno projeto, o Projeto Y teve a mesma duração do Projeto X, mas foi um projeto
menos complexo. Importante notar que no segundo Sprint, todas as transações desenvolvidas pela
equipe foram aceitas pelo Product Owner.
Tabela 11: Dados Projeto Z
Projeto E
Sprint Trabalho Aceito
(em pontos)
Trabalho
Realizado
(em pontos)
Tempo estimado
(em dias)
Tempo realizado
(em pontos)
1 10 10 5 5
2 10 11 5 6
3 9 11 5 6
4 9 11 5 6
5 8 12 5 7
6 9 10 5 5
7 11 12 5 5
Elaborado pelo autor
O Projeto Z foi um grande projeto que continha importantes transações de impacto
organizacional. Pode ser observado que o desenvolvimento durou 7 Sprints (35 dias úteis), e foram
concluídas tarefas que representam ao todo 66 Pontos de História. Entre o primeiro e o quarto
Sprint os valores do Trabalho aceito foram altos, significando que a equipe estava desenvolvendo
subprodutos muito próximos aos que os usuários desejavam, mas no decorrer do projeto esses
valores reduziram.
Tabela 11: Síntese de dados Projetos X,Y e Z
Projetos Média do
trabalho aceito
(em pontos)
Média do
trabalho
realizado
(em pontos)
Tempo
estimado
(em dias)
Tempo total
realizado
(dias)
Projeto X 10 11 25 29
Projeto Y 8 9 25 28
32
Projeto Z 9 11 35 40
Elaborado pelo autor
Sintetizando os dados de cada projeto, foi feita a tabela 8 com a média do Trabalho aceito e
do Trabalho realizado. Assim, foram calculados os somatórios do Tempo estimado e do Tempo
realizado. Estes valores serão utilizados nas métricas para analisar o desempenho da equipe dos
projetos.
4.3 – Cálculo dos indicadores
Conforme explica o capítulo 3, foram definidas 4 métricas para mensurar o desempenho dos
projetos, sendo a primeira o indicador Velocidade. A Tabela 9 descreve o resultado da métrica
Velocidade de todos os projetos analisados. O projeto X, de metodologia Scrum se destaca como mais
veloz, enquanto o destaque negativo está nos projetos B, D e E, de metodologia tradicional PMBOK,
com pior desempenho na métrica de Velocidade.
Tabela 12: Valores de Velocidade
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
8 7 9 7 7 10 8 9
Elaborado pelo autor
A segunda métrica definida foi o indicador de Capacidade de trabalho. A Tabela 10 descreve
o resultado da métrica Capacidade de trabalho de todos os projetos analisados. Para esta métrica,
enquanto 2 dos projetos se destacam empatados em primeiro lugar, sendo eles de metodologia Scrum
e PMBOK, dois se destacam negativamente com a menor pontuação, sendo ambos de metodologia
PMBOK.
Tabela 13: Valores de Capacidade de Trabalho
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
10 10 11 7 11 11 9 11
Elaborado pelo autor
A terceira métrica, o Fator de foco é calculado com a razão entre a Velocidade e a Capacidade
de trabalho. A Tabela 11 enumera os resultados da métrica Fator de foco de todos os projetos
analisados. Os projetos de maior e menor valores no indicador Fator de foco foram o Projeto X e o
Projeto E, com os valores de 0.91 e 0.64, respectivamente.
33
Tabela 14: Valores de Fator de Foco
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
0,8 0,7 0,81 1 0,64 0,91 0,89 0,81
Elaborado pelo autor
A Precisão da Estimativa foi a quarta métrica definida. A tabela 12 lista os resultados
relativos ao indicador de Precisão da estimativa. Pode-se notar projetos dois projetos superestimados,
o Projeto A e o Projeto B, ambos gerenciados utilizando a metodologia tradicional de gerenciamento
de projetos. O projeto mais próximo de estimativa mais próxima com a realidade, foi o Projeto C, de
97% de precisão.
Tabela 15: Valores de Precisão da estimativa
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
60% 46% 92% 87% 68% 84% 88% 86%
Elaborado pelo autor
Visando análise conjunta do desempenho dos projetos nas quatro métricas definidas, foram
elaborados gráficos comparativos para cada indicador no próximo capítulo.
34
4.4 – Análise do resultado
Nessa etapa, foram analisados diversos aspectos de congruência entre os projetos e as
metodologias utilizadas, a fim de encontrar os pontos fortes e fracos que as caracterizam.
Gráfico 2: Indicador de Velocidade.
Elaborado pelo autor.
Os projetos executados com a metodologia do Scrum obtiveram maiores valores de
Velocidade do que os executados com a metodologia PMBOK. Isso demonstra que, no caso
analisado, a divisão do projeto em ciclos de Sprint e o acompanhamento periódico através das
reuniões diárias, mantiveram a equipe do projeto desenvolvendo mais atividades importantes para a
entrega do escopo inicial.
Em relação à Capacidade de Trabalho, ambas metodologias obtiveram resultados similares. A
análise da variável Capacidade de Trabalho foi importante para saber que mesmo com a mudança de
metodologia, as equipes dos projetos trabalharam praticamente com o mesmo ritmo, dessa forma, a
metodologia Scrum não serviu para aumentar a quantidade de atividades desenvolvidas.
Gráfico 3: Indicador de Capacidade de Trabalho
0
2
4
6
8
10
12
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
35
Elaborado pelo autor.
Sobre os Projetos X, Y e Z, os resultados obtidos no Gráfico 4 foram similares aosdo Gráfico
3. Os projetos X e Z tiveram mais atividades concluídas por Sprint, significando maior empenho da
equipe dos projetos.
No Projeto Y, pode-se notar uma média de 2 pontos abaixo da média dos outros projetos,
mostrando que foram desenvolvidas menos atividades por ciclo de Scrum.
No caso específico dos Projetos B e E, pode-se verificar que a equipe de desenvolvedores
obteve um desempenho muito abaixo se comparado aos outros projetos. O mesmo não ocorreu com os
projetos executados utilizando a metodologia Scrum, sendo a menor Capacidade de Trabalho a do
Projeto Y, que atingiu 9 pontos.
Com as análises anteriores e constatando que a Capacidade de Trabalho máxima atingida por
um projeto de metodologia Scrum foi de 11 pontos, a equipe de gestão concluiu que, a metodologia
Scrum não possibilitou o aumento da Capacidade. Porém, a metodologia foi importante para garantir
que os projetos fossem continuamente acompanhados, impedindo que a Capacidade de Trabalho se
reduzisse a valores muito baixos, pois os artefatos do Scrum têm como objetivo principal eliminar
imprevistos e impedimentos no desenvolvimento da equipe.
Os projetos gerenciados com Scrum obtiveram maiores valores de Velocidade e valores
equiparados de Capacidade de Trabalho, por isso o Fator de foco deles apresentou resultados
melhores que os projetos gerenciados com a metodologia tradicional.
O gráfico 4 informa que no presente estudo de caso, os Projetos X, Y e Z desenvolveram
produtos mais alinhados com o escopo requisitado pelos usuários e com o planejamento do Product
Owner. Assim, os projetos tiveram menos retrabalho e redundâncias, com a equipe desenvolvendo
sempre funcionalidades importantes para o usuário.
0
2
4
6
8
10
12
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
36
Gráfico 4: Indicador de Fator de Foco.
Elaborado pelo autor.
Os gráficos ilustram que o Projeto D, de maior Fator de foco entre os da metodologia tradicional,
teve menos atividades concluídas, como informado no Gráfico 4, então é possível inferir que o alto
Fator de foco resulta de uma baixa quantidade de demandas, tornando mais fácil o gerenciamento das
tarefas.
Gráfico 5: Indicador de Precisão da Estimativa.
Elaborado pelo autor.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
0
10
20
30
40
50
60
70
80
90
100
Projeto A Projeto B Projeto C Projeto D Projeto E Projeto X Projeto Y Projeto Z
37
Indicador interligado diretamente com o desempenho da equipe de gestão, a Precisão da
estimativa tornou-se mais padronizada e próxima a 90%. Pode-se observar que durante a metodologia
tradicional de gerenciamento, muitos projetos eram subestimados e superestimados. A equipe de
gestão não tinha clareza do todo, e o escopo era várias vezes alterado, por isso a implementação do
Scrum e a divisão dos projetos em grupos de entregas, fizeram com que a gestão de escopo se tornasse
menos trabalhosa para a equipe envolvida.
Os outros projetos desenvolvidos pela metodologia Scrum também obtiveram
excelentes resultados, todos estando próximos de 90% de precisão. Além de projetos
atrasados, nota-se que os Projetos A e B foram planejados com duração maior do que o
necessário. Dados como esse, muitas vezes expunham a credibilidade da equipe de
desenvolvimento.
Com as reuniões diárias e o Jira™, foi possível manter o planejamento do tempo de
acordo com o esperado, já que a equipe de desenvolvimento verificava diariamente quanto
tempo ainda faltava para ter que finalizar suas tarefas, correndo atrás do tempo perdido das
atividades atrasadas.
Através dos Gráficos 4 e 5, é possível notar uma tendência nos valores mais discrepantes.
Quando o Fator de foco é muito abaixo de 1, ou seja, poucas atividades executadas são consideradas
“Resolvidas” pelo Product Owner, a Precisão de estimativa também é afastada de 100%. Pode-se
apontar o motivo dos projetos terem que ser replanejados, quando a equipe não desenvolve as
transações internas da maneira que osusuários desejam, havendo atrasos na entrega. Além disso, os
Product Owners relataram ter maior entendimento dos produtos a serem desenvolvidos pelos projetos,
pois toda a estrutura do Scrum fez com que a equipe estivesse mais próxima do desenvolvimento. Isso
afetou o andamento dos projetos de maneira geral, tornando as tarefas do gerente de projetos mais
eficazes. Como exemplo, pode-se apontar a negociação do Product Owner com os usuários nas
reuniões de planejamento dos projetos. Depois da implementação do Scrum, os Product Owners
passaram a entender melhor das transações internas, estimando melhor os prazos ao não ceder às
urgências muitas vezes infundadas dos usuários. Os resultados dessa melhora vieram com o feedback
dos usuários, que informaram ter percebido o cumprimento maior de prazos e a proximidade maior
deles com a execução do projeto. O tempo de resposta às alterações de escopo também agradaram aos
usuários, que conseguiram ter maior visibilidade de quando as mudanças entrariam nos ciclos Sprint
para serem desenvolvidas.
38
Capítulo 5
5.1 Conclusão
O desenvolvimento deste trabalho trouxe a identificação de um problema e
elaborou uma proposta de solução tendo como referência teórica o conteúdo exposto no
capítulo 2 e a implementação do método apresentado no capítulo 3. A análise dos
resultados obtidos deixou nítido, através dos indicadores definidos, que a
implementação da metodologia híbrida se justificou como uma melhoria,
proporcionando benefícios para o cenário empresarial estudado.
Os indicadores definidos proporcionaram a melhora na previsibilidade das
atividades dos projetos estudados, embasando resultados mais satisfatórios nas
iniciativas que foram gerenciadas utilizando a metodologia híbrida. Evidentemente o
estudo atual não se trata de uma solução que tem o objetido de resolver todos os
desafios de gestão de projetos, porém provê uma proposta de um cenário adaptável para
a natureza complexa e despendiosa de esforço – a fase de execução e monitoramento-
de um determinado projeto.
5.2 Trabalhos Futuros
Pesquisas futuras poderiam ter como objetivo diferentes formas e oportunidades
de aplicação do uso combinado do método tradicional de gerenciamento de projetos e
do SCRUM, conforme foi abordado no presente estudo. Apesar de ser limitado nas
possibilidades de implementação em projetos, pode servir de motivação para elaboração
de conteúdo científico sobre o tema proposto.
39
Bibliografia
[1] ALMEIDA, L. F. M., CONFORTO, E. C., SILVA, S. L., AMARAL, D. C., Fatores críticos da
agilidade no gerenciamento de projetos de desenvolvimento de novos produtos. Produto &
Produção, Porto Alegre, v. 13 n. 1, p. 93 - 113, fev. 2012, ISSN 1983-8026.
[2] BAJWA, J. K., Metrics of Scrum Methodology. International Journal of Computer Applications,
v.149, n.2, p. 24 - 27, Set. 2016.
[3] BRADY, T.; DAVIES, A. Managing structural and dynamic complexity: A tale of two projects.
Project Management Journal, v. 45, n. 4, p. 21-38, 2014.
[4] DOWNEY, S., SUTHERLAND, J. Scrum Metrics for Hyper-productive Teams: How They Fly
like Fighter Aircraft. In: HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES,
46., 2013, Hawaii. Anais… Wailea, Maui, Hawaii, Estados Unidos da America. IEE. 2013.
[5] FOWLER, Martin. The New Methodology. Disponível em:
http://martinfowler.com/articles/newMethodology.html. Acesso em: 11 fev. 2018.
[6] MARTINS, José Carlos Cordeiro. Técnicas Para Gerenciamento De Projetos De
Software. Brasport, 2007.
[7] MOURA, M. A., FRANÇA, V. J. A. T. M., ROUILLER, A. C. Implantação do Processo de
Medição Aderente ao Modelo MR-MPS-SW com Foco em Estudo de Tempos em Empresas com
Times SCRUM. In: Simpósio Brasileiro de Qualidade de Software, 14. 2015. Manaus. Anais...
Manaus, 2015.
[8] PEREIRA, Paulo; TORREÃO, Paula; MARÇAL, Ana Sofia. Entendendo Scrum para Gerenciar
Projetos de Forma Ágil. Disponível em: <http://www.trabalhosfeitos.com/ensaios/Entendendo-
Scrum-Para-Gerenciar-ProjetosDe/31439695.html>. Acesso em: 11 fev. 2018.
[9] PMBOK, PMI. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th
ed. Newton Square, Project Management Institute Inc., 2013. 589p.
[10] PMI (Project Management Institute). Um Guia do Conhecimento em Gerenciamento de Projetos
(Guia PMBOK®) – Quinta Edição. Newtown Square: Project Management Institute, 2013;
40
[11] PRESSMAN, R. Engenharia de Software: Uma abordagem Profissional. 7º edição. Editora
Bookman, 2007.
[12] SHENHAR, A. J.; DVIR, D. Reinventing project management: the diamond approach to
successful growth and innovation. Harvard Business Review Press, 2007.
[13] SOMMERVILLE, Ian. Software Engineering. 7th Edition, 2004.
[14] VIJAYASARATHY, L. R., & Butler, C. W. (2016). Choice of software development
methodologies: Do organizational, project, and team characteristics matter?. IEEE
Software, 33(5), 86-94.