ROBSON NEVES GONÇALVES

ESTUDO COMPARATIVO ENTRE O PMBOK E OS MÉTODOS ÁGEIS APLICADOS AO

GERENCIAMENTO DE PROJETOS DE SOFTWARE.

Trabalho apresentado ao curso MBA em

Gerenciamento de Projetos, Pós-

Graduação lato sensu, da Fundação Getulio

Vargas como requisito parcial para a

obtenção do Grau de Especialista em

Gerenciamento de Projetos.

ORIENTADOR: Arnaldo Lyrio Barreto

Salvador

Junho / 2018

FUNDAÇÃO GETULIO VARGAS PROGRAMA FGV MANAGEMENT MBA EM GERENCIAMENTO DE PROJETOS

O Trabalho de Conclusão de Curso

“Estudo comparativo entre o PMBOK e os Métodos Ágeis aplicados ao Gerenciamento de Projetos de software”,

elaborado por Robson Neves Gonçalves e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos, foi aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de especialização do Programa FGV Management.

Salvador, 12 de Junho de 2018

André Barcaui Coordenador Acadêmico Executivo

Arnaldo Lyrio Barreto

Prof. Orientador

TERMO DE COMPROMISSO

O aluno Robson Neves Gonçalves, abaixo assinado, do curso de MBA em

Gerenciamento de Projetos, Turma (GP 36) do Programa FGV Management,

realizado nas dependências da FGV Salvador, no período de 14/10/2016 a

12/05/2018, declara que o conteúdo do Trabalho de Conclusão de Curso intitulado

“Estudo comparativo entre o PMBOK e os Métodos Ágeis aplicados ao Gerenciamento

de Projetos de software”, é autêntico, original e de sua autoria exclusiva.

Salvador, 12 de Junho de 2018

Robson Neves Gonçalves

Dedico este trabalho a Deus, a minha

esposa Fernanda pela paciência e apoio

incondicional e meu querido filho Benício,

recém-nascido, que ilumina nossos

caminhos.

RESUMO

Este trabalho apresenta os conceitos principais do PMBOK e dos principais métodos ágeis,

sendo eles o SCRUM, Extreme Programming (XP), SCRUM/XP HYBRID, KANBAN,

SCRUMBAN e Feature-Driven Development (FDD).

Com base em todos os conceitos descritos, é apresentado uma análise comparativa dos

processos e área de conhecimento do PMBOK com os métodos ágeis no gerenciamento de

projetos de software, identificando os gaps, diferenças e similaridades.

É evidenciado que os métodos ágeis permitem o desenvolvimento rápido e com qualidade de

software, porém sem atender todas as caraterísticas necessárias para cobrir todos os aspectos e

peculiaridades presentes em cada negócio e desenvolvimento de projeto de software.

Ajustar e unir estas duas metodologias (Tradicional – PMBOK e Ágeis) apresenta-se como um

diferencial no desenvolvimento de projeto, atendendo as necessidades e desafios presentes.

Com este intuito o trabalho descreve soluções híbridas, sendo elas o Scrum + Guia PMBOK e

XPOKs.

Palavras-Chave: Metodos Ágeis, PMBOK, Análise Comparativa, Metodos híbridos

ABSTRACT

This work introduce the main concepts and principles from PMBOK and Agile methodology,

describing the SCRUM, Extreme Programming (XP), SCRUM / XP HYBRID, KANBAN,

SCRUMBAN and Feature-Driven Development (FDD).

Supported by all concepts described, it is performed a comparative analysis involving all

processes and areas of knowledge from PMBOK and the Agile methods in the software projects

management, identifying gaps, differences and similarities.

During this work evidenced that the agile methods allow the fast development and good quality

of software, but without complete all necessary characteristics to cover all aspects and

peculiarities present in each business and software project development.

Adjust and combine these two methodologies (Traditional – PMBOK and Agile) presents as a

differential in project development, attending the current needs and challenges.

For this purpose, the work describes hybrid methods, being the Scrum + PMBOK Guide and

the XPOKs.

Keywords: Agile Methods, PMBOK, Comparative Analysis, Hybrid Methods

LISTA DE FIGURAS

FIGURA 1 – Grupos de processo em um projeto e suas interações............................14

FIGURA 2 – Relação entre os valores, princípios e práticas oriundas da mentalidade ágil ..17

FIGURA 3 – O Agile abrange diversas abordagens distintas ..................................17

FIGURA 4 – Papeis, artefatos e cerimônias no framework Scrum ............................19

FIGURA 5 – Resumo framework Scrum ........................................................21

FIGURA 6 – Sumário das práticas...............................................................23

FIGURA 7 – Ciclo desenvolvimento método XP ...............................................25

FIGURA 8 – Modelo Scrum / XP Hybrid .......................................................26

FIGURA 9 – Modelo quadro Kanban com sistema de puxada .................................28

FIGURA 10 – Visão geral método Scrum .......................................................29

FIGURA 11 – Visão geral método Scrumban ...................................................30

FIGURA 12 – Modelo quadro Scrumban .......................................................31

FIGURA 13 – Comparação Scrum x Kanban x Scrumban .....................................32

FIGURA 14 – Ciclo de vida projeto FDD – AGILE GUIDE ..................................33

FIGURA 15 – Ciclo de vida projeto FDD .......................................................33

FIGURA 16 – Abordagens híbridas .............................................................44

FIGURA 17 – Ciclo de vida Scrum + Guia PMBOK ...........................................45

FIGURA 18 – Ciclo de vida projeto com Scrum + Guia PMBOK .............................45

FIGURA 19 – Grupo processo Iniciação - Scrum + Guia PMBOK ...........................46

FIGURA 20 – Grupo processo Planejamento - Scrum + Guia PMBOK ......................46

FIGURA 21 – Planejamento Backlog - Scrum + Guia PMBOK ...............................47

FIGURA 22 – Planejamento da Sprint - Scrum + Guia PMBOK ..............................48

FIGURA 23 – Execução - Scrum + Guia PMBOK .............................................48

FIGURA 24 – Monitoramento e Controle - Scrum + Guia PMBOK ..........................49

FIGURA 25 – Reunião de Revisão - Scrum + Guia PMBOK ..................................50

FIGURA 26 – Reunião de Retrospectiva - Scrum + Guia PMBOK ...........................50

FIGURA 27 – Encerramento da Fase - Scrum + Guia PMBOK ...............................51

FIGURA 28 – Encerramento do Projeto - Scrum + Guia PMBOK ............................51

FIGURA 29 – Ciclo de vida método XPOKs ...................................................52

FIGURA 30 – Etapa de Início - método XPOKs ...............................................53

FIGURA 31 – Etapa dos ciclos de desenvolvimento - método XPOKs .......................54

FIGURA 32 – Etapa do fechamento - método XPOKs .........................................55

FIGURA 33 – Base método XPOKs.............................................................57

LISTA DE QUADROS E TABELAS

TABELA 1 – Mapeamento processos pelos grupos de processo e áreas de conhecimento ...15

TABELA 2 – Comparativo Métodos Ágeis e Tradicionais ....................................18

TABELA 3 – Práticas do XP.....................................................................23

TABELA 4 – Princípios e propriedades do método Kanban ...................................27

TABELA 5 – Comparação PMBOK e Métodos Ágeis .........................................35

TABELA 6 – Quadro resumo/comparativo entre o gerenciamento tradicional e ágil ........43

SUMÁRIO

1. INTRODUÇÃO .............................................................................11

2. FUNDAMENTAÇÃO TEÓRICA .........................................................13

2.1 Guia PMBOK ...........................................................................13

2.2 Métodos Ágeis ..........................................................................16

2.2.1 SCRUM.............................................................................19

2.2.2 EXTREME PROGRAMMING - XP .............................................21

2.2.3 SCRUM / XP HYBRID............................................................25

2.2.4 KANBAN ..........................................................................27

2.2.5 SCRUMBAN .......................................................................29

2.2.6 FEATURE-DRIVEN DEVELOPMENT - FDD .................................32

3. ANÁLISE COMPARATIVA DOS PROCESSOS E ÁREAS DE CONHECIMENTO

DO PMBOK E MÉTODOS ÁGEIS ..........................................................35

4. ABORDAGENS HÍBRIDAS DE TRABALHO ..........................................44

4.1 PMBOK + SCRUM .....................................................................45

4.2 XPOKs ..................................................................................52

5. CONCLUSÕES .............................................................................58

REFERÊNCIAS BIBLIOGRÁFICAS ........................................................60

11

1. INTRODUÇÃO

De acordo com Prikladnicki (2014), na década de 90, os métodos tradicionais de

gerenciamento de projetos de software começaram a ser vistos como muito regrados, lentos,

burocráticos e não adequados ao desenvolvimento da atividade.

Nesta mesma década surgiram métodos alternativos para o desenvolvimento de software,

sendo chamados de métodos ágeis a partir de 2001, quando 17 especialistas se uniram para

encontrar uma forma de desenvolver projetos de software de forma rápida, leve e direcionada

em pessoas (PRIKLADNICKI, 2014).

Dessa forma, em 2001 foi publicado o “Manifesto for Agile Software Development”

