Post on 18-Oct-2021
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.