Departamento de Computao

Trabalho de Concluso de Curso

LUCAS JOS SEVERINO

O PODER DO PMBOK NO GERENCIAMENTO DE UM PROJETO SCRUM.

Londrina 2009

LUCAS JOS SEVERINO

O PODER DO PMBOK NO GERENCIAMENTO DE UM PROJETO SCRUM

Trabalho de Concluso de Curso apresentado ao Curso de Graduao em Cincia da Computao da Universidade Estadual de Londrina, como requisito parcial obteno do grau de Bacharel.

COMISSO EXAMINADORA

______________________________________ Prof. Dr. Rodolfo Miranda de Barros Universidade Estadual de Londrina ______________________________________ Prof. Ms. Elieser Botelho Manhas Junior Universidade Estadual de Londrina ______________________________________ ___________________________ ___________________________

Londrina, ____ de___________ de 2009

Agradecimentos
A Deus. Ao Prof. Dr. Rodolfo, brao amigo de todas as etapas deste trabalho. A meu pai e minha me, pela confiana e motivao. A minha irm Adriana que me deu apoio nessa jornada. A minha namorada Muriele, pelo carinho e amor. Ao meu scio e amigo Joo Paulo, pela compreenso prioridade desse trabalho. Aos amigos e colegas, pela fora e pela vibrao em relao a esta jornada. Aos professores e colegas de Curso, pois juntos trilhamos uma etapa importante de nossas vidas.

Dedico este trabalho a meu pai e a minha me,alias todas as minhas conquistas a eles so dedicadas.

Resumo
O mercado de tecnologia est se tornando cada vez mais globalizado e competitivo; assim, as empresas so compelidas a buscarem constantes atualizaes em seus projetos; um projeto um esforo temporrio para criar um produto, servio ou resultado exclusivo. O gerenciamento de projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. Tm-se notado uma busca incessante das organizaes no uso de mtodos geis e melhores prticas de gerenciamento de projetos. O objetivo desse trabalho apresentar uma nova forma de proporcionar agilidade no gerenciamento utilizando tcnicas do PMBOK, j consolidadas, no desenvolvimento de um projeto com SCRUM. O PMBOK um guia do conjunto de conhecimentos em gerenciamento de projetos, e est focado nas boas prticas da Gesto Tecnolgica.

Palavras-chave: PMBOK. SCRUM. Gerenciamento de projetos. Mtodos geis.

Abstract
The market technology is becoming more globalised and competitiv; thus, the companies are compelled to search constant updates in its projects; a project is a temporary effort to create a product, exclusive service or resulted effort. The project management is the application of knowledge, abilities, tools and techniques to the activities of the project in order to take care of to its requirements. They have noticed an incessant search of the organizations in the use of agile practical and better methods of project management. The objective of this work is to present a new form to provide agility in the management using techniques of the PMBOK, already consolidated, in the development of a project with agile practice SCRUM. The PMBOK is a guide of the set of knowledge in projects management, and focus in good the practical ones of the Technological Management. Keywords: PMBOK. SCRUM. Project Management. Agile methods.

SUMRIO

INTRODUO ............................................................................................................ 9 1 O QUE O PMBOK .......................................................................................... 11 1.1 1.2 1.3 1.4 1.5 2 O QUE UM PROJETO .................................................................................... 11 O QUE GERENCIAMENTO DE PROJETOS. ........................................................ 12 CICLO DE VIDA E A ORGANIZAO DO PROJETO: ............................................... 13 PARTES INTERESSADAS NO PROJETO: ............................................................. 14 PROCESSOS DE GERENCIAMENTO DE PROJETOS: ............................................ 15

AS REAS DE CONHECIMENTO DO PMBOK................................................ 17 2.1 INTEGRAO ................................................................................................. 17 2.1.1 Termo de abertura de um projeto ............................................................ 17 2.1.2 Declarao do escopo preliminar ............................................................ 18 2.1.3 Plano de gerenciamento de um projeto ................................................... 18 2.1.4 Orientao e execuo de um projeto ..................................................... 19 2.1.5 Monitoramento e controle do trabalho do projeto .................................... 19 2.1.6 Controle de mudanas ............................................................................ 19 2.2 ESCOPO ....................................................................................................... 20 2.2.1 Planejamento do escopo ......................................................................... 20 2.2.2 Definio ................................................................................................. 20 2.2.3 Criar EAP ................................................................................................ 20 2.2.4 Verificao ............................................................................................... 21 2.2.5 Controle ................................................................................................... 21 2.3 TEMPO ......................................................................................................... 22 2.3.1 Definio da atividade ............................................................................. 22 2.3.2 Sequenciamento de atividades ............................................................... 22 2.3.3 Estimativa de recursos ............................................................................ 22 2.3.4 Estimativa de durao da atividade ......................................................... 23 2.3.5 Desenvolvimento do cronograma ............................................................ 23 2.3.6 Controle do cronograma .......................................................................... 23 2.4 CUSTO ......................................................................................................... 23 2.4.1 Estimativa de custos................................................................................ 24 2.4.2 Oramento ............................................................................................... 24 2.4.3 Controle de custos................................................................................... 24 2.5 QUALIDADE ................................................................................................... 24 2.5.1 Planejamento da qualidade ..................................................................... 25 2.5.2 Garantia da qualidade ............................................................................. 25 2.5.3 Controle da qualidade ............................................................................. 26 2.6 RECURSOS HUMANOS.................................................................................... 26 2.6.1 Planejamento de recursos humanos ....................................................... 26 2.6.2 Contratar ou mobilizar a equipe do projeto.............................................. 28 2.6.3 Desenvolver a equipe do projeto ............................................................. 28 2.6.4 Gerenciar a equipe do projeto ................................................................. 29 2.7 COMUNICAES ............................................................................................ 29 2.7.1 Planejamento das comunicaes ............................................................ 30 2.7.2 Distribuio das informaes .................................................................. 31

2.7.3 Relatrio de desempenho ....................................................................... 32 2.7.4 Gerenciar as partes interessadas ............................................................ 33 2.8 RISCOS......................................................................................................... 33 2.8.1 Planejamento do gerenciamento de riscos.............................................. 34 2.8.2 Identificao dos riscos ........................................................................... 35 2.8.3 Anlise qualitativa de riscos .................................................................... 35 2.8.4 Anlise quantitativa de riscos .................................................................. 35 2.8.5 Planejamento de respostas a riscos ........................................................ 36 2.8.6 Monitoramento e controle dos riscos ....................................................... 36 2.9 AQUISIES .................................................................................................. 37 2.9.1 Planejar compras e aquisies ................................................................ 37 2.9.2 Planejar contrataes .............................................................................. 38 2.9.3 Solicitar respostas de fornecedores ........................................................ 38 2.9.4 Seleo de fornecedores ......................................................................... 39 2.9.5 Administrao de contrato ....................................................................... 40 2.9.6 Encerramento do contrato ....................................................................... 40 3 INTRODUO AO SCRUM .............................................................................. 42 3.1 CICLO DE VIDA .............................................................................................. 43 3.2 OS PAPIS DO SCRUM .................................................................................... 45 3.2.1 O papel do Product Owner ...................................................................... 46 3.2.2 O papel do SCRUM Master ..................................................................... 46 3.2.3 O papel do Time ...................................................................................... 46 3.3 ARTEFATOS DO SCRUM................................................................................ 47 3.3.1 Product Backlog ...................................................................................... 47 3.3.2 Sprint Backlog ......................................................................................... 48 3.3.3 Burndown Chart....................................................................................... 48 3.4 PLANEJANDO UM PROJETO SCRUM ............................................................... 49 3.5 GERENCIANDO UM PROJETO SCRUM ................................................................ 50 4 PMBOK X SCRUM ............................................................................................ 52 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 5 CICLO DE VIDA .............................................................................................. 53 INTEGRAO E ESCOPO ................................................................................. 53 DETERMINAR CUSTO ...................................................................................... 53 CRONOGRAMA .............................................................................................. 54 DEFINIR RISCOS DO PROJETO ......................................................................... 54 PLANEJAR RECURSOS HUMANOS ..................................................................... 54 QUALIDADE.................................................................................................... 55 COMUNICAES ............................................................................................ 55 AQUISIES .................................................................................................. 56 FINALIZAO DO PROJETO ............................................................................. 56 O PODER DO PMBOK NO GERENCIAMENTO DE UM PROJETO SCRUM .............. 56

CONCLUSO .................................................................................................... 58

REFERNCIAS BIBLIOGRFICAS ......................................................................... 60

LISTA DE FIGURAS
Figura 1 - Sequncia tpica de fases no ciclo de vida de um projeto......................... 14 Figura 2 A relao entre as partes interessadas e projeto. .................................... 15 Figura 3 - Processos de monitoramento e controle. .................................................. 16 Figura 4 - Desenvolver a declarao do escopo preliminar do projeto...................... 18 Figura 5 - Exemplo de uma EAP. .............................................................................. 21 Figura 6 - Formato de definies de funes e responsabilidades. .......................... 27 Figura 7 - Viso geral de atividades do SCRUM ....................................................... 45 Figura 8 - Exemplo de Burndown Chart .................................................................... 49 Figura 9 - Novo ciclo de vida do SCRUM. ................................................................. 57

INTRODUO

O mercado de tecnologia est se tornando cada vez mais globalizado e competitivo forando as empresas a viverem em constante atualizao, tem-se notado uma busca incessante das organizaes no uso de mtodos geis e melhores prticas de gerenciamento de projetos. Segundo Harris (2001), uma metodologia de planejamento de projetos uma abordagem estruturada empregada para guiar a equipe do projeto durante o seu desenvolvimento. A metodologia varia muito com relao complexidade e o tipo de ferramentas que usa para atingir seus objetivos. Seu emprego adequado pode significar a diferena entre se concluir satisfatoriamente ou no um projeto. Isso de especial importncia quando se sabe que, de um modo geral, aproximadamente 50% dos projetos falham em atingir seus objetivos, devido principalmente complexidade das atividades envolvidas. O guia Project Management Body of Knowledge, PMBOK, um conjunto de prticas em gerenciamento de projetos levantado pelo Project Management Institute, PMI. O PMBOK foi a primeira publicao da PMI como um white paper em 1987, uma tentativa de documentar e padronizar prticas e informaes aceitas como gerenciamento de projeto. A primeira verso oficial do guia foi lanada em 1996, aps quatro anos; em 2000, foi lanada a segunda edio. Em 2004 the PMBOK Guide - 3 Edio foi publicada com a maior alterao desde o seu lanamento. A verso em ingls da 4 Edio, PMBOK Guide - Fourth Edition, foi lanada em 31 de Dezembro de 2008 (PMBOK, 2004). O PMBOK sugere quais processos devem ser executados, nas reas de escopo, tempo, custo, recursos humanos, comunicao, risco, aquisies e qualidade, e tambm prope um conjunto de processos para a juno dessas reas. O Guia PMBOK tem sido a principal fonte de informaes para as empresas interessadas em melhorar os seus processos de gerenciamento. Identifica um conjunto de conhecimentos em gerenciamento de projetos que seria amplamente reconhecido como boa prtica (PMBOK, 2004). O SCRUM uma prtica gil de desenvolvimento que permite manter o foco da entrega da maior prioridade do projeto no menor tempo possvel, dis-