(http://agilemanifesto.org/), compartilhando os valores e princípios dos Métodos Ágeis.

O manifesto possui os seguintes valores fundamentais:

- Indivíduos e interações mais que processos e ferramentas - Software em funcionamento mais que documentação abrangente

- Colaboração com o cliente mais que negociação de contratos

- Responder a mudanças mais que seguir um plano (MANIFESTO ÁGIL, 2001)

Porém, segundo Fitsilis (2008) os métodos ágeis não definem todas as faces para cobrir

todos os aspectos os necessários no gerenciamento de projetos de software.

De acordo com Vargas (2016), ocorre uma luta entre duas vertentes, a primeira baseada

nos conceitos clássicos de gerenciamento de projetos, onde encontra-se o Project Management

Body of Knowlwdge – PMBOK, e a segunda baseada nos métodos ágeis de desenvolvimento.

Porém as duas linhas de trabalho possuem os mesmos objetivos, concluir o projeto de

software com a qualidade definida, no prazo e com a otimização dos recursos. O grande

obstáculo é como escolher, ajustar e unir estas duas metodologias para conquistar a excelência

no desenvolvimento do projeto de software (VARGAS, 2016).

Por este motivo é importante definir quais gaps, diferenças e similaridades ocorrem entre

o PMBOK e os principais métodos ágeis utilizados no mercado. Com este quadro comparativo

é possível esclarecer e delimitar os caminhos possíveis diante das diversas peculiaridades

presentes em cada negócio e consequentemente a cada novo projeto para desenvolvimento de

software.

A integração do PMBOK aos Métodos Ágeis e vice-versa, formando um método híbrido

apresenta-se como uma possível solução para muitas empresas, atendendo melhor suas

necessidades (COUTO, 2016).

12

O trabalho, portanto, se justifica, como exposto acima, pela necessidade de se realizar

uma comparação entre o PMBOK e os Métodos Ágeis aplicadas para o Gerenciamento de

Projetos de software com a apresentação de abordagens híbridas de trabalho.

Além disso, este trabalho irá abranger os principais métodos ágeis em apenas um

documento, tornando-se um diferencial diante de pesquisas bibliográficas realizadas até o

momento, aonde os temas são subdivididos e não abordados de forma abrangente, para um

entendimento comum e de fácil interpretação para o leitor.

Este trabalho está delimitado na fundamentação teórica do PMBOK e métodos ágeis,

além do detalhamento conceitual dos principais métodos ágeis, sendo eles o SCRUM, Extreme

Programming (XP), SCRUM/XP HYBRID, KANBAN, SCRUMBAN e Feature-Driven

Development (FDD).

Os respectivos métodos ágeis citados acima representam 80% dentre todos os Métodos

Ágeis mais utilizados na atualidade, segundo pesquisa apresentada no “The 11th annual State

of AGILETM report” (STATE OF AGILE, 2017).

Posteriormente será realizada a análise comparativa dos processos e áreas de

conhecimento do PMBOK e os respectivos métodos ágeis, identificando e detalhando gaps,

diferenças e similaridades.

Ao final será apresentado possíveis abordagens híbridas de trabalho que trazem

benefícios ao gerenciamento de projetos de software (FITSILIS, 2008, p.383).

Este trabalho não apresentará a aplicação e o desenvolvimento prático de cada método

ágil citado, sendo item fora do escopo

O objetivo geral deste trabalho é realizar uma comparação entre o PMBOK e os Métodos

Ágeis aplicadas para o Gerenciamento de Projetos de software.

Para o atingimento do objetivo geral acima exposto, serão necessários os seguintes

objetivos específicos para comporem a solução final:

i. Apresentar os conceitos principais do PMBOK e Métodos Ágeis.

ii. Apresentar os conceitos principais dos seguintes Métodos Ágeis: SCRUM, XP,

SCRUM / XP HYBRID, KANBAN, SCRUMBAN e FDD

iii. Realizar uma análise comparativa dos processos e áreas de conhecimento do

PMBOK e os Métodos Ágeis citados no trabalho.

iv. Identificar os gaps, diferenças e similaridades apresentadas entre o PMBOK e os

Métodos Ágeis citados.

v. Apresentar possíveis abordagens híbridas de trabalho.

13

Toda a fundamentação teórica, bem como todo os comparativos e possíveis soluções

serão obtidos através de uma pesquisa bibliográfica com revisão sistemática da literatura,

mantenho o foco sobre o tema em livros, artigos e monografias.

2. FUNDAMENTAÇÃO TEÓRICA

Neste capítulo apresenta-se o referencial teórico utilizado neste estudo, mostrando uma

breve revisão dos principais conceitos e teorias presentes na literatura e em trabalhos realizados

nas áreas de interesse.

Segundo Vergara (1997), o referencial teórico oferece uma contextualização e

consistências a investigação, facilitando a formulação de hipóteses e soluções.

Serão apresentados os conceitos básicos sobre o PMBOK e Métodos Ágeis, além dos

respectivos métodos ágeis que o estudo aborda, sendo eles o SCRUM, XP, SCRUM/XP

HYBRID, KANBAN, SCRUMBAN e FDD.

2.1 Guia PMBOK

Segundo o PMBOK (PMI, 2014) o guia Project Management Body of Knowlwdge -

PMBOK provem diretrizes e conceitos para o gerenciamento de projetos, sendo um guia padrão

e reconhecido internacionalmente, apresentando a aplicação do conhecimento, processos,

habilidades, ferramentas e técnicas amplamente reconhecidas como boas práticas com impacto

significativo no sucesso do projeto.

O guia PMBOK (PMI, 2014) apresenta cinco grupos de processos, sendo eles:

Grupo de processos de iniciação

Grupo de processos de planejamento

Grupo de processos de execução

Grupo de processos de monitoramento e controle

Grupo de processos de encerramento

A interação destes grupos de podem ser visualizadas na figura 1 abaixo:

14

FIGURA 1 – Grupos de processo em um projeto e suas interações

Fonte: PMI, 2014

Na figura 1 fica evidenciado como os grupos se interagem e as respectivas sobreposições

que ocorrem entre elas, sendo vinculadas pelas saídas que cada grupo de processo fornece.

O guia PMBOK (PMI, 2014) apresenta dez áreas de conhecimento, sendo elas:

Gerenciamento da Integração do projeto

Gerenciamento do Escopo do projeto

Gerenciamento do Tempo do projeto

Gerenciamento dos custos do projeto

Gerenciamento da qualidade do projeto

Gerenciamento dos recursos humanos do projeto

Gerenciamento das comunicações do projeto

Gerenciamento dos riscos do projeto

Gerenciamento das aquisições do projeto

Gerenciamento das partes interessadas do projeto

O PMBOK (PMI, 2014) ainda define formalmente o total de 47 processos de

gerenciamento de projeto nos respectivos cinco grupos de processos e dez áreas de

conhecimento mencionados anteriormente.

A tabela 1 abaixo demonstra o mapeamento de todos os processos com os respectivos

grupos de processo e áreas de conhecimento.

15

TABELA 1 – Mapeamento processos pelos grupos de processo e áreas de conhecimento

Fonte: PMI, 2014

Segundo ainda o próprio PMBOK (PMI, 2014), por se tratar de um guia, e não de uma

metodologia específica, é possível utilizar metodologias e ferramentas diversas, entre eles, os

16

próprios métodos ágeis, com o objetivo de criar uma estrutura de gerenciamento de projetos

mais completa possível.

2.2 Métodos Ágeis

Segundo Prikladnicki (2014), a partir dos nos 90, surgiram os chamados Métodos Ágeis,

sempre com o direcionamento de obter formas mais eficientes de desenvolver software, com

enfoque maior nas pessoas do que em processos (métodos tradicionais), viabilizando a

adaptação a novos fatores oriundos do desenvolvimento do projeto e respostas rápidas às

constantes mudanças do mercado.

Os autores do manifesto ágil definiram 12 princípios que norteiam os métodos ágeis,

sendo eles:

Nossa maior prioridade é satisfazer o cliente

através da entrega contínua e adiantada

de software com valor agregado.

Mudanças nos requisitos são bem-vindas,

mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das

mudanças visando vantagem competitiva para o cliente.

Entregar frequentemente software funcionando,

de poucas semanas a poucos meses, com preferência à menor escala de tempo.

Pessoas de negócio e desenvolvedores devem trabalhar

diariamente em conjunto por todo o projeto.

Construa projetos em torno de indivíduos motivados.

Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

O método mais eficiente e eficaz de transmitir

informações para e entre uma equipe de desenvolvimento

é através de conversa face a face.

Software funcionando é a medida primária de progresso.

Os processos ágeis promovem desenvolvimento

sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo

constante indefinidamente.

Contínua atenção à excelência técnica e bom design

aumenta a agilidade.

Simplicidade--a arte de maximizar a quantidade de

trabalho não realizado--é essencial.

As melhores arquiteturas, requisitos e designs

emergem de equipes auto organizáveis.

Em intervalos regulares, a equipe reflete sobre como

se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

(MANIFESTO ÁGIL, 2001)

17

O Agile Guide (2017), cita que o Agile é uma mentalidade definida por seus quatro

valores e direcionados pelos seus doze princípios, ambos já vistos anteriormente, e que por sua

vez são apresentados através de várias práticas distintas. Tal conceito é exemplificado na figura

2.

FIGURA 2 – Relação entre os valores, princípios e práticas oriundas da mentalidade ágil

Fonte: AGILE GUIDE, 2017

De acordo com Agile Guide (2017), as abordagens e métodos ágeis cobrem uma

variedade extensa de frameworks e métodos/práticas. A figura 3 demonstra que qualquer tipo

de método, abordagem, framework, técnica ou prática que atenda a todos aos valores e

princípios da Agile Mindset são agregados aos métodos ágeis.

FIGURA 3 – O Agile abrange diversas abordagens distintas

Fonte: AGILE GUIDE, 2017

18

Adicionalmente a figura 3 ratifica que tanto o Kanban quanto os métodos ágeis são

subconjuntos do Lean, compartilhando as mesmas ideias presentes no pensamento Lean, como

“foco no valor”, “bateladas de tamanho pequeno” e “eliminação de desperdícios”. (AGILE

GUIDE, 2017).

Para exemplificar as diferenças básicas na aplicação de métodos ágeis e tradicionais, a

tabela 2 traz um comparativo dos dois métodos, comparando tópicos básicos no gerenciamento

de projetos.

TABELA 2 – Comparativo Métodos Ágeis e Tradicionais

Fonte: PRIKLADNICKI, 2014

Através da tabela 2 fica claro o foco da metodologia ágil na geração de valor ao cliente,

via entregas frequentes e feedback, com controle orientado a pessoas, guiado sempre pelas

funcionalidades dos produtos com modelos interativo e incremental de entregas.

19

2.2.1 SCRUM

O nome ou termo Scrum vem do rúgbi, fazendo referência à maneira que o time se une

para avançar com a bola pelo campo, com um posicionamento cuidadoso, propósitos e objetivos

claros e unificados (SUTHERLAND, 2016).

Segundo Schwaber e Sutherland (2017), Scrum é um framework utilizado para

desenvolver, entregar e manter produtos complexos. A definição do Agile Guide (2017)

descreve que o Scrum é um framework utilizado para gerenciar o desenvolvimento de um

produto.

De acordo com Sutherland (2016), o Scrum baseia-se em um ciclo de inspeção e

adaptação, sendo necessário revisar o que já fez e analisar como poderia continuar fazendo

melhor e mais rápido, retirando possíveis impedimentos.

O Scrum intensifica a entrega de software de forma eficaz, adaptando-se à constante

realidade de mudanças, a equipe ágil poderá facilmente alterar as prioridades conforme

necessário, sendo as funcionalidades de maior valor desenvolvidas antecipadamente,

sobrepondo-se a funcionalidades menos prioritárias, ou seja, que agregam menos valor ao

cliente (PRIKLADNICKI, 2014).

Por princípios básicos do método, projetos onde é executada o framework do Scrum

possuem três papeis claros, três artefatos e quatro cerimônias padrões. A figura 4 apresenta os

respectivos papeis, artefatos e cerimônias.

FIGURA 4 – Papeis, artefatos e cerimônias no framework Scrum

Fonte: COHN, 2018

•Dono do produto•ScrumMaster•Equipe

Papéis

•Planejamento•Revisão•Retrospectiva•Reunião diária

Cerimônia

•Product backlog•Sprint backlog•Burndown charts

Artefatos

20

Segundo Cruz (2013), o framework é utilizado para solucionar um problema específico,

sendo divididos em frameworks verticais e horizontais, por definição:

Frameworks verticais, também conhecidos como especialistas, são

confeccionados através da experiência obtida em um determinado contexto

específico, tentando resolver problemas de um determinado domínio de aplicação.

Frameworks horizontais, não dependem do domínio de aplicação e podem

ser usados em diferentes domínios, ou seja, podem tentar resolver

problemas de qualquer domínio de aplicação.

(CRUZ, 2013).

Dentro dos papeis apresentados, o Dono do produto é responsável pelo valor do negócio

do produto (PRIKLADNICKI, 2014), além de definir e priorizar as funcionalidades, ser

responsável pelo aceite ou rejeito do produto, bem como a rentabilidade (COHN, 2018).

Por sua vez o Scrum Master representa o “gerente” do projeto, sendo responsável pela

aplicação dos princípios do framework Scrum, retirando obstáculos, garantindo a plena

produtividade e comunicação (COHN, 2018).

A equipe se auto organiza e é multifuncional, com o objetivo de entregar maior valor ao

final de cada sprint, através do desenvolvimento de software (COUTO, 2016), esta é uma

premissa importante para que os projetos tenham bom resultado (CRUZ, 2013).

Com referência aos artefatos, anteriormente já foi citado o primeiro deles, o Product

backlog, o segundo item é o Sprint Backlog, que basicamente é responsável pelo planejamento

estratégico e tático da próxima sprint em um nível mais micro, o Burndown charts é uma forma

gráfica que representa o progresso do trabalho em desenvolvimento (COHN, 2018).

Segundo Prikladnicki (2014), pode-se ainda citar o Incremento, representado pelas

funcionalidades do software pronto, definadas no Product backlog.

De acordo com Couto (2016), as cerimônias ou eventos são basicamente as atividades

rotineiras quando se utiliza o framework Scrum, podemos detalhar da seguinte forma:

Planejamento da Sprint: reunião responsável pela definição do planejamento do

trabalho e meta de uma Sprint, com duração média de (4-8h).

Revisão da Sprint: reunião onde o produto e incremento são inspecionados e se

necessário são ajustados, com duração média de (2-4h).

Retrospectiva da Sprint: reunião com objetivo de inspecionar e adaptar os

processos empíricos, com duração média de (0,5-1h).

Scrum/Reunião Diária: reunião responsável pela auto-organização da equipe e

sincronismo das atividades para o período de 24h. Deve ser realizada em pé com

duração de 15 minutos.

21

A figura 5 abaixo representa um resumo gráfico do framework Scrum.

FIGURA 5 – Resumo framework Scrum

Fonte: COHN, 2018

Segundo o Agile Guide (2017) o Scrum ocorre em ciclos de um mês ou menos (2-4

semanas), sendo normalmente chamados de Sprints, mantendo sempre um fluxo linear de

atividades.

O sprint é um processo empírico baseado no ciclo PDCA (Plan, Do, Check, Act), a cada

sprint a atividade/trabalho é priorizado conforme as listas de requisitos presentes no Product

Backlog (PRIKLADNICKI, 2014).

Para Cruz (2013), o Scrum pode ser aplicado em diversos tipos de projeto, porém os seus

resultados positivos são visualizados facilmente em projetos de natureza tecnológica, com

equipes de até 10 integrantes, formada por profissionais seniores.

2.2.2 EXTREME PROGRAMMING - XP

De acordo com o Agile Guide (2017), o Extreme Programming (XP) é um método de

desenvolvimento de software baseado em ciclos frequentes e na aplicação de uma determinada

melhor prática na sua forma mais pura e simples durante todo o projeto. A XP é mais conhecida

por popularizar um conjunto holístico de práticas destinadas a melhorar os resultados de

projetos de software.

22

Segundo Beck (2013), os benefícios de um código limpo são a menor quantidades de

falhas, maior velocidade na manutenção e um compartilhamento facilitada de código, além de

suavizar todo o processo de desenvolvimento.

Segundo Beck (2005), os seguintes valores são a base do XP, sendo elas:

Comunicação

Simplicidade

Feedback

Coragem

Respeito

Mesmos não sendo tão palpáveis do que as melhores práticas apresentadas no método, os

valores definem e resumem a proposta da metodologia. O foco é a comunicação, e o XP baseia-

se 14 princípios (PRIKLADNICKI, 2014), sendo eles:

Humanidade

Economia

Melhorias

Benefício mútuo

Semelhança

Diversidade

Passos pequenos

Reflexão

Fluxo

Oportunidade

Redundância

Falha

Qualidade

Aceitação da responsabilidade.

O método foi inicialmente formalizado como um conjunto de doze práticas primárias,

mas gradualmente evoluiu para adotar várias outras práticas secundárias (AGILE GUIDE,

2017), tais práticas são sinalizadas na tabela abaixo.

23

TABELA 3 – Práticas do XP

Fonte: AGILE GUIDE, 2017

Para Beck (2013), tais práticas são divididas em práticas primárias e secundárias (corollary),

sendo que as práticas primárias podem ser utilizadas no início da aplicação XP, de forma segura,

trazendo melhorias imediatas no desenvolvimento do software. Por sua vez as práticas

secundárias ou “corollary” são complementares as primárias, e devem ser aplicados após o

domínio total das práticas iniciais. A aplicação em paralelo das práticas primárias e secundárias

podem provocas danos ao desenvolvimento e aplicação do XP e consequentemente ao projeto.

FIGURA 6 – Sumário das práticas

Fonte: BECK, 2013

24

Conforme García Rodríguez (2015) o ciclo de desenvolvimento do método XP pode ser

dividido em quatro atividades principais, sendo elas:

Planejamento

o Entender o negócio.

o Escrever as histórias de usuário.

o Agrupar por seu valor e custo (realizado entre cliente e desenvolvedores)

o Priorizar e definir próxima versão (realizado entre cliente e

desenvolvedores).

Design

o Utiliza-se os cartões CRC (Classe - Responsabilidade - Colaborador),

onde são identificadas e organizadas as classes orientadas a objeto

relevantes para a versão.

o Se tiver problemas no design, recomenda-se realizar um protótipo (spike

solution), para reduzir os riscos.

o O design ocorre tanto antes como após a codificação, ou seja, refatorizar

significa que o design é atualizado continuamente a medida que se constrói

o software.

Codificação

o Desenvolvimento de software com testes individuais das histórias

incluídas na versão atual.

o Utilizar as boas práticas de programação em par e realizar a integração

continua do código com o resto da equipe.

Teste

o Após os testes de individuais citados na etapa de codificação deve-se

realizar os testes de aceitação especificadas pelo cliente.

o Todos os testes são oriundos das histórias de usuário criadas e

implementadas na versão.

o É importante ter um procedimento/estratégia de testes para cada vez que

ocorrer uma modificação do código (processo originado da filosofia de

refatorização).

25

A figura abaixo exemplifica o ciclo de vida XP:

FIGURA 7 – Ciclo desenvolvimento método XP

Fonte: GARCÍA RODRÍGUEZ,2015

Segundo Soares (2004b) a XP pode ser aplicada em projetos em que os stakeholders não

tenham o escopo bem definido e podem mudar muito de opinião durante o desenvolvimento do

projeto.

2.2.3 SCRUM / XP HYBRID

Segundo Musa e Tariq (2017) a combinação das metodologias do Scrum e XP

aprimorando a documentação (gerenciamento de requisitos) e tratando as desvantagens em

ambos os processos, é possível checar em um bom modelo de método ágil. Esta metodologia

ágil trabalha basicamente na união da gestão presente no Scrum com a Engenharia e práticas

oriundas do XP.

De forma prática, o Scrum/XP Hybrid trabalha na forma de sprints, assim como o Scrum,

depois de completar e testar cada sprint ele se move para o próximo sprint, e assim

sucessivamente. A figura 8 abaixo exemplifica o conceito da utilização do Sprint com aplicação

das práticas XP dentro de cada sprint especifico.

26

FIGURA 8 – Modelo Scrum / XP Hybrid

Fonte: MUSA e TARIQ, 2017

O objetivo deste modelo é manter o cliente envolvido a cada passo para que ele tenha um

produto com o qual esteja satisfeito ao final. Esse método economiza tempo e dinheiro do

cliente porque o cliente testa e aprova o produto em cada etapa do desenvolvimento (MUSA e

TARIQ, 2017).

De acordo ainda a Musa e Tariq (2017) alguns dos principais benefícios dessa

metodologia ágil híbrida são:

Custo mais baixo, redução de retrabalho.

Permite agregar mais valor aos clientes com o produto final desenvolvido, fazendo

melhorias e envolvendo os clientes com decisões de desenvolvimento durante

todo o processo.

Incentiva a comunicação aberta entre os membros da equipe e os clientes.

Fornece às equipes uma vantagem competitiva, detectando defeitos e fazendo

alterações ao longo do processo de desenvolvimento, em vez de no final.

Garante que as mudanças possam ser feitas mais rapidamente e ao longo do

processo de desenvolvimento, por meio de avaliações consistentes para avaliar o

produto com os resultados esperados solicitados.

27

2.2.4 KANBAN

Segundo com o Agile Guide (2017), o Kanban na manufatura enxuta é um sistema para

programar o controle de estoque e o reabastecimento, chamado “just-in-time”, inspirado nesses

sistemas de estoque, Taiichi Ohno desenvolveu o Kanban e foi aplicado na principal fábrica da

Toyota em 1953.

A palavra kanban é traduzida literalmente como “sinal visual” ou “cartão”. Quadros

kanban físicos com cartões permitem e promover a visualização e o fluxo do trabalho através

do sistema para que todos possam visualizar (AGILE GUIDE, 2017).

De acordo com Prikladnicki (2014), o Kanban torna-se um instrumento para a observação

daquilo que é realizado, permitindo também a reflexão sobre a próxima solução mais adequada

ao contexto atual.

Este método utiliza o “sistema de puxada” para mover o trabalho através dos

processos/estados, quando o time finaliza um trabalho, pode-se puxar um novo trabalho para

aquele processo/estado. Na tabela 4 são demonstradas os princípios e propriedades do método

Kanban.

TABELA 4 – Princípios e propriedades do método Kanban

Fonte: AGILE GUIDE, 2017

O quadro Kanban é composto por colunas (To do, Analysis, Development, Test and

Deploy) que representam os estados para os quais o trabalho precisa fluir para que seja possível

concluí-lo. A figura 9 apresenta um modelo de quadro que exemplifica um fluxo de trabalho.

28

FIGURA 9 – Modelo quadro Kanban com sistema de puxada

Fonte: AGILE GUIDE, 2017

Segundo Brechner (2015), no gerenciamento de projetos se identifica e limita o excesso

de trabalho em uma determinada atividade, evitando o caos de atividades em um grupo de

trabalho. Em uma abordagem tradicional, estes excessos/caos são limitados pela especificação

de todo o trabalho, com um procedimento formal de solicitação de mudança e a sincronização

de equipes de trabalho em etapas predeterminadas.

Ainda para Brechner (2015), no Scrum, o caos é limitado pelo planejamento de sprints

em um período determinado de tempo, retendo alterações no plano até o próximo sprint e

alinhando com o cliente ao final de cada sprint, já no Kanban, o caos é restringido pela limitação

direta da quantidade de trabalho em progresso (WIP – Working in process).

O WIP possui duas funções essenciais, limitar a quantidade de trabalho afetado pela

mudança de prioridades e alinhar o fluxo de trabalho, identificando gargalos e restrições,

controlando o nível de trabalhos intermediários, combinando a maior eficiência e maior

produtividade (BRECHNER, 2015) e (AGILE GUIDE, 2017).

O Método Kanban é usado e aplicável em muitas configurações e permite fluxo contínuo

de trabalho e valor para o cliente, sendo melhor utilizado quando uma equipe ou organização

busca os seguintes itens (AGILE GUIDE, 2017).

Flexibilidade.

Foco na entrega contínua.

29

Maior produtividade e qualidade.

Maior eficiência.

Foco do membro da equipe.

Variabilidade na carga de trabalho.

Redução de resíduos.

2.2.5 SCRUMBAN

De acordo com o Agile Guide (2017), o Scrumban é uma abordagem ágil originalmente

projetada como uma forma de transição do Scrum para o Kanban. Ela se tornou uma estrutura

híbrida, onde as equipes usam Scrum como estrutura e Kanban para melhoria de processos.

Como visto no item 2.2.1, no Scrum é selecionado o trabalho que será realizado o sprint,

e então o bloqueia, inicia-se o trabalho e após algumas semanas (duração normal do sprint) a

fila está vazia e pode-se iniciar um novo ciclo de sprint.

FIGURA 10 – Visão geral método Scrum

Fonte: PONOMAREFF, 2011

No Kanban, o tamanho das filas é limitado, chamado de limite de WIP, isso significa que

pode ser alterado os itens nas filas a qualquer momento, e que não há "final da sprint", o trabalho

continua fluindo (PAHUJA, 2015).

30

De acordo ainda com Pahuja (2015), no Scrumban, o planejamento de iteração pode ser

realizado em intervalos regulares, sincronizados com revisão e retrospectiva, mas o objetivo do

planejamento é sempre preencher os espaços disponíveis, isso não significa preencher todos os

slots e determinar o número de slots, mas sim otimiza-los ao máximo, reduzindo em muito a

sobrecarga e a cerimônia do planejamento de iteração.

O tempo gasto no processamento em lote pode ser substituído por uma inspeção de

controle de qualidade no momento em que o trabalho é promovido para a fila pronta, se um

item de trabalho for reprovado, será devolvido, e uma análise de causa raiz com plano de ação

será gerada (PAHUJA, 2015).

FIGURA 11 – Visão geral método Scrumban

Fonte: PONOMAREFF, 2011

No Scrumban, o trabalho é organizado em pequenos sprints e aproveita o uso de quadros

kanban, como visto anteriormente para visualizar e monitorar o trabalho. As histórias são

colocadas no quadro Kanban e a equipe gerencia seu trabalho usando limites de trabalho em

andamento (AGILE GUIDE, 2017). Dessa forma é formado o modelo do quadro Scrumban é

demonstrado na figura 12.

31

FIGURA 12 – Modelo quadro Scrumban

Fonte: PONOMAREFF, 2011

Reuniões diárias são realizadas para manter a colaboração entre a equipe e solucionar

possíveis impedimentos. Não há papéis pré-definidos no Scrumban, a equipe mantém seus

papéis atuais.

De acordo com o Agile Guide (2017), um gatilho de planejamento é definido na equipe,

justamente para saber quando planejar em seguida, isso ocorrerá normalmente quando o nível

de trabalho em andamento é menor que um limite predeterminado.

Eylean (2018a) cita alguns passos para a aplicação do Scrumban, sendo eles:

Criar o quadro

Desenvolver o plano de atividades

Analisar as histórias de usuários que serão trabalhadas naquela iteração

Priorizar o trabalho

Iniciar a iteração

Definir gatilho de planejamento

Finalizar e triar novos atividades

Na figura 13 é apresentado uma comparação básica entre os métodos SCRUM,

KANBAM e SCRUMBAN.

32

FIGURA 13 – Comparação Scrum x Kanban x Scrumban

Fonte: EYLEAN, 2018a

2.2.6 FEATURE-DRIVEN DEVELOPMENT - FDD

Segundo o Agile Guide (2017), o desenvolvimento orientado por recursos (FDD) foi

desenvolvido para atender às necessidades específicas de um grande projeto de

desenvolvimento de software.

De acordo com Prikladnicki (2014), um projeto de desenvolvimento orientado a recursos

é organizado em torno de cinco processos ou atividades, que são executados iterativamente,

sendo eles:

Desenvolver um modelo abrangente

Criar uma lista de funcionalidades

Planejar por funcionalidade

Detalhas por funcionalidade

Construir por funcionalidade

33

O fluxo de ciclo de vida e a interação desses cinco processos é ilustrada na Figura 14 e

15 abaixo.

FIGURA 14 – Ciclo de vida projeto FDD – AGILE GUIDE

Fonte: AGILE GUIDE, 2017

FIGURA 15 – Ciclo de vida projeto FDD

Fonte: PRIKLADNICKI, 2014

O FDD reconhece oito práticas fundamentais recomendadas de engenharia de software,

para garantia da qualidade do processo e do produto (PRIKLADNICKI, 2014), sendo elas:

Modelagem de objetos do domínio,

Desenvolvimento por funcionalidade

Posse individual de classe

Equipes de funcionalidades

34

Inspeções

Gestão de configuração

Montagens frequentes

Relatório e visibilidade de resultados

Em um projeto FDD há seis funções principais em que os indivíduos podem assumir uma

ou mais dos seguintes cargos (AGILE GUIDE, 2017):

Gerente de projeto

Arquiteto chefe

Gerente de desenvolvimento

Programador chefe

Proprietário da classe

Domain expert

35

3. ANÁLISE COMPARATIVA DOS PROCESSOS E ÁREAS DE CONHECIMENTO DO PMBOK E MÉTODOS ÁGEIS

No sentido de comparar os métodos ágeis apresentados e o PMBOK (PMI, 2014), foi criado a tabela 5 com a divisão por áreas de

conhecimento e respectivos processos, similar ao disposto no PMBOK (PMI, 2014), por ser conhecido e formalmente documentado, no intuito de

facilitar o entendimento e a comparação.

TABELA 5 – Comparação PMBOK e Métodos Ágeis

PMBOK

MÉTODOS ÁGEIS

XP SCRUM FDD KANBAN SCRUM /

XP HYBRID SCRUMBAN

Gerenciamento da Integração do Projeto

Desenvolver o termo

de abertura do

projeto.

Desenvolver o plano

de gerenciamento do

projeto.

Orientar e gerenciar

o trabalho do projeto.

Monitorar e controlar

o trabalho do projeto.

Realizar o controle

integrado de

mudanças.

Encerrar o projeto ou

a fase.

Integração do

software tão breve

quanto possível e o

mais frequente

possível (mais

relacionado com o

código do

software).

Código coletivo

proprietário.

Medição de

velocidade do

projeto.

Sprint backlog

Conjunto de

cerimonias/reuniões.

Sprint burndown

Chart.

Atividades de

revisão/higienização

do Product backlog.

Sprint review.

Sprint restrospective

Forte procedimento

de gerenciamento da

mudança com o

product e Sprint

backlog

Desenvolvimento

do modelo geral

do sistema.

Quadro com os

Itens de trabalho

(WI – Work Itens).

Classes de serviço

e tipos de WI.

Limites WIP (Work

in Process)

Ciclo de tempo e

tempo de espera.

Sprint

backlog /

Simple Design

Sprint review.

Sprint

restrospective

Sprint

burndown

Chart.

Atividades de

revisão/higien

ização do

Product

Backlog /

Simple Design

Scrunbam

backlog

Quadro

Scrumban

Limites WIP

Ciclo de tempo

Tempo médio do

ciclo

Reunião - Short

Kaizen event

Novos itens são

permitidos

durante as

iterações/sprint

sempre que a fila

permitir

36

PMBOK

MÉTODOS ÁGEIS

XP SCRUM FDD KANBAN SCRUM /

XP HYBRID SCRUMBAN

Gerenciamento do Escopo do Projeto

Planejar o

gerenciamento do

escopo.

Coletar os requisitos.

Definir o escopo.

Criar a estrutura

analítica do projeto

(EAP).

Validar o escopo.

Controlar o escopo.

Histórias de

usuário

Planejamento de

entregas, pequenas

entregas

Modelo de

gerenciamento da

Sprint.

Conjunto de

cerimonias/reuniões.

Modelo de

decomposição do

escopo.

Product backlog

Atividades de

revisão/higienização

do Product backlog.

Sprint planning

Sprint backlog

Sprint review.

Scrum/Reunião

diária

Sprint burndown

Chart.

Desenvolvimento

do modelo

abrangente

(Processo 1)

Construir lista de

funcionalidades

por áreas de

assunto (Processo

2)

Modelo de

Gerenciamento do

Fluxo

Regras quadro

Kanban

Classes de serviço

e tipos de WI.

Modelo de

decomposição do

escopo.

Backlog WI.

Atividades de

revisão/higienizaçã

o do Product

backlog.

Priorização

Quadro com os

Itens de trabalho

Definição de Feito

Coluna de

Validação ou teste.

Modelo de

gerenciament

o da Sprint

(Teste,

Programação

em par e

códigos

padrões).

Modelo de

decomposição

do escopo.

Product

Backlog /

Simple Design

Sprint

planning /

Simple Design

/ Histórias de

usuário

Sprint review.

Scrum/Reuniã

o diária

Sprint

burndown

Chart.

Planejamento sob

demanda para

novas tarefas

Modelo de

Gerenciamento

do Fluxo / Sprint.

Modelo de

decomposição do

escopo.

Limites WIP

Scrumban

backlog.

Quadro

Scrumban

Priorização

Reunião - Short

Kaizen event

Tempo médio do

ciclo

37

PMBOK MÉTODOS ÁGEIS

XP SCRUM FDD KANBAN

SCRUM /

XP HYBRID SCRUMBAN

Gerenciamento do Tempo do Projeto

Planejar o

gerenciamento do

cronograma.

Definir as atividades.

Sequenciar as

atividades.

Estimar os recursos

das atividades.

Estimar as durações

das atividades.

Desenvolver o

cronograma.

Controlar o

cronograma.

Planejamento de

entregas

Plano de Iterações

Modelo de

gerenciamento da

Sprint.

Conjunto de

cerimonias/reuniões.

Modelo de

decomposição de

atividades.

Sprint planning

Sprint backlog

Pontos de Estória

Sprint burndown

Chart.

Velocidade

Scrum/Reunião

diária

Determinar a

sequência de

desenvolvimento

(Processo 3)

Atribuir

atividades do

negócio para os

programadores

chefe (Processo

3)

Atribuir classes

para os

desenvolvedores

(Processo 3)

Pacote trabalho

programador

chefe

Modelo de

Gerenciamento do

Fluxo

Modelo de ciclo de

tempo e tempo de

espera

Definição dos

limites do WIP

Classes de serviço

e tipos de WI.

Backlog WI.

Quadro com os

Itens de trabalho

Limites WIP

Tempo médio de

ciclo e espera

Modelo de

gerenciament

o da Sprint

(Teste,

Programação

em par e

códigos

padrões).

Modelo de

decomposição

de atividades.

Sprint

planning /

Plano de

Iterações

Sprint

backlog

Pontos de

Estória

Sprint

burndown

Chart.

Velocidade

Scrum/Reuniã

o diária

Trabalho

contínuo com

ciclos curtos para

planejamento e

ciclos mais

longos para

liberação

Modelo de

Gerenciamento

do Fluxo / Sprint.

Scrumban

backlog.

Planejamento sob

demanda para

novas tarefas

Quadro

Scrumban

Limites WIP

Tempo médio de

ciclo

Reunião - Short

Kaizen event

38

PMBOK

MÉTODOS ÁGEIS

XP SCRUM FDD KANBAN SCRUM /

XP HYBRID SCRUMBAN

Gerenciamento dos Custos do Projeto Planejar o

gerenciamento dos

custos.

Estimar os custos.

Determinar o

orçamento.

Controlar os custos.

Não disponível Modelo de

gerenciamento da

Sprint.

Conjunto de

cerimonias/reuniões

Sprint backlog

Sprint planning

Velocidade

Product backlog

Sprint burndown

Chart.

Estimativa do custo

da entrega durante

fase de

planejamento.

Não disponível Modelo de

Gerenciamento do

Fluxo

Modelo de ciclo de

tempo e tempo de

espera

Classes de serviço

e tipos de WI.

Quadro com os

Itens de trabalho

Tempo médio de

ciclo e espera

Modelo de

gerenciament

o da Sprint.

Conjunto de

cerimonias/re

uniões

Sprint

backlog

Sprint planning

Velocidade

Product

backlog

Sprint

burndown

Chart

Modelo de

Gerenciamento

do Fluxo / Sprint.

Reunião - Short

Kaizen event

Ciclo de tempo

Scrumban

backlog.

Planejamento sob

demanda para

novas tarefas

Quadro

Scrumban

Tempo médio do

ciclo

Gerenciamento da Qualidade do Projeto Planejar o

gerenciamento da

qualidade.

Realizar a garantia

da qualidade.

Controlar a

qualidade.

Ênfase no teste

(unidade,

aceitação)

Baseado na

simplicidade

Uso de projetos

padrões

Modelo de

gerenciamento da

Sprint.

Conjunto de

cerimonias/reuniões

Sprint review

Sprint retrospective

Sprint burndown

Chart.

Reunião de

revisão (todos os

processos)

Inspeção do

código e teste da

unidade

(Processo 5)

Modelo de

Gerenciamento do

Fluxo

Modelo de ciclo de

tempo e tempo de

espera

Ciclo de tempo e

tempo de espera.

Ênfase no

teste

Baseado na

simplicidade

Uso de

projetos

padrões

Sprint review

Sprint

retrospective

Sprint

burndown

Chart.

Modelo de

Gerenciamento

do Fluxo / Sprint.

Reunião - Short

Kaizen event

Tempo médio do

ciclo

39

PMBOK

MÉTODOS ÁGEIS

XP SCRUM FDD KANBAN SCRUM /

XP HYBRID SCRUMBAN

Gerenciamento dos Recursos Humanos do Projeto

Planejar o

gerenciamento dos

recursos humanos.

Mobilizar a equipe

do projeto.

Desenvolver a equipe

do projeto.

Gerenciar a equipe

do projeto.

Rotação de pessoas

para várias

posições

Programação em

par

Boas condições de

trabalho (sem horas

extras)

Habilidades

necessárias

Nomear time

multidisciplinar

Regras

Tamanho do time

Conjunto de

cerimonias/reuniões

Time auto

organizado

Sprint retrospective

Nomear time de

modelagem

(Processo 1)

Nomear time de

lista de

funcionalidades

(Processo 2)

Nomear time de

planejamento e

funcionalidades

(Processo 3)

Habilidades

necessárias

Tamanho do time

Time auto

organizado

Habilidades

necessárias

Nomear time

multidisciplin

ar

Regras

Programação

em par

Sem horas

extras

Time auto

organizado

Sprint

retrospective

Especialização ou

preferência para

as tarefas

Suporta várias

equipes

proprietárias

Time auto

organizado

Reunião - Short

Kaizen event

Gerenciamento das Comunicações do Projeto

Planejar o

gerenciamento das

comunicações.

Gerenciar as

comunicações.

Controlar as

comunicações.

Clientes sempre

disponíveis

Reuniões diárias

Conjunto de

cerimonias/reuniões

Stakeholders

Sprint burndown

Chart.

Regra proprietário

produto

Regra Scrum Master

Reunião de

revisão (todos os

processos)

Stakeholders

Modelo de ciclo de

tempo e tempo de

espera

Ciclo de tempo e

tempo de espera.

Clientes

sempre

disponíveis

Conjunto de

cerimonias/re

uniões

Sprint

burndown

Chart.

Regra

proprietário

produto

Reunião - Short

Kaizen event

Stakeholders

Tempo médio do

ciclo

Regra

proprietário

produto

40

PMBOK

MÉTODOS ÁGEIS

XP SCRUM FDD KANBAN SCRUM /

XP HYBRID SCRUMBAN

Gerenciamento dos Riscos do Projeto

Planejar o

gerenciamento dos

riscos.

Identificar os riscos.

Realizar a análise

qualitativa dos

riscos.

Realizar a análise

quantitativa dos

riscos.

Planejar as respostas

aos riscos.

Controlar os riscos.

Cria protótipo para

limitar o risco

Avaliação inicial dos

riscos durante o

pregame (fase

anterior ao início do

sprint)

Conjunto de

cerimonias/reuniões

Não disponível Contingência do

risco

Avaliação

inicial dos

riscos durante

o pregame

(fase anterior

ao início do

sprint)

Conjunto de

cerimonias/re

uniões /

Contingência

do risco

Avaliação inicial

dos riscos /

contigência

Reunião - Short

Kaizen event

Gerenciamento das Aquisições do Projeto

Planejar o

gerenciamento das

aquisições.

Conduzir as

aquisições.

Controlar as

aquisições.

Encerrar as

aquisições.

Não disponível Não disponível Não disponível Não disponível Não

disponível

Não disponível

41

PMBOK

MÉTODOS ÁGEIS

XP SCRUM FDD KANBAN SCRUM /

XP HYBRID SCRUMBAN

Gerenciamento das Partes Interessadas do Projeto

Identificar as partes

interessadas

Planejar o

gerenciamento das

partes interessadas.

Gerenciar o

engajamento das

partes interessadas.

Controlar o

engajamento das

partes interessadas.

Stakeholders

Histórias de

usuário

Clientes sempre

disponíveis,

feedbacks

constantes

Stakeholders

Conjunto de

cerimonias/reuniões

Regra proprietário

produto

Proprietário produto

Scrum Master

Stakeholders

Alinhar os

requisitos com o

cliente.

Stakeholders

Modelo de

Gerenciamento do

Fluxo

Modelo de ciclo de

tempo e tempo de

espera

Classes de serviço

e tipos de WI.

Ciclo de tempo e

tempo de espera.

Stakeholders

Histórias de

usuário

Clientes

sempre

disponíveis,

feedbacks

constantes

Conjunto de

cerimonias/re

uniões

Regra

proprietário

produto

Proprietário

produto

Stakeholders

Modelo de

Gerenciamento

do Fluxo / Sprint.

Ciclo de tempo

Tempo médio do

ciclo

Regra

proprietário

produto

Proprietário

produto

Fonte: PMI, 2014; FITSILIS, 2008; TEIXEIRA,2013; SOARES,2004b; EYLEAN, 2018b; DARWISH,2014.

42

Analisando a tabela 5 pode-se observar que os métodos ágeis não definem as

características necessárias para cobrir todos os aspectos do gerenciamento de projeto

tradicional, neste caso utilizando como referência o guia PMBOK (PMI, 2014).

Segundo Fitsilis (2008) esta situação era parcialmente esperada, pois os processos

relacionados ao gerenciamento tradicional são totalmente descritos e definidos, ao contrário do

que é realizado com os métodos ágeis, sendo considerados empíricos.

De acordo ainda com Fitsilis (2008) os métodos ágeis claramente possuem uma ênfase

nas seguintes áreas do conhecimento:

Gerenciamento do Escopo, com ênfase no gerenciamento dos requisitos.

o Segundo Ribeiro; Arakaki (2006) no gerenciamento tradicional tem se o

objetivo de detalhar todo o escopo no início do projeto, com a WBS (Work

Breakdown Structure), já no gerenciamento ágil o detalhamento é em alto

nível, para entendimento das necessidades do negócio e do trabalho.

Gerenciamento dos Recursos Humanos, com ênfase no time de trabalho,

confiança.

Gerenciamento da Qualidade, na maioria das vezes não formalmente

documentados, porém com o uso de padrões, testes e revisões frequentes.

Da mesma forma os métodos ágeis não apresentam uma ênfase nas seguintes áreas do

conhecimento:

Gerenciamento do Risco, não sendo gerenciado explicitamente.

o De acordo Soares (2004a), no XP, por exemplo, não existe a

preocupação formal em fazer a análise e o planejamento de riscos.

Gerenciamento dos custos, sendo realizadas apenas estimativas durante a fase de

planejamento.

o Conforme Ribeiro; Arakaki (2006) no gerenciamento tradicional as

modificações são críticas e impactam todo o projeto, no gerenciamento

ágil as modificações são incorporadas nas próprias iterações e alinhada

com o cliente, possuindo maior flexibilidade, porém com a abertura para

de uma variação significativa para o custo final.

Gerenciamento das Aquisições, não incorporado as metodologias ágeis.

o Segundo Ribeiro; Arakaki (2006) processo de aquisição é evitado pela alta

volatilidade dos requisitos, baixo nível de documentação e presença do

cliente no time de projeto.

43

A tabela 6 apresenta um quadro resumo/comparativo entre o gerenciamento de projetos

tradicional e ágil, considerando as áreas de conhecimento do PMBOK (PMI, 2014).

TABELA 6 – Quadro resumo/comparativo entre o gerenciamento tradicional e ágil

Fonte RIBEIRO; ARAKAKI, 2006

44

4. ABORDAGENS HÍBRIDAS DE TRABALHO

Segundo Couto (2016), uma união entre as metodologias é possível e benéfica, trazendo

vantagens competitivas. Na mesma linha de raciocínio Fitsilis (2008) indica que a conexão do

PMBOK com as metodologias Ágeis beneficiará a comunidade de gerenciamento de projetos

de software.

Couto (2016) identificou que existem três abordagens para o uso conjunto dos métodos

ágeis e o PMBOK, sendo elas:

Abordagens ágeis com segmentos do PMBOK (maior aplicação dos métodos

ágeis e menor aplicação do PMBOK)

Abordagens híbridas com o uso equilibrado do PMBOK e métodos ágeis.

Abordagens PMBOK com segmentos do ágeis (maior aplicação do PMBOK e

menor aplicação dos métodos ágeis)

A figura 16 ilustra as diferenças de cada abordagem

FIGURA 16 – Abordagens híbridas

Fonte: COUTO, 2016

Nos próximos subcapítulos são apresentados alguns métodos híbridos unificando o

PMBOK à métodos ágeis específicos.

45

4.1 PMBOK + SCRUM

A figura 17 demonstra a união do ciclo de vida do método Scrum com o ciclo de vida do

grupo de processos do Guia PMBOK, integrando neste novo método os pontos fortes de ambos

os métodos para redução das fraquezas e limitações CRUZ (2013).

FIGURA 17 – Ciclo de vida Scrum + Guia PMBOK

Fonte: CRUZ, 2013

Todos os grupos de processos do PMBOK (Iniciação, Planejamento, Execução,

Monitoramento e Controle, Encerramento) são considerados neste novo método, partindo da

iniciação e chegando ao seu encerramento, incluindo alguns dos processos contemplados no

PMBOK e que se encaixam ao novo método em conjunto com o Scrum.

A figura 18 apresenta o ciclo de vida de projeto do Scrum associado ao PMBOK com a

descrição dos processos e atividades relacionadas.

FIGURA 18 – Ciclo de vida projeto com Scrum + Guia PMBOK

Fonte: CRUZ, 2013

46

De acordo com Cruz (2013), todas as cerimonias do Scrum foram utilizadas nesta

metodologia híbrida, além de permitir que inúmeros processos do PMBOK fossem utilizados.

Para facilitar a compreensão foram divididos a explicação pelos itens de conexão de ambos os

métodos.

A figura 19 apresenta o ponto de conexão do grupo de processo de iniciação, neste item

ainda o Scrum não está presente, é utilizado apenas as boas práticas do PMBOK, incluindo o

desenvolvimento do Termo de Abertura, alocação do gerente de projeto, realização do Kick-off

do projeto e identificação dos principais stakeholders.

FIGURA 19 – Grupo processo Iniciação - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

Após a etapa de Iniciação o grupo de processo planejamento é incorporado utilizando as

boas práticas do PMBOK, adicionando os planos do projeto, comunicações, riscos, qualidade

e aquisições (primeiras aquisições e contratações). Nesta fase ainda apenas o GP (Gerente de

Projeto) é o único integrante do projeto a estar envolvido. A figura 20 demostra o ponto de

conexão

FIGURA 20 – Grupo processo Planejamento - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

47

Posteriormente a realização do planejamento inicial, pode desencadear o planejamento

do backlog, nesta fase o PO (product owner) preocupa-se com o entendimento e detalhamento

do escopo que irá compor backlog da primeira entrega e que será fornecido para realização do

Sprint. Este fluxo de análise é realizado a cada ciclo até ao encerramento do projeto (CRUZ,

2013).

Adicionalmente nesta fase o PO e o GP realizam os seguintes processos (Figura 21):

Coletar os requisitos

Definir escopo

Estimar os recursos das atividades

Definir o time do projeto

Estimar os custos

Determinar o orçamento

Nesta fase fica claro a utilização tanto do Scrum quanto do PMBOK, neste ponto o escopo

toma forma das histórias de usuário, com o detalhamento através das especificações e

protótipos, sendo que tais especificações são enviadas ao cliente para revisão e aprovação antes

de iniciar o desenvolvimento/produção (CRUZ, 2013).

FIGURA 21 – Planejamento Backlog - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

Como apresentado na figura 22, no planejamento da Sprint o time Scrum já está

incorporado ao projeto para definição das atividades, estimar a duração das

atividades/atualização do cronograma e identificação/atualização dos riscos.

48

O PO fica encarregado das informações de qualidade desejadas pelo cliente, e o GP com

as informações obtidas pode desenvolver o cronograma, planejar o gerenciamento das

mudanças e enviar ao cliente para revisão e aprovação.

FIGURA 22 – Planejamento da Sprint - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

Encerrando a fase de planejamento inicia-se a fase de execução (Figura 23),

monitoramento e controle (através da realização das reuniões diárias). Nesta fase o

Scrummaster é inserido na equipe para juntamente com o GP conduzir/otimizar o trabalho do

time em cada ciclo das sprints. O GP ainda é responsável por conduzir aquisições que possam

vir a ser necessárias devido a alteração do escopo, desenvolver relatórios de situação,

comunicações e gerenciamento dos stakeholders, já o PO fica alerta a possíveis mudanças para

o gerenciamento integrado das mudanças.

FIGURA 23 – Execução - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

49

Durante a sprint o GP fica responsável pelos seguintes processos e controles, também

apresentados na figura 24.

Controlar o envolvimento dos stakeholders

Monitorar e controlar o trabalho do projeto

Controlar as mudanças

Controlar o escopo

Controlar o cronograma

Controlar custos

FIGURA 24 – Monitoramento e Controle - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

Na reunião de revisão do Sprint (Figura 25) as seguintes atividades são realizadas:

Apresentação dos incrementos dos produtos finalizados e prontos

Aprovação/Aceitação do PO/cliente

Solicitações de mudanças para os produtos reprovados

É importante observar que todos os integrantes do projeto, incluindo o time do cliente

participam desta etapa do projeto (CRUZ, 2013).

50

FIGURA 25 – Reunião de Revisão - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

A reunião de retrospectiva (Figura 26) é conduzida pelo Scrummaster com a

participação de todo o time, incluindo o GP. Além de buscar a melhoria continua esta reunião

alimenta o GP para a realização das seguintes atividades:

Gerenciar as comunicações

Controlar as comunicações

Controlar os riscos

Gerenciar a Equipe do Projeto

Registrar as lições aprendidas

FIGURA 26 – Reunião de Retrospectiva - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

No encerramento da fase (Figura 27), o PO e o GP participam desta fase realizando as

seguintes atividades:

Validação do escopo com o cliente

51

Efetuar a finalização formal da fase após o aceite final da etapa.

Encaminhar solicitações de mudança

Controlar as aquisições (Encerrar se necessário)

FIGURA 27 – Encerramento da Fase - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

Após o termino da última Sprint e incremento com aprovação do cliente e finalização

de todos os treinamentos, o GP pode encerrar o projeto, realizando algumas atividades:

Arquivamento dos aceites finais do projeto

Entrega dos manuais de utilização e documentação do projeto

Repasse da tecnologia para todas as áreas afins

Registro das lições aprendidas

FIGURA 28 – Encerramento do Projeto - Scrum + Guia PMBOK

Fonte: CRUZ, 2013

Desta forma, um projeto onde utiliza-se as boas práticas do PMBOK e do Scrum é

finalizado.

52

É importante ressaltar que em projetos de maior porte, um número maior de conexões

conforme descrito acima é necessário, exigindo maior aprofundamento em processos/áreas

específicas, porém em outros projetos de menor porte o funcionamento do PMBOK associado

ao Scrum pode ser limitado a menos conectores, com uma necessidade mais superficial (CRUZ,

2013).

4.2 XPOKs

Outro método hibrido que pode ser descrito é o XPOKs, que combina o Kanban, o

Outsystem (método muito similar ao Scrum não abordado neste trabalho), o próprio Scrum, XP

e as boas práticas do PMBOK. Sendo aplicada a pequenas e médias empresas de

desenvolvimento de Software que utilizem o Scrum e Kanban (SOUSA, 2018).

O XPOKs contempla três etapas, sendo:

Início

Ciclos de Desenvolvimento

Fechamento

O Ciclo de vida do XPOKs é ilustrado na figura 29

FIGURA 29 – Ciclo de vida método XPOKs

Fonte: SOUSA, 2018

53

Conforme ilustrado na figura 30, na etapa de Início são criadas as histórias do projeto e

transformadas nos itens presentes no Product backlog, com isto tem-se uma visão do produto.

Nesta fase a equipe de desenvolvimento trabalha na definição da arquitetura e das boas práticas,

no intuito de padronizar todas as atividades do time, além de realizar o termo de abertura e kick-

off, item originado do guia PMBOK (SOUSA, 2018).

FIGURA 30 – Etapa de Início - método XPOKs

Fonte: SOUSA, 2018

Os ciclos de desenvolvimento são constituídos por vários sprints, unindo em cada sprint

o método Scrum e o método XP. A figura 31 apresenta esta fase diferenciando o Scrum (na cor

laranja) e o XP (na cor azul).

Os métodos podem ser utilizados nesta fase em sua maioria, porém não é obrigatório a

aplicação de todas técnicas, técnicas como o pair programming e refactoring devem ser

utilizadas quando realmente necessárias, em itens importantes e de complexidade reconhecidas

(SOUSA, 2018).

54

FIGURA 31 – Etapa dos ciclos de desenvolvimento - método XPOKs

Fonte: SOUSA, 2018

Ainda na etapa dos ciclos de desenvolvimento dois eventos são considerados, sendo eles:

Demo

o Onde ocorre a apresentação do resultado da Sprint ao cliente

o Onde os feedbacks (melhorias e mudanças) são obtidos e transferidos ao

product backlog.

Retrospectiva

o Evento em que o time realiza uma autoanalise e consequentemente uma

autocrítica, com sugestões de melhoria.

De acordo com Souza (2018), a etapa de fechamento pode ser realizada em dois sprints:

Primeiro Sprint

o Etapa de estabilização, por não efetuar o planejamento da Sprint, o

backlog do produto é origem direta do trabalho, sendo entregue ao cliente

com a periodicidade que agregar maior valor.

Segundo Sprint:

o Indica à formação acompanhada pela equipa de desenvolvimento.

A fase de fechamento é ilustrada na figura 32.

55

FIGURA 32 – Etapa do fechamento - método XPOKs

Fonte: SOUSA, 2018

O XPOKs pretende seguir a filosofia proposta pela metodologia Kanban, com o ajuste

dos processos de acordo com as necessidades, dessa forma, a adoção do XPOKs não

necessariamente aponta sua utilização na íntegra. A etapa de fechamento do XPOKs pode ser

aplicada em projetos onde não é possível estimar a quantidade de trabalho, normalmente em

projetos de manutenção corretiva ou evolutiva (SOUSA, 2018).

O método apresenta os seguintes valores e princípios:

Começar com o que existe

Mudança continua e incremental

Regras bem definidas

Reflexão

Passos pequenos

Máximo 15 minutos para resolução de uma dificuldade, posteriormente acionar

cadeia de ajuda

Resumir em 120 caracteres os problemas, para facilitar o entendimento e

participação do time.

Humanidade

Feedback

Documentação

56

O XPOKs contempla os seguintes eventos:

Kick-off

Sprint

Planejamento da sprint

Reuniões diárias

Demo

Retrospectiva da sprint

Tais práticas e artefatos são parte do método:

Product Backlog

Visão do produto

Termo de abertura

História de usuário

Modelo de arquitetura

Sprint Backlog

Visão da Sprint

Documentação

Incremento

Projeto simples

Testes

Refactoring

Pair programming

Propriedade coletiva

Integração continua

Padrões de desenvolvimento

Segundo Souza (2018) os papéis e responsabilidades foram herdados e adaptados das

metodologias Scrum, Outsystems e XP, sendo divididos em dois grupos: cliente e time de

desenvolvimento.

Cliente

o Patrocinador

o Utilizadores chave

o Responsável da TI (Tecnologia da Informação)

57

Time de desenvolvimento

o Engagement Manager (EM)

o Team Leader (TL)

o Developer

o Qualidade

A figura 33 apresenta as influências que o XPOKs recebeu de cada metodologia, partindo

do XP, incorporando o Outsystems, Kanban, Scrum e algumas recomendações do PMBOK.

FIGURA 33 – Base método XPOKs

Fonte: SOUSA, 2018

O XPOKs possui as caraterísticas dos modelos ágeis com algumas boas práticas do

PMBOK, apresentando-se como uma alternativa em projetos que requerem rigor na sua

execução, com o envolvimento constante do cliente em todas as entregas frequentes (SOUSA,

2018).

58

5. CONCLUSÕES

Inicialmente foi realizado um estudo apresentando os conceitos principais do PMBOK

e dos principais métodos ágeis, sendo eles o SCRUM, Extreme Programming (XP),

SCRUM/XP HYBRID, KANBAN, SCRUMBAN e Feature-Driven Development (FDD).

Posteriormente foi realizada uma análise comparativa dos processos e área de

conhecimento do PMBOK com os métodos ágeis no gerenciamento de projetos de software,

identificando os gaps, diferenças e similaridades.

Foi constatado que os métodos ágeis permitem o desenvolvimento rápido e com

qualidade de software, reduzindo a burocracia, com um processo orientado a mudanças e

planejamento simples, porém não apresentam todas as caraterísticas necessárias para cobrir

todos os aspectos e peculiaridades presentes em cada negócio e consequentemente a cada novo

projeto para desenvolvimento de software, como o gerenciamento dos riscos, aquisições e

custos.

Dessa forma, as duas linhas de trabalho possuem os mesmos objetivos, concluir o

projeto de software com a qualidade definida, no prazo e com a otimização dos recursos. Ajustar

e unir estas duas metodologias é o grande diferencial para conquistar a excelência no

desenvolvimento do projeto de software.

No intuito de apresentar possíveis soluções este trabalho descreveu métodos híbridos

(Scrum + Guia PMBOK e XPOKs) como solução para muitas empresas, atendendo melhor suas

necessidades.

Além disso, este trabalho abrangeu os principais métodos ágeis em apenas um

documento, tornando-se um diferencial diante de pesquisas bibliográficas realizadas até o

momento, aonde os temas são subdivididos e não abordados de forma abrangente, para um

entendimento comum e de mais fácil interpretação para o leitor.

59

Este trabalho permitiu unir todo o conhecimento técnico adquirido durante o curso,

visualizando claramente todas as áreas de conhecimento, grupos de processo e etapas utilizadas

no gerenciamento de projetos tradicionais e de software, bem como as dificuldades enfrentadas

e possíveis soluções adotadas com as metodologias ágeis e híbrida.

Para trabalhos futuros novos métodos híbridos com uma maior diversidade de soluções

podem ser apresentados para aprofundar e atender as necessidades oriundas do gerenciamento

de projetos de software.

60

REFERÊNCIAS BIBLIOGRÁFICAS

AGILE GUIDE. Agile Practice Guide / Project Management Institute-PMI e Agile

Alliance®. EUA, Pennsylvania: PMI, 2017.

BECK, Kent. Padrões de Implementação / Kent Beck; tradução: Jean Felipe Patikowski

Cheiran; revisão técnica: Marcelo Soares Pimenta. Porto Alegre: Bookman, 2013.

BECK, Kent. Extreme Programming Explained: Embrance Change / Kent Beck with

Cynthia Andres. 2.ed. Boston: Addison-Wesley, 2005.

BECK, K.; CUNNINGHAM, W.; HUNT, A.; MARTIN, R.C; THOMAS, D.; BEEDLE, M.;

FOWLER, M., JEFFRIES, R.; MELLOR, S.; BENNEKUM, A. V.; GRENNING, J.; KERN,

J.; SCHWABER, K.; COCKBURN, A.; HIGHSMITH, J.; MARICK, B.; SUTHERLAND, J.

Manifesto for Agile Software Development, 2001. Disponível em: http://agilemanifesto.org/.

Acesso em: 29/01/2018.

BRECHNER, Eric. Agile Project Management with Kanban / Eric Brechner with a

contribution from James Waletzky. Washington: Microsoft, 2015.

COHN, Mike. Introduction to Scrum PPT. Mountain Goat, Software (Copyright ©1998-

2018). Tradução e adaptação: Cesar Brod. Disponível em:

https://www.mountaingoatsoftware.com/agile/scrum/resources/a-reusable-scrum-presentation.

Acesso em: 08/04/2018.

COUTO, Júlia Mara Colleoni. Métodos Ágeis & PMBOK: Uma Revisão Sistemática da

Literatura sobre o uso de Abordagens Híbridas no Gerenciamento de Projetos de

Software. 2016. Estácio, MBA Gestão de Projetos.

CRUZ, Fábio. Scrum e PMBOK® unidos no Gerenciamento de Projetos. Rio de Janeiro:

Brasport, 2013.

DARWISH, Nagy Ramadan. Enhancements in Scrum Framework Using Extreme

Programming Practices. International Journal of Intelligent Computing and Information

Science, IJICIS, v. 14, n. 2, Abril, 2014. p. 53-67.

EYLEAN Board. The Ultimate Agile Guide, Based on experiences by Eylean. 2018a.

Disponível em: https://www.subscribepage.com/agileguide . Acesso em: 26/05/2018.

EYLEAN Board. Whitepaper - Scrum vs Kanban vs Scrumban, Based on experiences by

Eylean. 2018b. Disponível em:

https://www.eylean.com/Publications/DownloadPublication/4e93cecc-4cb2-4e3f-849d-

810d7aea33a5?name=Whitepaper---Scrum-vs-Kanban-vs-Scrumban . Acesso em:

04/06/2018.

FITSILIS, Panos. Comparing PMBoK and Agile Project Management software development

processes. In: Advances in Computer and Information Sciences and Engineering.

Netherlands: Springer, p. 378-383, 2008.

61

GARCÍA RODRÍGUEZ, Manuel José. Estudio comparativo entre las metodologías ágiles y

las metodologías tradicionales para la gestión de proyectos software. 2015. Universidad de

Oviedo, Máster Universitario en Dirección de Proyectos. Disponível em:

http://hdl.handle.net/10651/32457 Acesso em: 26/05/2018.

LADAS, Corey. Scrumban And Other Essays on Kanban Systems for Lean Software

Development. Seattle: Modus Cooperandi, 2008.

MUSA, Farrukh; TARIQ, Muhammad Ali. Agile Methodology: Hybrid Approach Scrum and

XP. International Journal of Scientific & Engineering Research, v. 8, n. 4, Abril, 2017. p.

1405-1409.

PAHUJA, Savita, What is Scrumban? Outubro, 2015. Disponível em:

https://www.agilealliance.org/what-is-scrumban/ Acesso em: 20/05/2018.

PONOMAREFF, Dimitri. Scrum vs. Kanban. Julho, 2011. Disponível em:

https://www.slideshare.net/dimka5/scrum-vs-scrumban-8728461 Acesso em: 20/05/2018.

PMI. PMBOK - Um Guia do Conhecimento em Gerenciamento de Projetos (Guia

PMBoK®) / Project Management Institute - PMI. 5.ed. São Paulo: Saraiva, 2014.

PRIKLADNICKI, Rafael; WILLI, Renato; MILANI, Fabiano. Métodos Ágeis para

desenvolvimento de software. Porto Alegre: Bookman, 2014.

RIBEIRO, André Luiz Dias; ARAKAKI, Reginaldo. Gerenciamento de Projetos Tradicional x

Gerenciamento de Projetos Ágil: Uma análise comparativa. 3º Congresso Internacional de

Gestão de Tecnologia e Sistemas de Informação e 11th World Continuos Auditing

Conference. São Paulo, 2006.

SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum. Novembro, 2017. Disponível

em: http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-

Brazilian.pdf . Acesso em: 18/02/2018.

SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o

Desenvolvimento de Software. INFOCOMP – Journal of Computer Science, v. 3, n. 2,

2004a. p. 8-13.

SOARES, Michel dos Santos. Metodologias Ágeis Extreme Programming e Scrum para o

Desenvolvimento de Software. Revista Eletrônica de Sistema de Informação - RESI, v. 3,

n. 1, 2004b. p. 1-8.

SOUSA, João. Estudo comparativo das Metodologias ágeis e PMBOK. 2018. Escola

Superior de Tecnologia e Gestão de Viseu - Instituto Politécnico de Viseu, dissertação de

mestrado em Sistemas e Tecnologias de Informação para as Organizações.

STATE OF AGILE. The 11th annual State of AGILETM report. VersionOne® – Agile Made

Easier, 2017.

SUTHERLAND, Jeff. Scrum: A arte de fazer o dobro do trabalho na metade do tempo;

tradução Nina Lua. 2.ed. São Paulo: Leya, 2016.

62

TEIXEIRA, Bruno Afonso. Agile and traditional project management : bridge between two

worlds to manage IT projects. 2013. Universidade do Minho, dissertação de mestrado em

Engenharia e Gestão de Sistemas de Informação. Disponível em:

http://hdl.handle.net/1822/29113 . Acesso em: 26/05/2018.

VARGAS, Letícia Marques. Gerenciamento Ágil de projetos em desenvolvimento de software:

Um estudo comparativo sobre a aplicabilidade do SCRUM em conjunto com PMBOK e/ou

PRINCE2. Revista de Gestão e Projetos – GeP, v. 7, n. 3. 2016. p. 48-60.

VERGARA, S. Projetos e relatórios de pesquisa em administração. São Paulo: Atlas, 1997.