faculdades integradas do vale do ivaí instituto superior ... · o processo de gerenciamento de...
TRANSCRIPT
1
Faculdades Integradas do Vale do Ivaí Instituto Superior de Educação - ICEI
Recredenciada pela Portaria nº. 545 de 11/05/2012 – D.O.U. – 14/05/2012
ALEXANDRE BOEING DIEIMES NUNES DE SOUZA
GERENCIAMENTO DE PROJETOS DE SOFTWARE COM SCRUM E PMBOK
IVAIPORÃ 2013
2
ALEXANDRE BOEING
DIEIMES NUNES DE SOUZA
GERENCIAMENTO DE PROJETOS DE SOFTWARE COM SCRUM E PMBOK
Trabalho de Conclusão de Curso
apresentado a Faculdade Integrada do Vale
do Ivaí, como requisito parcial para obtenção
do título de Tecnólogo em Análise e
Desenvolvimento de Sistemas.
Orientador: Prof. Paulo Ricardo de Araújo
IVAIPORÃ/PR 2013
3
ALEXANDRE BOEING
DIEIMES NUNES DE SOUZA
GERENCIAMENTO DE PROJETOS DE SOFTWARE COM SCRUM E PMBOK
Trabalho de Conclusão de Curso apresentado a Faculdade Integrada do Vale do Ivaí, como requisito parcial para obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas, sob apreciação da seguinte banca examinadora:
Aprovado(a) em _____/_____/_____
________________________________________________ Professor:
________________________________________________
Professor:
________________________________________________ Professor:
4
Você precisa encontrar o que ama. E essa verdade
se aplica tanto aos amantes quanto aos
trabalhadores. O trabalho preenche boa partede sua
vida, e a única maneira de se sentir verdadeiramente
satisfeito é fazer o que acredita ser um ótimo
trabalho. E a única maneira devocê fazer um ótimo
trabalho é amar o que faz. (...) Não se acomode.”
(Steven Paul Jobs – Steve Jobs )
“As únicas grandes companhias que conseguirão ter
êxito são aquelas que consideram os seus produtos
obsoletos antes que os outros o façam.”
(William Henry Gates III – Bill Gates)
5
DEDICATÓRIA
Dedico este trabalho a todos que me ajudaram a cumprir esta árdua
tarefa, com muito esforço e luta.
A minha família, especialmente minha mãe que sempre me incentivou e
apoiou em todas as etapas da minha vida até agora.
Aos amigos que nunca deixaram eu desistir ou desanimar, sempre me
animando e fazendo com que eu seguisse em frente.
Alexandre Boeing
Dedico este trabalho primeiramente a Deus, pois sem Ele, nada seria
possível. Me iluminou todos estes anos que me fez não desistir do meu sonho.
A minha família pelo incentivo, cooperação nesta jornada, pois eles
estavam sempre no do meu lado dando todo apoio e me ensinaram os valor da
vida, da honestidade, humildade e do amor.
Aos meus amigos, em especial aos da Juventude Mariana, pelas
orações e pensamentos positivos para que eu pudesse alcançar meus
objetivos.
Dieimes Nunes de Souza
6
AGRADECIMENTOS
Eu Alexandre Boeing agradeço a minha família por me manter alegre e
inspirado por toda essa caminhada, minha mãe que me apoiou desde o início da
faculdade até agora, me mantendo focado e não deixando abater pelas dificuldades
encontradas no caminho.
Ao meu amigo Dieimes, que enfrentou comigo esse desafio, pesquisando,
aprendendo e se superando a cada etapa do projeto.
Aos amigos que sempre estiveram comigo durante a faculdade, que também
passaram pelas dificuldades de um trabalho de conclusão de curso.
Ao professor Paulo Ricardo de Araújo, por orientar o curso do trabalho
sempre adiante, com muita sabedoria. Um exemplo de dedicação e persistência.
A todo corpo docente, por colaborar com minha formação não só profissional
mas também pessoal.
Eu Dieimes Nunes de Souza agradeçoa Jesus, pelo dom da vida e pela
oportunidade de estar realizando este trabalho. Agradeço por guiar os meus passos,
nos momentos mais difíceis e nos momentos de alegrias e conquistas
A minha família que lutaram junto comigo para que este sonho torna-se
realidade, que se não fosse eles eu não conseguiria concluir este curso, que muitas
vezes eu pensei em desistir mais eles estão sempre do meu lado me dando todo
apoio e falando coisas bonitas como: Você é capaz. Obrigado.
Ao meu amigo e irmão Alexandre Boeing, pelas palavras amigas nas horas
difíceis, pelo auxilio nos trabalhos e dificuldades e principalmente por estarem
comigo nesta caminhada tornando-a mais fácil e agradável.
Ao professor Paulo Ricardo de Araújo por me orientar nesse trabalho, e pelo
exemplo contínuo de dedicação, sabedoria durante o período de nossa convivência.
Para mim, ser orientado por você foi uma satisfação imensa e motivo de muito
orgulho. Obrigado por tudo.
A todo o corpo docente pelos ensinamentos transmitidos. Tenham certeza de
aprendi muito com vocês e que levo em minha bagagem um pouco de cada um.
7
RESUMO
Boeing, Alexandre. Nunes, Dieimes.Gerenciamento de projetos de software com scrum e pmbok. Trabalho de conclusão de curso (superior de tecnologia em Análise e Desenvolvimento de Sistemas) - Faculdades Integradas do Vale do Ivaí. Ivaiporã, 2013.
A necessidade de projetar softwares que tenham qualidade e sejam desenvolvidos rapidamente é desafiador, devido a este fato utiliza-se métodos de desenvolvimento ágil. Nesse sentido, a finalidade deste trabalho é identificar os pontos de compatibilidade entre PMBOK e Scrum. Para isto foram realizados estudos bibliográficos que identificaram características e técnicas que apontam os laços de compatibilidade entre esses dois métodos. Como resultado da pesquisa serão analisados os processos do PMBOK que se encaixam no modelo de projeto Scrum sem que este perda suas características distintas das metodologias tradicionais. Ao final, como resultado de pesquisa e estudo, será apresentado um modelo híbrido contendo o ciclo de vida Scrum incorporado à processos do guia de referência de projetos PMBOK.
Palavras chave: Gerenciamento de Projetos. Scrum. PMBOK.
8
ABSTRACT
Boeing, Alexandre. Nunes, Dieimes.Project management software with scrum and PMBoK. Trabalho de conclusão de curso (superior de tecnologia em Análise e Desenvolvimento de Sistemas) - Faculdades Integradas do Vale do Ivaí. Ivaiporã, 2013. The need to design software that have quality and are developed quickly is challenging, due to this fact we use agile development methods. Accordingly, the purpose of this work is to identify the points of compatibility between PMBOK and Scrum. For this bibliographical studies were conducted that identified characteristics and techniques that link the bonds of compatibility between these two methods. As a result of the research will consider the PMBOK processes that fit the Scrum project template without it losing its distinct features of traditional methodologies. Finally, as a result of research and study, will be presented a hybrid model containing the Scrum lifecycle processes incorporated into some of the reference guide PMBOK project.
Keywords: Project Management. Scrum. PMBOK.
9
SUMÁRIO
Conteúdo 2. FUNDAMENTAÇÃO TEÓRICA ........................................................................... 15
2.1 O QUE É PMBOK ............................................................................................. 15
2.1.1 Processos do Guia PMBOK ..................................................................... 16
2.2 GERENCIAMENTO DE ESCOPO ................................................................. 17
2.2.1 Coletar os requisitos .............................................................................. 18
2.2.2 Definir o Escopo ...................................................................................... 19
2.2.3 Criar EAP - Estrutura Analítica do Projeto ............................................. 19
2.2.4 Verificar Escopo ......................................................................................... 19
2.2.5 Controlar Escopo ....................................................................................... 20
2.3 Gerenciamento de Integração............................................................................ 21
2.3.1 Desenvolver o termo de abertura do projeto ............................................ 22
2.3.2 Desenvolver o termo de abertura do projeto ............................................ 23
2.3.3 Business Case ............................................................................................... 23
2.3.4 Termo de abertura ...................................................................................... 24
2.3.5 Desenvolver o plano de gerenciamento do projeto ................................... 24
2.3.6 Orientar a execução do projeto .................................................................. 25
2.3.7 Realizar o controle integrado de mudanças .................................... 25
2.3.8 Encerrar projeto ou fase ........................................................................... 26
2.4 GERENCIAMENTO DE QUALIDADE ........................................................... 28
2.4.1 Planejar a qualidade .................................................................................. 30
2.4.2 Realizar a garantia da qualidade ............................................................. 31
2.4.3 Auditoria de qualidade .............................................................................. 32
2.4.4 Realizar o controle da qualidade ............................................................. 32
2.5 GERENCIAMENTO DO TEMPO DO PROJETO ......................................... 34
2.5.1 Definir as atividades .................................................................................. 35
2.5.2 Sequenciar as atividades ......................................................................... 36
2.5.3 Estimar os recursos da atividade ............................................................ 36
2.5.4 Estimar as durações da atividade ........................................................... 36
2.5.5 Desenvolver o cronograma ...................................................................... 37
2.5.6 Controlar o cronograma ............................................................................ 38
2.7 GERENCIAMENTO DOS CUSTOS DO PROJETO.................................... 38
2.7.1 Estimar os custos ....................................................................................... 39
10
2.7.2 Determinar o orçamento ........................................................................... 40
2.7.3 Controlar os custos .................................................................................... 40
2.8 GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO ................... 41
2.8.1 Identificar as partes interessadas ........................................................... 42
2.8.2 Planejar as comunicações ....................................................................... 42
2.8.3 Distribuir informações ............................................................................... 43
2.8.4 Gerenciar as expectativas das partes interessadas ............................ 43
2.8.5 Reportar o desempenho ........................................................................... 43
2.9 GERENCIAMENTO DE RECURSOS HUMANOS ...................................... 44
2.9.1 Desenvolver o plano de recursos humanos .......................................... 45
2.9.2 Mobilizar a equipe do projeto ................................................................... 45
2.9.3 Desenvolver a equipe do projeto ............................................................. 46
2.9.4 Gerenciar a equipe do projeto ................................................................. 46
2.10 GERENCIAMENTO DOS RISCOS DO PROJETO ................................... 47
2.10.1 Planejar o gerenciamento dos riscos ................................................... 47
2.10.2 Identificar os riscos .................................................................................. 48
2.10.3 Realizar a análise qualitativa dos riscos .............................................. 49
2.10.4 Realizar a análise quantitativa de riscos ............................................. 49
2.10.5 Planejar as respostas aos riscos .......................................................... 49
2.10.6 Monitorar e controlar os riscos .............................................................. 49
2.11 GERENCIAMENTO DAS AQUISIÇÕES DO PROJETO ......................... 50
2.11.1 Planejar as aquisições ............................................................................ 50
2.11.2 Realizar as aquisições ............................................................................ 51
2.11.3 Administrar as aquisições ...................................................................... 51
2.11.4 Encerrar as aquisições ........................................................................... 51
2.12 SCRUM - METODOLOGIA ÁGIL ............................................................... 52
2.12.1 Surgimento ............................................................................................... 52
2.12.2 Características do Scrum ....................................................................... 53
2.13 SCRUM - METODOLOGIA AGIL PARA DESENVOLVIMENTO DE SOFTWARE ............................................................................................................. 54
2.13.1 Product Backlog .................................................................................... 55
2.13.2 Sprint Backlog ......................................................................................... 56
2.13.3 Product Increment ................................................................................. 57
2.13.4 Sprint Planning Meeting ......................................................................... 57
2.13.5 Scrum Master ........................................................................................... 57
2.13.6 Product Owner ......................................................................................... 58
2.13.7 O Scrum Team ........................................................................................ 58
11
2.13.8 Daily Scrum .............................................................................................. 59
3. DESENVOLVIMENTO ............................................................................................ 61
3.1 SCRUM X PMBOK ........................................................................................... 61
3.1.1 Ciclo de vida Scrum ................................................................................ 61
3.2 INICIO DO PROJETO ...................................................................................... 62
3.2.1 Termo de abertura do projeto .............................................................. 62
3.2.2 Identificação dos Stakeholders ........................................................... 63
3.2.3 Desenvolver o plano de gerenciamento do proje to ....................... 63
3.3 EXECUTANDO O SCRUM .............................................................................. 64
3.4 PLANEJAMENTO SPRINT – PRIMEIRA ETAPA ...................................... 69
3.5 PLANEJAMENTO DA SPRINT – SEGUNDA ETAPA ............................... 74
3.6 NOVA SPRINT .................................................................................................. 83
3.7 CICLO DE VIDA SCRUM COM PROCESSOS PMBOK ............................ 88
Figura 14 - Ciclo de vida Scrum com PMBOK..................................................... 88
CONCLUSÃO ............................................................................................................... 89
REFERENCIAS BIBLIOGRÁFICAS ......................................................................... 91
12
Lista de figuras
Figura 1 - Áreas do conhecimento - Fonte: guia PMBOK ............................... 16
Figura 2 - Processos do guia PMBOK ................. Erro! Indicador não definido.
Figura 3 - Gerenciamento de escopo - Fonte: Guia PMBOK ........................... 21
Figura 4 - Gerenciamento de integração - Fonte: Guia PMBOK ...................... 28
Figura 5 - Gerenciamento de qualidade .............. Erro! Indicador não definido.
Figura 6 - Gerenciamento de tempo - Fonte: Guia PMBOK ............................. 38
Figura 7 - Gerenciamento de custos - Fonte: Guia PMBOK............................. 41
Figura 8 - gerenciamento da comunicação - Fonte: Guia PMBOK ................... 44
Figura 9 - Gerenciamento de recursos humanos - Fonte: Guia PMBOK ......... 47
Figura 10 - Gerenciamento de riscos - Fonte: Guia PMBOK............................ 50
Figura 11 - Gerenciamento de aquisições - Fonte: Guia PMBOK .................... 52
Figura 12 - Ciclo de vida SCRUM - Fonte: http://desenvolvimentoagil.com.br/ 55
Figura 13 - Ciclo de vida Scrum Fonte: www.fabiocruz.com ............................ 62
Figura 14 - Ciclo de vida Scrum com PMBOK- fonte: www.fabiocruz.com ..... 89
13
1. INTRODUÇÃO
O processo de gerenciamento de projetos de software é algo complexo devido
ao seu alto nível de abstração. As características dos projetos de software podem
variar dependendo da característica do software ou do próprio cliente requerente.
Diante dessa necessidade, metodologias de gerenciamento de projetos são
utilizadas.Existem as mais variadas metodologias de projetos para os mais diversos
segmentos da sociedade. Este trabalho irá apresentar duas “metodologias de
gerenciamento de projetos” (PMBOK e SCRUM), sendo a última conhecida como
metodologia ágil, que prezam por fatores como indivíduos e as suas interações,
constante aproximação e feedback dos clientes além de resposta imediata a
mudanças. Dentre as metodologias ágeis uma é voltada especificamente para o
setor de TI (Tecnologia da Informação), no segmento de desenvolvimento de
software, e a outra pode ser aplicada em outros segmentos. Após apresentá-las,
este estudo confronta seus pontos fortes e práticas utilizadas por cada uma delas
além de extrair o que há de melhor, a fim que atendam às necessidades de gestores
que buscam gerenciar projetos de forma efetiva com o mínimo de prazo possível.
Devido à alta complexidade que é exigida no gerenciamento de projetos, uma
grande dose de experiência e assertividade, são fundamentais para aos gerentes de
projetos. Para tal temos uma enorme gama de metodologias a serem aplicadas em
projetos. Com isso gerentes de projeto tendem a ter dificuldades em definir qual é a
melhor metodologia a ser aplicada em seu projeto. Alguns gerentes optam pela
metodologia que ele possui mais experiência, outros optam pela metodologia de
acordo com o perfil do projeto e das premissas reportadas no contrato, alegando que
muitas metodologias não podem ser aplicadas simultaneamente.
14
1.2 OBJETIVOS
1.2.1 Objetivo geral
Este trabalho objetiva identificar os pontos de compatibilidade entre a
metodologias de gerenciamento de projetos Scrum e PMBOK.
1.2.2 Objetivos específicos
• Criar um modelo híbrido utilizando as duas abordagens estudadas.
• Estudar a metodologia ágil de gerência de projetos Scrum.
• Estudar o guia de práticas em gerenciamento de projetos PMBOK
• Realizar uma abordagem comparativa entres as áreas de
conhecimento do PMBOK com a metodologia ágil de projetos Scrum
15
2. FUNDAMENTAÇÃO TEÓRICA
2.1 O QUE É PMBOK
O Project Management Body of Knowledge, também conhecido como PMBOK é um
conjunto de práticas em gerência de projetos levantado pelo Project Management
Institute (Instituto de Gerenciamento de projetos) e constituem a base da
metodologia de gerência de projetos do PMI. Estas práticas são compiladas na
forma de um guia, chamado de Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos, ou Guia PMBOK.
O principal objetivo do Guia PMBOK® é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. Boa prática significaque existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico (Guia PMBOK 4° edição). Figura 1 - Áreas do conhecimento
16
Fonte: guia PMBOK, 2008
2.1.1 Processos do Guia PMBOK
O gerenciamento de projetos é a aplicação de conhecimento, habilidades,
ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos.
O gerenciamento de projetos é realizado através de processos, usando
conhecimento, habilidades, ferramentas e técnicas do gerenciamento de projetos.A
figura abaixo apresenta a natureza dos processos de gerenciamento de projetos em
termos da integração entre os processos, das interações dentro deles e dos
objetivos a que atendem. Esses processos são agregados em cinco grupos,
definidos como os grupos de processos de gerenciamento de projetos(Guia PMBOK
4° edição):
a) Grupo de processos de iniciação
b) Grupo de processos de planejamento
c) Grupo de processos de execução
d) Grupo de processos de monitoramento e controle
e) Grupo de processos de encerramento.
Figura 2 - Processos do guia PMBOK
17
Fonte: gestaodainformacao-ufpr.blogspot.com.br
2.2 GERENCIAMENTO DE ESCOPO
Segundo o Guia PMBOK “O gerenciamento do escopo do projeto inclui os processos
necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas
o necessário, para terminar o projeto com sucesso”. Com base no Guia PMBOK, o
gerenciamento de escopo contém todos os processos para que o projeto seja
bemsucedido, tendo apenas o trabalho necessário e apenas o necessário para que
todos os objetivos sejam atendidos com sucesso, também controlando o que está e
o que não está no projeto. Os processos do Gerenciamento de Escopo são os
seguintes:
a) Coletar os requisitos - O processo de definição e documentação das
necessidades das partes interessadas para alcançar os objetivos do projeto.
b) Definir o escopo - O processo de desenvolvimento de uma descrição detalhada
do projeto e do produto.
c) Criar a EAP - O processo de subdivisão das entregas e do trabalho do projeto em
componentes menores e mais facilmente gerenciáveis.
d) Verificar o escopo -O processo de formalização da aceitação das entregas
18
terminadas do projeto.
e) Controlar o escopo - O processo de monitoramento do progresso do escopo do
projeto e escopo do produto e gerenciamento das mudanças feitas na linha de base
do escopo. (Guia PMBOK®)
Estes processos interagem entre si e também com outras áreas de conhecimento.
Dependendo da necessidade do projeto, cada processo envolve o esforço de uma
ou mais pessoas. Cada processo ocorre pelo menos uma vez em todo o projeto.
Apesar das interfaces bem definidas de cada processo, na prática eles interagem
entre si e se sobrepõem. Dentro de um projeto, a palavra escopo pode se referir ao:
a) Escopo do produto. As características e funções que descrevem um produto,
serviço ou resultado; e/ou
b) Escopo do projeto. O trabalho que precisa ser realizado para entregar um
produto, serviço ou resultado com as características e funções especificadas. (Guia
PMBOK)
Os processos usados para gerenciar o escopo variam de área de aplicação do projeto, normalmente sendo isso definido no ciclo de vida. A definição detalhada do escopo e a subdivisão do trabalho é a linha de base do escopo do projeto, após sua definição, ela é monitorada e controlada no ciclo de vida do projeto. Apesar de não ser um processo distinto no gerenciamento de escopo, o trabalho de produção do escopo do projeto é precedido pelo plano de gerenciamento do projeto, que fornece as diretrizes de como o escopo será definido, documentado, verificado, gerenciado e controlado [...] O plano de gerenciamento do escopo pode ser formal ou informal, altamente detalhado ou conciso, dependendo das necessidades do projeto(Dinsmore, 2004).
2.2.1 Coletar os requisitos
Este processo serve para definir e documentar as funções do projeto e do produto
necessárias para atender às necessidades e expectativas das partes interessadas.
De acordo com o guia“O sucesso do projeto é diretamente influenciado pela atenção
na captura e gerenciamento dos requisitos do projeto e do produto” (Guia PMBOK).
Os requisitos incluem todas as necessidades quantificadas e documentadas,
contendo também as expectativas das partes interessadas, todos os requisitos
obtidos precisam ser analisados, revisados e registrados para serem medidos assim
que o projeto se iniciar. Se os requisitos não forem atendidos, o projeto alcançará os
19
resultados esperados. Coletar os requisitos também inclui gerenciar as expectativas
do cliente. Com base neles, feito o planejamento de qualidade e custo e o
cronograma.
2.2.2 Definir o Escopo
Neste processo, é desenvolvida uma descrição detalhada do projeto e do produto.
Segundo o Guia PMBOK:
Definir o escopo é processo de desenvolvimento de uma descrição detalhada do projeto e do produto. A preparação detalhada da declaração do escopo é critica para o sucesso e baseia-se nas entregas principais, premissas e restrições que são documentadas durante a iniciação do projeto (Vargas, 2009).
Conforme o que foi citado do Guia PMBOK, o processo de definir o escopo é
extremamente importante para o projeto, pois nele está documentado todas as
premissas, riscos e restrições que deverão ser cumpridas durante o
desenvolvimento.
2.2.3 Criar EAP - Estrutura Analítica do Projeto
EAP é a estrutura analítica do projeto, criar a EAP é um processo que subdivide o
trabalho e as entregas do projeto para componentes menores, de gerenciamento
mais fácil, a EAP é totalmente orientada às entregas do trabalho pela equipe. Cada
nível da EAP representa uma definição gradualmente detalhada da definição do
trabalho do projeto (Guia PMBOK 4° edição).
Todo o trabalho é divido em pacotes de trabalho[…] O trabalho planejado é contido dentro dos componentes de nível mais baixo da EAP, que são chamados de pacotes de trabalho. Um pacote de trabalho pode ser agendado, ter seu custo estimado, monitorado e controlado[…] com o planejamento de pacotes de trabalho o gerenciamento torna-se mais fácil e aprimorado (Menezes, 2003).
2.2.4 Verificar Escopo
20
O processo de verificar o escopo é o processo de aceitação das entregas concluídas
do projeto, o processo inclui a revisão das entregas com o cliente ou patrocinador,
afim de verificar se estão satisfazendo as necessidades e para receber a aceitação
formal das mesma. De acordo com o Guia PMBOK, o processo de verificar o Escopo
difere com o controle de qualidade, pois o controle de qualidade está interessado na
precisão das entregas e no alcance dos requisitos de qualidade especificados por
ela mesmo, normalmente a controle de qualidade é feito antes da verificação do
escopo, mas estes processos podem ser executados paralelamente. (Guia PMBOK
4° edição).
2.2.5 Controlar Escopo
O processo de controlar o escopo é responsável pelo monitoramento do andamento
do escopo do projeto e também por suas mudanças. Este processo também
assegura que qualquer mudança na linha de base do projeto, passe pelo processo
de Realizar o controle integrado de mudanças. Ele é integrado com os outros
processos de mudanças. Mudanças de escopo costumam ser inevitáveis, portanto,
exigindo algum tipo de controle de mudanças (Guia PMBOK 4° edição).
Figura 3 - Gerenciamento de escopo
21
Fonte: Guia PMBOK, 2008
2.3 Gerenciamento de Integração
Segundo o Guia PMBOK o “O Gerenciamento da integração do projeto inclui os
processos e as atividades necessárias para identificar, definir, combinar, unificar e
coordenar os vários processos e atividades dos grupos de processos de
gerenciamento”. Conforme o que foi citado, o Gerenciamento de Integração serve
para ter-se o controle e melhor coordenar as fases e atividades que são necessárias
para o termino do projeto, gerenciar as expectativas das partes interessadas quanto
ao atendimento dos requisitos. O gerenciamento de integração resume-se em vários
processos, sendo eles:
a) Desenvolver o termo de abertura do projeto - Documento que formaliza o início
do projeto, tendo nele toda a documentação e requisitos iniciais que serão atendidos
satisfazendo as partes interessadas.
b) Desenvolver o plano de gerenciamento do projeto - Documentação das ações
que serão realizadas para definir, integrar e coordenar todos os planos auxiliares.
c) Orientar e gerenciar a execução do projeto - A realização do trabalho descrito
no plano de gerenciamento de projeto.
22
d) Monitorar e controlar o trabalho do projeto - Revisão e regulação do progresso
em atender os objetivos de desempenho propostos no plano de gerenciamento de
projeto.
e) Realizar o controle integrado de mudanças - Controle de todas as solicitações
de mudanças do projeto, abrangendo desde requisitos até o plano de gerenciamento
de projeto.
f) Encerrar o projeto ou fase - Finalização formal de todas as atividades ou grupo
de processos de alguma parte do plano de gerenciamento do projetos.
Um bom gerenciamento de integração é evidentemente necessário quando
processos distintos interagem, necessitando por exemplo, de uma estimativa de
risco, custo e tempo de desenvolvimento de um projeto, sendo que três diferentes
setores vão ter que trabalhar juntos para obter-se um único resultado.
A maioria dos praticantes de gerenciamento de projetos aplicam as técnicas e habilidades de gerenciamento para obter o desempenho esperado dos processos, entretanto, a ideia de que um processo distinto não é exigido não significa que ele não deve ser discutido com a equipe, o gerente sempre deve discutir todos os processos e nível de execução para cada fase do projeto, mantendo o mesmo rigor para todos os processos e fases(Kerzner, 2002).
A seguir, será explicado com mais detalhes cada um dos processos do
gerenciamento de integração, expondo as partes mais importantes de cada um
deles.
2.3.1 Desenvolver o termo de abertura do projeto
O documento de abertura de projeto estabelece uma parceria entre organização
executora (empresa desenvolvedora) e organização solicitante (cliente), que
formalmente inicia o projeto. Um gerente de projeto é solicitado preferencialmente
antes do início do desenvolvimento do termo de abertura do projeto para
acompanhar o desenvolvimento do mesmo, é muito importante o que o gerente de
23
projetos participe do desenvolvimento do termo, uma vez que este supre o gerente
com autoridade para usar recursos nas atividades do projeto.
O termo de projeto é desenvolvido por alguém externo a ele, que normalmente são
as pessoas que vão financiar o projeto. Eles criam o termo ou passam a tarefa para
o gerente de projetos, assim que o termo estiver pronto, o iniciador do projeto o
assina e dá o início formal do projeto. De acordo com o Guia PMBOK:
Projetos são autorizados devido a necessidade de negócios internos ou a influência externa”, muitas vezes é necessário uma análise de necessidades ou a descrição da situação que o projeto tratará, pois uma vez assinado, o projeto se conecta à estratégia e ao trabalho em progresso da organização.
2.3.2 Desenvolver o termo de abertura do projeto
A primeira coisa a ser feita é a declaração do trabalho (DT), que é uma descrição
dos produtos e serviços que o projeto irá oferecer. Para projeto internos a
declaração é feita pelo iniciador ou patrocinador do trabalho com base nos requisitos
das necessidades de negócios, produtos ou serviços. Para projetos externos a
declaração pode vir por meio de uma licitação feita pelo cliente, por exemplo,
solicitação de preços, solicitação de informações ou até como parte de um contrato.
A declaração de trabalho informa (Kerzner, 2002):
a) Necessidade de negócios: A necessidade de negócios de uma organização
pode ser definida por demanda de mercado, regulamentação do governo, avanço
tecnológico ou requisito legal.
b) Descrição de escopo do produto: Documenta as características do produto que
será resultado do projeto, deve documentar também a relação entre o que está
sendo criado com a necessidade de negócios que o projeto se dedicará.
c) Plano estratégico: Todos os projetos devem contribuir com os objetivos
estratégicos da organização. O plano estratégico é levado em conta quando forem
feitas decisões em seleções de prioridade dos projetos.
2.3.3 Business Case
24
O business case é muito semelhante a uma análise de viabilidade. É um documento
que fornece as informações de negócio, focando sempre no custo benefício, nele ao
contidas também a necessidade do projeto e análise de custo. O business case
pode ser escrito pelo cliente em algumas situações.
2.3.4 Termo de abertura
Segundo o Guia PMBOK 4° edição “o termo de abertura do projeto documenta as
necessidades do negócio, o entendimento atual das necessidades do cliente”,
portanto, ele deve documenta o propósito do projeto, o serviço ou resultado que o
projeto pretende satisfazer, tais como:
a) Propósito ou justificativa do projeto;
b) Requisitos de alto nível;
c) Objetivos mensuráveis do projeto;
d) Descrição do projeto em alto nível;
e) Riscos de alto nível;
f) Resumo do cronograma de marcos;
g) Resumo do orçamento;
h) Requisitos de aprovação de projeto;
i) Gerente do projeto, responsabilidade, nível de autoridade designados;
j) Nome da autoridade ou patrocinador ou outra pessoa que autoriza o
termo de abertura do projeto;
2.3.5 Desenvolver o plano de gerenciamento do proje to
Desenvolver o plano de gerenciamento do projeto é o processo de documentação
das açõesnecessárias para definir, preparar, integrar e coordenar todos os planos
auxiliares”. Com base no que foi citado, o Guia PMBOK diz que desenvolver o plano
de gerenciamento do projeto é documentar como ele executado, monitorado e
encerrado. O conteúdo do plano de gerenciamento do projeto varia dependendo da
área de aplicação do mesmo. Através de uma série de processos integrados o plano
25
de gerenciamento do projeto é desenvolvido, sendo progressivamente elaborado por
meio de atualizações controladas e aprovadas pelo controle integrado de
mudanças(Kerzner, 2002).
2.3.6 Orientar a execução do projeto
A orientação da execução do projeto é o processo de realização do trabalho definido
no plano de gerenciamento do projeto para atingir os objetivos. A seguir, algumas
atividades que incluem a orientação da execução do projeto:
a) Criar as entregas do projeto;
b) Formar, treinar e gerenciar os membros da equipe designados para o
projeto;
c) Obter, gerenciar e usar recursos, inclusive materiais, ferramentas,
equipamentos e instalações;
d) Implementar os padrões e os métodos planejados;
e) Estabelecer e gerenciar os canais de comunicação do projeto, tanto
externos como internos à equipe do projeto;
f) Gerar dados do projeto, tais como custo, cronograma, progresso técnico e
da qualidade e informações sobre o andamento do projeto para facilitar
previsões;
g) Emitir solicitações de mudanças e adaptar mudanças aprovadas no escopo
do projeto, planos, e ambiente;
h) Gerenciar riscos e implementar atividades de resposta a riscos;
i) Gerenciar vendedores e fornecedores;
j) Coletar e documentar lições aprendidas e implementar as atividades de
melhorias nos processos aprovados. (Guia PMBOK 4°)
2.3.7 Realizar o controle integrado de mudanças
26
Realizar o controle integrado de mudanças é o processo que controla e gerência todas as solicitações, aprovação, gerenciamento em entregas, ativos de processos organizacionais, documentos do projeto e plano de gerenciamento do projeto. O processo de realizar o controle integrado de mudanças é mantido do início ao fim do projeto. O plano de gerenciamento de projeto, a declaração do escopo e outras entregas só são incorporadas no projeto após passarem pelo controle integrado de mudanças, garantindo assim que somente mudanças aprovadas e revisadas serão aceitas no projeto (Keelling, 2002).
O processo de realizar o controle integrado de mudanças inclui as seguintes
atividades de gerenciamento de mudanças, diferenciando o nível de detalhes em
cada atividade:
a) Influenciar os fatores que tentam evitar o controle integrado de mudanças
para que somente as mudanças aprovadas sejam implementadas;
b) Revisar, analisar e aprovar as solicitações de mudança imediatamente, que
é essencial já́ que uma decisão lenta pode afetar negativamente o tempo,
custo ou viabilidade de uma mudança;
c) Gerenciar as mudanças aprovadas;
d) Manter a integridade das linhas de base liberando somente as mudanças
aprovadas para
serem incorporadas ao plano de gerenciamento do projeto e aos documentos
do projeto;
e) Revisar, aprovar ou rejeitar todas as ações corretivas e preventivas
recomendadas;
f) Coordenar as mudançasatravés de todo o projeto (por exemplo, uma
mudança propostano cronograma frequentemente afetará o custo, o risco, a
qualidade e a equipe);
g) Documentar o impacto completo das solicitações de mudança. (Guia
PMBOK 4° edição)
2.3.8 Encerrar projeto ou fase
De acordo com Keelling (2002)“Encerrar o projeto ou fase é o processo de
27
finalização de todas as atividades, de todos os grupos de processos de
gerenciamento do projeto, para encerrar formalmente o projeto ou a fase”. Conforme
o que citado, o Guia PMBOK determina que no processo de encerrar projeto ou fase
o gerente revisa todas as fases anteriores do projeto e certifica que o mesmo
alcançou os objetivos. Esse processo também serve para documentar e investigar
os motivos de ações realizadas caso o mesmo tenha sido encerrado antes do seu
término. Isso inclui todas as atividades para administrar o encerramento do projeto
ou de uma fase, inclusive metodologias passo a passo que tratam das:
a) Ações e atividades necessárias para satisfazer a conclusão ou critérios de
saída para a fase ou o projeto;
b) Ações e atividades necessárias para transferir os produtos, serviços ou
resultados do projeto para a próxima fase ou produção e/ou operações e
c) Atividades necessárias para coletar registros do projeto ou da fase, auditar o
sucesso ou fracasso do projeto, coletar lições aprendidas e arquivar
informações do projeto para ouso futuro da organização. (Guia PMBOK 4°
edição)
Figura 1 - Gerenciamento de integração
28
Fonte: Guia PMBOK, 2008
2.4 GERENCIAMENTO DE QUALIDADE
O gerenciamento de qualidade inclui os processos responsáveis pela garantia que o
projeto satisfaça as necessidades do cliente. Os processos deste gerenciamento são
iterativos, eles procuram garantir a melhoria contínua das atividades durante todo o
projeto. A seguir, um resumo dos três processos que envolvem este gerenciamento,
segundo o Guia PMBOK 4° edição:
a) Planejar a qualidade - O processo de identificar os requisitos e/ou padrões
de qualidade do projeto e do produto, bem como documentar de que modo o
projeto demonstrará a conformidade.
b) Realizar a garantia da qualidade - O processo de auditoria dos requisitos
de qualidade e dos resultados das medições de controle de qualidade para
garantir que sejam usados os padrões de qualidade e as
definiçõesoperacionais apropriadas.
29
c) Realizar o controle da qualidade - O processo de monitoramento e
registro dos resultados da execução das atividades de qualidade para avaliar
o desempenho e recomendar as mudanças necessárias.
O gerenciamento de qualidade é aplicado em projetos de qualquer origem, no entanto, as medidas e técnicas de qualidade do produto variam de acordo com sua natureza, por exemplo, as técnicas e medidas de qualidade de um desenvolvimento de software diferem do projeto de uma construção de uma usina nuclear, mas as abordagens de gerenciamento são as mesmas paras as duas situações, se algum requisito deixar de ser atendido, poderá acarretar graves prejuízos a qualquer parte interessada(Keelling, 2002).
De acordo com o Guia PMBOK, o gerenciamento de qualidade moderno, os
seguintes tópicos são abordados:
a) Satisfação do cliente: Entender, avaliar, definir e gerenciar as expectativas para
que os requisitos do cliente sejam atendidos. Para isso, é necessária uma
combinação de conformidade com os requisitos (para garantir que o projeto produza
o que ele foi criado para produzir) e adequação ao uso (o produto ou serviço devem
satisfazer as necessidades reais).
b) Prevenção ao invés de inspeção: Um dos princípios fundamentais do moderno
gerenciamento da qualidade determina que a qualidade deve ser planejada,
projetada e incorporada — em vez de inspecionada. O custo de prevenir os erros
geralmente é muito menor do que o custo de corrigí-lós quando são encontrados
pela inspeção.
c) Melhoria continua: O ciclo PDCA (planejar-fazer-verificar-agir) é a base para a
melhoria da qualidade conforme definida por Shewhart e modificada por Deming.
Além disso, as iniciativas de melhoria da qualidade empreendidas pela organização
executora, tais como GQT e Seis Sigma devem aprimorar a qualidade do
gerenciamento do projeto e também a qualidade do produto do projeto. Os modelos
de melhoria de processos incluem Malcolm Baldrige, Modelo organizacional de
maturidade em gerenciamento de projetos (Organizational Project Management
Maturity Model, OPM3®) e Modelo integrado de maturidade da capacidade
30
(Capability Maturity Model Integrated, CMMI®).
d) Responsabilidade da gerência: O sucesso exige a participação de todos os
membros da equipe do projeto, mas continua sendo a responsabilidade da gerência
fornecer os recursos necessários ao êxito.
2.4.1 Planejar a qualidade
O processo de planejar a qualidade, de acordo com o Guia PMBOK tem a seguinte
definição: [...]identificação dos requisitos e/ou padrões de qualidade do projeto e do
produto, além da documentação de como o projeto demonstrará a
conformidade.Este processo dever ser executado em paralelo com o restantes
processos de planejamento do projeto. Toda mudança no projeto para atender a
qualidade, pode exigir custo, ajustes no cronograma e deve receber uma análise de
riscos de seus impactos nos planos (Guia PMBOK 4° e dição). A seguir, estarão
descritas algumas técnicas utilizadas para execução deste processo:
a) Análise de custo-benefício: De acordo com o Guia PMBOK “Os principais
benefícios de cumprir os requisitos de qualidade podem incluir menos retrabalho,
maior produtividade, custos mais baixos e aumento da satisfação das partes
interessadas”. É realizado um business case para cada atividade de qualidade, para
comparar o custo da etapa com o benefício esperado.
b) Custo da qualidade: O custo da qualidade inclui todos os gastos com
investimentos na prevenção contra falhas nos requisitos e o não cumprimento dos
mesmos. De acordo com o Guia PMBOK os custos com falhas de qualidade são
categorizados da seguinte maneira: “Os custos de falhas geralmente são
categorizados como internos (encontrados pelo projeto) e externos (encontrados
pelo cliente). Os custos de falhas tambémsão chamados de custos da má́
qualidade.” (Guia PMBOK).
c) Benchmarking: De acordo com o Guia PMBOK"Benchmarking envolve a
comparação de práticas de projetos reais ou planejados com as de projetos
31
comparáveis para identificar as melhores práticas, gerar ideias para melhorias e
fornece uma base para medir o desempenho".
No fim desse processo de planejar a qualidade, se obtém o plano de gerenciamento
de qualidade, que terá as informações de como a equipe de gerenciamento de
projeto implementará a política de qualidade da organização executora. Também é
um documento auxiliar do plano de gerenciamento de projetos. De acordo com
Keeling:
O plano de gerenciamento da qualidade pode ser formal ou informal, altamente detalhado ou estruturado em termos gerais. O estilo e os detalhes são determinados pelos requisitos do projeto. O plano de gerenciamento da qualidade deve ser revisado na parte inicial do projeto para garantir que as decisões sejam baseadas em informações precisas. As vantagens dessa revisão incluem a redução dos custos e dos atrasos no cronograma causados pelo retrabalho(Keelling, 2002).
2.4.2 Realizar a garantia da qualidade
Realizar a garantia da qualidade tem como objetivo auditar os requisitos de
qualidade e os resultados das medições do controle de qualidade, para certificar que
estejam usando os padrões de qualidade e definições operacionais apropriados.
O suporte da garantia da qualidade, independentemente do título da unidade, pode ser fornecido à equipe do projeto, à gerência da organização executora, ao cliente ou ao patrocinador, bem como a outras partes interessadas que não estejam envolvidas ativamente no trabalho do projeto (Vargas, 2009)
O processo de realizar a garantia de qualidade também inclui a melhoria contínua do
processo, que é uma forma iterativa de melhorar a qualidade de todos os processos.
Essa melhoria contínua elimina processos que não agregam valor ao projeto,
permitindo que os processos sejam operados com níveis mais altos de eficiência e
eficácia.
32
2.4.3 Auditoria de qualidade
Esta técnica consiste numa revisão estruturada afim de determinar se as atividades
do projeto estão cumprindo as políticas, os processos e os procedimentos da
organização e do projeto. De acordo com o Guia PMBOK, os objetivos dessa
auditoria são:
a) Identificar todas as boas/melhores práticas que estão sendo
implementadas;
b) Identificar todas as lacunas/deficiências;
c) Compartilhar as boas práticas utilizadas ou implementadas em projetos
similares na organização e/ou no setor;
d) Oferecer apoio proativo de forma positiva para melhorar a implementação
de processos, a fim de ajudar a equipe a aumentar a produtividade e
e) Destacar as contribuições de cada auditoria no repositório de lições
aprendidas da organização.
Por fim, este processo inclui adotar ações para aumentar a eficácia e a eficiência
dos processos e procedimentos da organização executora. Solicitações de
mudanças são muito comuns com o término deste processo, por meio do controle
integrado de mudanças, são aderidas ou rejeitadas as alterações solicitadas.
2.4.4 Realizar o controle da qualidade
Este processo tem como objetivo o monitoramento e registro dos resultados da
execução das atividades de qualidade para avaliar o desempenho e recomendar as
mudanças necessárias. De acordo com o guia PMBOK, 2008:
Os padrões de qualidade incluem os processos do projeto e as metas do produto. Os resultados do projeto incluem as entregas e os resultados do gerenciamento do projeto, tais como desempenho de custos e de prazos. O controle da qualidade em geral é realizado por um departamento de controle de qualidade ou uma unidade da organização com nome semelhante.
33
As ações do processo de realizar o controle da qualidade, identificam as causas da
baixa qualidade e recomendam e/ou executam ações paraelimina-las. É necessário
que a equipe de gerenciamento de projeto tenha conhecimento prático de controle
estatístico de qualidade, para ajudar a avaliar as saídas do controle da qualidade.
De acordo com o Vargas (2009), a equipe precisa conhecer a diferença entre os
seguintes termos:
a) Prevenção (manter os erros fora do processo) e inspeção (manter os erros
fora do alcance do cliente).
b) Amostragem de atributos (o resultado está́ em conformidade ou não está em
conformidade) e amostragem de variáveis (o resultado é classificado em uma
escala continua que mede o grau de conformidade).
c) Tolerâncias (intervalo especificado de resultados aceitáveis) e limites de
controle (limites que podem indicar se o processo está fora de controle).
Figura 5 - Gerenciamento de qualidade
Fonte: Guia PMBOK, 2008
34
2.5 GERENCIAMENTO DO TEMPO DO PROJETO
O gerenciamento do tempo do projeto lida com os processos que garantirão o
termino pontual do projeto. De acordo com o Guia PMBOK, os processos que fazem
parte desse gerenciamento são os seguintes:
a) Definir as atividades : O processo de identificação das
açõesespecíficas a serem realizadas para produzir as entregas do
projeto.
b) Sequenciar as atividades: O processo de identificação e
documentação dos relacionamentos entre as atividades do projeto.
c) Estimar os recursos da atividade: O processo de estimativa dos
tipos e quantidades de material, pessoas, equipamentos ou suprimentos
que serãonecessários para realizar cada atividade.
d) Estimar as durações da atividade: O processo de estimativa do
número de períodos de trabalho que serãonecessários para terminar
atividades específicas com os recursos estimados.
e) Desenvolver o cronograma: O processo de análise das sequências
das atividades, suas durações, recursos necessários e restrições do
cronograma visando criar o cronograma do projeto.
f) Controlar o cronograma: O processo de monitoramento do
andamento do projeto para atualização do seu progresso e
gerenciamento das mudanças feitas na linha de base do cronograma.
Estes processos interagem entre si e também com outras áreas de conhecimento.
Dependendo da necessidade do projeto, cada processo envolve o esforço de uma
ou mais pessoas. Cada processo ocorre pelo menos uma vez em todo o projeto.
35
Apesar das interfaces bem definidas de cada processo, na prática eles interagem
entre si e se sobrepõem (Keelling, 2002).
2.5.1 Definir as atividades
O processo de definir as atividades tem como função identificar as ações específicas
para serem realizadas para produzir as entregas do projeto. Após o processo da
criação da EAP (estrutura analítica do projeto), são identificadas as entregas do nível
mais baixo da EAP, os pacotes de trabalho. Estes são decompostos em atividades
que representam o que terá de ser feito para completar o pacote de trabalho. As
atividades fornecem uma base para estimativa, desenvolvimento do cronograma,
execução, monitoramento e controle do trabalho do projeto.Com o término desse
processo são gerados três itens, o primeiro é a lista de atividades (Vargas, 2009):
A lista das atividades é uma lista abrangente que inclui todas as atividades necessárias no projeto. Inclui o identificador e uma descrição do escopo do trabalho de cada atividade em detalhe suficiente para assegurar que os membros da equipe entendam qual trabalho precisa ser executado (Guia PMBOK 4° edição).
O segundo item gerado por este processo são os atributos das atividades. Que de
acordo com o Guia PMBOK é o seguinte:
“Os atributos ampliam a descrição da atividade através da identificação dos múltiplos componentes associados a cada atividade. Os componentes de cada atividade evolvem através do tempo. Durante os estágios iniciais do projeto, eles incluem o identificador (ID) da atividade, o ID da EAP e o nome da atividade; quando completos podem incluir códigos das atividades e sua descrição, atividades predecessoras, sucessoras, relaçõeslógicas, antecipações e esperas, requisitos de recursos, datas impostas, restrições e premissas. Podem ser usados para identificar a pessoa responsável pela execução do trabalho, áreageográfica, ou local onde o trabalho tem que ser realizado e o tipo de atividades como o nível de esforço (NDE), esforço distinto e esforçodistribuído.
Por fim, o terceiro e último item gerado pelo processo de definir as atividade é,
segundo o Guia PMBOK, é a lista de marcos:
36
Um marco é um ponto ou evento significativo no projeto. A lista dos marcos identifica todos os marcos do projeto e indica se os mesmos sãoobrigatórios, tais como aqueles exigidos por contrato, ou opcionais, tais como os baseados em informaçãohistórica.
2.5.2 Sequenciar as atividades
De acordo com Vargas (2009) “sequenciar as atividades é processo de identificação
e documentação dos relacionamentos entre as atividades do projeto”. Conforme o
que foi citado, após o processo de definir as atividades, é feito a documentação dos
relacionamentos entre elas. Estas são ligadas por relações lógicas, cada atividade é
relacionada com sua antecessora e sua sucessora, com exceção da primeira e da
última atividade. O sequenciamento pode ser feito através de ferramentas
automatizadas(softwares) ou técnicas manuais.
2.5.3 Estimar os recursos da atividade
O processo de estimar os recursos da atividade é utilizado para estimar os tipos e
quantidades de materiais, pessoas, equipamentos ou suprimentos para realizar uma
atividade. Um software de gerenciamento de recursos pode ser utilizado para auxiliar
no processo, ele é capaz de auxiliar no planejamento, organização e gerenciamento
do pool de recursos e no desenvolvimento das estimativas dos recursos. O Guia
PMBOK 4° também afirma que “Dependendo da sofistica ção do software, a estrutura
analítica de recursos, a disponibilidade de recursos, as taxas dos recursos e os
várioscalendários dos recursos podem ser definidos para apoiar a otimização do seu
uso”.
2.5.4 Estimar as durações da atividade
Segundo o Vargas (2009) o processo de estimar as durações das atividades define-
se em: "Estimar as durações da atividade é o processo de estimativa do número de
períodos de trabalho que serão necessários para terminar as atividades específicas
com os recursos estimados".
Para se fazer a estimativa da duração das atividades, são utilizadas informações do
escopo do projeto, tipos de recursos necessários, quantidades estimadas de
37
recursos e calendários de recursos. A estimativa é feita progressivamente e
considera a qualidade e a disponibilidade dos dados de entrada, ou seja, quanto
mais elabora já estiver o projeto, mais precisa será a estimativa. Exemplo de
estimativa retirado do Guia PMBOK, 2008:
Conforme o trabalho de engenharia e planejamento do projeto se desenvolve, dados mais detalhados e precisos se tornam disponíveis e a precisão das estimativas de duração melhora. Portanto, a estimativa da duração pode ser assumida como sendo progressivamente mais precisa e de melhor qualidade.
De acordo com o Guia PMBOK pode-se usar um software para gerenciar este
processo:
A maior parte dos softwares de gerenciamento de projetos para elaboração de cronogramas manipulará essa situaçãoatravés do uso de um calendário do projeto e calendários alternativos de recursos de trabalho-período que são normalmente identificados pelos recursos que requerem períodos de trabalho específicos. Além da lógica de sequenciamento, as atividades serão executadas de acordo com o calendário do projeto e os calendários de recurso apropriados.
2.5.5 Desenvolver o cronograma
O processo de desenvolvimento do cronograma é um dos mais importantes do
Gerenciamento de tempo, pois nele é definido a data de início e término de todas as
atividades planejadas no projeto. O Guia PMBOK define este processo da seguinte
maneira:
Desenvolver o cronograma é o processo de análise de sequências das atividades, suas durações, recursos necessários e restrições do cronograma visando criar o cronograma do projeto. A entrada das atividades, durações e recursos na ferramenta de elaboração de cronograma gera um cronograma com datas planejadas para completar as atividades do projeto.
O desenvolvimento de um cronograma é frequentemente iterativo, devido à
dificuldade na previsão de quanto tempo a equipe levará para cumprir cada
atividade. A precisão de um cronograma está diretamente relacionada ao nível de
experiência da pessoa que estimará as durações das atividades, quanto mais
preciso for, mais realista será o cronograma. Um cronograma realista é revisado e
mantido durante todo o decorrer do projeto.
38
2.5.6 Controlar o cronograma
Controlar o cronograma é o processo que faz o monitoramento do andamento do
projeto, para atualização do seu progresso e gerenciamento das mudanças feitas na
linha de base do cronograma. O controle de cronograma está relacionado a:
a) Determinação da situação atual do cronograma do projeto;
b) Influencia nos fatores que criam mudanças no cronograma;
c) Determinação de que o cronograma do projeto mudou;
d) Gerenciamento das mudanças reais conforme ocorrem.
Figura 6 - Gerenciamento de tempo -
Fonte: Guia PMBOK, 2008
2.7 GERENCIAMENTO DOS CUSTOS DO PROJETO
O gerenciamento de custos do projeto inclui processos de estimativa, orçamentos e
controle de custos, a seguir, um resumo dos processos que envolvem este
gerenciamento, segundo o Guia PMBOK, 2008:
a) Estimar os custos - O processo de desenvolvimento de uma estimativa de
custos dos recursos monetáriosnecessários para terminar as atividades do
39
projeto.
b) Determinar o orçamento - O processo de agregação dos custos
estimados de atividades individuais ou pacotes de trabalho para estabelecer
uma linha de base autorizada dos custos.
c) Controlar os custos - O processo de monitoramento do andamento do
projeto para atualização do seu orçamento e gerenciamento das mudanças
feitas na linha de base dos custos.
Em projetos de menor escopo, os processos de gerenciamento de custo são tão
fortemente interligados que geralmente são feitos por uma única pessoa, em um
curto prazo de tempo. Também estão associados com um trabalho já produzido pela
equipe de gerenciamento, que de acordo com Vargas (2009) são:
Esse esforço é parte do processo Desenvolver o plano de gerenciamento do projeto, que produz um plano de gerenciamento dos custos que delimita o formato e estabelece o critério para o planejamento, estruturação, estimativa, orçamento e controle dos custos do projeto.
2.7.1 Estimar os custos
Segundo o Guia PMBOK, “estimar os custos é o processo de desenvolvimento de
uma estimativa dos recursos monetários necessários para executar as atividades do
projeto”. As estimativas de custo são baseadas nas informações conhecidas em um
determinado momento, elas incluem a identificação e as considerações das
alternativas de custo para iniciar e terminar um projeto.
Os custos geralmente são expressados através de unidades de alguma moeda
(dólar, real, euro, etc.). Mas podem ser representados através de horas ou dias de
serviço, afim de eliminar os efeitos das flutuações das moedas. Estimar os custos é
um processo iterativo, ele se refina e aprimora de acordo com o avanço do ciclo de
vida do projeto, dificilmente os custos estimados no início do projeto serão precisos.
As fontes de informações para este processo, derivam dos resultados obtidos de
outras áreas de conhecimento, após serem levantadas, essas informações sevem
como entradas para a estimativa de custo. Os custos que serão estimados são para
40
todo o projeto, não limitando-se apenas a mão de obra, materiais, equipamentos,
serviços e instalações mas também para provisões em caso de inflação e recursos
de contingência. Conforme diz o Guia PMBOK, “Uma estimativa de custo é uma
avaliação quantitativa dos custos prováveis dos recursos necessários para completar
a atividade”.
2.7.2 Determinar o orçamento
O processo de determinar o orçamento tem a finalidade de agregar os custos
estimados de atividades individuais ou pacotes de trabalho para estabelecer uma
linha de base dos custos autorizada, linha que inclui todos os orçamentos
autorizados mas exclui as reservas de orçamento.
De acordo com o Guia PMBOK “Os orçamentos do projeto compõem os recursos
financeiros autorizados para executar o projeto. O desempenho dos custos do
projeto será́ medido em relação ao orçamento autorizado”.O do processo de
determinar o orçamento é a linha de base do desempenho de custos, que segundo o
Guia PMBOK é o seguinte:
A linha de base do desempenho de custos é um orçamento no termino autorizado, sincronizado com o tempo, para medir, monitorar e controlar o desempenho de custos geral do projeto. É desenvolvido como um acumulo dos orçamentos aprovados por período de tempo e é tipicamente mostrado numa curva com formato em S. Na técnica de gerenciamento do valor agregado, a linha de base do desempenho de custos é chamada de linha de base da medição do desempenho.
2.7.3 Controlar os custos
Controlar os custos é o processo de monitoramento de controle do progresso do
projeto para a atualização dos custos e orçamentos feitos na linha de base de
custos. Qualquer aumento no orçamento autorizado só pode ser alterado após
passar pelo Controle integrado de mudanças. Segundo Dinsmore (2004):
Monitorar os gastos dos recursos financeiros sem se considerar o valor do trabalho sendo realizado para tais gastos tem pequeno valor para o projeto, a não ser permitir que a equipe fique dentro dos limites dos recursos financeiros autorizados. Consequentemente, muito do esforço desprendido no controle de custos envolve a análise da relação entre o consumo dos fundos do projeto e o trabalho físico sendo realizado para tais gastos. A
41
chave para o controle eficaz de custos é o gerenciamento da linha de base do desempenho de custos aprovada e as mudanças na mesma.
O processo de controlar os custos também inclui:
a) Influenciar os fatores que criam mudanças na linha de base de custos autorizada;
Assegurar que todas as solicitações de mudanças sejam feitas de maneira oportuna;
b) Gerenciar as mudanças reais conforme ocorrem;
c) Assegurar que os gastos de custos não excedam os recursos financeiros
autorizados, por período e total do projeto;
d) Monitorar o desempenho de custos para isolar e entender as variações a partir da
linha de base de custos;
e) Monitorar o desempenho do trabalho em relação aos recursos financeiros gastos;
f) Prevenir que mudançasnão aprovadas sejam incluídasno relato do custo ou do
uso de recursos;
g) Informar as partes interessadas apropriadas a respeito de mudanças aprovadas e
custos associados;
h) Agir para manter os excessos de custos não previstos dentro de limites
aceitáveis.(Guia PMBOK, 2008)
Figura 7 - Gerenciamento de custos
Fonte: Guia PMBOK, 2008
2.8 GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO
O gerenciamento das comunicações é responsável de assegurar que as
informações do projeto sejam geradas, coletadas, distribuídas, armazenadas,
recuperadas de formar oportuna e apropriada. As comunicações se resume em
cinco processos que são: Identificar as partes interessadas, Planejar as
42
comunicações, Distribuir informações, Gerenciar as expectativas das partes
interessadas e Reportar o desempenho.
Segundo o Guia PMBOK esses processos interagem entre si e com os processos de outras áreas também. Cada processo ocorre pelo menos uma vez em todos os projetos. A atividade de comunicação inclui método interno e externo, formal, vertical, oficial, escrita e oral, e verbal e não verbal.
2.8.1 Identificar as partes interessadas
É o processo que identifica todas as pessoas ou empresas que fazem partes
do projeto. A maior parte dos projetos tem grande números de partes interessadas e
podem exercer influência sobre o projeto e suas entregas.
As partes interessadas são pessoas e organizações, tais como cliente, patrocinadores, a organização executora, e o público, que estão ativamente envolvidos no projeto ou cujos interesses podem ser positiva ou negativa afetados pela execução ou pelo término do projetoDinsmore (2004).
2.8.2 Planejar as comunicações
De acordo com Dinsmore (2004), "planejar as comunicações é o processo de
determinar quais as necessidades de informações das partes interessadas no
projeto e definir uma abordagem de comunicação".
Identificar necessidades de informações e determinar meios apropriados, para
atender as necessidades, são fatores importantes para o sucesso do projeto. O
processo Planejar as comunicações reponde às necessidades de informações e
comunicação das partes interessadas; por exemplo, quem precisa de quais
informações, quando elas serão necessárias, como serão fornecidas e por quem.
O mal planejamento das comunicações pode causar problemas, como atrasa
a entrega de mensagens comunicações de informações confidenciais para o público
incorreto ou falta de comunicação para algumas das partes interessadas.
43
2.8.3 Distribuir informações
É o processo que disponibiliza as informações necessárias das partes
interessadas no projeto. O processo é executado durante todo o ciclo de vida e em
todos os projetos de gerenciamento.
2.8.4 Gerenciar as expectativas das partes interess adas
É o processo de comunicação e interação com as partes interessas do
projeto, que tem por finalidade atender às necessidades e solucionar medida que
ocorrerem.
O gerenciamento das expectativas ajuda a aumentar a probabilidade de sucesso do projeto do projeto, garantindo que as partes interessadas entendam os benefícios e os riscos do projeto. Isso permite que elas apoiem ativamente o projeto e ajudem na avaliação de riscos das escolhas do projetoDinsmore (2004).
2.8.5 Reportar o desempenho
É o processo de coleta e fornecimento de informações sobre o desempenho,
ou seja, distribui informações da situação atual dos riscos e questões, trabalhos a
serem concluídos, resumo de mudanças e entre outros.
44
Figura 8 - gerenciamento da comunicação
Fonte: Guia PMBOK, 2008
2.9 GERENCIAMENTO DE RECURSOS HUMANOS
É o gerenciamento que cuida da equipe do projeto, onde documenta as
funções, responsabilidades, habilidades e hierarquias. Também é responsável de
obter equipe necessária para concluir as designações do projeto, melhoria de
competências, interação da equipe e ambiente global, acompanhar o desempenho
de membros da equipe, fornece feedback, resolver questões de mudanças para
otimizar o desempenho do projeto.A equipe do projeto consiste nas pessoas com
papéis e responsabilidade, o guia PMBOK nos diz que a equipe é responsável pelas
atividades de gerenciamento do projeto e liderança, como iniciação, planejamento,
execução, monitoramento, controle e encerramento das várias fases do projeto.
a) Desenvolver um plano de recursos humanos: é o processo é
responsável de identificar e documentar funções habilidades,
responsabilidades e relação hierárquica do projeto.
45
b) Mobilizar a equipe do projeto: responsável para obter a equipe
necessária para o desenvolvimento do projeto.
c) Desenvolver a equipe do projeto: é o processo de melhoria da equipe,
onde envolve interação e o ambiente global para o melhor desempenho do
projeto.
d) Gerenciar a equipe do projeto: como o nome já diz, é o processo que
gerencia a equipe do projeto, tem como responsabilidade de acompanhar e
otimizar o desempenho e resolver questões.
Os processo apresentados acima e também todos os processos de
gerenciamento de projetos são apresentados no guia PMBOK como processos
distintos mas são bem definidos. Já na prática o guia mostra que os processos
sobrepõem e interagem de formas que não podem ser completamente detalhadas.
2.9.1 Desenvolver o plano de recursos humanos
Esse processo com dito em resumo acima tem por função identificar,
documentar, gerenciar responsabilidades, relações hierárquicas entres planos desse
processo. Nesse processo também pode incluir a identificação de necessidades de
treinamento, estratégias para desenvolver uma equipe e questões de segurança
(Kerzner, 2002).
2.9.2 Mobilizar a equipe do projeto
Mobilizar a equipe do projeto é o processo de confirmação de disponibilidade
de recursos humanos para concluir o projeto. É o processo de obtenção dos
recursos humanos necessários para terminar o projeto. A equipe de gerenciamento
de projetos pode ter ou não controle sobre os membros da equipe selecionados para
o projeto. A mobilização da equipe do projeto inclui (Kerzner, 2002):
a) Disponibilidade. Quem está disponível e quando estará disponível;
46
b) Capacidade. Quais competências as pessoas possuem;
c) Experiência. Qualidade e características de cada membro;
d) Interesses. As pessoas estão interessadas em trabalhar neste projeto;
e) Custo. Quanto receberá cada membro da equipe, especialmente se for
contratado de fora da organização;
2.9.3 Desenvolver a equipe do projeto
Segundo o Guia PMBOK, 2008, esse processo é de melhoria de
competência, interação e ambiente global da equipe para aprimorar o desempenho
do projeto. Deve-se motivar a equipe continuamente fornecendo desafios e
oportunidades, oferecendo feedback e apoio conforme necessário e reconhecendo e
recompensando o bom desempenho.
2.9.4 Gerenciar a equipe do projeto
É o processo de acompanhar o desempenho de membros da equipe, fornece
feedback e otimizar o projeto. A equipe observa o comportamento e assim gerencia
os conflitos, resolve questões e avalia o desempenho dos membros da
equipe.“Gerenciar a equipe do projeto requer diversas habilidades de gerenciamento
para estimular o trabalho em equipe e integrar os esforços dos membros da equipe
para criar equipes de alto desempenho. (Guia PMBOK4° edição)
47
Figura 2 - Gerenciamento de recursos humanos
Fonte: Guia PMBOK, 2008
2.10 GERENCIAMENTO DOS RISCOS DO PROJETO
Este gerenciamento tem por seus processos de planejamento, identificação,
análise, planejamento de resposta, monitoramento e controle de riscos. Seu objetivo
é aumentar probabilidade de eventos positivos reduzir a probabilidade de eventos
negativos do projeto.Segundo o PMBOK "todos os processos que fazem parte da
gerencia de risco interagem entre si e com processos das outras áreas também. Os
processo ocorre pelo menos uma vez a cada projeto em uma ou mais fase do
projeto".
O risco do projeto é sempre futuro. O risco é um evento ou uma condição incerta que, se ocorrer, tem um efeito em pelo menos um objetivo do projeto. Os objetivos podem incluir escopo, cronograma, custo e qualidade. Um risco pode ter uma ou mais causas e, se ocorrer, pode ter um ou mais impactos(Kerzner, 2002).
2.10.1 Planejar o gerenciamento dos riscos
48
O gerenciamento de riscos do projeto inclui os processos que tratam da
realização de identificação, análise, respostas, monitoramento e controle e
planejamento do gerenciamento de riscos em um projeto; a maioria desses
processos é atualizada durante todo o projeto. Os objetivos do gerenciamento de
riscos do projeto são aumentar a probabilidade e o impacto dos eventos positivos e
diminuir a probabilidade e o impacto dos eventos adversos ao projeto. Os processos
de gerenciamento de riscos do projeto incluem os seguintes (Guia PMBOK, 2008):
a) Planejamento do gerenciamento de riscos – decisão de como abordar,
planejar e executar as atividades de gerenciamento de riscos de um projeto.
b) Identificação de riscos – determinação dos riscos que podem afetar o
projeto e documentação de suas características.
c) Análise qualitativa de riscos – priorização dos riscos para análise ou
ação adicional subsequente através de avaliação e combinação de sua
probabilidade de ocorrência e impacto.
d) Análise quantitativa de riscos – análise numérica do efeito dos riscos
identificados nos objetivos gerais do projeto.
e) Planejamento de respostas a riscos – desenvolvimento de opções e
ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do
projeto.
f) Monitoramento e controle de riscos – acompanhamento dos riscos
identificados, monitoramento dos riscos residuais, identificação dos novos riscos,
execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o
ciclo de vida do projeto.
2.10.2 Identificar os riscos
É o processo de determinação dos riscos, segundo o Guia PMBOK, 2008, os
participantes deste processos podem incluir o gerente de projeto, membros da
equipe, clientes, especialistas no assuntos esternos à equipe do projeto, outros
gerentes de projetos que estejam estimulado a identificar riscos.
49
2.10.3 Realizar a análise qualitativa dos riscos
É o processo de priorização de riscos para análise ou ação adicional.
Segundo o guia PMBOK, 2008,"Este processo avalia a prioridade dos riscos
identificados usando a relativa probabilidade ou plausibilidade de ocorrência, o
impacto, custo, cronograma, escopo e qualidade do projeto".
2.10.4 Realizar a análise quantitativa de riscos
Atualizações do registro dos riscos faz parte do processo do realizar a análise
quantitativa de riscos no gerenciamento de riscos. Segundo o PMBOK, 2008, os
registro de riscos são atualizado para poder incluir no relatório quantitativo dos
riscos, detalhando as abordagens quantitativas, saídas e recomendações. Esta
saída incluem quatros componentes que são análise probabilística do projeto,
probabilidade de atingir os objetivos de custo e tempo, lista priorizada de riscos
quantificados e tendência nos resultados da análise quantitativas de riscos.
2.10.5 Planejar as respostas aos riscos
De acordo com o PMBOK, 2008, o planejamento para resposta aos riscos faz
parte do gerenciamento de riscos, é o processo responsável de desenvolvimento de
opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos
do projeto.
As resposta planejadas devem ser adequadas à relevância do risco, ter eficácia de custos para atender ao desafio, ser realista dentro do contexto do projeto, acordadas por todas as partes envolvidas e ter um responsável designado. Também devem ser oportunas. Em geral é necessário selecionar a melhor resposta ao risco entre as diversas opções possíveis (Dinsmore, 2004).
2.10.6 Monitorar e controlar os riscos
50
É o processo de implementação dos planos de resposta a riscos o que diz o
PMBOK, 2008, também acompanhamento dos riscos identificados, monitoramento
dos riscos residuais, identificação de novos riscos e avaliação da eficácia do
processo de riscos. O monitoramento e o controle dos riscos podem envolver a
escolha de estratégias alternativas, a execução de um plano alternativo ou de
contingência, a adoção de ações corretivas e a modificação do plano de
gerenciamento do projeto.
. Figura 3 - Gerenciamento de riscos
Fonte: Guia PMBOK, 2008
2.11 GERENCIAMENTO DAS AQUISIÇÕES DO PROJETO
É o gerenciamento responsável por adquirir produtos, serviços ou resultados
externos à equipe do projeto. Está dividido por quarto processo que são planejar,
realizar, administrar e encerrar as aquisições.
O gerenciamento das aquisições do projeto abrange os processos de gerenciamento de contratos e controle de mudanças que são necessários para desenvolver e administrar contratos e controle de mudanças que são necessários para desenvolver e administrar contratos ou pedidos de compras emitidos por membros autorizados da equipe do projeto (Vargas, 2009).
Um contrato de aquisições inclui termo e condições e pode incorporar outros
itens especificados pelo comprador para estabelecer o que deve fornecer ou realizar.
Assegurar que todas as aquisições atendam às necessidades do projeto é
responsabilidade da equipe de gerenciamento, sendo assim que atenda as políticas
de aquisição da organização.
2.11.1 Planejar as aquisições
51
É o processo de documentação, que registra as decisões de compras do
projeto e identificando seus fornecedores. Engloba também a consideração de
fornecedores, principalmente se o comprador deseja exercer algum grau de
influência ou controle sobre as decisões de aquisições (Guia PMBOK, 2008).
2.11.2 Realizar as aquisições
É o processo de obter reposta de fornecedores, seleção de um fornecedor e
adjudicação de um contrato segundo o guia de boas práticas de gerenciamento de
projeto PMBOK.O guia fala ainda “[...]nesse processo, a equipe receberá licitações
ou proposta e aplicará critérios de seleção previamente definidos para escolher um
ou mais fornecedores que sejam qualificados para realizar o trabalho e aceitação
com fornecedor.” (Guia PMBOK, 2008).
2.11.3 Administrar as aquisições
É o processo de gerencia das relações de aquisições, monitoramento do
desempenho do contrato e realização de mudanças e correções.
Tanto o com o comprador como o fornecedor administram o contrato de aquisições para objetivos semelhantes. Cada um precisa assegurar que as duas partes cumpram suas obrigações contratuais e que seus próprios direitos legais sejam protegidos. O processo de administração das aquisições garante que o desempenho do fornecedor cumpra os requisitos da aquisição e que o comprador cumpra os termos do contrato legal (Menezes, 2003).
Administrar aquisições engloba a aplicação dos processos de gerenciamento de
projetos, isso ocorre em vários níveis quando existem vários fornecedores e quando
há o envolvimento de vários produtos, serviços e resultados. Pode incluir os
processos, orientar a gerenciar a execução do projeto, reportar o desempenho,
realizar o controle da qualidade, realizar o controle integrado de mudança e
monitorar e controlar os riscos.
2.11.4 Encerrar as aquisições
52
Como nome diz, é o processo que finaliza todas as aquisições do projeto, envolve a
verificação dos trabalhos e as entregas são aceitáveis.O processo de encerramento
das aquisições também envolve atividades administrativas como finalização das
reivindicações em aberto, atualizações dos registros para refletir os resultados finais
e arquivamento dessas informações para uso futuro (Menezes, 2003).
Figura 4 - Gerenciamento de aquisições
Fonte: Guia PMBOK, 2008
2.12 SCRUM - METODOLOGIA ÁGIL
2.12.1 Surgimento
53
Segundo Schwaber (2002) a metodologia SCRUM"é uma metodologia de
desenvolvimento de software considerada ágil, que foi fortemente influenciada pelas
boas práticas adotadas pela indústria japonesa, especialmente pelos princípios de
manufatura adotadas pelas empresas Honda e Toyota".
A denominação dessa metodologia deve-se a um evento do jogo esportivo Rugby,
quando a bola sai de campo ou ocorre algum incidente, uma formação denominada
Scrum é utilizada para reiniciar o jogo, reunindo todos os jogadores. A utilização
desse nome pareceu adequado porque no Rugby o time age em conjunto, com cada
membro desempenhando um papel especifico em busca do benefício comum. Mais
tarde Jeff Sutherland, vice- presidente da Easel, necessitava de uma forma mais
rápida e adequada de desenvolvimento de aplicações, então Sutherland, contando
com o apoio de John Scumniolates e Jeff Mackenna, documentaram e
implementaram o SCRUM, incorporando os estilos de gerenciamento observados
por Takeuchi e Nokata no artigo “The new product development game” pela Harvard
Business Review em 1986. Posteriormente, Ken Schwaber e Sutherland contanto
com o apoio de Mike Beedle a pedido da Object Magenament Group (OMG),
formalizaram e definiram a metodologia SCRUM que hoje conhecemos (Schwaber,
2002).
2.12.2 Características do Scrum
De acordo com o Guia Scrum (2002),"o SCRUM baseia-se em seis características:
flexibilidade dos resultados, flexibilidade dos prazos, times pequenos, revisões
frequentes, colaboração e orientação a objetos". Não existe soluçõesfáceis para
problemas complexos, mas existe um consenso de que pode-se usar o SCRUM para
desenvolvimento complexos em que os requisitos mudam rapidamente e
constantemente, gerenciar e controlar o desenvolvimento do trabalho, tornar a
equipe autogerenciável e funcional, implementar o conceito iterativo e incremental
no desenvolvimento de software e/ou produtos, identificar causas de problemas e
remover impedimentos e valorizar os indivíduos. Segundo os autores, o SCRUM
pode ser utilizado como forma de gerencia de qualquer projeto ou trabalho, que
possua característica iterativa e incremental.
54
O SCRUM também é conhecido por estruturar seu funcionamento por ciclos, chamados de Sprint, eles duram de duas a quatro semanas e representam as iterações de trabalho. Dentro dos Sprint, os componentes da equipe tem um especifico papel, sendo os três principais : o Product Owner que é o “dono” do produto, ele representa o cliente e é responsável por manter a equipe funcional e produtiva, o SCRUM Master que desempenha o papel de líder, representando a gerência do projeto, responsável pelo uso correto do processo SCRUM e a aplicação de suas regras e o Team, que é o time de desenvolvedores, eles que vão desenvolver o produto e garantir a qualidade do mesmo(Guia Scrum, 2002).
Sbrocco cita também que “Muitos acreditam ser prudente também incluir a figura do
cliente entre os papéis, uma vez que de fato ele tem uma participação importante no
processo de desenvolvimento”. Uma forte característica do SCRUM, são as
cerimonias que são realizadas, elas são realizadas antes, durante e depois dos
Sprint, a seguir, o nome e sua decisão.
2.13 SCRUM -METODOLOGIA AGIL PARA DESENVOLVIMENTO DE SOFTWARE
Scrum é uma metodologia ágil e todo o trabalho é dividido em iterações, cada uma
delas é chamada de Sprint. O Sprint representa um ciclo, ele pode durar de duas a
quatro semanas, mas é tipicamente mensal, pois 30 dias fornecem uma melhor
visibilidade dos objetivos do projeto e comprometimento da equipe. No final de cada
Sprintdeve-se ter uma parte do produto concluída que possa ser apresentada ao
cliente, segundoKen Schwaber, 2002.
Estas entregas parciais vão sendo implementadas até o produto final estar concluído, e à medida que forem surgindo novas funcionalidades desejadas, novos Sprintsvão sendo realizados. Um projeto Scrum começa mesmo que ainda se tenha uma visão superficial no princípio, talvez expressa em termos de marketing ou uma visão técnica, mas que se esclarece melhor à medida que o projeto evolui.
A partir dessa visão inicial se elabora uma lista enxuta dos principais itens, de tudo o
que se deseja para o software, contendo funcionalidades e requisitos que precisarão
ser desenvolvidos até a finalização do projeto. Esta lista de itens é conhecida como
Product Backlogou “Backlogdo Produto”. Cada item tem uma prioridade de entrega
que indica o quanto de valor ele gera para o negócio. Esta lista não precisa estar
completa logo no começo, ela pode ganhar outros itens no decorrer do projeto.
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de 2011)
As funcionalidades a serem implementadas em um projeto são mantidas em uma
lista que é conhecida como
Sprint Planning Meeting
Owner prioriza os itens do
ela será capaz de implementar durante o
em um Sprint são transferidas do
de uma Sprint, a equipe faz uma breve reunião (norma
Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia
anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.Ao final
de umaSprint, a equipe apresenta as funcionalidades implementad
Review Meeting. Finalmente, faz
o planejamento do próximo
(Alves 2011):
Fonte :
2.13.1 Product Backlog
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprintrepresenta um Timeconjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum2011).
erem implementadas em um projeto são mantidas em uma
lista que é conhecida como Product Backlog. No início de cada
Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o
prioriza os itens do Product Backlog e a equipe seleciona as atividades que
ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas
são transferidas do Product Backlog para o Sprint
, a equipe faz uma breve reunião (normalmente de manhã), chamada
. O objetivo é disseminar conhecimento sobre o que foi feito no dia
anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.Ao final
, a equipe apresenta as funcionalidades implementad
. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para
o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo
Figura 12 - Ciclo de vida SCRUM
: http://desenvolvimentoagil.com.br, 2005
Product Backlog
55
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são dividos em ciclos (tipicamente mensais)
Time-Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido
no caso do Scrum (Alves,
erem implementadas em um projeto são mantidas em uma
. No início de cada Sprint, faz-se um
, ou seja, uma reunião de planejamento na qual o Product
e a equipe seleciona as atividades que
que se inicia. As tarefas alocadas
Sprint Backlog.A cada dia
lmente de manhã), chamada
. O objetivo é disseminar conhecimento sobre o que foi feito no dia
anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.Ao final
, a equipe apresenta as funcionalidades implementadas em uma Sprint
e a equipe parte para
se o ciclo. Veja a ilustração abaixo
56
Product Backlogé uma lista contendo todas as funcionalidades desejadas para um
produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog
não precisa estar completo no início de um projeto. Pode-se começar com tudo
aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog
cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
Durante o Sprint Planning Meeting (Reunião de planejamento), o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o SprintBacklog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas (desenvolvimentoagil.com.br).
2.13.2Sprint Backlog
O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer
em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela
equipe, com base nas prioridades definidas pelo Product Owner e a percepção da
equipe sobre o tempo que será necessário para completar as várias
funcionalidades.Cabe a equipe determinar a quantidade de itens do Product Backlog
que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a
implementá-los.
Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico(Alves, 2011).
No início de cada Sprint(iteração) a equipe seleciona os itens do Product Backlog,
de acordo com as suas prioridades e o tempo que será gasto para completar as
suas funcionalidades. Esta nova lista é conhecida como Sprint Backlog. É importante
que a equipe identifique os itens e tamanho do Sprint Backlog, porque ela
estarácomprometida a finalizar tais tarefas. Os seus membros são quem deverão
57
escolher com o que irão se comprometer. Nesse momento as tarefas maiores são
subdivididas em partes menores.
2.13.3 Product Increment
A finalização das funcionalidades definidas para um determinado Sprint
marca a realização de um Product Increment. Os membros da equipe trabalham de
maneira colaborativa de forma a realizar todas as metas definidas para aquele Sprint
2.13.4Sprint Planning Meeting
É o início de uma Sprint, onde o Product Owner(representante do cliente ou o
próprio cliente) tem a oportunidade de atualizar a priorização dos itens do Product
Backlog e definir juntamente com a equipe um Product Increment(uma parte do
produto) a ser entregue ao cliente ao final do Sprint
O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog(http://desenvolvimentoagil.com.br).
2.13.5Scrum Master
O Scrum Master procura assegurar que a equipe respeite e siga os valores e as
práticas do Scrum. Ele também protege a equipe assegurando que ela não se
comprometa excessivamente com relação àquilo que é capaz de realizar durante um
Sprint.O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável
por remover quaisquer obstáculos que sejam levantados pela equipe durante essas
reuniões. O papel de Scrum Master é tipicamente exercido por um gerente de
projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe
(http://desenvolvimentoagil.com.br).
58
2.13.6 Product Owner O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do
Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém
o Backlog do Produto e garante que ele está visível para todos. Todos sabem quais
itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar. O
Product Owner é uma pessoa, e não um comitê. Podem existir comitês que
aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de
um item, terá que convencer o Product Owner. Empresas que adotam Scrum podem
perceber que isso influencia seus métodos para definir prioridades e requisitos ao
longo do tempo (Schwaber, 2002).
O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings.O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes itens transformam-se no Sprint Backlog (desenvolvimentoagil.com.br).
A equipe se empenha a executar um conjunto de atividades no Sprint e o Product
Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint.
Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint.
Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece
concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.
2.13.7 O Scrum Team
É a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão
funcional através de papéis tradicionais, tais como programador, designer, analista
de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto
de trabalho com o qual se comprometeram conjuntamente para um Sprint.Um Scrum
Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com
equipes maiores. A principal abordagem para trabalhar com equipes grandes no
Scrum é usando o conceito de "Scrum ofScrums". Cada Scrum Team trabalha
normalmente, mas cada equipe também contribui com uma pessoa que deverá
frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas
equipes Scrum. Esses encontros são análogos aos DailyScrums, mas não
59
acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes
por semana tende a ser suficiente na maioria das organizações(Alves, 2011).
2.13.8 Daily Scrum
A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem
como objetivo disseminar conhecimento sobre o que foi feito no dia anterior,
identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
É um encontro diário realizado pela equipe e o Scrum Masteronde os membros
discutem aquilo em que trabalharam, no que irão trabalhar e possíveis impedimentos
que estejam atrapalhando o progresso do trabalho. Esta reunião é uma maneira
eficiente de manter os membros cientes dos objetivos e impedir que o projeto “saia
do rumo”.São tipicamente rápidas e objetivas, realizadas em pé, preferencialmente
pelamanhã, duram de 15 a 30 minutos, para evitar perder o foco do que está sendo
desenvolvido e possíveis divergências de assuntos(Alves, 2011).
Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do
dia. O ideal é quese realizem na parte da manhã, para ajudar a estabelecer as
prioridades do novo dia de trabalho.Todos os membros da equipe devem participar
do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão
escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe
disseminar informações sobre o estado do projeto.
O Daily Scrum não deve ser usado como uma reunião para resolução de problemas.
Questões levantadas devem ser levadas para fora da reunião e normalmente
tratadas por um grupo menor de pessoas que tenham a ver diretamente com o
problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada
membro da equipe(Alves, 2011).
Utilização do Scrum pelas empresas.
A seguir, uma pesquisa realizada em 2009, afim de descobrir a porcentagem de
empresas que utilizam metodologias ágeis para o desenvolvimento de seus projetos.
60
61
3. DESENVOLVIMENTO
3.1 SCRUM X PMBOK
Neste capítulo, será descrito o ciclo de vida Scrum com a adição de processos do
PMBOK para reforça-lo, constituindo uma metodologia mista. O Scrum possui um
ciclo de vida mais simplificado e menor que o PMBOK, por isso, será mais fácil
acompanhar, entender como encaixar e utilizar os processos do Guia PMBOK dentro
do Scrum.
Enquanto oScrum é rodado, podemos visualizar os efeitos da aplicação dos
processos do PMBOK e onde podem ser encaixados, formando uma metodologia
unificada de três formas distintas: internamente, externamente e paralelamente ao
ciclo Scrum.(Cruz, 2012)
3.1.1 Ciclo de vida Scrum
Existem várias abordagens, entretanto, seguiremos a proposta de Fábio Cruz para a
união das metodologias do Guia PMBOK e do Scrum, nesta partiremos do princípio
que o Scrum é mais simples e possui um ciclo de vida mais fácil de acompanhar.
Com isso, o objetivo é visualizar o Scrum sendo aplicado, e principalmente rodando segundo suas regras, e encaixar o Guia PMBOK conforme o Scrum acontece, porém, para o ciclo do Scrum iniciar é preciso que alguns processos sejam executados antes, bem como outros depois do seu termino(Cruz, 2012).
Alguns processos do Guia PMBOK devem ser executados antes, durante e depois
das cerimônias e atividades do Scrum. Será possível visualizar claramente como as
ferramentas e técnicas do Guia darão pleno suporte a equipe Scrum. Evidenciando
como é benéfico a união das metodologias.
Figura 5 - Ciclo de vida Scrum
62
Fonte: www.fabiocruz.com, 2013
3.2 INICIO DO PROJETO
O fato de o ambiente de desenvolvimento ser ágil, não dispensa alguns
procedimentos formais, por exemplo, a oficialização do início do projeto. Grandes
clientes costumam aderir bem às metodologias ágeis, mas não abrem mão de
processos contidos nas metodologias tradicionais. Os modelos tradicionais do guia
PMBOK resolvem este problema.(Cruz, 2012)
A seguir, os processos do guia PMBOK e do Scrum, que são utilizados para a
oficialização do início de um projeto:
3.2.1 Termo de abertura do projeto
Este processo formaliza e oficializa o começo de um projeto, dando permissão e
liberação para equipe começar os trabalhos, segundo Cruz, um termo de abertura do
projeto deve conter no mínimo:
a) Propósito ou justificativa do projeto;
b) Requisitos de alto nível;
c) Riscos de alto nível;
d) Resumo do cronograma de marcos;
e) Resumo do orçamento;
f) Requisitos para aprovação do projeto e quem é responsável por decidir se o
63
projeto é bem sucedido ou não;
g) Gerente do projeto, responsabilidade, nível de autoridade e designados;
h) Nome e autoridade do patrocinador que autoriza o termo de abertura.(Cruz
2012)
3.2.2 Identificação dos Stakeholders
Em um projeto, a identificação das partes interessadas é de suma importância, pois
são essas pessoas ou organizações que provavelmente fornecerão as informações
necessárias para a execução do projeto, além eles são responsáveis pela aprovação
do produto. Os stakeholders tem influência no projeto, segundo Cruz, 2012:
Lembrando que as partes interessadas podem influenciar o projeto de forma positiva ou negativamente, e/ou serem afetadas pelo projeto, também de forma positiva ou negativa. Portanto, dar atenção a este processo é fundamental para qualquer tipo de ambiente de projeto, seja ágil ou waterfall.
Neste processo, o Gerente de Projetos e o Product Owner trabalham juntos, afim de
realizar a mesma atividade.
3.2.3 Desenvolver o plano de gerenciamento do proje to
Este documento tem a finalidade de orientar todos os trabalhos de gerenciamento de
projeto, também formaliza como o projeto será conduzido em todas suas etapas. De
acordo com Cruz, 2012:
Este é inclusive o momento ideal, e o documento perfeito, para deixar bem claro para todos os stakeholders do projeto que serão utilizadas ferramentas e técnicas do waterfall combinados com o ágil, e principalmente em que momento cada um será́ aplicado e quais seus benefícios.
Conforme o que foi citado, esta etapa é ideal para explicar às partes interessadas
que o projeto será gerenciado com a mistura de duas metodologias, deixando claro
quais são as vantagens dessa aplicação e formalizando todo o plano de
gerenciamento do projeto.
Recomenda-se a publicação deste documento para todas as partes interessadas,
contendo no mínimo os seguintes itens:
a) O ciclo de vida do projeto e os processos que serão aplicados em cada fase;
64
b) Como o trabalho será́ executado para completar os objetivos do projeto;
c) Como serão gerenciadas as mudanças no projeto;
d) Como serão gerenciadas as configurações do projeto;
e) Como serão gerenciados os requisitos do projeto;
f) O que será́ feito para manter a integridade das linhas de base do projeto;
g) Quais as necessidades para as comunicações entre as partes interessadas.
(Cruz, 2012)
3.3 EXECUTANDO O SCRUM
Após a execução de algumas tarefas formais do PMBOK, o gerente de projetos e a
equipe formada pelos papéis do Scrum, podem dar início ao projeto pela ótica do
Scrum. Durante a execução do Scrum, o time irá trabalhar na realização de tarefas
da metodologia ágil e nas atividades de planejamento, realizando testes, entregas e
outras etapas. Sobre as entregas das tarefas, Cruz, 2013, afirma:“Tudo ao seu
tempo, mas, devido ao ambiente ágil, de uma forma mais dinâmica, mais breve e
mais recorrente, seguindo um estilo de ciclos com iterações de duração mais curtas.”
Quando se fala de Scrum, logo vem uma de suas principais características, as
Sprints, que segundo Sbrocco:
“Projetos que utilizam o Scrum progridem por intermédio de uma série sequencial de Sprints, que correspondem a interações. O objetivo é gerar um produto “entregável” de valor ao cliente, que foi previamente com ele. Cada Sprint deve ocorrer em um período de duas a quatro semanas. O produto é projetado, codificado e testado durante a Sprint.”(Sbrocco, 2012)
Antes do início de uma Sprint, é necessário fazer um planejamento dos itens do
Product Backlog que serão desenvolvidos. É necessário coletar, entender, analisar e
detalhar os itens antes de manda-los para a Sprint. O PMBOK pode ajudar o Scrum
nessa etapa, pois possui um bom gerenciamento de trabalhos com os requisitos do
projeto, o Product Backlog são os requisitos de um projeto, no Scrum.
A seguir, estarão descritos os processos do PMBOK e do Scrum que serão
utilizados nesta etapa do projeto:
3.3.1 Coletar os requisitos
65
Processo básico para a realização de qualquer projeto, este processo obrigatório para
ser possível aplicar o Scrum, e onde o Product Owner procura os Stakeholders e identifica
todos os requisitos necessários para se entregar o projeto.” (Cruz, 2012). Neste processo,
a principal atividade é a delimitação dos requisitos, que pode ser complementado
pelo documento conhecido como Matriz de Rastreabilidade de Requisitos.
3.3.2 Definir o escopo
Após a coleta dos requisitos, sua definição e detalhamento vem logo em seguida,
com mesma importância para o projeto. Com o escopo detalhado, pode-se saber o
quais os requisitos que deverão ser atendidos no final do projeto, ou, no momento
da entrega. Segundo Cruz, 2012:"Este processo é conhecido pelo Guia PMBOK
como definir o escopo. Para o Scrum, definir o escopo nada mais é do que o
detalhamento dos requisitos que só assim vão formar o Backlog do produto.”
Após a definição do escopo, o Product Owner terá o material para criar as Estórias,
artefato já bem conhecido pelo Scrum. Além disso, poderão ser feitas protótipos de
telas, para descrever de forma visual as ações do sistema, e documentos de apoio
com as definições de regras de negócio. (Cruz, 2013)
Quanto as regras de negócio, é altamente recomendável que se registre e confirme
todas as regras no sistema, sem exceção, independente da metodologia utilizada
para o desenvolvimento. Um bom documento para isso, são os Casos de Uso, do
modelo UML (Unified Modeling Language).
3.3.3 Criar a EAP (estrutura analítica do projeto)
A EAP(Estrutura Analítica de Projeto) tem como objetivo mostrar graficamente todo o
escopo definido para o projeto, utilizada para que o gerente de projeto e a equipe de
gestão, saibam os objetos precisam ser construídos, e de forma hierárquica, como
são distribuídos. A EAP é uma ótima ferramenta de acompanhamento, com ela, o
time não deixa de construir nenhuma funcionalidade descrita no escopo. Para
facilitar sua construção nesta metodologia mista, é usar o conceito dos pacotes de
trabalho da EAP quando estiver definindo as estórias, com isso, o esforço de
construir a EAP será somente colocar as estórias em formato visual e seguir os
66
padrões estruturais da EAP. (Cruz, 2012)
3.3.4 Definição do Scrum Team
Este é um processo do Scrum, o ideal é que ele seja realizado apenas uma vez,
durante a preparação da primeira Sprint, o ideal é que ele se mantenha com os
mesmos e a mesma quantidade de membros, isto é importante para que o Time
Scrum consiga o autogerenciamento, auto monitoração, autocontrole e a auto-
melhoria constante. Infelizmente projetos são instáveis, e a equipe pode mudar a
qualquer momento, mas o processo de Definição do time Scrum poderá ser
executado novamente entre as iterações.
Este processo é o responsável por estimar os recursos das atividades conforme as estórias definidas, e determinar o tamanho do Time, o tamanho das Sprints, e se ter a primeira ideia de quantas Sprintsserãonecessárias para completar o trabalho do projeto. Para o Guia PMBOK este processo é conhecido como Estimar os recursos das atividades. Juntamente com esta estimativa de recursos, o gerente de projetos pode preparar um plano de recursos humanos, que é outro processo contido no Guia PMBOK, e visa principalmente atender e gerenciar preocupações com recompensas e treinamentos do Time. Este mesmo é um processo que pode ser revisto outras vezes ao longo de outras iterações, porque ao longo do projeto poderão surgir novas necessidades de treinamentos e recompensas especiais. (Cruz, 2012)
3.3.5 Apresentação do Backlog do Produto
Assim que o Product Owner termina de preparar o Backlog do Produto, chega a hora
de apresenta-lo para o Time e transforma-lo em funcionalidade ou parte
potencialmente entregável. Este é o momento de definir quais serão as próximas
entregas, e a distribuição das Sprints para concluir todo o trabalho necessário para
realizar as entregas. Em alguns casos, o planejamento de entrega é feito e
detalhado no início projeto, junto ao termo de abertura e ao plano de gerenciamento
de projeto, na fase de apresentação de Backlog do Produto, ele é apenas detalhado
e associado às funcionalidades específicas que o compõem e as estórias criadas. A
seguir, os processos do Scrum e do PMBOK que compõe essa fase do projeto:
3.3.5.1Mobilizar equipe do projeto
Por meio deste processo, o gerente de projetos oficializa a formação do Time Scrum.
Apesar da equipe ter seus papéis e responsabilidades estimados no processo
67
“Definindo o time Scrum”, as pessoas participantes das equipes serão mobilizadas
para dentro do projeto, ou seja, serão colocadas efetivamente e oficialmente para
trabalhar dentro dele. (Guia PMBOK, 2008)
3.3.5.2Limpar o Backlog
Este processo tem como função o entendimento do Backlog, por parte do Time com
ajuda do Product Owner. De acordo com Cruz 2012, o ideal para a realização deste
exercício é o agendamento de uma reunião de entrega da versão, na qual o Product
Owner irá apresentar todos os itens que deverão ser entregues ao cliente no final de
um período.
3.3.5.3Definindo o tamanho das estórias
Após o entendimento do Backlog, o Time terá condições de analisar as estórias, afim
de definir seu tamanho de acordo com sua complexidade. Depois que os tamanhos
das estórias estiverem definidos, já pode-se começar a pensar no trabalho do
Backlog, e nas estimativas de duração e quantidade de Sprints. O time também
pode reforçar a estimativa de recursos com base no tamanho das estórias. (Cruz,
2013)
3.3.5.4Planejar as aquisições
Neste processo o Time realiza uma análise conhecida como “Fazer ou Comprar”,
onde com base no tamanho e complexidade das estórias, nessa análise, o Time
avalia se vale mais a pena a compra de uma solução pronta que atenda a
necessidade do cliente, ou o desenvolvimento dela em casa mesmo. Quanto a
participação do gerente de projetos nessa etapa, Cruz afirma o seguinte: “A
participação do gerente de projetos é opcional aqui, mas se torna obrigatória caso
haja a necessidade de realizar compras, pois é ele que analisará o orçamento do
projeto e dará́ a palavra final sobre a compra ou não.” (Cruz, 2013)
3.3.5.5Velocidade do time
68
Os resultados do processo de limpar o Backlog são utilizados em diversos outros
processos. Neste processo, o time verifica já possui uma velocidade definida, ou
seja, a quantidade de estórias que consegue realizar por Sprint, considerando seu
tamanho e complexidade. Caso não haja a definição precisa de velocidade neste
processo, após a primeira Sprint o Time armazenará a velocidade e poderá usa-la
para os próximos planejamentos e comparações com o resultado de futuras Sprints.
3.3.5.6 Identificar os Riscos
Nesta etapa, é realizado o primeiro trabalho com riscos no projeto. O processo de
entender as estórias é de suma importância no Scrum, pois outros processos serão
executados com seus resultados. A primeira identificação de riscos é realizada
quase no final dos trabalhos com o Product Backlog.
3.3.5.7Gerenciamento de Custos
Na metodologia híbrida entre Scrum e PMBOK, o gerente de projetos poderá
trabalhar paralelamente no gerenciamento de custos, à preparação do Product
Backlog, definido pelo PMBOK. Esta é uma etapa muito importante para qualquer
projeto, sendo também considerada uma das mais difíceis.
“[...] é preciso lembrar que a economia na execução de um projeto pode acarretar o encarecimento da manutenção do produto resultado no projeto. Sendo assim, não se pode gastar descontroladamente nem economizar excessivamente. É preciso realizar um gerenciamento de custos.” (Cruz, 2013. p.152)
Este é uma das áreas de gerenciamentos do PMBOK que mais justificam a união
das metodologias, ela tem o seguinte objetivo:
“O objetivo deste processo é estabelecer políticas, procedimentos e uma documentação para planejar, gerenciar, consumir e controlar os custos, tendo como chave para o sucesso o fornecimento de uma orientação e direção de como os custos serão gerenciados ao longo de todo o projeto.” (Cruz, 2013. P.153)
3.3.5.8 Estimar os custos
No fim dos trabalhos com o Product Backlog, o gerente de projetos conseguirá
69
estimar os custos da próxima entrega do projeto, podendo também, de acordo
com o tamanho do projeto ou a divisão de fases, o gerente de projetos poderá
fornecer o custo para todo ele, não só da próxima etapa. O custo poderá ser
estimado por atividade, tendo como base as informações fornecidas pelo Time.
(Cruz, 2012).
Essencialmente, o processo será utilizado para desenvolver uma estimativa dos
recursos monetários às atividades do projeto, incluindo a identificação e a
consideração de alternativas de custos do início até o fim do projeto.
3.3.5.9Determinar o Orçamento
Junto com a estimativa de custos, o gerente de projetos poderá mostrar orçamentos
previstos para o projeto, ou para a próxima entrega. Este processo é muito
importante para o gerente conseguir autorização no âmbito financeiro, e o cliente
possuir dados mais precisos quanto o custo do projeto.
3.3.5.10Planejar o gerenciamento de Riscos no proje to
Nesta etapa do projeto, o gerente poderá elaborar o gerenciamento de riscos, com
base nas informações reunidas no Product Backlog. O gerenciamento de riscos tem
a seguinte finalidade: “[...] Os objetivos do gerenciamento dos riscos são aumentar a
probabilidade e o impacto dos eventos positivos e reduzir a probabilidade e o
impacto dos eventos negativos no projeto.” (Guia PMBOK, 2008)
Com o plano de gerenciamento de riscos, o gerente de projetos poderá mostrar aos
Stakeholders os riscos identificados, e como irá trata-los com o desenvolvimento do
projeto.
3.4 PLANEJAMENTO SPRINT – PRIMEIRA ETAPA
O planejamento da Sprint é um processo do Scrum muito importante, onde todas as
suas etapas precisam ser cumpridas para que o projeto siga adiante. O tempo de
execução dura em média 8 horas, sendo assim dividido em duas reuniões de 4
70
horas. Neste planejamento são realizados uma ou mais cerimônias, com o intuito de
definir os trabalhos que serão realizados durante ela. Os seguintes processos são
sugeridos para esta etapa do processo:
3.4.1 Preparar o ambiente de trabalho
Este processo é responsável pela infraestrutura requerida pela equipe para
desenvolver o projeto, tudo que está relacionado equipamentos, salas, ferramentas,
softwares, dentre outras coisas que serão necessárias para a iniciação da
Sprint.Segundo Cruz, 2012, este é um processo que tem como objetivo diminuir
riscos, pois muitos consideram este processo como “automático”, não tendo a
necessidade de constar nos planejamentos.
3.4.2 Identificar a velocidade do Time
O processo de identificar a velocidade do Time é responsável pela oficialização da
mesma, e/ou por sua definição. Durante os trabalhos com o Product Backlog, é
sugerido que o Time defina sua velocidade, mas caso ele não tenha definido uma
ainda, o momento é agora. Entretanto, a chance do Time errar a estimativa de
velocidade na primeira Sprint é alta, poderão ser feitas alterações na velocidade a
qualquer momento durante a Sprint, retirando ou adicionando trabalho. Conforme
seguem as iterações as estimativas vão ficando mais precisas. (Cruz, 2012).
3.4.3 Definir o tamanho da Sprint
Esta é uma pequena e muito importante etapa para o projeto, pois o tamanho da
Sprint que será definido agora, valerá para o resto todas as outras. Caso o Time
errar no tamanho, ele terá de identificar o erro e concerta-lo o mais rápido possível,
porque neste momento o projeto poderá sofrer alterações no cronograma, assim o
Gerente de Projetos poderá fazer as alterações necessárias.
Por meio dos resultados obtidos com os processos de preparar o ambiente de
trabalho, reunir a equipe, identificação da velocidade do Time e a preparação do
Product Backlog, é possível determinar o tamanho e a quantidade de Sprints que
serão necessárias para a conclusão dos trabalhos do Backlog.
71
3.4.4 Revisar os Riscos
Nesta etapa do projeto, serão revisados e atualizados os riscos já identificados.
Considerando também os possíveis impactos causados pelos processos de
preparação do ambiente, definição da velocidade do time e tamanho das Sprints.
(Cruz, 2012)
3.4.5 Objetivo da Sprint
O objetivo da Sprint é deixar claro que será realizada a implementação do Product
Backlog, este processo tem como finalidade a orientação do Time, acerca sobre a
razão pela qual está sendo desenvolvido o incremento.
3.4.6 Definir as atividades – primeira etapa
Neste processo, o Time selecionará os itens do Product Backlog que serão
desenvolvidas, a seleção é feita conforme a capacidade e velocidade do Time,
determinadas anteriormente. De acordo com Cruz, este processo está presente
tanto no Scrum quanto no PMBOK.
“Note que este é mais um processo que, apesar de nomes diferentes no Scrum e no Guia PMBOK®, o propósito de ambos é exatamente o mesmo: selecionar os itens de Backlog (atividades) que serão trabalhados na próxima Sprint. Sem perceber, o Time Scrum realiza o processo Definindo as atividades, que é sugerido pelo Guia PMBOK®.”(Cruz, 2013)
A escolha das atividades deve ser baseada na velocidade do Time, se ainda não
possuírem essa informação, o Time precisará definir uma velocidade e a partir desta
reunião, calibra-la a cada Sprint concluída.
3.4.7 Entendendo o Backlog
Com o apoio do Product Owner, o time irá entender todos os itens que serão
trabalhos na Sprint. O Product Owner explica item a item, o Time faz os
questionamentos necessários. O bom entendimento também será útil quando o Time
for determinar o tamanho de cada item.
Durante esta reunião, o Time deverá consultar e questionar ao máximo o Product
72
Owner, para aprimorar o conhecimento sobre o Backlog. Como auxílio, o Time
poderá ler documentos que o Product Owner produziu junto ao cliente, tais como
especificações funcionais, protótipos, casos de uso, e outro materiais que venham a
ajudar no entendimento dos itens.
3.4.8 Priorizando o Backlog
O Product Owner em conjunto com o Time, coloca em ordem os itens do Backlog da
Sprint, definindo o caminho crítico com a escolha dos itens de maior importância e
impacto (Cruz, 2013). Esta priorização já foi feita inicialmente pelo Product Owner.
Nesta etapa é o Time que trabalha com a prioridade, para verificar casos de um item
depender do outro para ser desenvolvido.
3.4.9 Sequenciar as atividades
Com base nos resultados dos processos de definição da importância das estórias
realizada pelo Product Owner, e priorização do Backlog realizado pelo Time, o
gerente de projetos irá sequenciar as atividades, e assim começa a preparar o
cronograma do projeto.O gerente de projetos também tem a necessidade de definir
as atividades mais, ou menos, críticas, de acordo com informações referentes ao
projeto ou ao cliente. Uma boa prática, segundo Cruz, é a seguinte:
“Pelas boas práticas, os itens mais críticos devem ser realizados primeiro, então qualquer informação que o gerente de projetos tenha que possa alterar a criticidade de qualquer item do Backlog deve ser repassada ao Time o mais breve possível”. (Cruz, 2013)
Uma boa prática é colocar os itens mais críticos na frente da fila, eles costumam ser
os que mais agregam valor ao final do produto. Como fortalecimento dessa
sugestão, vale lembrar que com certeza o cliente gostaria de receber as
funcionalidades mais importantes primeiro.O processo de ordenação dos itens a
serem desenvolvidos por prioridade, é uma das mais importantes tarefas no
gerenciamento do escopo, e por consequência da Sprint. Com isso, o gerente de
projetos e o Product Owner podem se ajudar nesta tarefa.
3.4.10 Registrar, Qualificar e quantificar os Risco s
73
O trabalho com o gerenciamento de Riscos começa na primeira parte da reunião da
Sprint, com isso, nessa etapa o Time com a ajuda do gerente de projetos, e do
Product Owner registram novos erros encontrados e revisão os já listados.Este é o
momento ideal para fazer uma análise quantitativa e qualitativa dos riscos, pois o
Time inteiro está focado nos trabalhos com os itens do Backlog para a Sprint, neste
momento os riscos surgem e podem ser analisados.
3.4.11 Planejar as respostas aos riscos
Com os riscos analisados e quantificados, o Time e o gerente de projetos planejar
como serão tratados tais riscos, antecipando problemas e prevendo como manter o
projeto sob controle.
3.4.12 Desenvolvendo o cronograma
Com base em todas as informações produzidas no projeto até o momento, o gerente
de projetos pode desenvolver o cronograma da fase que está se iniciando. O
desenvolvimento de um cronograma aceitável é uma tarefa iterativa, e é sugestivo
conter somente o detalhamento da fase em que o projeto se encontra, não o
andamento do projeto inteiro.
O início da fase pode ter um cronograma de marcos, ele poderá ser acompanhado
junto ao cliente durante o projeto. Para Cruz, o objetivo maior dessa etapa é:
“Neste ponto o objetivo principal é detalhar o cronograma com datas, tarefas e recursos apenas para esta fase, definindo e servindo de documento de comunicação dos trabalhos que serão realizados dentro da próxima Sprint. Isto faz com que o cronograma seja mais simples, além de crescer e ganhar mais detalhes gradativamente seguindo o conceito de ondas sucessivas.”(Cruz, 2012)
3.4.13 Distribuir informações
Este processo tem como responsabilidade a disponibilização da informação corretas
à disposição dos interessados, a fim de comunicar o projeto conforme planejado.
Esta distribuição de informações deve ser executada durante todo o projeto e em
74
todos os processos, pois tanto o gerente de projetos quanto o Time Scrum devem
considerar as comunicações um ponto chave para o sucesso do projeto.
3.5 PLANEJAMENTO DA SPRINT – SEGUNDA ETAPA
Conforme dito na primeira etapa do planejamento da Sprint, a cerimônia de
planejamento da Sprint é dividido em duas reuniões de 4 horas, cada uma com
objetivos distintos. Na primeira etapa da Sprint é determinado o que será feito, na
segunda etapa será descrito como será feito.
3.5.1 Definindo atividades – segunda etapa
As tarefas são pedaços detalhados do trabalho necessário para converter os itens
do Backlog em produto pronto para entrega. Para isso, as tarefas precisam ser
decompostas para que o time consiga desenvolve-la em um dia de Sprint, esta lista
de tarefas complementa o Backlog da Sprint.O próprio Time deve se auto-organizar
e realizar os trabalhos com o Backlog da Sprint. Este processo está presente nas
duas metodologias, tanto no Scrum e no PMBOK, somente muda a nomenclatura.
No Scrum o processo de decompor os itens de Backlog equivale ao processo de
definir as atividades no PMBOK.
3.5.2 Realizando a garantia de qualidade
Este processo é responsável por verificar se os padrões de qualidade estão sendo
seguidos. O ponto forte deste processo é na execução, mas é no planejamento que
se garante que a qualidade será atendida.Na garantia de qualidade é necessário
conferir se foram incluídos tarefas de testes, e qualidade e se estas fizeram parte
das estimativas de cada tarefa. É de extrema importância que a garantia de
qualidade tenha sido incluída nas estimativas, pois diversas vezes o Time lembra de
que para realizar as tarefas serão necessários esforços de desenvolvimento, mas
esquecem que será preciso fazer as validações e testes.
3.5.3 Montando o painel de controle
75
O Quadro de Tarefa, também conhecido como Taskboard, é uma das principais
ferramentas do Scrum para exercitar a transparência do que está sendo
desenvolvido e o que aguarda o desenvolvimento. O Taskboard deve ter no mínimo
duas áreas, uma para as estórias que estão sendo desenvolvidas, e outra para as
que aguardam desenvolvimento. Para Cruz, uma terceira área seria destinada para
tarefas que não foram planejadas. (Cruz, 2013)
Outra ferramenta que é utilizada como controle, é o Gráfico de Burndown, que
representa visualmente a soma das estimativas dos esforços restantes para
completar o Backlog. O Taskboard e o Gráfico de Burndown podem ser distribuídos
aos stakeholders do projeto.
3.5.4 Realizando o controle integrado de mudanças
Este processo é proveniente do PMBOK, possui a seguinte definição:“O processo de
revisão de todas as solicitações de mudança, aprovação de mudanças e
gerenciamento de mudanças nas entregas, ativos de processos organizacionais,
documentos de projeto e plano de gerenciamento do projeto.” (PMBOK, 2008).Ele é
responsável neste momento como parte do planejamento para que seja dada a
devida importância à necessidade de controle efetivo sobre as mudanças que
podem ocorrer a partir deste ponto. No plano de gerenciamento do projeto, é
necessário uma seção somente para a descrição de como funcionará o tratamento
das mudanças ao longo do projeto, ela pode ser adicionada no início do projeto, ou
se não tiver sido criada ainda, pode ser feita nesta etapa.
3.5.5 Revisando os riscos
Após os processos de planejamento da Sprint e dos trabalhos realizados com as
estórias e atividades, o Time tem uma nova oportunidade de registrar, quantificar,
qualificar e planejar as respostas aos riscos. Este processo será executado diversas
vezes ao longo do projeto, com o auxílio das cerimônias do Scrum, que são aliadas
para os trabalhos de gerenciamento de risco.
3.5.6 Executando a Sprint
76
Nesta etapa do projeto o Time começa a “colocar a mão na massa”, dando o ponta
pé inicial no desenvolvimento do produto, aplicando os planejamentos realizados
nas fases iniciais.
Este grupo de processos representa os dias em que o Time está transformando
estórias em partes incrementais do produto, construindo e preparando uma próxima
entrega. Ao passo que o produto é desenvolvido, oportunidades de inspeção surgem
naturalmente e permitem que o Time monitore o seu próprio andamento e tenha uma
percepção real da evolução dos trabalhos que está realizando.A seguir, a descrição
dos trabalhos de cada papel durante a execução do Scrum:
3.5.7 O Time Scrum na execução
O time obrigatoriamente deve estar livre para realizar as tarefas diretamente
relacionadas ao objetivo da Sprint, consequentemente, do projeto. Neste processo, o
próprio Time é o responsável por se auto-orientar e auto-gerenciar, proporcionando
uma agilidade que facilitará os trabalhos necessário que a Sprint seja completada.
3.5.8 O Scrummaster na execução
A principal função do Scrummaster é atuar fortemente para remover os obstáculos
para que o Time consiga completar suas tarefas. Ele também fica com suas outras
responsabilidades, conforme o Guia Scrum:
“O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda o Time Scrum e a organização a adotarem o Scrum. O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade.”(Guia Scrum, 2009. p.06)
Cruz afirma que na prática, o Scrummaster geralmente realiza atividades objetivas
com o Time, como atualizar o Quadro de Tarefas e o Gráfico Burndown.
3.5.9 O ProductOwner na execução
O ProductOwner é responsável pela remoção de obstáculos que envolvem regras de
77
negócio, dúvidas ou problemas de definição de escopo ou entendimento de
requisitos e comunicações com Stakeholders.
Uma das suas tarefas mais importantes, é que geralmente o ProductOwner realiza
ao longo da execução do projeto, é a pré-confirmação e validação das construções
que o Time está realizando, especialmente a conferência do atendimento aos
padrões de qualidade estipulados com o cliente.
3.5.10 O gerente do projeto na execução
O gerente de projetos auxilia o Scrummaster na remoção de impedimentos que
estejam ligados com o macrogerenciamento do projeto, além de influenciar o cliente
e comunica-lo sobre o progresso do projeto sempre que necessário. Algumas
atividades de monitoramento e controle são de responsabilidade do gerente de
projetos, tais como:
a) Formar, treinar e gerenciar os membros do Time do Projeto.
b) Obter, gerenciar e suar os recursos (pessoas e equipamentos).
c) Estabelecer e gerenciar os canais de comunicação do projeto.
d) Gerar dados do projeto e informações sobre o andamento do projeto, para
facilitar previsões
e) Emitir solicitações de mudança e adaptar mudanças aprovadas.
f) Gerenciar riscos e implementar as respostas aos riscos.
g) Gerenciar fornecedores. (Cruz, 2013)
3.5.11 Atualizando e verificando o painel de contro le
Com a atualização do painel, o Time demonstrará que está cumprindo algumas
tarefas de acompanhamento e controle e dando insumos ao gerente de projetos
para que ele realize alguns processos de monitoramento e controle. É sugestivo que
o próprio Time mantenha o painel de controle atualizado diariamente.
1. Quadro de tarefas: assim que um integrante do Time inicia uma tarefa, ele
deve mover esta tarefa para da coluna “A fazer” para a “Fazendo” no Quadro
de Tarefas. Cada integrante deve estar fazendo somente uma tarefa por vez.
2. Gráfico Burndown: o gráfico mostrará como o Time está avançando no
Projeto, em relação ao planejado. O gráfico deverá mostrar duas linhas, a
primeira com o avanço esperado após o planejamento da Sprint ou versão e a
78
segunda com o real avanço diário do projeto.
3.5.12 Monitorando e controlando o trabalho do proj eto
Neste processo o painel proverá insumos para que o Time e/ou o gerente de
projetos acompanhe, revise e ajuste o progresso do projeto para atender aos
objetivos de desempenho definidos no plano de gerenciamento de projeto (Cruz,
2013)
Tanto o PMBOK quanto o Scrum são compatíveis neste ponto de monitoramento do
projeto. O PMBOK sugere que o monitoramento contínuo forneça à equipe de
gerenciamento uma compreensão clara da vitalidade do projeto. O Scrum sugere
que o painel de controle seja atualizado diariamente, sendo assim, o painel de
controle do Scrum fornece uma compreensão transparente do andamento do
projeto, mais uma vez evidenciando a eficiência da abordagem da metodologia
mista.
3.5.13 Controlando o escopo
Este é o momento onde o gerente de projetos e o Time monitoram o andamento do
escopo do projeto e gerenciem as mudanças na linha de base. É um dos principais
processos que tratam as mudanças do escopo e seus impactos dessas mudanças
no projeto. Seu objetivo é assegurar que todas as solicitações de mudança e ações
corretivas ou preventivas sejam tratados pelo processo de realizar o controle
integrado de mudanças.
As mudanças no escopo tem diversas origens, podem ser fatores externos como
medidas de órgãos regulamentadores (Aneel, Banco Central, Receita Federal, etc),
ou falhas internas, como erros de planejamento (especificações incorretas) e/ou
alterações no produto realizadas pelo próprio cliente. (Cruz, 2013)
3.5.14 Controlando o cronograma
Uma tarefa quase exclusiva do gerente de projetos, tendo em alguns casos, o apoio
do Time. O gerente compara o cronograma com os painéis de andamento e
monitora o andamento do projeto, com o intuito de atualizar o seu progresso e
79
gerenciar as mudanças feitas na linha de base do cronograma.Para obter o
andamento do cronograma do projeto, o gerente realiza uma análise de
desempenho que pode ser feita com coleta de dados dos painéis de controle.
3.5.15 Controlando os custos
Durante a execução do projeto, é de suma importância ter o controle da saúde
financeira do projeto. Assim como o controle de cronograma, o controle de custos é
realizado pelo gerente de projetos.
O gerente precisa controlar os custos a uma distância próxima o suficiente para que,
quando necessário, seja possível agir para manter os excessos de custos não
previstos dentro de limites aceitáveis em tempo hábil para não ter perdas maiores do
que as estimadas durante o planejamento.
3.5.16 Realizando o controle integrado de mudanças
Segundo Cruz, 2012, este é o processo responsável por revisar todas as solicitações
de mudanças, gerenciando-as e garantindo que apenas as mudanças aprovadas
sejam realizadas e incorporadas à linha de base revisada.
Este processo tem foco na identificação, documentação e no controle das mudanças
e das linhas de base do produto, envolvendo atividades relacionadas ao
gerenciamento de mudanças com base na execução do projeto.
3.5.17 Conduzindo aquisições
Caso o Time tenha errado no primeiro trabalho com as aquisições e faltou algum
recurso necessário, ou até mesmo nesta etapa do projeto, este processo é acionado
afim de iniciar novamente as atividades de aquisição.
As aquisições costumam ser planejadas anteriormente, neste processo, obtém a
resposta de fornecedores, como cotações, propostas e licitações sobre como os
requisitos podem ser atendidos por eles.
3.5.18 Monitorando e controlando a Sprint
A partir desta etapa, o ciclo de desenvolvimento começa a tomar uma forma mais
80
conhecida pelas equipes de desenvolvimento tradicional, porém seguindo o fluxo e
as regras do Scrum.A seguir, os processos que compõe essa fase do projeto.
3.5.19 Reuniões diárias ( Stand up meeting )
A proposta da reunião diária e fornecer ao Timeuma oportunidade de inspecionar o
próprio trabalho e compartilha-lo com todos os integrantes deste mesmo Time,
fornecendo informações para que seja possível controlar o andamento do projeto,
monitorar riscos e problemas e acompanhar a velocidade do projeto. (Cruz,
2013)Segundo o Guia Scrum, os benefícios da reunião diária são:As Reuniões
Diárias melhoram a comunicação, eliminam outras reuniões, identificam e removem
impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de
decisões e melhoram o nível de conhecimento de todos acerca do projeto. (Guia
Scrum, 2009)
3.5.20 Desenvolvendo a equipe do projeto
Este processo é um dos que deixa muito claro e evidente a importância da união da
abordagem ágil do Scrum com a tradicional do Guia PMBOK. O processo visa
melhoria das competências, interação e ambiente global da equipe para aprimorar o
desempenho do projeto, e a reunião diária é um dos melhores momentos em que o
Time Scrum e o gerente de projetos têm a oportunidade de observar e coletar
informações para aplicar a melhoria contínua no próprio Time.
A capacidade do Time aumenta através de treinamentos ou formas de alinhar e
sincronizar os conhecimentos de todos, sendo que cada um do Time poderá sugerir
e solicitar capacitações específicas para desenvolver a equipe do projeto. Tendo
como foco aumentar as capacidades individuais e de grupo, para que a equipe
realmente funcione como um Time.
3.5.21 Realizando a garantia de qualidade
Neste momento do projeto o Time poderá consultar os documentos iniciais do
projeto, afim de verificar os padrões de qualidade que deviam ser atendidos e
81
verificar se estão sendo colocados em prática.
O ProductOwner participa das reuniões diárias afim de reunir informações a respeito
de como estão sendo atendidos os requisitos do projeto, além de obter informações
acerca dos padrões de qualidade, podendo inclusive influenciar para que estes
sejam atendidos.
3.5.22 Identificando novos riscos
Durante a reunião diária Time tem uma ótima oportunidade de identificar novos
riscos, sendo isso possível através da reposta à pergunta sobre impedimento e do
diálogo de todo o Time sobre os trabalhos que serão realizados até a próxima
reunião diária.O gerente de projetos participa da reunião diária afim de colher e ser
informado de riscos que podem afetar ou influenciar o andamento do projeto e que
podem ser tratados ou direcionados pelo próprio gerente do projeto. (Cruz, 2013)
3.5.23 Revisão da Sprint
Nas fases finais do ciclo de desenvolvimento dentro da Sprint, temos a revisão da
mesma. Onde pode ser resumida como validação e verificação dos requisitos, se
foram atendidos com o desenvolvimento, assim, disponibilizando o pacote ao
cliente.A revisão da Sprint tem a duração de 4 horas, com o objetivo de apresentar
ao ProductOwner o que foi construído e transformado em produto, permitindo assim
que como responsável, ele aprove ou reprove os trabalhos completados.
3.5.24 Reunião de revisão da Sprint
Este processo é realizado no final da Sprint, ele tem o objetivo de avaliar o que está
sendo entregue e o que deveria ser entregue. Nesta etapa todos os envolvidos no
projeto devem participar. Esta reunião é conhecida como apresentação da Sprint,
nesta apresentação é realizada uma revisão, pelo ProductOwner, dos itens
concluídos pelo Time. Uma boa prática é que o Time demostre o funcionamento do
produto. Com isso, o ProductOwner poderá avaliar o que está sendo considerado
como pronto, levando em conta o que está sendo entregue versus o que deveria ser
82
entregue.
3.5.25 Controlando a qualidade
Este processo ocorre naturalmente durante a reunião de revisão da Sprint, o
ProductOwner pode controlar a qualidade do projeto, verificando se os padrões de
qualidade anteriormente definidos estão sendo atendidos com a entrega realizada.
Com o monitoramento dos resultados específicos do projeto, é possível verificar se
esse resultados atendes aos padrões de qualidade pretendidos, permitindo
assegurar a conformidade com os atributos, as características e as funcionalidades,
além de identificar formas de eliminar as causas dos resultados insatisfatórios.
3.5.26 Retrospectiva da Sprint
Nesta etapa o projeto está chegando ao final de uma Sprint e vem um pensamento
em à tona de forma forte e imponente “É mais importante melhorar na próxima Sprint
do que simplesmente terminar a Sprint atual”. Segundo Cruz:
Terminar a Sprint atual e entregar um produto ao cliente é importante e sempre será. Porém, sem olhar para trás, inspecionar o que ocorreu e buscar melhorar no próximo ciclo, não haverá evolução e caminhada na direção de uma melhoria contínua constante e da criação de um Time de alta performance. (Cruz, 2013. p.289)
Com isso, é realizada a última cerimônia de um ciclo do Scrum, chamada
Retrospectiva da Sprint, e esta deve ocorrer sempre após a reunião de revisão e
antes da reunião de planejamento da próxima Sprint. Todos os envolvidos com o
projeto devem participar dessa reunião (Scrummaster, ProductOwner, Time e
Gerente de Projetos).
3.5.27 Registrando as lições aprendidas
Este processo pode ser realizado em qualquer etapa do projeto, mas na cerimônia
de retrospectiva é o momento ideal para sua execução. O registro das lições
aprendidas tem como objetivo a documentação dos acontecimentos que
83
influenciaram ou impediram algum avanço do projeto ao longo da fase anterior, bem
como as experiências ruins e boas que foram percebidas.
3.6 NOVA SPRINT
Assim que a reunião de retrospectiva é encerrada, o Time Scrum juntamente com o
Gerente de Projetos, deverão considerar o inicio de uma nova Sprint. Lembrando
que devem seguir as regras do Scrum, afirmando que não pode haver intervalo entre
uma Sprint e outra.Deve-se continuar o ciclo Scrum, dando início aos processos de
planejamento da Sprint, recomeçando uma nova rodada de processos e reuniões, e
assim sucessivamente até que o projeto seja terminado ou o produto esteja
completado.A seguir, os processos que o Time do Projeto realizará antes de iniciar
uma nova Sprint:
3.6.1 Gerenciando as comunicações do projeto
Com a Sprint finalizada e o painel de controle atualizado, o gerente de projetos tem
o material de apoio suficiente para coletar e disseminar as informações de
desempenho do projeto e com isso realizar mais uma vez o gerenciamento das
comunicações do projeto.O gerente deverá coletar esses dados através do próprio
painel de controle atualizado, após a coleta do que é necessário, o gerente deverá
compilar os dados podendo gerar diversos relatórios de desempenho. Tais como:
a) Desempenho do cronograma planejado em relação ao real.
b) Desempenho dos custo planejados em relação aos reais.
c) Desempenho técnico planejado em relação ao real.
3.6.2 Controlando os riscos
Nesta etapa, são aplicadas as repostas aos riscos, acompanhamento aos risco
identificados, monitoramento dos riscos residuais, identificação de novos riscos e de
avaliação de eficácia do processo de gerenciamento de riscos durante o projeto.
84
Relembrando que estes processos do gerenciamento de riscos podem ser aplicados
qualquer hora do projeto. (Cruz, 2013)
Este processo está destacado neste ponto do projeto devido as reuniões de revisão
e retrospectiva da Sprint, pois nessas duas cerimônias é provável que apareçam
novos riscos e/ou mudança de situação de riscos já planejados.
Por fim, esse processo vai determinar se:
a) As premissas ainda são validas.
b) Houve modificação ou possibilidade de desativação de um risco.
c) Políticas e procedimentos de gerenciamento dos riscos estão sendo seguidos.
d) As reservas de contingência devem ser modificadas conforme a avaliação
atualizada dos riscos.
e) Novos riscos foram identificados.
f) Ocorreram sintomas de riscos.
3.6.3 Gerenciando a equipe do projeto
Este processo consiste em acompanhar o desempenho do Time do projeto, fornecer
feedback, resolver questões e gerenciar mudanças para otimizar o desempenho do
projeto, especialmente através da melhoria das condições para aumento do
desempenho individual. O gerenciamento de uma equipe envolve uma série de
combinações de habilidade, onde se mais destacam, o gerenciamento de conflitos, a
negociação e a liderança. (Cruz, 2013)
Para gerenciar a equipe, o gerente de projeto precisa observar o comportamento do
Time, contribuir para a resolução de conflitos, resolver as questões pendentes e
avaliar o desempenho dos membros da equipe. Durante a Sprint, o gerente e os
outros membros do Time possuem condições de avaliar de forma incremental todos
os demais integrantes, especialmente por meio da técnica de observação.
3.6.4 Encerrando a Fase
Como já foi dito anteriormente, assim que uma Sprint termina, ou começa
imediatamente, o Time não realiza nenhuma atividade entre elas. Isso acontece
porque, exceto quando for a última Sprint e o projeto terminar, há mais incrementos
85
do produto a serem realizados.
Entretanto, enquanto o Time segue para outra Sprint, há outras atividades a serem
realizadas que envolvem tanto o cliente quanto os incrementos do produto a serem
realizados, nesta abordagem, o encerramento da fase é simplesmente a entrega da
versão planejada. De acordo com o planejado, pode ser que este processo não seja
executado todas as vezes que o Time do projeto passar por esta etapa no ciclo.
A seguir, os processos que compõem essa fase.
3.6.5 Entregando o valor
Este processo marca o momento em que oficialmente é realizada a entrega de valor
ao cliente, que se dá pela liberação do incremento de produto até o momento para
que o cliente o utilize.Este processo se encontra fora do ciclo Scrum, ou seja, fora da
Sprint. Isso ocorre porque um importante conceito deve ser observado: a
possibilidade de uma ou mais Sprints gerarem o resultado esperado de valor ao
cliente, sendo assim, somente quando este valor for alcançado a entrega deverá ser
realizada. (Cruz, 2013)
3.6.6 Orientando e acompanhando a homologação da en trega
Ao se entregar um valor ao cliente, ou seja, um incremento do produto pronto para o
usuário final, recomenda-se testar, validar e conferir tudo que foi entregue em
comparação com tudo que foi planejado e definido para ser entregue.
A homologação precisa ser coordenada de maneira que os trabalhos sejam
realizados em um tempo determinado, com retornos e documentações de registro de
questões, erros ou inconformidades para que o Time possa responder o mais rápido
possível, afim de que a homologação termine o mais rápido possível, gerando a
aprovação da versão de entrega. A execução deste processo deve ser realizada
pelo gerente de projetos.
3.6.7 Controlando a qualidade
Durante a homologação do produto entregue aparece mais uma oportunidade para
controlar a qualidade do projeto e verificar se os padrões de qualidade anteriormente
86
definidos estão sendo prontos.
Durante este processo o cliente costuma produzir uma documentação de registro de
erros ou inconformidades que precisará ser encaminhada para o Time de
desenvolvimento trabalhar e retornar para o cliente conferir novamente as correções
e assim finalizar a homologação.
3.6.8 Validando o escopo
Este processo tem como objetivo formalizar a aceitação das entregas concluídas,
incluindo principalmente a revisão das entregas com o cliente ou patrocinador, para
assegurar que foram concluídas satisfatoriamente e obter deles uma aceitação
formal.
A conferência através de uma inspeção também chamada de revisão, se o trabalho
entregue atente aos requisitos e aos critérios de aceitação do produto é realizado
neste processo. Ele também é praticado no mesmo momento do controle de
qualidade, pois ao realizar o processo de homologação o cliente já realiza a
inspeção dos requisitos e critérios de aceitação.
3.6.9 Gerenciando mudanças
Caso o cliente encontre alguma necessidades que não foram caracterizadas como
erros ou inconformidades, mas precisam ser realizadas no produto antes de sua
conclusão, esses itens precisam ser designados como solicitações de mudanças e
ser tratados como tal.Segundo Cruz, este processo se propõe ao seguinte:
“[...] este processo também poderá gerar solicitações de mudança que irão compor o Backlog da próxima Sprint, podendo até já entrar como itens não previstos da Sprint que está em andamento paralelamente ao encerramento da fase.” (Cruz, 2013. p.327)
3.6.10 Controlando as aquisições
Nesta etapa, com a fase (Sprint) já fechada, o gerente de projetos tem condição de
administrar as aquisições, que é o processo de gerenciar as relações de aquisição,
87
monitorar o desempenho do contrato e fazer mudanças conforme necessário,
contudo o objetivo principal é garantir que o desempenho do fornecedor esteja
adequado aos requisitos contratuais.
Os fornecedores tratados neste processo não envolve os fornecedores que estão
executando o projeto, e sim fornecedores terceiros que são responsáveis por
produtos ou serviços relacionados ao projeto em execução.
3.6.11 Nova fase
Assim que uma fase terminar, ou deve começar. No entanto, como alguns processos
são executados entre uma fase e outra, este processo tem como objetivo
caracterizar que todo o Time do Projeto está pronto para iniciar uma nova fase.
Ao conectar o Time à uma nova fase, o ciclo retorna ao início da fase de
planejamento da Sprint e executa novamente todos os processos contidos no ciclo
até chegar a este ponto novamente, continuando nessas iterações até a última fase.
Quando esta for a última fase do projeto, o ciclo deve ser encerrado e o Time do
Projeto deve caminhar para a última etapa, que é o encerramento do projeto.
3.6.12 Encerrando o Projeto
Este processo tem como objetivo formalizar o encerramento do projeto, garantindo
que todo trabalho foi realizado e aceito pelo cliente.
Para isso, algumas atividades devem ser realizadas, tais como:
a) Assinatura de encerramento de contratos ou termo de aceite das entregas.
b) Atualização de toda a documentação do projeto.
c) Transferência dos produtos completados, incluindo documentações, para o
cliente.
d) Coleta final de lições aprendidas e registro para uso futuro em novos projetos.
Neste momento, o gerente deve revisar todas as informações prévias dos
encerramentos anteriores, conferindo e assegurando que todo o trabalho do projeto
está completo e que este atingiu seus objetivos. (Cruz, 2013. p.332)
88
3.6.13 Encerrando as aquisições
Este é o processo que tem como objetivo encerrar cada aquisição do projeto.
Envolve atividades administrativas como finalização de reinvindicações abertas,
atualizações dos registros para refletir os resultados finais e arquivamento dessas
informações para uso futuro.A seguir uma imagem com os ciclos de vida mistos e
com todos os seus processos :
3.7 CICLO DE VIDA SCRUM COM PROCESSOS PMBOK
Figura 6 - Ciclo de vida Scrum com PMBOK
Figura 15 - Ciclo de vida Scrum com
CONCLUSÃO
Fonte: www.fabiocruz.com
Ciclo de vida Scrum com áreas de conhecimendo do PMBOK
Fonte: Autoria própria.
89
áreas de conhecimendo do PMBOK
90
Esta revisão bibliográfica apresentou o estudo de duas abordagens utilizadas para o
desenvolvimento de softwares e projetos, com o intuito de ajudar gerentes ou
equipes a entenderem estas duas metodologias unidas.
Primeiramente esta revisão concentrou-se em estudar fundamentos teórios
sobre o tema, no que se diz a respeito aos processos de gerenciamento de projetos
do PMBOK e do método ágil Scrum.
Depois, foi apresentado um estudo com adição entre os dois métodos,
denominado um estudo hibrido, onde pode-se concluir que as noves areas de
conhecimento do PMBOK são compatíveis de alguma forma com a metodologia
Scrum. Entretanto como este trabalho é uma compilação de diversos estudos como
monografias, dissertações e teses, não foi realizado testes para se terresultados
práticos e absolutos.
Em seguida, foi visto com detalhes os processos do PMBOK sendo
incrementados no Scrum, que não sobrecarrega em termos de documentação, só os
torna mais robusto. O segredo de tudo isso é saber adaptá-los corretamente.
No início deste trabalho de conclusão de curso, o objetivo geral do mesmo foi
analisar a viabilidade de utilizar o PMBOK na metodologia Scrum, onde foi levantado
uma proposta que buscou respondera seguinte questão problema:É viável utilizar o
Scrum em conjunto com o PMBOK para ter progresso no desenvolvimento de
software?
Conclui-se que há duas hipóteses onde pode-se chegar as seguintes
considerações:
Hipótese 1: Não é viável utilizar o Scrum com métodos tradicional PMBOK,
pois não irá proporcionar agilidade na entrega, com isto o Scrum irá perder
performance na entrega do produto, como idealizado no manifesto ágil (2001).
Esta hipótese não foi validada, pois através da fundamentação e estudos foi
demonstrado no desenvolvimento que a utilização dos processos do PMBOK ajudam
corrigir erros de todo projeto, com isso garante redução do tempo final. Vale também
ressaltar que o projeto documentado será de fácil manutenção, não dependo
exclusive de um time ou equipe de desenvolvimento, o que gera extrema agilidade
em manutenção e testes.
91
Hipótese 2: Sim, é viável, pois proporcionará mais qualidade no
desenvolvimentode software trazendo melhorias significativas no gerenciamento e
planejamento de projetos de software.
Essa hipótese foi validada, pois em nossa revisão comprova que com a
utilização dos processos de conhecimento do PMBOK com a metodologia Scrum o
resultado final do desenvolvimento do projeto pode ser considerado satisfatório,
tendo em vista que os processos do PMBOK trazem melhorias significativas. Como
vimos no desenvolvimento atende as necessidades do cliente, não ocorrendo falta
de interação com as partes interessadas. Também essa hipótese contribui com a
divulgação da comunicação entre a equipe de desenvolvimento.
Após a realização deste trabalho, conclui-se que somente com
fundamentação bibliográfica não é possível afirmar absolutamente que as
metodologias são compatíveis. Há uma necessidade de ser testada, realizando uma
pesquisa quantitativa para tal abordagem.
Para finalizar, fica a sugestão para trabalhos futuros o desenvolvimento de
uma pesquisa de testes dos paradigmas estudados, para continuar trazendo
melhorias no processo de desenvolvimento de software.
REFERENCIAS BIBLIOGRÁFICAS
92
ALVES, Renata de Souza. Scrum - Revista Engenharia de Software. Edição 23 - 2011.
CRUZ, Fábio. PMBOK e Scrum, como uni-los?.Engenharia de Software Magazine . 47 vol. pg 6-13, 2012. CRUZ, Fábio. Scrum e Guia PMBOK unidos no gerenciamento de proje tos . 1 ed. Rio de Janeiro: Brasport, 2013. DISNMORE, P. C. e Silveira Neto F. H. Gerenciamento de Projetos, Como Gerenciar seu Projeto com Qualidade, dentro do Praz o e Custos Previstos . – Rio de Janeiro : Qualitymark, 2004
HTTP://DESENVOLVIMENTOAGIL.COM.BR/ - Aprendendo sobre metodologias
ágeis
KEELLING, R, Gestão de projetos, uma abordagem global ; Tradução Cid Knipel Moreira; Saraiva, 2002. Titulo Original: “Project management: an international perspective.
KERZNER, H, Gestão de Projetos, As Melhores práticas . Tradução.: Marco Antonio Viana Borges, Marcelo Klippel e Gustavo Severo de Borba. – Porto Alegre: Bookman, 2002 Título Original “Applied project management: best pratices on implementation”.
MENEZES, Luis Cesar de Moura. Gestão de projetos . 2. ed. São Paulo: Atlas, 2003.
Project Management Institute. Project Management Guide of Knowledged (PMPOK), Quarta Edição, 2008. SBROCCO, J. H; MACEDO, P. H. Metodologias ágeis: engenharia de software sob medida . 1 ed. São Paulo: Érica 2012
SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum . New Jersey: Prentice Hall, 2002. Traduzido para o português.
VARGAS, Ricardo. Manual Prático do Plano de Projeto (4a. edição). Editora
BRASPORT (2009).