10

ponibilizando artefatos aos quais vm se mostrando eficazes no gerenciamento de projetos. O objetivo desse trabalho apresentar uma nova forma de proporcionar agilidade no gerenciamento de projetos utilizando tcnicas do PMBOK, j consolidadas, no desenvolvimento de um projeto com SCRUM. O estudo foi realizado primeiramente por meio de um levantamento bibliogrfico, em uma condio metodolgica qualitativa, sobre o cenrio atual do desenvolvimento de software, sobre o PMBOK e o SCRUM. Em um segundo momento, buscou-se verificar como as reas de conhecimento do PMBOK podem auxiliar o SCRUM no gerenciamento de um projeto, para finalmente, mostrar documentos, artefatos ou indicaes tcnicas j consolidadas que podero ser usadas para auxiliar neste gerenciamento. A meta estabelecer um relacionamento por meio de um framework entre o PMBOK e o SCRUM, identificando e descrevendo como as reas de conhecimento do PMBOK podem ser usadas e implementadas no SCRUM. O captulo 1 trata-se de uma introduo sobre o que ensina o guia de conhecimentos PMBOK abordando a importncia de um bom gerenciamento de projetos. O captulo 2 explica resumidamente as 9 reas de conhecimento descritas no guia PMBOK. O captulo 3 introduz outra realidade de gerenciamento de projetos que so os mtodos geis, a prtica gil abordada ser o SCRUM. O captulo 4 realiza uma comparao das atividades realizadas no SCRUM com as 9 reas de conhecimento descritas no guia PMBOK. Por fim, sugeriremos abordagens a serem includas nas atividades do SCRUM com a finalidade de tornar o gerenciamento de projetos com SCRUM mais preventivo e eficaz.

11

O QUE O PMBOK Segundo Delemos (2001) o Project Management Body of Knowled-

ge, PMBOK, consiste na consolidao do conhecimento e expertise na rea de gesto de projetos, desenvolvido pelo Project Management Institute (PMI), uma organizao internacional que rene profissionais da rea de gerncia de projetos. O PMBOK,foi criado para gerenciar projetos de grande porte, apresentando os requisitos necessrios a serem empregados no planejamento e gerenciamento de forma satisfatria na maioria das empresas. O PMBOK fornece um conjunto de conhecimentos reconhecidos como boa prtica no gerenciamento de projetos. No significando que um determinado projeto deve seguir a risca o Guia PMBOK, assim sendo, cabe a equipe de gerenciamento de projetos indicar o que adequado a um projeto especifico (PMBOK, 2004).

O Guia PMBOK est dividido em trs sees: 1. A estrutura do gerenciamento de projetos: define termos-chave do guia e aborda o ciclo de vida e organizao de um projeto. 2. A norma de gerenciamento de projetos de um projeto: especifica os cinco grupos de gerenciamento de projetos necessrios. 3. As reas de conhecimento em gerenciamento de projetos: organiza os 44 processos do grupo de gerenciamento de projetos em nove reas de conhecimento.

1.1

O QUE UM PROJETO

De acordo com o guia do PMBOK (2004) projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. Por ser temporrio, possui inicio e finais bem definidos. Nessa concepo, um projeto pode ser um produto, servio ou resultados esperados, um item final ou item componente, um software, uma pesquisa, um documento.

12

Operaes diferem de projeto, este temporrio, terminando quando todas as etapas so cumpridas, enquanto operaes tm como objetivo manter o negcio adotando um novo conjunto de objetivos e o trabalho contnuo. Os projetos organizam tarefas que no podem ser abordadas dentro dos limites operacionais de uma organizao, atingindo assim um plano estratgico que pode ser uma ou mais dos seguintes itens:

a) b) c) d) e)

Demanda de mercado. Necessidade organizacional. Solicitao de um cliente. Avano tecnolgico. Requisito legal.

Em uma explicao: uma empresa de software autoriza o desenvolvimento de um projeto para criao de um novo software capaz de prever o futuro de uma pessoa com base em estatsticas e no histrico de sua vida.

1.2

O QUE GERENCIAMENTO DE PROJETOS.

O guia do PMBOK (2004) define o gerenciamento de projetos como sendo o emprego dos seguintes processos: iniciao, planejamento, execuo, monitoramento e controle, e encerramento. O gerente de projetos o responsvel pela realizao dos objetivos, sendo suas funes: a identificao de necessidades; o estabelecimento de objetivos claros e alcanveis; balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo; Adaptao das especificaes e planos. H trs fatores que afetam no gerenciamento e qualidade de um projeto: escopo, tempo e custo do projeto. Se um desses fatores muda, pelo menos outro fator ser prejudicado tambm (PMBOK, 2004). Para que um gerenciamento de projetos seja eficaz necessrio que a equipe entenda e use o conhecimento e habilidades de no mnimo cinco reas de especializao:

13

a) O conjunto de conhecimentos em gerenciamento de projetos. b) Conhecimentos, normas e regulamentos da rea da aplicao. c) Entendimento do ambiente do projeto. d) Habilidades interpessoais.

1.3

CICLO DE VIDA E A ORGANIZAO DO PROJETO:

Os gerentes de projetos podem dividir projetos em fases iniciais e fases finais, assim obtendo um melhor controle gerencial, conhecido como ciclo de vida de um projeto. Um ciclo de vida geralmente define o trabalho a ser realizado em cada fase; quando e como as entregas so verificadas e validadas; quem so as pessoas ou departamentos envolvidos e como realizar o controle e aprovao de cada fase (PMBOK, 2004). A descrio do ciclo de vida pode conter formulrios, grficos e listas de verificao oferecendo estrutura e controle. Os ciclos de vida podem compartilhar caractersticas em comum, como fases sequenciais e definidas por algum formulrio de transparncia e informaes tcnicas, os custos so baixos no inicio, apresentam valor mximo em fases intermediarias e decaem no final (PMBOK, 2004).

Caractersticas das fases do projeto:

De acordo o guia PMBOK (2004) uma fase a aprovao de um ou mais produtos. Devido a restries de complexidade, financeiras, controle e nvel de risco, as fases tambm podem ser subdivididas em subfases, e cada subfase associada a um ou mais produtos para monitoramento e controle. Normalmente as fases recebem nomes relacionados a seus produtos: requisitos, projeto, construo, teste, inicializao, entrega e outros.

14

Concluir-se- uma fase revisando o trabalho realizado para analisar se ainda existe algo a ser feito. Uma nova fase pode ser iniciada sem que seja finalizada a atual, por exemplo, quando o gerente de projetos escolhe paralelismo como ao. Enquanto est sendo realizado um mdulo, a coleta de requisitos de outro pode estar sendo realizada em paralelo (PMBOK, 2004). Uma fase tambm pode ser finalizada sem a deciso de iniciar outras fases, se o projeto terminou ou oferece um risco grande demais (PMBOK, 2004).

Figura 1 - Sequncia tpica de fases no ciclo de vida de um projeto. Fonte: (PMBOK, 2004).

1.4

PARTES INTERESSADAS NO PROJETO:

Pessoas e organizaes ativamente envolvidas no projeto ou que exercem alguma influncia so as partes interessadas. A equipe de gerenciamento deve identificar as necessidades e expectativas das partes interessadas e gerenciar sua influncia em relao aos requisitos para garantia de sucesso (PMBOK, 2004).

15

Figura 2 A relao entre as partes interessadas e projeto. Fonte: (PMBOK, 2004).

As partes interessadas podem ter uma influncia positiva ou negativa em um projeto. Como exemplo, lderes de uma comunidade, que se beneficiariam de um projeto de expanso industrial as quais enxergam benefcios econmicos para a comunidade a partir do sucesso do projeto, se comportariam como influncia positiva. Por outro lado, grupos ambientais poderiam ser partes interessadas negativas se considerarem que o projeto prejudica o meio ambiente (PMBOK, 2004).

1.5

PROCESSOS DE GERENCIAMENTO DE PROJETOS:

De acordo com o guia PMBOK (2004) existem cinco grupos de gerenciamento de projetos: - Grupo de iniciao tem a responsabilidade de definir ou autorizar um projeto ou fase. - Grupo de planejamento faz a definio e o refinamento dos objetivos planejando a ao necessria para alcanar os objetivos e o escopo para os quais o projeto foi realizado. - Grupo de execuo rene pessoas e recursos para realizar o plano de gerncia do projeto.

16

- Grupo de monitoramento e controle faz a medio e o monitoramento do progresso do projeto, de forma que possam ser feitas correes para que o andamento do projeto seja um sucesso. - Grupo de encerramento, por sua vez, tem o papel de formalizar a aceitao do produto.

Figura 3 - Processos de monitoramento e controle. Fonte: (PMBOK, 2004).

17

AS REAS DE CONHECIMENTO DO PMBOK

O PMBOK dividido em nove reas de conhecimento que so: Integrao; Escopo; Tempo; Custo; Qualidade; Recursos Humanos; Comunicaes; Riscos e Aquisies. O guia PMBOK descreve boas prticas para cada uma dessas reas de conhecimento, assim como fornece toda a documentao necessria mostrando todos os processos de entrada, algumas ferramentas e tcnicas necessrias que auxiliam na documentao de cada rea e, tambm as sadas geradas (PMBOK, 2004).

2.1

INTEGRAO A rea de conhecimento integrao fornece processos necessrios

que asseguram que os elementos do projeto sero gerenciados de forma correta (PMBOK, 2004). Entre os processos de gerenciamento de integrao podemos destacar:

2.1.1 Termo de abertura de um projeto

Documento que autoriza formalmente um projeto ou uma fase. O termo de abertura e a autorizao dos projetos muitas vezes sero realizados fora do ambiente da empresa, motivado por uma demanda de mercado, uma necessidade de negcios, alguma solicitao realizada por um cliente dentre outras. Um exemplo de motivao seria: uma empresa de software autoriza o projeto de desenvolvimento de um sistema para supermercados devido demanda excessiva de pedidos por parte dos supermercados. (PMBOK, 2004). O termo de abertura fornece ao gerente a autoridade necessria, a aplicao de recursos organizacionais que sero utilizados. O gerente de projetos deve ser designado antes do inicio do planejamento e, melhor, se for designado durante o desenvolvimento do termo de abertura (PMBOK, 2004).

18

Esse documento trata das necessidades de negcios, justificando o desenvolvimento desse projeto atravs do detalhamento das atuais necessidades dos clientes (PMBOK, 2004).

Figura 4 - Desenvolver a declarao do escopo preliminar do projeto. Fonte: (PMBOK, 2004).

2.1.2 Declarao do escopo preliminar

A declarao do escopo preliminar o processo necessrio para produo de uma definio prvia de alto nvel do projeto tendo como base o termo de abertura unido a outras entradas para os processos de iniciao. Este processo consiste em um documento com os requisitos do projeto e da entrega, os requisitos do produto, os limites, os mtodos de aceitao e o controle de alto nvel do escopo. Em projetos com vrias fases, este processo valida ou refina o escopo do projeto para cada fase (PMBOK, 2004). 2.1.3 Plano de gerenciamento de um projeto Documento que descreve as aes necessrias para definio, preparao, integrao e coordenao de todos os planos auxiliares. O plano de gerenciamento do projeto se torna a principal fonte de informaes de planejamento, execuo, monitoramento e controle e, encerramento (PMBOK, 2004).

