scrum e pmbok: gerenciamento ágil de projetos
Post on 16-Oct-2021
9 Views
Preview:
TRANSCRIPT
Universidade Federal do Rio de Janeiro
Escola Politécnica
MBA em Governança, Projetos e Serviços de TI
SCRUM E PMBOK: gerenciamento ágil de projetos
Autor:
_________________________________________________
Caroline Mariano Sena
Orientador:
_________________________________________________
Prof Edilberto Strauss, Ph.D.
Examinador(es):
_________________________________________________
Claudio Luiz Latta de Souza, Msc.
_________________________________________________
Prof Edilberto Strauss, Ph. D.
_________________________________________________
Flávio Luis de Mello, DSc.
_________________________________________________
Manoel Villas Bôas Júnior, MSc.
_________________________________________________
Noberto Ribeiro Bellas, MSc.
_________________________________________________
Paulo Fernando Peixoto da Costa Fazzioni, MSc.
MGPS
Maio de 2016
AGRADECIMENTO
Dedico este trabalho aos meus professores que contribuíram de forma
significativa à minha formação e estada nesta Universidade. Agradeço aos meus amigos,
Searle Oliveira, Daniel José Chaves Ferreira e Marcelo Predebon, pela ajuda e
companheirismo nos trabalhos e durante toda essa jornada. Os meus pais, Sidney Zani
Sena e Reginete Mariano Leite Sena, por sempre acreditarem em mim e confiar em
qualquer escolha minha. Ao meu namorado Ítalo Muciaccia Deps Almeida, pela
paciência de sempre, por apoiar e estar ao meu lado sempre. A minha tia Regina
Mariano Leite e prima Beatriz Mariano Leite Duarte, pelas esperas na volta para casa,
por me apoiar e dar suporte nessa jornada. Este projeto é uma pequena forma de retribuir
o investimento e confiança em mim depositados.
RESUMO
Atualmente as empresas enfrentam problemas em gestão de projetos, pois
devido ao aumento das demandas por entregas mais rápidas, as mesmas sentiram a
necessidade de atualizar a forma de gerir projetos. Um projeto é um esforço temporário
empreendido para criar um produto, serviço ou resultado exclusivo (Guia PMBOK®,
2013). O gerenciamento do projeto é a aplicação de conhecimentos, habilidades,
ferramentas e técnicas, às atividades do projeto a fim de atender aos seus requisitos
(Guia PMBOK®, 2013). Sendo assim, as empresas têm buscado de forma incessante o
uso de métodos ágeis e boas práticas de gerenciamento de projetos. Logo o objetivo
desse trabalho é apresentar uma proposta de utilização conjunta das técnicas do Guia
PMBOK®, já consolidadas, com a utilização do framework Scrum.
Palavras-Chave: PMBOK. Scrum. Gerenciamento Ágil. Métodos Ágeis. Gerenciamento
de Projetos.
ABSTRACT
Currently, the companies face problems in project management, since due to
increased demands for faster deliveries, they felt the need to update how to manage their
projects. A project is a temporary endeavor undertaken to create a product, service or
result unique (PMBOK® Guide, 2013). Project Management is the application of
knowledge, skills, tools and techniques to project activities in order to meet your
requirements (PMBOK® Guide, 2013). Thus, the companies have sought incessantly to
use agile methods and best practices for Project Management. In this way, the purpose
of this paper is to present a proposal for joint use of the PMBOK® Guide techniques,
already consolidated, using the SCRUM framework.
Keywords: PMBOK. Scrum. Agile Management. Agile Methods. Project Management.
SIGLAS
UFRJ – Universidade Federal do Rio de Janeiro
PMBOK – Project Management Body of Knowledge
PMI – Project Management Institute
TAP – Termo de Abertura
PO – Product Owner
GP – Gerente de Projetos
SM – Scrum Master
UML – Unified Modeling Language
EAP – Estrutura Analítica do Projeto
Sumário
Capítulo 1 ........................................................................................................................ 9
Introdução ..................................................................................................................... 9
1.1 – Tema ................................................................................................................ 9
1.2 – Motivação ........................................................................................................ 9
1.3 – Justificativa .................................................................................................... 10
1.4 – Objetivos ........................................................................................................ 10
1.5 – Metodologia ................................................................................................... 10
1.6 – Descrição ....................................................................................................... 10
Capítulo 2 ...................................................................................................................... 12
PMBOK ...................................................................................................................... 12
2.1 – O que é projeto .............................................................................................. 13
2.2 – Gerenciamento de projetos ............................................................................ 13
2.3 – Áreas de conhecimento do PMBOK ............................................................. 14
2.3.1 – Gerenciamento da Integração do Projeto.................................................... 16
2.3.2 – Gerenciamento do Escopo do Projeto ........................................................ 16 2.3.3 – Gerenciamento do Tempo do Projeto ......................................................... 17
2.3.4 – Gerenciamento de Custos do Projeto ......................................................... 18 2.3.5 – Gerenciamento de Qualidade do Projeto .................................................... 19
2.3.6 – Gerenciamento dos Recursos Humanos do Projeto .................................... 20 2.3.7 – Gerenciamento das Comunicações do Projeto ........................................... 21 2.3.8 – Gerenciamento de Riscos do Projeto .......................................................... 22
2.3.9 – Gerenciamento das Aquisições do Projeto ................................................. 23 2.3.10 – Gerenciamento das Partes Interessadas do Projeto................................... 24
Capítulo 3 ...................................................................................................................... 26
SCRUM ...................................................................................................................... 26
3.1 – Definição ....................................................................................................... 26
3.2 – Papéis do Scrum ............................................................................................ 27
3.2.1 – Scrum Master .............................................................................................. 27 3.2.2 – Proprietário do Produto (Product Owner) .................................................. 28 3.2.3 – Time ............................................................................................................ 28
3.3 – Artefatos do Scrum ........................................................................................ 28
3.3.1 – Backlog do Produto (Product Backlog) ...................................................... 28 3.3.2 – Sprint Backlog ............................................................................................ 29
3.3.3 – Burndown Chart ......................................................................................... 29
3.4 – Cerimônias do Scrum .................................................................................... 30
3.4.1 – Reunião de Planejamento das Atividades (Sprint Planning)...................... 30 3.4.2 – Reuniões Diárias (Daily Scrum Meeting) ................................................... 30 3.4.3 – Reunião de revisões das atividades (Sprint Reviews) ................................. 31 3.4.4 – Reunião de Retrospectiva (Sprint Retrospective) ....................................... 31
3.5 – Ciclo de vida do Scrum ................................................................................. 31
Capítulo 4 ...................................................................................................................... 33
PMBOK x SCRUM .................................................................................................... 33
4.1 – Funções e papéis ............................................................................................ 33
4.2 – Ciclo de Vida ................................................................................................. 34
4.2.1 – Iniciação e Planejamento ............................................................................ 35
4.2.2 – Execução do Scrum .................................................................................... 36 4.2.3 – Planejamento do Sprint – primeira etapa .................................................... 42 4.2.4 – Planejamento do Sprint – segunda etapa .................................................... 44
4.2.5 – Encerramento .............................................................................................. 45
Capítulo 5 ...................................................................................................................... 47
5.1 – Conclusão .......................................................................................................... 47
5.2 – Trabalhos Futuros .............................................................................................. 48
Capítulo 6 ...................................................................................................................... 49
Bibliografia ................................................................................................................. 49
Lista de Figuras
Figura 1 – Grupo de Processos no Ciclo da Vida de um Projeto ................................... 13
Figura 2 – Processos de Gerenciamento de Projetos ...................................................... 14
Figura 3 – Grupos de Processos versus Área de Conhecimento .................................... 15
Figura 4 – Visão geral do gerenciamento da integração do projeto ............................... 16
Figura 5 – Visão geral do gerenciamento do escopo do projeto .................................... 17
Figura 6 – Visão geral do gerenciamento do tempo do projeto...................................... 18
Figura 7 – Visão geral do gerenciamento dos custos do projeto .................................... 19
Figura 8 – Visão geral do gerenciamento da qualidade do projeto ................................ 20
Figura 9 – Visão geral do gerenciamento dos recursos humanos do projeto ................. 21
Figura 10 – Visão geral do gerenciamento das comunicações do projeto...................... 22
Figura 11 – Visão geral do gerenciamento dos riscos do projeto ................................... 23
Figura 12 – Visão geral do gerenciamento das aquisições do projeto............................ 24
Figura 13 – Visão geral do gerenciamento das partes interessadas do projeto .............. 25
Figura 14 – Burndown Chart .......................................................................................... 30
Figura 15 – Ciclo de vida do Scrum ............................................................................... 32
Figura 16 – Ciclo de vida Scrum com Guia PMBOK® .................................................. 34
Figura 17 – Exemplo de uma matriz de rastreabilidade de requisitos ............................ 38
Figura 18 – Amostra de EAP decomposta em pacotes de trabalho ................................ 39
Figura 19 – Distribuição de processos ao longo das fases do ciclo de vida do projeto .. 46
Capítulo 1
Introdução
No atual cenário das empresas fala-se muito em frequentes alterações dos
requisitos durante o ciclo do desenvolvimento do projeto para atender as necessidades
de entregas rápidas. Este fato torna o desenvolvimento um desafio, pois a mudança
exige investimento de recursos.
Analisando este cenário, as empresas passam por momentos críticos para terem
sucesso na entrega de seus projetos, visando agilidade, inovação de forma rápida e
eficiente, e capacidade de aprimoramento possuindo recursos restritos. Sendo assim as
empresas tem visto a necessidade da utilização de uma boa prática e uma metodologia
ágil para tal desafio, apresentando projetos longos com tempo curto.
1.1 – Tema
A utilização das melhores práticas do Guia PMBOK® tem auxiliado muito na
gestão de projetos, abordando uma estrutura empregada para guiar a equipe do projeto
durante o desenvolvimento do mesmo. A metodologia varia de acordo com a
complexidade do projeto e o tipo de ferramenta empregada para atingir o produto final.
A aplicação do Guia PMBOK® promove a utilização de boas práticas e
informações aceitas pelo gerenciamento de projeto. Procurando agilidade nesse
processo, muitas empresas têm utilizado métodos ágeis para atender a demanda de
mercado por entregas mais rápidas a gestão de projetos.
1.2 – Motivação
Considerando a demanda por projetos complexos com tempo, prazo e custo cada
vez mais restritos, muitas empresas têm buscado a utilização de métodos ágeis para
auxiliar a gestão de projetos. Contudo, além desta necessidade, também existe a
necessidade de utilização de um framework consolidado para gestão de projetos, como
o Guia PMBOK®.
1.3 – Justificativa
Muitos creem que a junção das duas metodologias (Scrum e Guia PMBOK®)
não se misturem tipo água e óleo. Porém este trabalho visa apresentar uma forma de
união para auxiliar na gestão de projetos, que deseja manter de forma contextualizada as
técnicas do Guia PMBOK® com a agilidade apresentada na metodologia ágil,
apresentada pelo framework Scrum.
1.4 – Objetivos
O objetivo desse trabalho é apresentar os pontos de compatibilidade na
utilização das metodologias de gerenciamento de projetos Scrum e Guia PMBOK®.
Criar um método híbrido utilizando as duas abordagens estudadas. Apresentar a
metodologia ágil de gerenciamento de projetos Scrum e de boas práticas do Guia
PMBOK®. E por fim, apresentar uma comparação entre as duas áreas apresentadas.
1.5 – Metodologia
A pesquisa foi feita através de artigos publicados, livros, envolvendo o Guia do
PMBOK®, e livros direcionados ao Scrum. A metodologia aplica é qualitativa. A
trajetória do trabalho é analisar separadamente o PMBOK® e sua abordagem no
gerenciamento de projetos e depois analisar o Scrum e suas práticas. Analisando assim
o que é bom em um e o que o outro pode utilizar para melhor atender ao gerenciamento
de projetos nos tempos atuais. Visando sempre inovação com baixo custo e riscos.
1.6 – Descrição
O capítulo 1 trata-se de uma introdução falando sobre o Guia PMBOK® e como
ele aborda um bom gerenciamento de projetos.
O capítulo 2 explica a gestão de projetos baseado no Guia PMBOK®, falando do
que se trata a gestão, os tipos e seus embasamentos.
O capítulo 3 aborda somente sobre Scrum, o conceito, técnicas, seus papéis e
responsabilidades.
O capítulo 4 realiza a aplicação da ideia, comparando as atividades do Scrum
com as dez áreas de conhecimento aplicado pelo Guia PMBOK®.
Por fim, sugerimos no capítulo 5 a abordagem das atividades do Scrum com a
finalidade abordar e provar que com o Guia PMBOK®, o gerenciamento de projetos
com Scrum se torna mais ágil e eficiente.
Capítulo 2
PMBOK
O Guia PMBOK® (Guia para o Conjunto de Conhecimentos de Gerenciamento
de Projetos, ou em inglês PMBOK® Guide – A Guide to the Project Management Body
of Knowledge) trata-se de um guia que reúne boas práticas, uma visão ampla, para
contemplar principais aspectos que são abordados no gerenciamento de projetos
genéricos. Não se trata de uma metodologia, e sim de um conjunto de conhecimentos
em gerenciamento de projetos. Sendo assim, o guia reúne informações consensuais que
foram identificados por profissionais da área.
Nele são apresentados vários processos e ferramentas, mas nem sempre tudo é
usado, e sim visando à necessidade de cada projeto particularmente. O guia não
determina como deve ser gerenciado um projeto e sim sugeri através das boas práticas.
O guia é divido em três seções:
Estrutura do gerenciamento de projetos;
Gerenciamento de projetos de um projeto; e
Áreas de conhecimento em gerenciamento de projetos.
As dez áreas do conhecimento se agrupam e definem os 47 processos de
gerenciamento detalhadamente.
Os processos são organizados em cinco grupos, todos de acordo com um
determinado objetivo dentro de um fluxo do projeto, são:
Iniciação;
Planejamento;
Execução;
Controle; e
Encerramento.
Os grupos de processos possuem papéis destacados para cada momento no ciclo
de vida de um projeto, podendo se sobrepor em cada fase, como mostra figura.
Figura 1 – Grupo de processos no ciclo da vida de um projeto. Fonte: Guia PMBOK®, 2013.
2.1 – O que é projeto
Segundo o guia do PMBOK® (2013) define-se projeto como um esforço
temporário empreendido para criar um produto, serviço ou resultado exclusivo. Sendo
assim, um projeto tem um início e um término definido. Devemos dar destaques a duas
palavras sobre a definição do que é um projeto que são: temporário e exclusivo.
Temporário não quer dizer que um projeto tem curta duração e sim por se tratar de um
projeto que tem o início e fim bem definidos, já exclusivo trata cada projeto com sua
singularidade, mesmo que tenha passado por etapas ou processos similares, cada
produto final tem seu valor único.
2.2 – Gerenciamento de projetos
O gerenciamento de projetos consiste em aplicar os seus conhecimentos,
habilidades, ferramentas e técnicas as atividades do projeto, com objetivo de atender os
requisitos do projeto.
No gerenciamento a identificação das necessidades, o estabelecimento dos
objetivos, de forma clara e alcançável, e o balanceamento das demandas que são:
escopo, tempo, custo e qualidade, constituem o fator de sucesso do projeto.
Os grupos de processos de gerenciamento de projetos utilizam o conceito do
Ciclo PDCA (Plan – Do – Check – Act), onde Planejar corresponde ao Planejamento no
grupo de processos, já Fazer corresponde a Execução, Verificar e Agir engloba ao
Monitoramento e Controle, segue a figura.
Figura 2 – Processos de Gerenciamento de Projetos. Fonte: Guia PMBOK®, 2013.
2.3 – Áreas de conhecimento do PMBOK
O guia PMBOK® divide em dez áreas de conhecimento que caracterizam os
principais aspectos envolvidos de um projeto e seu gerenciamento, são elas:
Integração;
Escopo;
Tempo;
Custos;
Qualidade;
Recursos Humanos;
Comunicação;
Riscos;
Aquisições; e
Partes Interessadas.
Segundo o guia PMBOK® existe uma matriz de relação entre as áreas de
conhecimento e o grupo de processos, como é mostrado abaixo pela figura.
Figura 3 – Grupos de Processos versus Área de Conhecimento. Fonte: Guia PMBOK®, 2013.
2.3.1 – Gerenciamento da Integração do Projeto
Segundo o Guia PMBOK® (2013), o gerenciamento da integração do projeto
inclui os processos e atividades para identificar, definir, combinar, unificar e coordenar
os vários processos e atividades dentro dos grupos de processos de gerenciamento do
projeto.
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento da integração.
Figura 4 – Visão geral do gerenciamento da integração do projeto. Fonte: Guia PMBOK®, 2013.
2.3.2 – Gerenciamento do Escopo do Projeto
No gerenciamento de escopo do projeto tem-se a finalidade de garantir que o
projeto possa ser completado com sucesso, fazendo apenas o trabalho necessário.
Controlando o que deve e o que não deve estar incluso em um projeto, segundo o Guia
PMBOK® (2013).
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento do escopo do projeto.
Figura 5 – Visão geral do gerenciamento do escopo do projeto. Fonte: Guia PMBOK®, 2013.
2.3.3 – Gerenciamento do Tempo do Projeto
O gerenciamento do tempo do projeto inclui os processos necessários para
gerenciar o término pontual do projeto, Guia PMBOK®2013.
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento do tempo do projeto:
Figura 6 – Visão geral do gerenciamento do tempo do projeto.
Fonte: Guia PMBOK®, 2013.
2.3.4 – Gerenciamento de Custos do Projeto
O gerenciamento de custos do projeto envolve os processos de planejamento,
estimativas, orçamentos, financiamentos, gerenciamento e controle de custos, fazendo
com que o projeto termine dentro do orçamento inicialmente aprovado.
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento dos custos do projeto.
Figura 7 – Visão geral do gerenciamento dos custos do projeto.
Fonte: Guia PMBOK®, 2013.
2.3.5 – Gerenciamento de Qualidade do Projeto
No gerenciamento de qualidade do projeto é descrito os processos que são
envolvidos na garantia de que o projeto irá satisfazer os objetivos para os quais foram
realizados. Nessa etapa os processos determinam normas ou padrões de qualidade que
devem ser seguidos ao longo do projeto, realizando auditorias da qualidade, sempre
verificando se o projeto está seguindo o planejado, tentando impedir uma não
conformidade ao produto.
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento da qualidade do projeto.
Figura 8 – Visão geral do gerenciamento da qualidade do projeto.
Fonte: Guia PMBOK®, 2013.
2.3.6 – Gerenciamento dos Recursos Humanos do Projeto
Na área de recursos humanos tratamos o gerenciamento e organização da
equipe do projeto. Determina os tipos e perfis dos profissionais, além da hierarquia e
responsabilidades, mobilizando as pessoas que foram requisitadas para o projeto.
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento dos recursos humanos do projeto.
Figura 9 – Visão geral do gerenciamento dos recursos humanos do projeto.
Fonte: Guia PMBOK®, 2013.
2.3.7 – Gerenciamento das Comunicações do Projeto
Essa área inclui os processos necessários para garantir que as informações do
projeto sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas,
gerenciadas, controladas, monitoradas e finalmente dispostas de forma oportuna e
adequada (Guia PMBOK®, 2013).
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento das comunicações do projeto.
Figura 10 – Visão geral do gerenciamento das comunicações do projeto.
Fonte: Guia PMBOK®, 2013.
2.3.8 – Gerenciamento de Riscos do Projeto
O gerenciamento de riscos do projeto inclui o planejamento, a identificação,
análise, planejamento de respostas e controle de riscos de um projeto. O objetivo é
aumentar a probabilidade e o impacto dos eventos positivos e reduzir os impactos
negativos, segundo o Guia PMBOK®, 2013.
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento dos riscos do projeto.
Figura 11 – Visão geral do gerenciamento dos riscos do projeto. Fonte: Guia PMBOK®, 2013.
2.3.9 – Gerenciamento das Aquisições do Projeto
Na área de aquisições o processo necessário é a compra ou aquisição de
produtos, serviços ou resultados externos à equipe do projeto, também gerencia os
processos de contratos e controle de mudanças (Guia PMBOK®, 2013).
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento das aquisições do projeto.
Figura 12 – Visão geral do gerenciamento das aquisições do projeto.
Fonte: Guia PMBOK®, 2013.
2.3.10 – Gerenciamento das Partes Interessadas do Projeto
Essa área ganhou destaque no Guia PMBOK® 5ª edição, com o objetivo de
identificar todas as pessoas, grupos ou organizações que podem impactar ou serem
impactadas pelo projeto.
Na figura abaixo é mostrado à visão geral dos processos referente ao
gerenciamento das partes interessadas do projeto.
Figura 13 – Visão geral do gerenciamento das partes interessadas do projeto. Fonte: Guia PMBOK®, 2013.
Capítulo 3
SCRUM
No ano de 2001, houve uma reunião com 17 gurus da comunidade de
desenvolvimento que foi realizada numa estação de esqui nas montanhas Utah, Estados
Unidos para discutir sobre desenvolvimento ágil de software, pois queriam se basear no
conceito do Lean Manufacturing, conhecido como o Sistema de Produção da Toyota,
onde materiais apropriados encontravam-se no local certo, na quantidade certa, assim
minimizando o desperdício e também era flexível e aberto a mudanças, que ficou
conhecido como o manifesto ágil.
O manifesto valoriza o indivíduo e interação entre eles mais que processos e
ferramentas, se preocupam mais com o funcionamento do software e menos com a
documentação abrangente, a colaboração com os clientes e menos a negociação de
contratos, e rápida resposta a mudanças e menos a seguir um plano.
Visando essa necessidade de ser ágil, surgiram várias metodologias ágeis, como:
DSDM (Dynamic Systems Development Method), Familia Crystal, ASD (Adaptive
Software Development), XP (Extreme Programming) e SCRUM.
Nesse trabalho iremos falar do SCRUM.
3.1 – Definição
Scrum é um nome derivado de uma atividade que ocorre durante o jogo de ruby,
foi criado por Jeff Sutherland e Ken Schwaber em 1995. Inicialmente ele foi
desenvolvido para ser empregado por equipes de desenvolvimento de produtos de
software. Porém, atualmente pode ser utilizado por qualquer área que tem o intuito de
implementar processos de gerenciamento de projetos.
Segundo Schwaber & Beedle (2007), o Scrum consiste em ser um framework
onde pode ser empregado vários processos e técnicas para desenvolver produtos
complexos. O Scrum baseia-se em seis características:
Flexibilidade de prazos;
Flexibilidade de resultados;
Times pequenos;
Revisões frequentes;
Colaboração; e
Orientação.
O Scrum é leve, simples de entender, porém é difícil de aplicar. Constitui o
Time Scrum e seus papéis e artefatos, que falaremos mais a diante. Também se baseia
na teoria de controle empírico de processos, possui uma abordagem iterativa e
incremental, ou seja, o produto é feito aos poucos e em constante entrega.
3.2 – Papéis do Scrum
O Scrum possui poucos papéis, onde são bem definidos, que são: Scrum Master
(S.M), Proprietário do produto (em inglês, Product Owner (P.O)) e o Time. Sendo
formado por times bem organizados e multifuncionais e não devem depender de pessoas
que não fazem parte da equipe para realizar o trabalho.
3.2.1 – Scrum Master
Para Schwaber (2004) as principais responsabilidades do Scrum Master estão
relacionadas em como o Scrum funciona e ter um conhecimento profundo do processo
de gerenciamento do projeto. Ele deve:
Assegurar produtividade e funcionamento pleno da equipe;
Remover todos ou quaisquer impedimentos que possa interferir no
objetivo do projeto;
Assegurar que as regras, os valores e as boas práticas do Scrum estejam
sendo utilizados;
Assegurar que estão sendo feitas as reuniões diárias (Daily Scrum
Meetings), revisões das atividades (Sprint Reviews) e reuniões de
planejamentos das atividades (Sprint Planning).
O Scrum Master não tem autoridade perante o Proprietário do produto e/ou ao
Time.
3.2.2 – Proprietário do Produto (Product Owner)
O Proprietário do Produto (em inglês, Product Owner) consiste em ser o dono
do produto. É ele que passa a visão do produto para a equipe e faz a ponte entre o
cliente e o time. Suas responsabilidades constituem em definir o conteúdo e
características do produto e gerenciar o Backlog do Produto (em inglês, Product
Backlog), garantindo que o mesmo estará sempre visível e claro para toda a equipe.
O Proprietário do Produto consiste em uma única pessoa e não em um comitê.
3.2.3 – Time
O Time é composto pelas pessoas que irão desenvolver o projeto, entre seis a
dez pessoas. São pessoas multidisciplinares que possuem características de autogestão.
Eles têm a responsabilidade de planejar os Sprints, assumir as metas do Proprietário do
Produto e dar os feedbacks sobre quaisquer impedimentos ao Scrum Master.
3.3 – Artefatos do Scrum
Este capítulo irá definir cada artefato utilizado pelo Scrum, que são: Backlog do
Produto (em inglês, Product Backlog), o Sprint Backlog e o Burndown Chart. O
objetivo comum desses artefatos é dar uma direção ao processo.
3.3.1 – Backlog do Produto (Product Backlog)
O Backlog do Produto constitui em uma lista de requisitos levantados através
das necessidades do Proprietário do Produto junto ao cliente, sem a necessidade de estar
completa inicialmente, podendo ser completada ao longo do projeto.
O Proprietário do produto tem a função de alimentar e dar prioridades nos
requisitos ao longo do Sprint e o Time tem a função de analisar e estimar cada item da
lista para serem contempladas ao longo do Sprint.
3.3.2 – Sprint Backlog
O Sprint Backlog consiste numa nova lista retirada da seleção de itens do
Backlog do Produto feita pelo Proprietário do produto, de acordo com as prioridades e
analisados pelo Time, após estimativas iniciais para execução do Sprint.
Tarefas que não forem atendidas serão contempladas num próximo Sprint
Backlog. Cada membro tem a liberdade de incluir, excluir ou alterar tarefas.
O número de horas para a conclusão de cada tarefa deve ser estimado pela
equipe. É de responsabilidade de ela manter atualizada diariamente a lista de tarefas,
com as já concluídas, e a estimativa de tempo necessário para a conclusão das tarefas
ainda em andamento. Tarefas já concluída devem ter o número de horas para a
conclusão estimadas como zero (Tavares, 2008).
3.3.3 – Burndown Chart
O Burndown Chart é um gráfico que mostra a quantidade de trabalho acumulado
do restante de um Sprint, é atualizado diariamente pelo time. Indica a soma de horas
necessárias para finalizar versus os dias determinados para o Sprint, assim deixando
visivelmente fácil verificar se o trabalho está em progresso ou não.
Ao longo das reuniões diárias, o Scrum Master acompanha a equipe para ver as
atividades fim, ajustando o gráfico do Burndown Chart. Esse gráfico também pode ser
verificado pelo Proprietário do Produto, para ficar ciente se o projeto está andando bem
ou não.
Esse gráfico é um dos principais recursos de medição do progresso do
desenvolvimento e um diferencial para a metodologia Scrum. A figura, abaixo mostra
um exemplo do gráfico de Burndown, onde o eixo Y indica o número de horas estimado
para o Sprint e o eixo X os dias do tamanho do Sprint analisado. (Tavares, 2008)
Figura 14 – Burndown Chart. Fonte: https://www.oficinadanet.com.br/artigo/gerencia/o_que_e_scrum, acessado 16 setembro 2015.
3.4 – Cerimônias do Scrum
3.4.1 – Reunião de Planejamento das Atividades (Sprint Planning)
A reunião de planejamento das atividades, chamada em inglês por Sprint
Planning, é feita para o Proprietário do Produto descrever as funcionalidades de maior
prioridade para a equipe. Nesta reunião estão presentes o Proprietário do produto, o
Scrum Master e todo o time, como qualquer outra pessoa interessada que esteja
representando a gerencia ou o cliente.
Durante a reunião a equipe faz perguntas para serem capazes de quebrar as
funcionalidades em etapas e tarefas técnicas, sendo essas que darão origem ao Sprint
Backlog.
Essa reunião tem como objetivo definir o que será entregue no final de um
Sprint ao cliente e é de responsabilidade do time definir o que serão capazes de fazer.
3.4.2 – Reuniões Diárias (Daily Scrum Meeting)
Ao longo de cada Sprint são feitas reuniões diárias, chamado em inglês de Daily
Scrum, com a participação da equipe de desenvolvimento e o Scrum Master, com a
finalidade de discutirem o que já foi executado, o que irão trabalhar quais possíveis
impedimentos para o progresso do projeto e formas de sanarem quaisquer problemas.
As reuniões são relativamente rápidas e objetivas, normalmente feitas no
período da manhã, entre 15 a 30 minutos, são feitas em pé, com objetivo de não
perderem o rumo do projeto.
Ao fim de cada reunião diária o Scrum Master tem uma visão do andamento do
Sprint, assim identificando possíveis problemas ou novas subtarefas e planejar futuras
ações a serem tomadas e atualizando o Burndown Chart do Sprint.
3.4.3 – Reunião de revisões das atividades (Sprint Reviews)
Ao final de cada Sprint, é realizada uma revisão do produto entregue, com
objetivo de verificar se tudo foi realmente implantado, o time demonstra o produto
gerado e valida se o objetivo foi atingido.
Os participantes dessa reunião normalmente são: o proprietário do produto, o
time e o Scrum Master.
3.4.4 – Reunião de Retrospectiva (Sprint Retrospective)
Ao final de cada Sprint e depois da reunião de revisões das atividades, é feita
uma reunião para fazer a retrospectiva das lições aprendidas e o que pode ser levado ou
não para o próximo Sprint, ações que podem ser tomadas para melhorar o projeto.
3.5 – Ciclo de vida do Scrum
No Scrum, os projetos possuem quatro ciclos de vida que são: planejamento,
preparação, desenvolvimento e entrega que são chamados de Sprint. Cada Sprint pode
durar em torno de duas a quatro semanas. Ao final de cada Sprint, uma parte do produto
é apresentada ao cliente, na figura abaixo ilustramos o ciclo de vida do Scrum.
Figura 15 – Ciclo de vida do Scrum. Fonte: http://gerentedeprojeto.net.br/?p=13, acessado 21 agosto 2015.
Para iniciar um Sprint, é realizada uma reunião de planejamento das atividades
(Sprint Planning), onde é levantada a lista com os principais itens, contendo as
funcionalidades e os requisitos do produto, o Backlog do Produto, que foi planejada
pelo Proprietário do produto. Sendo assim definidas, o Backlog do produto é transferido
para o Sprint Backlog.
Ao decorrer dos dias, durante a manhã normalmente, é feito reuniões diárias
(Daily Scrum Meeting) para alinhar o que foi feito no dia anterior, identificar
impedimentos e priorizar os trabalhos do que dia que se inicia. Essa reunião sempre
alinha o que está descrito no Sprint Backlog.
Ao final do Sprint, o time de desenvolvimento apresenta as funcionalidades já
implementadas durante a reunião para revisões das atividades (Sprint Reviews). Nessa
reunião é apresentado ao Proprietário do produto e demais interessado o resultado dos
itens do Backlog do Produto que foram produzidos, assim avaliando qual será o
próximo Sprint, vendo a necessidade de prosseguir ou não com o projeto.
Capítulo 4
PMBOK x SCRUM
Neste capítulo iremos apresentar uma proposta da união de boas práticas do
Guia PMBOK® com o framework Scrum. Partindo do princípio que o Guia PMBOK®
sugere tudo que aborda num projeto, do início ao fim, mas não possui uma “receita de
bolo” para tal e muitas vezes essa ideia não fica muito clara em que momento utilizar o
processo correto. Com o objetivo de apoiar os pontos fracos do Guia PMBOK®,
sugerimos o framework Scrum, uma vez que ele é aplicável em qualquer projeto que
tem o objetivo de um gerenciamento ágil.
4.1 – Funções e papéis
O guia PMBOK® possui o papel do patrocinador do projeto, ele que descreve o
que deseja e sendo assim, tem que ser feita uma boa entrevista com o mesmo, pois
muita das vezes eles não sabem o que querem mesmo quando pensam que sabem e é
função dos gerenciadores do projeto entender tudo o que o patrocinador do projeto
necessita e assim gerenciar sua equipe, já o Scrum tem o papel do dono do produto, que
descreve o projeto através do documento de visão e participa ativamente em todas as
reuniões diárias (Tavares, 2008). Tem-se o papel do Scrum Master que diferencia do
gerente do guia PMBOK® na questão de que o papel de gerencia do projeto não é
totalmente focado na figura do Scrum Master e sim de responsabilidade também do
time, sendo o Scrum Master somente um facilitador.
No Scrum o projeto é dividido em Sprints e no guia PMBOK® é em fases e
sequencial.
O cliente no guia PMBOK® tem baixo envolvimento, porém o fato do Scrum
trabalhar por Sprints e interação direta com o cliente em todas as reuniões do Sprint o
torna mais flexível, no Scrum a reunião diária é obrigatória, o que ajuda com que tudo
saia como o planejado.
A diferença no planejamento do projeto é que o guia PMBOK® é feito no
começo do projeto e no Scrum é feito na iniciação do Sprint e somente para aquele
Sprint que se inicia.
No guia PMBOK®, o projeto é desenvolvido e fechado quando todas as entregas
são realizadas, no Scrum o projeto é desenvolvido em iterações, permitindo que os
clientes parem o projeto quando todas as principais entregas forem satisfeitas.
4.2 – Ciclo de Vida
Iremos analisar a partir do ciclo de vida do Scrum, pelo fato de ser mais
compacto que o guia PMBOK®. Podemos dizer que ao “rodar” o Scrum percebemos o
momento onde o guia PMBOK®se encaixa de maneira natural na rotina, utilizando suas
técnicas, ferramentas e papéis, com o objetivo de unir os pontos fortes e tentar
minimizar as fraquezas ou limitações.
Então o objetivo é visualizar o Scrum rodando e encaixar o guia PMBOK®
conforme o ciclo ocorre. A figura abaixo ilustra de forma simples o ciclo de vida do
Scrum com o guia PMBOK® sendo encaixado nos momentos de cada processo.
Figura 16 – Ciclo de vida Scrum com guia PMBOK®. Fonte: http://projectprime.com.br/?p=215, acessado 14 agosto 2015.
4.2.1 – Iniciação e Planejamento
Mesmo em um ambiente de desenvolvimento ágil, o início do projeto é marcado
pela formalização. Sendo assim, os métodos tradicionais do guia PMBOK® resolve esse
problema. Abaixo listaremos os processos que marcam oficialmente o início de um
projeto.
Termo de Abertura do Projeto (TAP):
O termo de abertura do projeto formaliza e oficializa a existência de um projeto
e dá ao gerente do projeto a autoridade necessária para aplicar os recursos as atividades
do projeto. Este documento tem que conter no mínimo as seguintes características:
Finalidade ou justificativa do projeto;
Objetivos mensuráveis do projeto e critérios de sucesso relacionados;
Requisitos de alto nível;
Premissas e restrições;
Descrição de alto nível do projeto e seus limites;
Riscos de alto nível;
Resumo do cronograma de marcos;
Resumo do orçamento;
Listas das partes interessadas;
Requisitos para aprovação do projeto (ou seja, o que constitui o sucesso do
projeto, quem decide se o projeto é bem-sucedido e quem o assina);
Gerente do projeto, responsabilidade, nível de autoridade designados; e
Nome e autoridade do patrocinador ou pessoas que autorizam o termo de
abertura do projeto (Guia PMBOK®, 2013).
Identificação dos Stakeholders
Ao iniciar um projeto, a primeira coisa a se fazer é identificar as partes
interessadas, sendo essa pessoa ou organização responsável por fornecer informações
para a realização do projeto, além de aprovar e usar o produto do projeto.
Nesse momento ocorre a interação entre o gerente de projetos, de acordo com o
conceito do guia PMBOK®, com o Product Owner, segundo o Scrum.
Desenvolver o plano de gerenciamento do projeto
O plano de gerenciamento do projeto é o documento que descreve como o
projeto será executado, monitorado e controlado. Ele integra e consolida todos os planos
de gerenciamento auxiliares e linhas de base dos processos e planejamento, segundo o
guia PMBOK®.
Para Cruz (2013), é altamente importante publicar o plano para todas as partes
interessadas do projeto, e que contenham pelo menos os conteúdos abaixo:
O ciclo de vida do projeto e os processos que serão aplicados em cada fase;
Como trabalho será executado para completar os objetivos do projeto;
Como serão gerenciadas as mudanças no projeto;
Como serão gerenciadas as configurações do projeto;
Como serão gerenciados os requisitos do projeto;
O que será feito para manter a integridade das linhas de base do projeto;
Quais as necessidades para as comunicações entre as partes interessadas;
Essa atividade do desenvolvimento do plano envolve o Gerente de Projetos, o
Product Owner e o Scrum Master.
Todos esses planejamentos preveem incluir as atividades ágeis que
proporcionam comunicar, gerenciar os riscos, controlar a qualidade e prever as
aquisições para o projeto.
4.2.2 – Execução do Scrum
Nessa fase do ciclo de vida podemos dizer que “vai colocar o Scrum para rodar”,
sendo que já realizamos as atividades formais e externas ao Scrum, é aqui que o gerente
de projetos juntamente com o time do Scrum pode iniciar a execução do projeto pela
ótica do mesmo.
Para Cruz (2013), quando estamos executando o Scrum, ao mesmo tempo ocorre
à execução do projeto, dando continuidade as atividades de planejamento, realizando os
testes, entregas e outras etapas. Tudo ao seu devido tempo, mas no ambiente ágil, de
forma dinâmica, breve e recorrente.
No guia PMBOK®, existe o conceito de Planejamento por Ondas Sucessivas,
que combinam com os ciclos do Scrum, ou seja, o projeto será dividido em várias fases
de acordo com a entrega acordada com o cliente. Sendo assim, temos os Sprints do
Scrum atuando como as fases das Ondas Sucessivas do guia.
Antes de iniciar um Sprint no ciclo de vida do Scrum, sabemos que no
planejamento, definimos, estimamos e separamos os itens do Backlog do Produto que
são transformados em funcionalidades, ou seja, entregue ao cliente no final da Sprint.
Porém para fazer esse processo, precisa-se coletar, analisar, entender e detalhar os itens
trabalhados dentro de um Sprint.
É nesse momento que os processos do guia PMBOK® podem orientar e ajudar
a equipe do projeto, mesmo porque é preciso ter uma organização e controle sobre o
gerenciamento dos requisitos, sendo assim, falamos que o Backlog do Produto é os
requisitos do projeto dentro do Scrum.
Nesse levantamento, seguindo as regras do Scrum, a responsabilidade do
Backlog do Produto é exclusiva do Product Owner, o GP apoia e controla as atividades
que estão sendo executadas, dando suporte e facilitar as tarefas do PO.
Abaixo listaremos os processos que são utilizados nessa fase de execução de um
projeto.
Coletar os requisitos
Esse processo é obrigatório para se puder aplicar o Scrum, onde o Product
Owner procura os Stakeholders e faz o levantamento dos requisitos necessários para a
entrega do projeto. No guia do PMBOK® existe a Matriz de Rastreabilidade de
Requisitos, que é uma tabela que liga os requisitos do produto desde as suas origens até
as entregas que os satisfazem, ajudando a garantir que todos os requisitos agregam valor
de negócio ao projeto. A figura abaixo mostra um exemplo da tabela.
Figura 17 – Exemplo de uma matriz de rastreabilidade de requisitos. Fonte: Guia PMBOK®, 2013.
Definir o Escopo
Com a mesma importância do levantamento de requisitos, definir o escopo nada
mais é do que a definição e detalhamento do mesmo. Tendo o escopo bem detalhado, o
PO terá matéria para criar as Estórias, que são artefatos já bem conhecidos pelo Scrum.
Sendo assim, poderão criar protótipos de telas, para descrever de forma visual as ações
do sistema, e documentos que possuem as regras de negócios do sistema.
Essas regras de negócio são altamente recomendadas para registras e confirmar
as regras do sistema, independente da metodologia utilizada. Um bom exemplo de
documento é o Caso de Uso, do modelo UML.
O responsável por essa etapa é o PO.
Criar a EAP
Segundo o guia PMBOK® (2013), a EAP é uma decomposição hierárquica do
escopo total do trabalho a ser executado pela equipe do projeto a fim de alcançar os
objetivos do projeto e criar as entregas requeridas. A EAP organiza e define o escopo
total do projeto e representa o trabalho especificado na atual declaração do escopo do
projeto aprovada.
O trabalho planejado está dentro dos componentes de nível mais baixo da EAP,
que são chamados de pacotes de trabalho. Um pacote pode ser usado para agrupar as
atividades onde o trabalho é agendado, tem seu custo estimado, monitorado e
controlado. O trabalho se refere a produtos de trabalho ou entregas que são o resultado
da atividade e não a atividade propriamente dita. A figura mostra um exemplo de uma
EAP construída.
Figura 18 – Amostra de EAP decomposta em pacotes de trabalho. Fonte: Guia PMBOK®, 2013.
A responsabilidade dessa fase de criar a EAP é do GP, porém o PO dá suporte a
ele.
Definir o time Scrum
Seguindo as regras do Scrum, o ideal seria definir o Time na primeira Sprint,
apenas uma vez. Pois o Time Scrum precisa ter autogerenciamento, auto monitoração,
autocontrole e principalmente auto melhoria.
Porém os projetos não são estáveis, assim não podendo garantir que isso seja
mantido, podendo assim ser modificado nas próximas iterações do ciclo de vida do
Scrum.
Esse processo é conhecido como estimar recursos das atividades, conforme as
estórias definidas, determinar o tamanho do Time, das Sprints, e quantas serão
necessárias para completar o projeto.
No guia PMBOK® esse processo é conhecido como “Estimar os recursos das
atividades”. Junto com esse processo, o GP pode planejar o plano de recursos humanos,
que é outro processo contido no guia PMBOK®, visando atender e gerenciar
preocupações com recompensas e treinamentos do Time. Este processo pode ser revisto
outras vezes ao longo das iterações, uma vez que os recursos podem necessitar de novos
treinamentos e recompensas especiais.
O PO e o GP são responsáveis por esta realização, onde o PO apoia o GP no
levantamento dos recursos e no planejamento dos recursos humanos.
Apresentar o Backlog do Produto
Depois do Product Owner preparar o Backlog do Produto, é a fase de apresentar
ele para o Time, sendo o mesmo a transformá-lo em funcionalidades potencialmente
entregáveis, podendo estar completo ou parcial, seguindo as Ondas Sucessivas.
Independente de completo ou parcial o Backlog do Produto, este é o momento
também para definir o planejamento da próxima entrega, e como as Sprints serão
distribuídas para completar todo o trabalho necessário até lá.
Essa fase em alguns projetos é definida em alto nível na iniciação do projeto,
junto com o termo de abertura e ao plano de gerenciamento do projeto, e aqui seria
somente detalhar e associar as funcionalidades especifica que o compõe e as estórias
criadas.
Na apresentação o PO, com apoio do GP, realiza as seguintes atividades junto
com o Time:
Mobilizar a equipe do projeto:
Nesse processo o GP oficializa a formação do Time Scrum, com seus papéis e
responsabilidades. Além de oficializar para todo o Time qual o papel e importância do
GP atuando neste modelo misto.
Lembrando que a equipe foi estimada e seus papéis e responsabilidades já
previsto no passo de Definição do Time Scrum, nesse processo a equipe é mobilizada e
alocada ao projeto, havendo possiblidades de pequenas alterações na definição.
Os responsáveis por esse processo são formados pelo GP e PO.
Planejar as aquisições:
Para Cruz (2013), esse processo consiste no entendimento das estórias e a
definição dos seus tamanhos, o Time realiza uma análise conhecida como “Fazer ou
Comprar”, ou seja, avaliar o tamanho e a complexidade de uma estória, sendo possível e
mais interessante comprar uma solução pronta do que desenvolver em “casa”.
O papel do GP nesse processo não é obrigatório, mas caso haja a necessidade da
compra, ele se torna uma figura importante, pois é ele que analisará o orçamento do
projeto e dará a palavra final sobre a decisão a ser tomada.
Os responsáveis por esse processo são formados pelo Time, PO e GP.
Identificar os Riscos:
Nessa etapa, ocorre o primeiro trabalho envolvendo gerenciamento de riscos do
projeto. Entender as estórias é de suma importância no Scrum, pois outros processos
serão executados com base nos seus resultados. A primeira identificação de riscos é
realizada quase no final dos trabalhos com o Backlog do Produto.
Os responsáveis por esse processo são formados pelo Time, PO e GP.
Gerenciamento de Custos
Nessa metodologia híbrida entre Scrum e PMBOK®, o gerente de projetos
poderá trabalhar paralelamente no gerenciamento de custos, à preparação do Backlog do
Produto, definido pelo PMBOK®. Esta etapa é muito importante para o projeto e
considerada uma das mais difíceis.
Segundo Cruz (2013), a economia de um projeto pode acarretar o encarecimento
da manutenção do produto resultado do projeto. Sendo assim, não se pode gastar
descontroladamente ou economizar excessivamente, é preciso realizar um
gerenciamento de custos.
Nessa etapa, o gerente de projetos tem condições de trabalhar paralelamente ao
Backlog do Produto, no gerenciamento de custos, e focar nos dois seguintes processos:
Estimar custos:
No final dos trabalhos com o Produto do Backlog, mobilizar o Time, definir a
velocidade e as aquisições, o gerente de projetos consegue estimar os custos da próxima
entrega do projeto, podendo também, de acordo com o tamanho do projeto ou a divisão
das fases, fornecer o custo para todo ele, e não somente para a próxima etapa.
As informações sempre disponíveis pelo Time do Scrum, o gerente de projetos
poderá estimar o custo para cada atividade (ou estória).
O responsável por essa etapa é o GP.
Determinar o orçamento:
Segundo Cruz (2013), essa etapa ocorre juntamente com estimar custos, onde o
gerente de projetos determina o orçamento previsto para o projeto, ou para a próxima
entrega. Este processo é importante para autorizar a realização do projeto no âmbito
financeiro, e publicar como se darão as aprovações periódicas.
O responsável por essa etapa é do GP.
Planejar o gerenciamento dos riscos
No Scrum o gerenciamento de riscos é feito informalmente, contrário ao Guia
PMBOK®, uma vez que é sugerido um plano documentado. A gestão de risco está
incorporada ao processo de Scrum, logo toda a equipe faz a identificação e análise de
riscos do projeto, durante as reuniões diárias, sprints e suas retrospectivas.
Então essa etapa requer que o gerente de projetos, faça a análise dos riscos e
comunique aos Stakeholders os riscos identificados, e como será o tratamento durante o
desenvolvimento do projeto.
4.2.3 – Planejamento do Sprint – primeira etapa
Essa etapa é de suma importância para o Scrum, é uma cerimônia em que a
equipe do projeto deve planejar em conjunto todos os trabalhos para a próxima Sprint,
deve realizar completamente, ou seja, não deve interrompê-la antes de todos os itens
serem discutidos e plenamente atendidos. (CRUZ, 2013)
A fase inicial do planejamento é o momento de preparar o ambiente de trabalho
antes de iniciar a reunião de planejamento da Sprint, o objetivo é evitar que algo não
planejado interfira com a execução da Sprint, e envolver o gerente do projeto.
Os processos sugeridos nessa etapa são:
Preparar o ambiente de trabalho:
Esse processo é responsável pela infraestrutura requerida pela equipe para
desenvolver o projeto, tudo que tem relação com equipamentos, salas, ferramentas,
softwares, dentre outros que são desejáveis para a realização dos Sprints. Segundo Cruz
(2013), essa etapa na maioria das vezes é feita de forma “automática” e até mecânica,
não levando em consideração o mapeamento no planejamento, porém ele recomenda o
mapeamento, uma vez que ajuda a mitigar os riscos.
Os responsáveis por essa etapa são: PO, GP e SM.
Identificar a velocidade do Time:
Essa fase é de importância para identificar a velocidade do Time. Ao longe do
trabalho com o Produto do Backlog, é sugerido que o próprio Time defina sua
velocidade, caso não façam, esse é o momento para realizarem essa medição.
Entretanto, a chance de errar a estimativa de velocidade na primeira Sprint é alta, assim
possibilita alterações na velocidade a qualquer momento durante a Sprint, retirando ou
adicionando trabalho. Com o tempo e as execuções das iterações torna-se mais precisa a
definição da velocidade do Time. (CRUZ, 2013)
Essa fase é de responsabilidade do Time do Scrum.
Definir o tamanho das Sprints:
Essa etapa do processo tem a importância de definir o tamanho das Sprints, que
valerá para todas, e não somente para a próxima Sprint.
O tamanho tem que ser o mesmo para todo o projeto, assim o Scrum
proporciona medições de desempenho e melhoria.
Para Cruz (2013), com o resultado da preparação do ambiente, reunindo a
equipe, possuindo a identificação da velocidade do Time e os itens do Backlog que a
equipe irá trabalhar, é possível definir o tamanho e o número das Sprints que serão
necessárias para completar o trabalho do Backlog.
O gerente de projetos precisa ser incluído nesse momento, uma vez que o
projeto poderá sofrer alterações de cronograma, e é o mesmo que adequará o que o
Time pode entregar com os requisitos estratégicos do cliente.
Os responsáveis por esta realização são: Time, PO e GP.
Revisar os riscos:
Para Cruz (2013), nesse momento é feito a revisão dos riscos já identificados
anteriormente, podendo ocorrer atualização desta lista conforme as etapas anteriores,
levando em conta os possíveis impactos gerados durante a preparação do ambiente,
definição da velocidade do Time e o tamanho das Sprints.
Se for preciso, o gerente de projetos já pode iniciar a execução de processos
como quantificar, qualificar e planejar as respostas aos riscos.
Os responsáveis por esta realização são: GP, Time e PO.
4.2.4 – Planejamento do Sprint – segunda etapa
No Scrum a reunião referente ao planejamento da Sprint deve ter oito horas de
duração, o usual é fazer a divisão da reunião em duas partes de quatro horas com
objetivos distintos. Na primeira metade da cerimônia, o objetivo é decidir o que será
feito na Sprint, sem desrespeitar o limite de tempo.
Os seguintes processos sugeridos são:
Definir as atividades:
Esse processo no guia PMBOK® é conhecido como definir atividades, já no
Scrum consisti em decompor os itens do Backlog.
As tarefas definidas na primeira parte do trabalho consistem em selecionar os
itens do Backlog pelo Time do Scrum de acordo com a prioridade definida pelo Product
Owner cm base na capacidade do Time, previamente definida.
O responsável por essa atividade é: PO.
Entendimento do Backlog:
Para Cruz (2013), ao selecionar os itens que o Time irá trabalhar durante a
Sprint, o mesmo realiza o entendimento destes itens juntamente com o apoio do Product
Owner. O caminho mais utilizado para isso é quando o Product Owner explica item a
item ao Time do Scrum, e o mesmo faz os questionamentos.
Os responsáveis por essa atividade são: PO e Time.
4.2.5 – Encerramento
Segundo Cruz (2013) define este processo com objetivo formalizar o
encerramento do projeto, garantindo que todo o trabalho foi realizado e aceito pelo
cliente.
Tanto para o Scrum, como para o guia PMBOK®, algumas atividades têm que
ser realizadas para a conclusão do projeto, tais como:
Assinatura de encerramento de contratos ou termo de aceite das entregas;
Atualização de toda a documentação do projeto;
Transferência dos produtos completados, incluindo documentações, aos
clientes;
Coleta final de lições aprendidas e registro para uso futuro em novos projetos.
Nesse processo o gerente deve rever todas as informações do escopo do projeto
antes do encerramento, conferindo e assegurando que todo o trabalho do projeto está
completo e que atingiu seus objetos.
A figura abaixo fortalece mais o entendimento sobre o sequenciamento do ciclo
do Scrum com o guia PMBOK®, servindo de guia para a utilização dos processos de
forma objetiva no ciclo de vida do projeto do início ao fim.
Figura 19 – Distribuição de processos ao longo das fases do ciclo de vida do projeto. Fonte: http://www.fabiocruz.com.br/pmbok5/, acessado dia 11 de novembro de 2015.
Capítulo 5
Conclusão e Trabalhos Futuros
5.1 – Conclusão
Concluímos sob essa análise que as boas práticas no guia PMBOK® prioriza a
documentação do projeto, já o Scrum vive o dia a dia de uma empresa, a entrega e
tomadas de decisões em mudanças no momento, pouco se preocupando com a
documentação engessada do guia PMBOK®. Sendo assim, a junção do guia PMBOK®
com o Scrum possibilita uma melhor documentação dos processos envolvidos no
projeto, facilitando e orientando a utilização dos mesmos pelo Scrum Master, para
condução da sua equipe no desenvolvimento de forma eficaz e preventiva.
O Scrum visa seguir o que foi determinado pelo manifesto ágil que é a
valorização dos indivíduos e suas interações, preocupado no funcionamento do software
e na colaboração do cliente para obter respostas rápidas a mudanças quando necessárias,
que é contraria ao guia PMBOK® que se preocupa com os processos, ferramentas
utilizadas, e documentação impecável, e sempre seguir ao plano inicialmente definido.
Podemos analisar que a junção dos dois modelos descritos inicialmente é
perfeitamente viável ao gerenciamento de um projeto, uma vez que os processos têm
que ser aplicados nos momentos e/ou etapas certas ao longo do processo. Onde o Scrum
pode oferecer a maior agilidade ao guia PMBOK® que por sua vez oferece melhor
prevenção ao projeto. Adequando os dois modelos, gera uma eficaz no gerenciamento
de projetos no momento da utilização de reuniões diárias previstas pelo Scrum,
acrescentando as documentações criadas pelo processo descrito pelo guia PMBOK®.
Logo podemos dizer que muitas das práticas propostas pelo guia PMBOK® são
implícitas no próprio processo do framework Scrum, sendo assim o guia do PMI, sugere
vários tipos de planos, exemplo plano de gerenciamento de riscos, aquisições, etc.,
porém a adequação a cada processo é variável de acordo com a necessidade do projeto
em questão, seguindo orientações apresentadas no guia do PMBOK®, de
responsabilidade compartilhada por todos os membros da equipe.
5.2 – Trabalhos Futuros
Para trabalhos futuros:
Sugere-se um aprofundamento maior em cada área de processos do guia
PMBOK® em comparação com o SCRUM, mostrando as semelhanças ou diferenças
dessas boas práticas em projetos;
Um estudo do envolvendo o PRINCE2 (Projects IN Controlled
Environments), que é uma abordagem baseada nos processos de gerenciamento de
projetos. Fazer o comparativo dele com o guia PMBOK®.
Capítulo 6
Bibliografia
[1] PMBOK, GUIDE. (2013) Um Guia do Conhecimento em Gerenciamento de
Projetos. 5ª ed. Versão em Português.
[2] D’ÁVILA, M., “PMBOK e Gerenciamento de Projetos”, http://www.mhavila.com.br/topicos/gestao/pmbok.html, 2006, (Acesso em 11
agosto 2015).
[3] Agile Manifesto, “Manifesto for Agile Software Development”, Agile Alliance,
http://www.agilemanifesto.org/, 2001, (Acessado em 12 agosto 2015).
[4] Schwaber, K., “Agile Project Management with Scrum”, Microsoft Press, 2004.
[5] Cruz, F., SCRUM e PMBOK® unidos no Gerenciamento de Projetos. Brasport,
2013.
[6] Tavares, A., “Gerência de Projeto com PMBOK e SCRUM. Um estudo de caso”.
Trabalho de Conclusão de curso, Faculdade Cenecista Nossa Senhora dos Anjos,
2008.
[7] Nascimento, A., “O que é SCRUM? ”,
https://www.oficinadanet.com.br/artigo/gerencia/o_que_e_scrum, 2010, (Acessado
em 16 de setembro de 2015).
[8] Sliger, M., “Relating PMBOK Practices to Agile Practices”,
http://www.stickyminds.com/article/relating-pmbok-practices-agile-practices-part-
1-4, 2006, (Acesso em 11 de novembro de 2015).
[9] PRINCE2 Training Organization, “What is PRINCE2? ”,
https://www.prince2.com/uk/what-is-prince2, Copyright ILX Group 2015
(Acessado em 25 de novembro de 2015).
top related