METODOLOGIA HÍBRIDA: ANÁLISE DE GERENCIAMENTO DE …

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

https://2.bp.blogspot.com/-YpREkEKwmp8/WrvPnlXH_7I/AAAAAAAAAao/bNcT56wtcsgVk2SX630drZrvQquHB4ZsACLcBGAs/s1600/metodologiasUsadas.png

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.

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


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


(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


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


(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


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


(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


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


(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


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


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


(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


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


(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


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


(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


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


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


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


10 10 11 7 11 11 9 11


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


0,8 0,7 0,81 1 0,64 0,91 0,89 0,81


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


60% 46% 92% 87% 68% 84% 88% 86%


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


35


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


36

Gráfico 4: Indicador de Fator de Foco.


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.


0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1


0

10

20

30

40

50

60

70

80

90

100


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;

http://www.pmi.org/

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.

METODOLOGIA HÍBRIDA: ANÁLISE DE GERENCIAMENTO DE …

Documents

Transcript of METODOLOGIA HÍBRIDA: ANÁLISE DE GERENCIAMENTO DE …