19

2.1.4 Orientao e execuo de um projeto Cumprimento do plano de gerenciamento a fim de atingir os requisitos definidos no documento de declarao do escopo. Este o processo necessrio para orientar as diversas interfaces tcnicas e organizacionais (PMBOK, 2004). As entregas so produzidas como sadas dos processos realizados conforme definido no plano de gerenciamento. Informaes sobre a situao atual das entregas e sobre a quantidade de trabalho realizado so coletadas como parte da execuo do projeto e como entradas para o processo de relatrio de desempenho (PMBOK, 2004).

2.1.5 Monitoramento e controle do trabalho do projeto Esse processo tem o papel de monitorar e controlar os processos usados para iniciar, planejar, executar e encerrar atendendo os objetivos do plano de gerenciamento. Este o processo necessrio para coletar, medir e disseminar informaes sobre o desempenho e, avaliar as medies e as tendncias para efetuar melhorias no processo. Este processo inclui o monitoramento de riscos para garantir que os riscos sejam identificados no incio, que o andamento seja relatado e que planos de risco adequados estejam sendo executados. O monitoramento inclui emisso de relatrios de andamento, avaliao do progresso e previso. Os relatrios de desempenho fornecem informaes sobre o desempenho do projeto em relao a escopo, cronograma, custo, recursos, qualidade e risco (PMBOK, 2004).

2.1.6 Controle de mudanas Reviso de todas as solicitaes de mudana, aprovao e controle. Este o processo necessrio para controlar os fatores que criam mudanas e oferecem garantia de beneficio, determinar se ocorreu uma mudana e gerenci-la, inclusive o momento em que ocorre. Esse processo realizado durante todo o projeto, desde a iniciao at o encerramento do projeto (PMBOK, 2004).

20

2.2

ESCOPO Segundo o guia PMBOK (2004), o gerenciamento de escopo tem a

finalidade de garantir que o projeto possa ser completado com sucesso, fazendo apenas o trabalho necessrio. Controlando o que deve e o que no deve estar incluso em um projeto. Os principais processos dessa rea de conhecimento so:

2.2.1 Planejamento do escopo Documento que tem a finalidade de descrever como ser a definio, verificao e controle do projeto de escopo e da estrutura analtica do projeto. A definio e o planejamento do projeto influenciam totalmente no sucesso de um projeto. O desenvolvimento do planejamento do escopo se inicia analisando o termo de abertura do projeto, a declarao do escopo preliminar do projeto, a ultima verso aprovada do gerenciamento do projeto, o histrico dos ativos dos processos organizacionais e por fatores ambientais relevantes (PMBOK, 2004).

2.2.2 Definio Definio detalhada do escopo de um projeto, das entregas necessrias e do trabalho necessrio para criar essas entregas como base para decises futuras. Essa definio desenvolvida a partir das principais entregas, premissas e restries que so documentadas no inicio do projeto, na declarao do escopo preliminar do projeto (PMBOK, 2004).

2.2.3 Criar EAP Consiste em dividir as principais entregas e trabalhos do projeto de modo que se tornem mais fceis de serem gerenciadas, organizando e definindo o escopo geral do projeto. Uma EAP faz a decomposio das entregas em componentes menores at o ponto no qual o custo e o cronograma de trabalho possam ser estimados de forma confivel. Muito frequentemente, uma organizao pode aproveitar

21

uma EAP de um projeto anterior, pois na maioria dos projetos dentro de uma determinada organizao possuem entregas iguais ou semelhantes (PMBOK, 2004).

Figura 5 - Exemplo de uma EAP. Fonte (PMBOK, 2004).

2.2.4 Verificao Documento que formaliza a aceitao das entregas finalizadas que foram aprovadas e tambm as entregas finalizadas que foram reprovadas, essas so documentadas juntamente com as razes de sua reprovao (PMBOK, 2004).

2.2.5 Controle Controle de mudanas do escopo de um projeto. Esse controle consiste em influenciar os fatores que geram alteraes no escopo e pretende controlar o impacto dessas alteraes. As mudanas so inevitveis e por isso necessrio esse processo, se as solicitaes aprovadas afetam o escopo do projeto ento devero ser atualizados os documentos da declarao do escopo do projeto, da estrutura

22

analtica do projeto, do dicionrio de EAP, da linha base de escopo, de ativos de processos organizacionais e no plano de gerenciamento do projeto. (PMBOK, 2004).

2.3

TEMPO Segundo o guia PMBOK (2004), o gerenciamento do tempo envolve

processos e tcnicas para assegurar que um projeto seja concludo dentro do prazo determinado. Os principais processos dessa rea de conhecimento so:

2.3.1 Definio da atividade Identificao da lista de atividades necessrias para produzir as entregas do projeto. A lista de atividades inclui um identificador e a descrio do escopo de cada atividade a ser realizada no cronograma de modo que, os membros da equipe do projeto compreendam que essa atividade dever ser cumprida (PMBOK, 2004).

2.3.2 Sequenciamento de atividades Documento que identifica as dependncias entre as atividades do cronograma. So utilizados alguns diagramas como o mtodo de diagrama de precedncia, e o mtodo de diagrama de setas (PMBOK, 2004).

2.3.3 Estimativa de recursos Estimativa do tipo e das quantidades de recursos necessrios (pessoais, equipamentos ou material) para realizar cada atividade do cronograma. Esse processo de estimativa de recursos estreitamente coordenado com a estimativa de custos (PMBOK, 2004).

23

2.3.4 Estimativa de durao da atividade Estima o nmero de perodos necessrios para finalizar as atividades individuais usando as informaes sobre escopo da atividade de cronograma, tipos de recursos, quantidades de recursos necessrios, e calendrio com a disponibilidade de recursos. O processo exige que a quantidade de esforo de trabalho para a finalizao de cada atividade do cronograma seja estimada assim como a previso da quantidade de recursos necessrios para o trmino da atividade do cronograma e o nmero de perodos de trabalhos necessrios (PMBOK, 2004).

2.3.5 Desenvolvimento do cronograma Anlise dos recursos necessrios, restries no cronograma, duraes e seqncia de atividades necessrias para criar o cronograma do projeto. Esse processo ira determinar as datas de inicio e trmino das atividades do projeto, podendo ser necessrio reexaminar as estimativas de durao e de recursos, assim criando um cronograma aprovado o qual possa servir como linha base do projeto. (PMBOK, 2004). Esse desenvolvimento do cronograma continua durante todo o trabalho, pois conforme o trabalho se desenvolve tambm ocorrem mudanas no gerenciamento do projeto e alguns eventos esperados ocorrem ou deixam de existir, assim como novos eventos tambm podem ser identificados (PMBOK, 2004).

2.3.6 Controle do cronograma Esse processo tem o papel de controlar as mudanas realizadas no cronograma de um projeto (PMBOK, 2004).

2.4

CUSTO Segundo o guia PMBOK (2004), o gerenciamento de custo descre-

ve os processos para que um projeto seja concludo dentro do oramento que lhe foi aprovado. Os principais processos so:

24

2.4.1 Estimativa de custos Desenvolvimento de uma estimativa dos custos dos recursos necessrios para a concluso de cada atividade do projeto (PMBOK, 2004).

Essa estimativa inclui a identificao de alternativas de custos. Os custos de cada atividade devero ser estimados para cada recurso, como por exemplo, mo-de-obra, materiais e equipamentos (PMBOK, 2004).

2.4.2 Oramento Estabelece uma base de custos envolvendo os custos estimados de atividades individuais do cronograma ou pacotes de trabalho, com o objetivo de estabelecer uma linha de base de todos os custos para a realizao da medida do desempenho do projeto (PMBOK, 2004). Pretende-se obter uma linha base dos custos, que nada mais do que um oramento dividido em fases. desenvolvida a partir da soma de custos estimados por perodo. Atravs da linha base de custos poderemos determinar a necessidade de financiamento total e peridica do projeto (PMBOK, 2004).

2.4.3 Controle de custos Controlar os fatores que alteram os custos das atividades no oramento do projeto garantindo que houve um acordo sobre as alteraes solicitadas, tambm garante e monitora mudanas nos custos para que esses no ultrapassem o financiamento autorizado peridico ou total do projeto (PMBOK, 2004).

2.5

QUALIDADE De acordo com o guia PMBOK (2004), o gerenciamento de qualidade

tem a finalidade de assegurar que todas as necessidades originais as quais levaram a criao do projeto sejam atendidas. O gerenciamento de qualidade se preocupa

25

principalmente com a satisfao dos clientes, com a preveno de erros, pois os custos de prevenir so muito menores dos custos de corrigir, com a responsabilidade da gerncia, e com a melhoria contnua do processo. Os principais processos de gerenciamento de qualidade so:

2.5.1 Planejamento da qualidade Identificar os padres de qualidade essenciais e como satisfaz-los. Esse procedimento um dos principais durante a execuo do grupo de processos de planejamento sendo realizado em paralelo com outros processos de planejamento. As mudanas no padro de qualidade podem alterar os custos, ou o cronograma do projeto (PMBOK, 2004). O gerenciamento moderno de qualidade possui os princpios de que a qualidade no inspecionada e sim planejada, projetada e incorporada (PMBOK, 2004). Para o planejamento de qualidade so aplicadas algumas ferramentas e tcnicas como analise de custo-benefcio, benchmarking, custo da qualidade e outras ferramentas adicionais de planejamento, como brainstorming, diagramas de afinidade e analise do campo de fora (PMBOK, 2004).

2.5.2 Garantia da qualidade Realizao de atividades de qualidade com a finalidade de garantir que um projeto possa empregar todos os processos necessrios, assim atendendo todos os requisitos (PMBOK, 2004). A melhoria contnua dos processos consegue reduzir desperdcios e o desenvolvimento de atividades que no possuem valor algum, permitindo aos processos trabalhar em nveis maiores com uma melhor eficincia (PMBOK, 2004).

26

2.5.3 Controle da qualidade Monitoramento e controle dos resultados para verificao do padro de qualidade e a eliminao das causas de um desempenho insatisfatrio (PMBOK, 2004). O controle da qualidade monitora os resultados especficos de um projeto com o objetivo de determinar se esto de acordo com os padres e identifica algumas maneiras para eliminar as causas de resultados no satisfatrios. Precisa ser realizado ao longo de todo o plano. Os padres de qualidade incluem objetivos de produtos e processos de um projeto (PMBOK, 2004).

A realizao do controle de qualidade muitas vezes feita por um departamento de controle de qualidade ou uma unidade organizacional. uma responsabilidade da equipe de gerenciamento reter o conhecimento prtico de controle estatstico da qualidade, em especial de amostragem e probabilidade, para que seja possvel avaliar as sadas (PMBOK, 2004).

2.6

RECURSOS HUMANOS

Para o guia PMBOK (2004) o gerenciamento de recursos humanos inclui processos de organizao e gerenciamento da equipe do projeto, tendo o papel fundamental de tornar mais efetivo a participao das pessoas envolvidas no projeto. Os membros da equipe devem participar do processo de tomada de deciso, pois o envolvimento dos membros com o projeto fortalece o interesse e o comprometimento com o trabalho. Os principais processos dessa rea de conhecimento so: 2.6.1 Planejamento de recursos humanos Documento que descreve as funes, responsabilidades, hierarquia de cargos e um plano de gerenciamento de pessoal. As funes podem ser designadas para pessoas ou grupos internos ou externos organizao executora (PMBOK, 2004).

