Você está na página 1de 92

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

Conteúdo

SUMÁRIO

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

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

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 projeto

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

Figura 2 - Processos do guia PMBOK

16

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

16 Fonte: guia PMBOK, 2008 2.1.1 Processos do Guia PMBOK O gerenciamento de projetos é a

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

17 Fonte: gestaodainformacao-ufpr.blogspot.com.br 2.2 GERENCIAMENTO DE ESCOPO Segundo o Guia PMBOK “O gerenciamento do

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

O plano de gerenciamento do escopo pode ser formal ou

controlado [

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).

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

21 Fonte: Guia PMBOK, 2008 2.3 Gerenciamento de Integração Segundo o Guia PMBOK o “O Gerenciamento

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.

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 projeto

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,

equipamentos e instalações;

gerenciar

e

usar

recursos,

inclusive

materiais,

ferramentas,

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°)

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

28 Fonte: Guia PMBOK, 2008 2.4 GERENCIAMENTO DE QUALIDADE O gerenciamento de qualidade inclui os processos

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

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:

definição: [

]identificação

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

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)

açõesespecíficas a serem realizadas para produzir as entregas do projeto.

atividades: O processo de identificação das

Definir

as

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 -

reais conforme ocorrem. Figura 6 - Gerenciamento de tempo - Fonte: Guia PMBOK, 2008 2.7 GERENCIAMENTO

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

PMBOK, 2008) Figura 7 - Gerenciamento de custos Fonte: Guia PMBOK, 2008 2.8 GERENCIAMENTO DAS COMUNICAÇÕES

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 interessadas

É 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

44 Figura 8 - gerenciamento da comunicação Fonte: Guia PMBOK, 2008 2.9 GERENCIAMENTO DE RECURSOS HUMANOS

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

47 Figura 2 - Gerenciamento de recursos humanos Fonte: Guia PMBOK, 2008 2.10 GERENCIAMENTO DOS RISCOS

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).

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

do projeto. . Figura 3 - Gerenciamento de riscos Fonte: Guia PMBOK, 2008 2.11 GERENCIAMENTO DAS

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

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).

projeto PMBOK.O guia fala ainda “[

]nesse

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.

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

(Menezes, 2003). Figura 4 - Gerenciamento de aquisições Fonte: Guia PMBOK, 2008 2.12 SCRUM - METODOLOGIA

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.

55

Scr um é uma metodologia ágil para gestão e plan ejamento de projetos de

soft ware. No Scrum, os projetos são dividos em cicl os (tipicamente mensais) cha mados de Sprints. O Sprintrepresenta um Time -Box dentro do qual um

Metodologias ágeis de

des envolvimento de software são iterativas, ou sej a, o trabalho é dividido

con junto de atividades deve ser executado.

em

iterações, que são chamadas de Sprints no

caso do Scrum (Alves,

201

1).

As funcionalidades a se rem implementadas em um projeto sã o mantidas em uma lista que é conhecida c omo Product Backlog. No início de cad a Sprint, faz-se um Sprint Planning Meeting , ou seja, uma reunião de planejament o na qual o Product

Owner prioriza os itens do Product Backlog e a equipe selecion a as atividades que

ela será capaz de imple mentar durante o Sprint que se inicia. em um Sprint são transf eridas do Product Backlog para o Sprin

de uma Sprint, a equipe faz uma breve reunião (normalmente d e manhã), chamada

Daily Scrum. O objetivo

anterior, identificar impe dimentos e priorizar o trabalho do dia q ue se inicia.Ao final de umaSprint, a equipe apresenta as funcionalidades implement adas em uma Sprint Review Meeting. Finalm ente, faz-se uma Sprint Retrospective e a equipe parte para

o planejamento do próxi mo Sprint. Assim reinicia-se o ciclo. Vej a a ilustração abaixo (Alves 2011):

As tarefas alocadas Backlog.A cada dia

que foi feito no dia

é disseminar conhecimento sobre o

Figura 12 - Ciclo de vida SCRUM

conhecimento sobre o Figura 12 - Ciclo de vida SCRUM Fonte: http://desenvolvimentoagil.com.br, 2005 2.13.1

Fonte: http://desenvolvimentoagil.com.br, 2005

2.13.1 Product Backlog

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

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

62 3.2 INICIO DO PROJETO Fonte: www.fabiocruz.com, 2013 O fato de o ambiente de desenvolvimento ser

3.2 INICIO DO PROJETO

Fonte: www.fabiocruz.com, 2013

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 projeto

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 projeto

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

Os objetivos do gerenciamento dos riscos são aumentar a

a seguinte finalidade: “[

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 Riscos

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.

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.

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 controle

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.

78

segunda com o real avanço diário do projeto.

3.5.12 Monitorando e controlando o trabalho do projeto

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 entrega

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

89

89 Fonte: www.fabiocruz.com Figura 15 - Ciclo de vida Scrum com áreas de conhecimendo d o

Fonte: www.fabiocruz.com

Figura 15 - Ciclo de vida Scrum com áreas de conhecimendo d o PMBOK

www.fabiocruz.com Figura 15 - Ciclo de vida Scrum com áreas de conhecimendo d o PMBOK CONCLUSÃO

CONCLUSÃO

Fonte: Autoria própria.

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

considerações:

duas

hipóteses

onde

pode-se

chegar

as

seguintes

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 projetos. 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 Prazo 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).