27

O plano de gerenciamento de pessoal inclui informaes sobre como e quando os membros sero contratados, assim como os critrios da liberao do projeto, identificando as necessidades de treinamento, desenvolvendo planos de premiao, analisando os problemas de segurana e tambm sobre o impacto geral do planejamento de recursos humanos da empresa (PMBOK, 2004). Existem diversas maneiras para documentar as funcionalidades de cada membro da equipe, uma delas atravs do organograma e descries de cargo, a maioria dos formatos dessa documentao se enquadra nesses trs tipos:

Figura 6 - Formato de definies de funes e responsabilidades. Fonte: (PMBOK, 2004).

Ao final do planejamento de recursos humanos, tm-se documentos das funes e responsabilidades de cada membro envolvido no projeto, bem como o organograma de hierarquia e grfico de responsabilidades. H tambm um plano de gerenciamento de pessoal formal ou informal para a orientao de recrutamento, seleo de membros da equipe em andamento e aes de desenvolvimento (PMBOK, 2004). O plano de gerenciamento de pessoal varia de acordo com a rea de aplicao; mas, geralmente, inclui itens a serem considerados como recrutamento e seleo, tabela de horrios, critrios de liberao, necessidades de treinamento, reconhecimentos e premiaes, conformidade e segurana (PMBOK, 2004).

28

2.6.2 Contratar ou mobilizar a equipe do projeto Mobilizar a equipe do projeto obtendo recursos humanos necessrios para a concluso do projeto. Nem sempre a equipe de gerenciamento do projeto consegue ter o controle sobre os membros selecionados da equipe (PMBOK, 2004). Em alguns casos, os membros da equipe do projeto so pr-designados, conhecidos antes do inicio. Quando a organizao no dispuser do pessoal interno necessrio para finalizao do projeto, os servios exigidos podem ser adquiridos atravs da ajuda de mo-de-obra externa. Isso, alguma vezes, envolve a contratao de consultores individuais ou a subcontratao de trabalho de outra organizao (PMBOK, 2004). J frequente, o uso de equipes virtuais em muitas empresas, pois cria novas possibilidades durante a contratao. Uma equipe virtual pode ser definida como grupos de pessoas com uma meta compartilhada que executam suas funes sem se encontrarem pessoalmente na maior parte do tempo. Os avanos da tecnologia, mas especificamente da Internet, viabilizou esse tipo de contribuio atravs de comunicao via email, videoconferncia, e muitas outras ferramentas interessantes (PMBOK, 2004). O processo de contratao e mobilizao da equipe do projeto designa o quadro de pessoal adequado para trabalhar, bem como a disponibilidade de recursos, documentando a quantidade de tempo que cada membro poder trabalhar e atualizando o plano de gerenciamento do pessoal conforme as pessoas especificadas preenchem as funes e responsabilidades do projeto (PMBOK, 2004).

2.6.3 Desenvolver a equipe do projeto Esse processo busca melhorar a qualidade e a interao entre os membros de um projeto, aprimorando as habilidades, sentimentos de confiana e coeso dos membros da equipe, e assim, aumentando sua capacidade de terminar atividades do projeto e desenvolvendo uma equipe de melhor qualidade (PMBOK, 2004).

29

Os esforos de desenvolvimento da equipe apresentam uma maior eficcia se direcionados de forma correta desde o inicio, mas esse processo deve ocorrer durante todo o ciclo de vida do projeto (PMBOK, 2004). Ao final desse processo, pode-se avaliar melhor o desempenho da equipe, espera-se que as estratgias e treinamentos aumentem o seu desempenho e, consequentemente, a probabilidade do projeto ser concludo com eficcia (PMBOK, 2004).

2.6.4 Gerenciar a equipe do projeto Acompanha o desempenho das pessoas envolvidas com o fornecimento de opinio, resolvendo os problemas e coordenando mudanas para obteno de um melhor desempenho (PMBOK, 2004). A equipe de gerenciamento de projetos deve fazer o monitoramento do comportamento da equipe, gerenciando conflitos, resolvendo problemas e avaliando o desempenho das pessoas. Assim obtendo como resultado, a atualizao do plano de gerenciamento de pessoal, solicitaes de mudanas, resoluo de problemas, fornecimento de entradas para as avaliaes de desempenho da organizao e a atualizao do banco de dados da organizao com as lies aprendidas (PMBOK, 2004). O gerenciamento da equipe do projeto se torna complexo quando membros da equipe precisam prestar contas a um gerente funcional e a um gerente de projetos dentro de uma organizao matricial. um fator relevante para o sucesso do projeto o gerenciamento correto dessa dupla relao de responsabilidade, e o gerente de projetos o responsvel (PMBOK, 2004). 2.7 COMUNICAES Os gerentes de projetos podem gastar um tempo desnecessrio na comunicao com a equipe do projeto, partes interessadas, cliente e patrocinador. Todas as partes envolvidas no projeto so obrigadas a entender como as comunicaes afetam o projeto inteiro. O gerenciamento de comunicaes faz o uso de processos necessrios para assegurar a gerao, a captura, distribuio, armazena-

30

mento e apresentao das informaes do projeto, de forma adequada. (PMBOK, 2004). O processo de gerenciamento de comunicaes do projeto fornece os relacionamentos entre pessoas e informaes que sero necessrios para comunicaes eficazes (PMBOK, 2004). De acordo com o guia PMBOK (2004), as habilidades de comunicao esto relacionadas s comunicaes de gerenciamento de projetos. O conjunto de conhecimento da arte da comunicao inclui: - Modelos emissor-receptor - Loops de feedback e barreiras comunicao. - Escolha dos meios de comunicao. Quando e como se comunicar, por escrito ou verbalmente, se necessrio escrever um memorando informal ou um relatrio formal e quando se comunicar pessoalmente ou por email. O meio de comunicao escolhido depende da situao de cada caso. - Estilo de redao. Voz ativa ou passiva, estrutura da frase e escolha das palavras. - Tcnicas de apresentao. Linguagem corporal e design de recursos visuais. - Tcnicas de gerenciamento de reunies. Preparao de uma pauta e tratamento de conflitos. Os principais processos dessa rea de conhecimento so: 2.7.1 Planejamento das comunicaes Determina as informaes e comunicaes necessrias das partes interessadas no projeto. O processo de planejamento das comunicaes determina as necessidades de informaes e comunicaes das partes interessadas, assim como quem precisa de determinada informao, quem a fornecera, quando e como ser fornecida (PMBOK, 2004). Um fator determinante do sucesso do projeto a identificao das necessidades de informaes das pessoas envolvidas no projeto e a determinao da maneira adequada para o atendimento dessas necessidades. Na maioria dos projetos, a grande parte do planejamento das comunicaes realizada na fase inicial do projeto, porem, os resultados desse processo de planejamento so reexami-

31

nados freqentemente durante o desenvolvimento do projeto e revisados conforme a necessidade, garantindo assim a aplicao continua do processo de comunicaes (PMBOK, 2004). O plano de gerenciamento das comunicaes faz parte ou auxilia o plano de gerenciamento do projeto fornecendo: - Requisitos de comunicao das partes interessadas. - Informaes que sero comunicadas, incluindo o formato do comunicado, a partir de seu contedo at os detalhes da comunicao. - A pessoa que ser responsvel pela divulgao da comunicao dessas informaes. - A pessoa ou os grupos de pessoas que sero as receptoras da informao. - Mtodos e tecnologias usados na transmisso dessas informaes, como memorandos, email, cartas e comunicados imprensa - A frequncia da comunicao. - Os prazos para identificao de processos aumentando o nvel e a cadeia gerencial e assim levando a nveis mais altos problemas que no podero ser solucionados em um nvel hierrquico mais baixo. - O mtodo de atualizao e refinamento do plano de gerencia das comunicaes conforme o projeto se desenvolve. - Glossrio da terminologia comum.

2.7.2 Distribuio das informaes No momento certo, devem-se repassar as informaes para as partes interessadas. O processo de distribuio das informaes fornece as informaes disposio das partes interessadas no projeto em um momento oportuno. Essa distribuio de informaes inclui o desenvolvimento do plano de gerenciamento das comunicaes, alm de responder s requisies de informaes no previstas (PMBOK, 2004). As habilidades de gerenciamento geral que possuem relacionamento com as partes de gerenciamento de comunicaes incluem a garantia de que as

32

pessoas certas consigam as informaes corretas no tempo certo, da maneira como definida no plano de gerenciamento das comunicaes. Tambm esta inclusa a arte de gerenciar requisitos das partes interessadas nas habilidades de gerenciamento geral (PMBOK, 2004). As informaes podem ser captadas e recuperadas atravs de diversas formas, como por exemplo, sistemas manuais de arquivamento, bancos de dados eletrnicos, softwares para gerenciamento de projetos e outros sistemas que fornecem o acesso documentao tcnica, como desenhos de engenharia, especificaes de design e planos de teste (PMBOK, 2004). Uma sesso de lies aprendidas possui o foco na identificao dos sucessos e fracassos do projeto e fornece recomendaes para uma melhora de desempenho futuro. No decorrer do ciclo de vida do projeto, a equipe e as principais partes interessadas identificam as lies aprendidas que so relacionadas com aspectos tcnicos, gerenciais e de processos do projeto. Durante o projeto essas lies que foram aprendidas so compiladas, formalizadas e armazenadas (PMBOK, 2004). O foco das reunies de lies aprendidas pode ser varivel, o mesmo pode se concentrar em processos slidos de desenvolvimento tcnico, como tambm, se concentrar nos processos que auxiliaram ou prejudicaram o desempenho do trabalho. Se for justificado o investimento de tempo e dinheiro, as equipes podem buscar informaes com mais frequncia, se essa maior quantidade de dados trouxer benefcios. As lies aprendidas ajudam s futuras equipes de projetos a aumentar a eficincia do gerenciamento. Os gerentes de projetos tm o dever profissional de utilizar as sesses de lies aprendidas em todos os projetos em conjunto com as partes interessadas, internas e externas (PMBOK, 2004).

2.7.3 Relatrio de desempenho Coleta e distribuio de informao sobre o desempenho, fazendo um relatrio de andamento, medio do progresso e previso (PMBOK, 2004). O processo de relatrio de desempenho tem um envolvimento com a coleta dos dados da linha de base e o fornecimento de informaes sobre o desem-

33

penho para as partes interessadas. As informaes sobre o desempenho incluem a maneira como os recursos esto sendo utilizado para garantir os objetivos do projeto. O relatrio de desempenho deve fornecer informaes sobre escopo, cronograma, custo e qualidade (PMBOK, 2004).

2.7.4 Gerenciar as partes interessadas

Gerenciar as comunicaes de forma a satisfazer os requisitos das partes interessadas, resolvendo os problemas deles (PMBOK, 2004). O gerenciamento das partes interessadas faz referencia a gerencia de comunicaes para a concluso do desenvolvimento das necessidades das partes interessadas no projeto e resoluo de problemas. O gerenciamento constante das partes interessadas aumenta as chances do projeto no desviar de seus objetivos pela falta de resoluo de problemas das partes interessadas e aumenta a capacidade das pessoas trabalharem em sinergia, limitando as interrupes durante o projeto. O gerente de projetos o responsvel pelo gerenciamento das partes interessadas (PMBOK, 2004). 2.8 RISCOS O gerenciamento de riscos identifica, faz a analise, monitora, controla e reage aos riscos de um projeto. O gerenciamento de riscos atualizado durante todo o projeto com o objetivo de dar prioridade a maximizar os eventos positivos e diminuir a probabilidade de acontecer eventos negativos (PMBOK, 2004). O risco do projeto trata-se de um evento que ter um efeito positivo ou negativo caso ocorra, sobre ao menos um objetivo do projeto, assim influenciando no tempo, custo, escopo ou qualidade. Um risco pode ter vrios motivos, e se ocorrer o risco, vrios impactos. Por exemplo, uma causa pode ser a falta de pessoal designado para a codificao do projeto. O impacto de risco que o pessoal de programao disponvel e designado pode no estar preparado para a atividade (PMBOK, 2004). Se ocorrendo um desses eventos incertos, ir haver tambm um impacto no custo, cronograma ou desempenho do projeto. O ambiente da organizao

34

ou do projeto, praticas deficientes, muitos projetos simultneos ou a dependncia de mo-de-obra externa que foge ao controle da organizao, podem ajudar a maximizar essas condies de risco (PMBOK, 2004). O risco do projeto originado a partir de uma incerteza que tem presena em todos os projetos. Os riscos que j foram identificados e analisados so os riscos conhecidos, e esses riscos podem ser aceitos no planejamento usando os processos descritos no gerenciamento de riscos (PMBOK, 2004). As organizaes geralmente descobrem os riscos quando eles esto ligados a ameaas ao sucesso do projeto ou a oportunidades para maximizar as chances de sucesso. possvel aceitar os riscos ameaadores do projeto se os mesmos forem equivalentes premiao que pode ser obtida ao se assumir esses riscos (PMBOK, 2004). Os principais processos dessa rea de conhecimento so: 2.8.1 Planejamento do gerenciamento de riscos O planejamento do gerenciamento de riscos a tomada de decises sobre planejamento e execuo de atividades de gerenciamento que constituem de um ou mais riscos a um projeto (PMBOK, 2004). Esse planejamento deve ser cuidadoso, pois isso ir aumentar a probabilidade de sucesso dos outros cinco processos de gerenciamento de riscos. O planejamento do gerenciamento de riscos decide como sero, encaradas e executadas as atividades de gerenciamento de riscos de um projeto. O planejamento dos processos de gerenciamento de riscos garante que o nvel, tipo e visibilidade estejam de acordo com o risco e a importncia do projeto (PMBOK, 2004). So realizadas anlises e reunies de planejamento com as equipes de projetos a fim de desenvolver o plano de gerenciamento de riscos, onde os participantes dessas reunies podem incluir o gerente de projetos, o time selecionado e partes interessadas como tambm qualquer pessoa da organizao que tenha responsabilidade no gerenciamento de riscos (PMBOK, 2004). Sero discutidos os elementos de custo de riscos e as atividades do cronograma de riscos que necessitam ser includas no oramento e no cronograma (PMBOK, 2004).

35

2.8.2 Identificao dos riscos Documento contendo as caractersticas dos riscos que podem afetar o projeto. A identificao de riscos importante para a determinao dos riscos que podem afetar o projeto e para a documentao das caractersticas desses riscos (PMBOK, 2004). Todo o pessoal do projeto deve ser incentivado a realizar esse procedimento (PMBOK, 2004). 2.8.3 Anlise qualitativa de riscos A anlise qualitativa de riscos a avaliao da probabilidade de ocorrncia e do impacto dos riscos, atravs de mtodos que priorizam os riscos identificados para ao adicional de respostas ou uma anlise quantitativa (PMBOK, 2004). Se as empresas se concentrarem nos riscos de maior prioridade elas podem melhorar o desempenho do projeto. A anlise qualitativa avalia a prioridade e identifica a probabilidade dos riscos ocorrerem bem como o impacto para o desenvolvimento do projeto caso ocorram, e outros fatores como alteraes no cronograma, escopo e qualidade. Os dados de nveis de probabilidade e impacto juntamente com entrevistas com pessoas especializadas podem ajudar na correo de desvios freqentes nos dados usados deste processo, por esse motivo, uma avaliao da qualidade das informaes disponveis sobre riscos do projeto essencial para entender a avaliao da importncia do risco para o projeto (PMBOK, 2004).

2.8.4 Anlise quantitativa de riscos A anlise quantitativa de riscos uma anlise numrica dos efeitos dos riscos identificados. Os riscos que foram priorizados na anlise qualitativa so analisados agora nesse processo que avaliara o efeito desses riscos atribuindo uma classificao numrica a esses ricos (PMBOK, 2004). A anlise quantitativa faz uso de tcnicas como, a simulao de Monte Carlo e a anlise da rvore de deciso para assim quantificar possveis resultados do projeto bem como suas probabilidades, avaliando as chances do projeto

36

atingir seus objetivos, identificando riscos e metas reais que no entrem em conflito com o custo, cronograma ou escopo e determinando a melhor deciso de gerenciamento de projeto quando alguns resultados no forem certos (PMBOK, 2004). 2.8.5 Planejamento de respostas a riscos O planejamento de respostas a riscos tem o objetivo de reduzir as ameaas e aumentar as oportunidades dos objetivos de um projeto. Esse planejamento deve ser realizado depois dos processos de anlise qualitativa e quantitativa de riscos, identificando e designando uma ou mais pessoas que assumiro a responsabilidade sobre cada resposta a risco aprovada (PMBOK, 2004). .O planejamento de respostas trata dos riscos dando importncia a sua prioridade, inserindo recursos e atividades no oramento, cronograma e plano de gerenciamento, se for preciso. Algumas vezes necessrio selecionar a melhor resposta a riscos a partir de diversas opes (PMBOK, 2004). 2.8.6 Monitoramento e controle dos riscos Essa etapa realiza o monitoramento e controle dos riscos, acompanhando os riscos identificados e realizando novas avaliaes, identificando novos riscos e, execuo e controle do planejamento de respostas a riscos. As respostas a riscos planejadas includas no plano de gerenciamento do projeto so realizadas ao longo do ciclo de vida do projeto e o trabalho do projeto deve ser monitorado freqentemente com o objetivo de encontrar novos riscos e mudanas nos riscos (PMBOK, 2004). O processo de monitoramento e controle de riscos faz o uso de tcnicas que analisam as tendncias e variaes que exigem a utilizao dos dados de desempenho gerados durante a execuo do projeto. Esse processo como outros do gerenciamento de riscos deve ser realizado durante toda a durao do projeto. O monitoramento e controle de riscos tambm tm o objetivo de determinar se premissas do projeto ainda so vlidas, se o risco mudou sua tendncia, se os procedimentos e poltica esto sendo seguidos e se as reservas oramentrias e do cronograma devem ser atualizadas de acordo com os riscos do projeto (PMBOK, 2004).

37

2.9

AQUISIES O gerenciamento de aquisies dispe de tcnicas para aquisies

de mercadorias, produtos, resultados necessrios e servios externos da forma adequada para a realizao do trabalho (PMBOK, 2004). A organizao pode estar tanto comprando como fornecendo um produto, servio ou resultados sob um contrato. O gerenciamento de aquisies inclui processos de gerenciamento de contratos e de controle de mudanas necessrios para administrao de contratos ou pedidos de compra realizados por membros com autorizao. Incluindo tambm a administrao dos contratos emitidos por uma organizao externa que est adquirindo o projeto do fornecedor e administra tambm as obrigaes contratuais que foram estabelecidas para a equipe do projeto pelo contrato (PMBOK, 2004). O contrato tem um papel muito importante, pois define um acordo gerando obrigaes entre as partes obrigando que se cumpra o prometido disposto no contrato sob a pena de multas e outras penalidades, uma relao legal sujeita a discusso nos tribunais. Os principais processos da rea de conhecimento de gerenciamento de aquisies so: 2.9.1 Planejar compras e aquisies O planejamento de compras e aquisies e a determinao do que comprar, quando e de que modo. Quando um projeto adquiriu produtos, servios e resultados necessrios para o desempenho do projeto de uma organizao externa, os processos de planejamento, compras e aquisies at o final do contrato so executados para todos os itens a serem adquiridos. Esse processo tambm considera a incluso de possveis fornecedores, especialmente se o comprador desejar ter influncia ou controle sobre as decises de contratao. Tambm deve ser considerado quem responsvel por adquirir ou manter autorizaes e licenas que a legislao vigente pode exigir (PMBOK, 2004).

38

O cronograma do projeto pode influenciar muito no processo de planejamento de compras, pois esse planejamento inclui a anlise dos riscos envolvidos sob cada deciso (PMBOK, 2004).

2.9.2 Planejar contrataes O processo de gerenciar o planejamento de contrataes um documento contendo requisitos dos produtos, servios e resultados para ajudar nas identificaes de novos fornecedores e solicitar respostas (PMBOK, 2004). Algumas ferramentas e tcnicas para esse processo incluem a necessidade de uma opinio especializada e de formulrios padro que incluem contratos padro, descries padro de itens de aquisio, termos de confidencialidade, listas para verificar o critrio avaliado nas propostas ou verses padronizadas de todas as partes dos documentos de licitao necessrios. As organizaes que realizam muitas aquisies podem ter muitos documentos padronizados. Organizaes de compradores e fornecedores que trabalharem com transaes que envolvem propriedade intelectual garantem que os termos de confidencialidade sero aprovados e aceitos antes da divulgao de alguma informao que tenha direitos autorais especficos do projeto (PMBOK, 2004).

2.9.3 Solicitar respostas de fornecedores O processo de solicitao de respostas aos fornecedores consiste em obter informaes, propostas e preos com os fornecedores. Os possveis fornecedores, normalmente so os que devem gastar a maior parte do esforo real nesse processo (PMBOK, 2004). Entre as ferramentas e tcnicas disponveis esta inclusa as reunies com licitantes que so reunies com os fornecedores em potncia antes da preparao de uma licitao ou proposta, com o objetivo de garantir que os fornecedores possuem o conhecimento necessrio para o fornecimento. Todos os fornecedores em potencial devem receber o mesmo tratamento durante essa interao inicial en-

39

tre comprador e fornecedor para que seja possvel analise das melhores respostas (PMBOK, 2004). Uma organizao pode encontrar mais fornecedores em potencial atravs da insero de anncios em publicaes de circulao geral, como jornais ou revistas profissionais. A organizao pode at mesmo j ter desenvolvido uma lista de fornecedores ou a equipe do projeto tambm poder desenvolver suas prprias fontes (PMBOK, 2004).

2.9.4 Seleo de fornecedores Analise dos melhores fornecedores com base em suas respostas e fechamento de contrato com cada fornecedor. O processo de seleo de fornecedores vai trabalhar com as propostas aplicando critrios de avaliao, com o objetivo de selecionar um ou mais fornecedores qualificados para a realizao do trabalho, muitos fatores podem ser avaliados como preo e custo, pois nem sempre o menor preo apresenta o menor custo se o fornecedor no tiver a capacidade de fornecer os servios no momento certo, as propostas muitas vezes so separadas em sees tcnicas e comerciais e so avaliadas separadamente (PMBOK, 2004). Algumas ferramentas e tcnicas incluem um sistema de ponderao para ser usado como modo de selecionar um fornecedor solicitando a assinatura do contrato padro, e o estabelecimento de uma seqncia de negociao classificatria para todas as propostas atravs da mdia ponderada atribuda a cada proposta. Nos itens de aquisies com maior prioridade h a possibilidade de repetir o processo de solicitao de respostas de fornecedores e tambm o processo de avaliao de resposta (PMBOK, 2004). Ao final desse processo teremos os fornecedores selecionados que foram considerados como aptos com base no resultado da proposta ou da avaliao de licitao e que cuja verso preliminar do contrato foi negociada. Um contrato assinado com cada fornecedor selecionado, podendo ser um documento simples ou complexo de pedido de compra, o contrato independe da complexidade do documento, ele essencial pois um acordo que gera obrigaes para as partes obri-

40

gando o fornecedor a fornecer o que foi prometido e obriga o comprador a pagar ao fornecedor (PMBOK, 2004). Em geral um contrato inclui sees que declaram o trabalho realizado, o prazo para a realizao, funes e responsabilidades, estabelecimento de preos e condies de pagamento, garantia, suporte a produtos, limitao de responsabilidade, penalidades, incentivos, tratamento de solicitaes de mudana e um mecanismo de resoluo de disputas e resciso, podendo ter diversas outras sees conforme o caso (PMBOK, 2004).

2.9.5 Administrao de contrato A administrao de contrato um processo que consiste na administrao do contrato com cada fornecedor de forma a avaliar se o contrato esta sendo cumprido, o que deve ser alterado, tendo como principal objetivo estabelecer aes corretivas necessrias para o bom relacionamento entre fornecedor e comprador (PMBOK, 2004). O comprador e o fornecedor administram o contrato com objetivos semelhantes. Ambas as partes garantem que iro atender s suas obrigaes contratuais e que seus prprios direitos legais esto protegidos. O processo de administrao de contrato ira garantir que o desempenho do fornecedor atenda ao que foi acordado. Em projetos maiores onde se tem vrios fornecedores de produtos, servios e resultados, um aspecto importante da administrao de contrato o gerenciamento de interfaces entre os diversos fornecedores (PMBOK, 2004).

Devido s consideraes jurdicas, muitas organizaes tratam a administrao de contrato como uma funo administrativa separada da organizao do projeto (PMBOK, 2004).

2.9.6 Encerramento do contrato O processo de encerramento de contrato consiste em finalizar cada contrato aplicvel a cada projeto ou fase do projeto com os fornecedores. O processo de encerramento envolve a confirmao de que todo o trabalho e as entregas foram aceitveis e atualiza os registros para refletir e arquivar as informaes dos resultados finais para uso posterior. O encerramento do contrato aborda cada contrato

41

aplicvel ao projeto ou a uma de suas fases. Em projetos com vrias fases, o prazo contratual pode aplicar-se somente uma determinada fase do contrato (PMBOK, 2004). Segundo o guia PMBOK, A resciso de um contrato um caso especial de encerramento do contrato e pode resultar de um acordo mtuo entre as partes ou de descumprimento das obrigaes de uma das partes. Os direitos e responsabilidades das partes no caso de uma resciso esto includos em uma clusula de trmino de vigncia do contrato. (PMBOK, 2004).

42

INTRODUO AO SCRUM

Mtodos geis podem ser definidos como aqueles que seguem os ideais do chamado Manifesto gil. Esse manifesto foi formalizado em 2001 por alguns dos criadores de algumas das metodologias geis (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas) (AGILE MANIFESTO, 2001). O manifesto gil possui os seguintes valores: indivduos e interaes, software que funciona, colaborao do cliente e resposta a mudanas. Ao invs de processos e ferramentas, documentao abrangente, negociao de contrato e seguir um plano (AGILE MANIFESTO, 2001). Segundo Cohn (COHN, 2005), uma das principais diferenas entre mtodos geis em relao aos mtodos tradicionais a produo de documentao simplificada para um projeto. O SCRUM uma prtica gil de desenvolvimento que permite manter o foco da entrega da maior prioridade do projeto no menor tempo possvel, permitindo assim a rpida e contnua avaliao do software em produo (normalmente entre duas a quatro semanas). O SCRUM utiliza um projeto prtico, simples e com poucas regras sendo muito fcil de aprender (SCHWABER, 2004). So as necessidades de negcio que determinam as prioridades no desenvolvimento de um software. As equipes se auto-organizam para determinar a melhor forma de entregar as funcionalidades mais prioritrias do projeto (BROD, 2004) O lder de uma equipe o SCRUM Master, ele o responsvel por liderar, orientar e treinar os membros da equipe. Um Sprint um conjunto de atividades de desenvolvimento realizadas durante um perodo pr-definido, usualmente entre duas e quatro semanas. Geralmente, entre duas a quatro semanas todos podem visualizar o software em produo decidindo se o mesmo deve ser finalizado, ou se seu desenvolvimento deve continuar por mais um Sprint (BROD, 2004).

43

Quando um projeto est atrasado, o que a maioria das empresas fazem adicionar mais colaboradores o que servir apenas para atras-lo ainda mais, pois devemos levar em considerao o tempo perdido na gesto e comunicao quando h um nmero muito grande de pessoas trabalhando no projeto. Quando calculamos o tempo de desenvolvimento de alguma coisa, necessrio dobr-lo, pois o programador no necessita apenas do tempo para programar, ele precisa pensar tambm (BROD, 2004). O SCRUM utilizado por algumas empresas famosas e reconhecidas, como: Microsoft, Yahoo, Google, Electronic Arts, Philips, Siemens, entre outras usado para desenvolvimento de software comercial, desenvolvimento interno, sistemas embarcados, vdeo games, web sites, telefones celulares, aplicaes para rede, sistemas para controle de satlites, entre outras modalidades (BROD, 2004). As equipes se auto-organizam para desenvolver uma srie de Sprints mensais, os requerimentos so listados atravs do documento Product Backlog. O Product Backlog uma lista de todo o trabalho desejado no projeto, cada item dessa lista tem seu peso de acordo com as vontades dos clientes ou usurios, o dono do produto prioriza essa lista e o time por sua vez ir prioriz-la novamente antes do incio de cada Sprint. Os projetos SCRUM progridem em uma srie de Sprints com durao entre duas a quatro semanas, pois com um perodo constante o ritmo fica melhor, e o projeto codificado e testado durante o desenvolvimento da Sprint. O SCRUM se diferencia de um projeto normal no qual o processo analisar requerimentos, documentar o projeto, escrever o cdigo e testar o funcionamento. Ao invs de completar uma etapa de cada vez, no SCRUM essas etapas so desenvolvidas em conjunto (BROD, 2004).

3.1

CICLO DE VIDA

Segundo Schwaber (2004), o SCRUM possui um ciclo de vida composto por quatro fases: planejamento, preparao, desenvolvimento e entrega. A

44

seguir apresenta-se uma descrio das atividades a serem realizadas em cada fase do SCRUM (SCHWABER, 2004): Planejamento: Desenvolvimento claro e objetivo de uma lista de atividades do produto; Definio da data de release e funcionalidades de um ou mais Sprints; Mapeamento e estimativa das atividades a serem includas na lista de atividades do produto; Definio do time do projeto; Avaliao e controle de riscos; Avaliao das ferramentas de desenvolvimento e infra-estrutura do projeto; Estimativa de custos. Preparao: Reviso e possveis ajustes a lista de atividades do produto; Identificao das mudanas necessrias para implementar as atividades do produto; Realizar a anlise de domnio; Refinar a arquitetura do sistema; Identificao de possveis problemas ou impedimentos na implementao dos requisitos; Reunio de reviso do design, onde so apresentados cada proposta de implementao de cada item do backlog. Desenvolvimento (Sprint): A fase de desenvolvimento composta pelos seguintes macros processos: Reunio de planejamento do Sprint, a ser realizada sempre no primeiro dia de cada Sprint. Essa reunio deve definir as atividades a serem includas na iterao corrente. Reunies dirias (daily meeting) com os membros da equipe para revisar o andamento do projeto; Reviso e ajustes nos requisitos do projeto;

45

Sprints iterativos at que o produto seja considerado pronto para a entrega. Cada Sprint seguido por uma reunio de retrospectiva, onde: Todos os membros do time e os envolvidos participam. avaliado o que pode ser modificado para melhorar a produtividade do prximo Sprint; Uma demonstrao aos stakeholders(pessoa ou entidade que afeta ou afetada pelas atividades de uma empresa) com os resultados do Sprint organizada; Novos itens so adicionados a lista de atividades do produto (product backlog). A figura a seguir apresenta uma viso geral das atividades e processos do SCRUM.

Figura 7 - Viso geral de atividades do SCRUM

3.2

OS PAPIS DO SCRUM

Segundo Schwaber (2004) h 3 papis no SCRUM: O Product Owner, o SCRUM Master e o Time.

46

3.2.1 O papel do Product Owner

Dentro de um projeto, gil ou no, o Product Owner o responsvel pelo ROI (Return of Investiment) de um projeto. Para isso, ele deve conhecer o projeto com uma viso de negcio para definir e priorizar todas as funcionalidades do produto. No SCRUM, existem algumas tcnicas que guiam e auxiliam o Product Owner a garantir o ROI e o andamento do processo. Seguem suas principais responsabilidades: Viso e metas; Escrever, Priorizar e Refinar requisitos; Fazer planos de entrega; Comunicao com o cliente; Estar sempre disponvel (SCHWABER, 2004).

3.2.2 O papel do SCRUM Master

Um SCRUM Master assume responsabilidades diferentes das de um gerente de projetos tradicional, esta diferena em terminologia simboliza uma drstica mudana a ser feita para que os gerentes de projetos tradicionais possam gerenciar efetivamente projetos SCRUM (SCHWABER, 2004). O SCRUM Master responsvel pelo sucesso do projeto, e ele ajuda a aumentar a probabilidade de sucesso, ajudando o Product Owner selecionar os mais valiosos Product Backlogs, e orientando o time no desenvolvimento de funcionalidades. O SCRUM Master no ganha prmios ou medalhas, porque o SCRUM Master apenas um facilitador (SCHWABER, 2004).

3.2.3 O papel do Time O time o responsvel pelo desenvolvimento do produto de acordo com as prioridades definidas pelo Dono do Produto. No h uma definio de papis formal como programador, testador, arquiteto ou analista, o que no impede que haja estas funes. Todos trabalham juntos para completar as funcionalidades que todos conjuntamente se comprometeram para o Sprint.

47

A equipe deve ser pequena, de 5 a 9 pessoas, porm pode ser maior. Quando se possui equipes maiores uma prtica comum a diviso da equipe em SCRUM de SCRUMs (SCHWABER, 2004).

3.3

ARTEFATOS DO SCRUM Esse captulo trata dos principais artefatos utilizados pelo SCRUM

que so o Product Backlog, o Sprint Backlog e o Burndown Chart. O Product Backlog uma lista de funcionalidades definidas pelo Product Owner. O Sprint Backlog uma lista dos itens contidos no Product Backlog que foram priorizados para serem atendidos no Sprint. E o Burndown Chart consiste de um grfico para acompanhamento dirio do Sprint quanto velocidade do time pelo consumo dirio de horas. Esses artefatos so melhores descritos a seguir. 3.3.1 Product Backlog

Nada mais do de uma lista de funcionalidades desejadas para o produto a qual definida pelo Product Owner. No h a necessidade de essa lista estar completa desde o incio do projeto, podendo ser complementada com novas funcionalidades durante o andamento do projeto, medida que o conhecimento do produto vai aumentando. Na maioria das vezes, contm no incio do projeto os itens necessrios para comear o primeiro Sprint. uma lista dinmica, e a mesma pode sofrer alteraes durante todo o andamento do projeto, como o cancelamento de itens, a mudana de prioridade, ou da prpria descrio da funcionalidade (MOUNTAIN, 2009). Na prtica do SCRUM, no h uma teoria que ensina como esta lista deve ser formada, podendo ser usadas vrias tcnicas de captura de requisitos. Uma das tcnicas utilizadas o tratamento de cada item da lista como se fosse uma histria (MOUNTAIN, 2009) O Product Owner deve priorizar os itens desta lista, e a equipe deve analisar e estimar cada item para definirem o trabalho, ou funcionalidades que sero contempladas no Sprint.

48

3.3.2 Sprint Backlog

uma lista de tarefas que o time ir trabalhar durante o Sprint. Os itens do Product Backlog que foram priorizados pelo Product Owner, e analisados pela equipe, que aps estimativa inicial e a percepo do trabalho necessrio se comprometeu a entregar dentro do Sprint, so depois distribudos em tarefas formando o Backlog do Sprint. Essas tarefas devem ser atendidas dentro do Sprint, mas se por algum motivo no sejam, as tarefas que no foram realizadas faro parte do prximo Sprint Backlog. Cada membro da equipe tem a liberdade de escolher qual tarefa ir trabalhar e qualquer membro pode adicionar, alterar ou excluir tarefas. A equipe deve estimar o nmero de horas para a concluso de cada tarefa. E responsabilidade da equipe manter atualizada diariamente a lista de tarefas, com as tarefas j concludas, e a estimativa de tempo necessrio para a concluso das tarefas ainda em andamento. Tarefas j concludas devem ter o nmero de horas para a concluso estimadas como zero (TAVARES, 2008). 3.3.3 Burndown Chart A partir da lista de tarefas do Sprint atualizadas diariamente pelo time com as tarefas j finalizadas e as tarefas ainda pendentes desenvolvido o principal artefato para acompanhamento de um projeto SCRUM: um grfico chamado de Burndown. baseado no nmero de horas restantes para a concluso de cada tarefa. A soma de horas das tarefas determina a quantidade de horas necessrias para finalizar o Sprint, e conforme tarefas vo sendo concludas ao longo dos dias do Sprint, o grfico vai descendo at atingir o nmero de horas zero. No eixo Y encontrase o nmero de horas total estimado para o Sprint e no eixo X os dias do Sprint, de acordo com o seu tamanho (TAVARES, 2008). A figura a seguir apresenta um exemplo do grfico de burndown:

49

Figura 8 - Exemplo de Burndown Chart Fonte: http://www.chrisspagnuolo.com/content/binary/Sprint%20Burndown.jpg

Atravs da nalise do grfico pode-se visualizar a velocidade da equipe no Sprint e verificar se no ritmo de consumo de horas atual a equipe ir conseguir terminar todas as tarefas dentro do Sprint. O grfico pode oscilar tanto para cima quanto para baixo. Oscilaes para cima podem indicar alguma tarefa que foi mal estimada, cujo nmero de horas est consumindo mais que o planejado inicialmente ou tarefas novas que entraram ao longo do Sprint. Oscilaes para baixo com queda muito brusca, geralmente indica uma ou mais tarefas que foram mal estimadas e que consumiram um nmero menor de horas do que foi planejado (TAVARES, 2008).

3.4

PLANEJANDO UM PROJETO SCRUM O SCRUM Master e o Time se juntam para definir as capacidades

de equipe, o product backlog, condies de negcio, produto atual e tecnologia que ser utilizada para fazer um planejamento. O primeiro passo identificar o objetivo. Este planejamento deve ser feito com analise e verificao dos itens do product backlog e priorizao dos objetivos do Sprint. Aps desenvolvido um plano para decidir como chegar a esse objetivo, criando as tarefas do Sprint backlog a partir dos

50

itens do product backlog e realizando o clculo de quantas horas sero necessrias para realizao de cada Sprint, geralmente as tarefas so estimadas em 1 a 16 horas (TAVARES, 2008). A tabela a seguir representa um exemplo de Sprint backlog com tarefas a serem realizadas para o desenvolvimento de um cadastro de clientes com categorias.
Tabela 1 - Exemplo de Sprint Backlog

Modelagem Criao do Banco Codificar interface Fazer testes de desempenho

8 horas 5 horas 10 horas 8 horas

3.5

GERENCIANDO UM PROJETO SCRUM Todo o dia deve ser feita uma reunio de no mximo 15 minutos pa-

ra discusso do andamento do projeto, todos devem ficar em p. Todos na empresa so convidados, porm podem falar nessa reunio apenas o Dono do Produto, o SCRUM Master e os membros da equipe. Nessa reunio so feitas trs perguntas importantes: a) O que voc fez ontem? b) O que voc vai fazer hoje? c) H algum obstculo? Os membros da equipe devem encarar essas respostas como um compromisso perante aos outros membros de seu grupo, no como apenas um questionrio bobo que o gerente est fazendo (TAVARES, 2008). Ao trmino do Sprint, a equipe apresenta os resultados obtidos, demonstrando novas funcionalidades ou arquitetura. A retrospectiva do Sprint ocorre periodicamente, onde a equipe observa o que funciona e o que no funciona, o que gostaria de iniciar, continuar e parar de fazer, ela dura aproximadamente 3 horas e realizada aps a concluso de cada reunio (TAVARES, 2008). Sprint, e toda a equipe deve participar dessa

51

Os trabalhos nunca so atribudos a um usurio, cada um deve escolher o que vai fazer e fazer a atualizao da estimativa do trabalho diariamente. Qualquer membro da equipe tem o poder de alterar, criar e modificar tarefas. Se uma tarefa no for clara, a mesma deve ser definida com uma estimativa de tempo maior e subdividida em vrios itens. A tabela a seguir mostra um exemplo de um Sprint Backlog dividido durante a semana:
Tabela 2 - Sprint Backlog Semanal

Tarefa Codificar interface do usurio Codificar regra de negcio Realizar testes Escrever help online Escrever a classe foo Adicionar log de erros

Seg 8 16 8 10 8

Ter 4 12 16

Qua 8 10 9

Qui

Sex

4 10 16

8 8

8 4

Fonte: ( MOUNTAIN Goat Software)

O SCRUM utilizado em projetos envolvendo mais de 500 pessoas, para evitar a disperso e proporcionar um melhor entendimento e uma comunicao, as equipes so divididas em vrias equipes menores, fazendo uma escala atravs de equipes.

52

PMBOK X SCRUM

Neste captulo far-se- uma comparao entre o PMBOK e o SCRUM e posteriormente o desenvolvimento de um framework que combine os dois paradigmas. No PMBOK tem-se o papel do patrocinador do projeto, o qual descreve o que ele precisa e nesse caso deve ser feita uma boa entrevista, pois muitos patrocinadores no sabem o que querem mesmo quando pensam que sabem e cargo dos gerenciadores do projeto entender tudo o que patrocinador do projeto necessita e assim gerenciar sua equipe, enquanto no SCRUM tem-se o dono do produto, que descreve o projeto atravs do documento de viso e participa ativamente de todas as reunies dirias (TAVARES, 2008). No PMBOK h o papel do gerente de projetos, e ele que, logicamente, gerencia todo o projeto, define todo o trabalho e prioriza-o sendo responsvel por qualquer falha, no entanto no SCRUM o dono do produto escreve story points priorizando eles. Tem-se o papel do SCRUM Master a diferena entre ele e o gerente do PMBOK; que o papel de gerncia do projeto no totalmente focado na figura do SCRUM Master sendo responsabilidade tambm do time fazer parte da gerncia, o SCRUM Master um facilitador. No SCRUM o projeto dividido em Sprints enquanto no PMBOK dividido em vrias fases, seguindo a sequncia uma aps a outra. (TAVARES, 2008). No PMBOK, o envolvimento do cliente menor, j o fato de o SCRUM trabalhar com Sprints e interao direta com o cliente em toda reunio de Sprint o torna mais flexvel que o PMBOK, no SCRUM a reunio diria uma obrigao o que tambm ajuda que tudo saia exatamente como foi programado (TAVARES, 2008). O planejamento do projeto no PMBOK feito no comeo do projeto e o planejamento no SCRUM feito na iniciao do Sprint somente para aquele Sprint. No PMBOK, o projeto desenvolvido e fechado quando todas as entregas so realizadas, enquanto no SCRUM o projeto desenvolvido em interaes

53

permitindo que os clientes parem o projeto quando todas as principais entregas forem satisfeitas. 4.1 CICLO DE VIDA

No PMBOK, a equipe de gerenciamento seleciona as fases, os processos, as ferramentas e tcnicas adequadas a determinado projeto. E geralmente define que trabalho deve ser realizado, quando as entregas devem ser geradas, quem est envolvido e como controlar e aprovar cada fase (PMBOK, 2004). No SCRUM, o projeto tem um ciclo de vida composto por quatro fases: planejamento, preparao, desenvolvimento e entrega (ADM, 2003).

4.2

INTEGRAO E ESCOPO

No PMBOK, o gerenciamento de integrao bem detalhado e o gerente de projetos tem total controle aos recursos organizacionais, a definio de escopo que consiste em um documento contendo os requisitos do projeto e da entrega, os requisitos do produto, os limites, os mtodos de aceitao e controle de alto nvel garantindo que o projeto possa ser completado com sucesso, fazendo apenas o trabalho necessrio. Controlando o que deve e o que no deve estar incluso no projeto. Para o gerenciamento de escopo no PMBOK devemos planejar, definir, verificar, controlar o escopo e criao da estrutura analtica do projeto (PMBOK, 2004). No SCRUM, o Scrum Master apenas um facilitador. H o documento de viso, que descreve porque o projeto est sendo implementado e o que deseja ao seu final, o product backlog e o Sprint backlog que representam o plano de um projeto e so atualizados constantemente durante o desenvolvimento (ADM, 2003).

4.3

DETERMINAR CUSTO No PMBOK o gerenciamento de custos de um projeto visa garantir

que um projeto termine dentro do oramento aprovado para isso a uma estimativa e controle de custos dos recursos necessrios para terminar atividades, controlando

54

fatores que podem gerar alteraes no oramento que geram todo o oramento do projeto. No SCRUM estimativas de custos so realizados na fase de planejamento, o SCRUM Master e o time fazem a gerncia de custo de forma indireta e no to bem planejada como no PMBOK.

4.4

CRONOGRAMA

No PMBOK, a gerncia de tempo visa assegurar que o projeto termine dentro do prazo estipulado, para cumprir tal funo necessrio uma definio das atividades, a identificao de interdependncia das atividades, estimao de recursos e duraes de cada atividade, desenvolvimento e controle do cronograma de todo o projeto (PMBOK, 2004). No SCRUM, estimativa de esforo combinada com velocidade igual ao oramento e cronograma de um projeto, no SCRUM o cronograma desenvolvido de forma iterativa atravs do sprint e gerenciado atravs do grfico de burndown.

4.5

DEFINIR RISCOS DO PROJETO

No PMBOK, o gerenciamento de riscos garante a identificao, avaliao, quantificao, planejamento de respostas, monitoramento e controle dos eventos e condies no planejadas durante o ciclo de vida do projeto (ADM, 2003). No SCRUM, os riscos so tratados na reunio diria e na reunio de planejamento do Sprint.

4.6

PLANEJAR RECURSOS HUMANOS

No PMBOK, o gerenciamento dos recursos humanos organiza e gerencia a equipe do projeto, os processos envolvidos neste gerenciamento so responsveis por identificar e documentar as funes, responsabilidades e relaes hie-

55

rrquicas entre os envolvidos, obter recursos humanos necessrios, melhorar as competncias e interao dos membros da equipe atravs de premiaes e acompanhar o desempenho dos membros da equipe (PMBOK, 2004). No SCRUM, a equipe criada com conhecimento e habilidades necessrias para atender o product backlog (ADM, 2003). No h papis definidos, a idia que todos tem a liberdade de fazer um pouco de tudo.

4.7

QUALIDADE

No PMBOK, o processo de gerenciamento de qualidade do grupo de processos de Monitoramento e Controle tem a funo de monitorar a qualidade dos resultados do projeto e garantir que esses estejam em conformidade com os requisitos esperados pelo cliente e de acordo com os padres relevantes de qualidade. No SCRUM, atravs do Product Burndown e Sprint Burndown, revises so feitas na Sprint Review e na reunio diria e acompanhadas durante o desenvolvimento. Problemas identificados devem ser resolvidos pelo SCRUM Master e pelo Product Owner. Durante a Sprint Review, o Product Owner pode aceitar as entregas feitas pela equipe ou pode negar, caso as entregas realizadas no sejam as esperadas. O Product Owner pode ainda solicitar que sejam feitas alteraes, as quais sero realizadas de acordo com a prioridade dada pelo prprio Product Owner. Quando executadas, as alteraes passaro novamente pela aceitao do Product Owner em uma Sprint Review (SCHWABER, 2004). No SCRUM, ao final de cada Sprint, a equipe tem duas cerimnias a serem realizadas: A Sprint Review, onde so realizadas as entregas para o Product Owner e a Sprint Retrospective, que tem como objetivo principal a melhoria do processo de cada Sprint; onde a equipe avalia a sua forma de trabalhar e verifica que prticas deixaro de fazer, o qu dever ser mantido e prticas a equipe dever passar a realizar (SCHWABER, 2004).

4.8

COMUNICAES

56

O Gerente de projetos gasta cerca de 75% a 90% do seu tempo com comunicaes atravs de reunies, direcionamentos e superviso. No PMBOK o gerente de comunicaes utiliza processos necessrios para assegurar a gerao, captura, distribuio, armazenamento e apresentao das informaes do projeto, de forma adequada (PMBOK, 2004) No SCRUM a comunicao ocorre nas reunies dirias, na reviso de Sprint e durante todo o desenvolvimento; porem no cita documentos e tcnicas que podem ser importantes para essa comunicao. 4.9 AQUISIES O PMBOK descreve tcnicas de aquisio de mercadorias, produtos e servios externos enfatizando a importncia do planejamento e do fechamento do contrato que obriga que ambas as partes cumpram o combinado. No SCRUM no h essa preocupao detalhada. 4.10 FINALIZAO DO PROJETO No PMBOK o projeto desenvolvido e fechado quando todas as entregas so realizadas. No SCRUM, um projeto esta concludo no momento em que todas as tarefas do product backlog foram concludas; e pelo fato de ser iterativa, os clientes podem interromper o projeto assim que decidirem que suas necessidades esto satisfeitas.

4.11 O PODER DO PMBOK NO GERENCIAMENTO DE UM PROJETO SCRUM As boas prticas de gerenciamento de projetos definidas pelo guia PMBOK aliado ao desenvolvimento SCRUM criam um mtodo de gerenciamento preventivo que no onera o projeto em termos de documentao, s o torna mais eficaz e preventivo. A figura a seguir sugere um novo ciclo de vida para o SCRUM, atravs da comparao entre os dois paradigmas, agregando prticas importantes descritas no guia PMBOK que no framework gil SCRUM esto incompletas ou no so referenciadas.

57

Figura 9 - Novo ciclo de vida do SCRUM.

58

CONCLUSO

O conjunto de boas prticas do PMBOK no gerenciamento de projetos com SCRUM possibilitaria a vantagem de uma melhor documentao dos processos desenvolvidos que devero ser utilizados pelo SCRUM Master, para conduzir a sua equipe a um desenvolvimento mais eficaz e preventivo. O SCRUM uma prtica gil e pelo manifesto gil possui os seguintes valores: indivduos e interaes, software que funciona, colaborao do cliente e resposta mudanas. Ao invs de processos e ferramentas, documentao abrangente, negociao de contrato e seguir um plano. Depois desse estudo, ratificou-se o fundamento de que perfeitamente vivel a aplicao de ambos os paradigmas em conjunto, somente necessrio saber aplicar os processos para o projeto. O SCRUM pode oferecer maior agilidade ao PMBOK que por sua vez oferece uma melhor preveno ao projeto SCRUM. Adequando-se os dois modelos, obtm um gerenciamento eficaz de projetos acrescentando em reunies do SCRUM alguns documentos criados com os processos do PMBOK. Foi realizado um estudo dos principais artefatos tanto do PMBOK quanto do SCRUM, buscando compreender a forma de trabalho propostos por ambos os paradigmas, e identificar formas de adapt-las para o uso em conjunto. Embora muitos defensores do SCRUM possam discordar, o SCRUM no substitui a gerncia de projetos, atravs do estudo realizado pode-se entender que o SCRUM, por ser uma prtica gil, trata de forma superficial a algumas prticas importantes que deveriam ser seguidas para garantir o sucesso de um projeto. Se o SCRUM no for bem gerenciado (de forma efetiva) o processo de implementao do mesmo dentro de uma empresa pode levar ao fracasso. Existem pensamentos de que o SCRUM gerencia riscos em sua fase de planejamento e atravs das reunies, mas no h uma documentao especifica e padronizada que defina uma maneira de fazer essa gerncia, por esse motivo podemos seguir o PMBOK para realizar esse processo desde o incio do projeto para o

59

desenvolvimento de uma anlise mais global dos riscos que podem acontecer, documentando-os e controlando-os do inicio ao fim. Por outro lado, tem-se o PMBOK como conjunto de conhecimentos em gerenciamento de projetos j consolidados que pode ser utilizado para atender as necessidades de gerenciamento de um projeto SCRUM tornando-o mais eficiente. Como o escopo algo primordial para a qualidade do produto final faz-se necessrio no SCRUM uma especificao um pouco mais aprofundada que pode ser por meio do gerenciamento de escopo descrito no PMBOK utilizando-se de uma WBS. A rea de conhecimento de Integrao do PMBOK favorece o SCRUM por um controle melhor que ao mesmo tempo agrega a qualidade que no onera um projeto em termos de documentao, s incorpora documentao suficiente. Sugiro tambm um documento contendo as funes, responsabilidades e telefone dos membros da equipe e fornecedores para facilitar a gerncia de recursos humanos em um projeto com SCRUM, facilitando tambm a gerncia de comunicaes. O SCRUM no atende ao quesito de aquisies, no h sequer indcios de como controlar esse procedimento importante em seu conjunto de conhecimento, se faz necessrio para um projeto organizado a utilizao de processos como os documentados no Guia PMBOK, para descrio de tcnicas para aquisio de mercadorias, produtos e servios com fechamento posterior de um contrato que obriga ambas as partes a cumprirem com o combinado com pena de punio ou ressarcimento outra parte, caso no seja realizado o que estava disposto no acordo. Portanto caso um projeto SCRUM necessite adquirir algum software faz-se necessrio desenvolver uma gerncia de aquisies que pode ser baseado no que prega o PMBOK. A sugesto de uma boa gerncia de projetos, definida neste trabalho, agregando os dois paradigmas foi realizada apenas com o embasamento terico, como pesquisa futura, podemos citar o estudo da aceitao do modelo em empresas que j trabalham com PMBOK ou SCRUM.

60

REFERNCIAS BIBLIOGRFICAS

ADM - Advanced Development Methods , SCRUM Methodology Incremental, Iterative Software Development from Agile Processes, Revision 0.9, 2003. AGILE MANIFESTO. Manifesto for Agile Software Development. Agile Alliance, 2001. Disponvel em: <http://www.agilemanifesto.org/>. Acessado em: 10 de outubro de 2009. BROD, cesar. Introduction of SCRUM Agile Process Development . Disponvel em: <http://www.mountaingoatsoftware.com/SCRUM>. Acessado em: 15 de agosto de 2009. COHN, Mike. Agile Estimating and Planning. Prentice Hall PTR, 2005. 368p. DELEMOS, R. PMBOK - project management body of knowledge. Disponvel em: <http://www.widebiz.com.br/gente/delemos/PMBOK.html>. Acesso em 05 Outubro 2009. HARRIS, K et PHELAN, P. Project management: a new look for a new economy. 1 jan 2001. Mounthly Research Review. Gartner Group. LARMAN C., Agile & Iterative Development, A Managers Guide, Addison-Wesley, 2004. MOUNTAIN Goat Software. Uma introduo ao SCRUM, http://www.mountaingoatsoftware.com/system/hidden_asset/file/52/PortugueseSCR UM.pdf Acessado em: 16 de maio de 2009. s 14h30min. MOUNTAIN Goat Software. Introduction of SCRUM Agile Process Development . Disponvel em: <http://www.mountaingoatsoftware.com/SCRUM>. Acessado em: 15 de agosto de 2009. PMBOK - PROJECT MANAGEMENT INSTITUTE, PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos: Guia PMBOK. Terceira Edio. Local Pennsylvania: Four Campus Boulevard, 2004. 388p.

61

SCRUM | Heptagon, http://www.heptagon.com.br/SCRUM Acessado em: 14 de maro de 2009. s 15:12min. SCHWABER, Ken Agile Project Management with SCRUM, Microsoft Press, 2004. SCRUM metodologia gil para gesto e planejamento de projetos, http://improveit.com.br/SCRUM Acessado em: 16 de maro de 2009. s 17:30hs. SCRUM e PMBOK, http://blogdoabu.blogspot.com/ Acessado em: 16 de outubro de 2009. s 18h30min. TAVARES, Aleckssandro. Gerncia de Projeto com PMBOK e SCRUM. Um Estudo de Caso. Trabalho de concluso de curso, Faculdade Cenecista Nossa Senhora dos Anjos, 2008.