Sie sind auf Seite 1von 94

KNIO DIAS LOYOLA NICKSON DUTRA PINHEIRO

ESTUDO DA VIABILIDADE DE UTILIZAO DO PMBOK E O SCRUM COMO MODELO DE GESTO DE PROJETOS NO SETOR DE TI DE INSTITUIES DE TEFILO OTONI

FACULDADES UNIFICADAS DOCTUM TEFILO OTONI 2010

KNIO DIAS LOYOLA NICKSON DUTRA PINHEIRO

ESTUDO DA VIABILIDADE DE UTILIZAO DO PMBOK E O SCRUM COMO MODELO DE GESTO DE PROJETOS NO SETOR DE TI DE INSTITUIES DE TEFILO OTONI

Trabalho de Concluso de Curso apresentado Comisso Examinadora das Faculdades Unificadas Doctum - Campus Tefilo Otoni como requisito para obteno de ttulo do Bacharel em Sistemas de Informaes, sob orientao do Prof. Fabiano Ferreira Santos.

FACULDADES UNIFICADAS DOCTUM TEFILO OTONI 2010

FOLHA DE APROVAO

Aprovada em 18 de Novembro de 2010

____________________________________ Prof. Fabiano Souza Santos (Orientador)

____________________________________ Prof. Yvssa Carneiro Desmots

____________________________________ Prof. Salim Ziad Pereira Aouar

Dedicamos

Deus

por

ter

nos

acompanhado nesta trajetria, dando - nos fora e inspirao para concluir este

trabalho.

AGRADECIMENTOS

Agradecemos primeiramente a Deus por ter nos dado fora, e nos guiado para conseguirmos chegar ao fim de mais uma importante etapa de nossas vidas. Aos nossos familiares, pela base slida que sempre nos deu incentivo para encarar a vida de frente e nunca desistir dos nossos sonhos. Ao nosso orientador, Prof. Fabiano Souza Santos pela dedicao e disponibilidade em sempre estar sanando nossas dvidas e dificuldades atravs de uma orientao inteligente e esclarecedora. Ao professor Prof. Salim Ziad Pereira Aouar pela disponibilidade de nos ajudar sempre que necessitamos. Por fim, agradecemos aos demais professores e amigos da faculdade que fizeram parte dessa jornada, e que nos influenciaram de forma determinante para a concluso deste trabalho.

No se deve julgar o mrito de um homem pelas suas grandes qualidades, mas pelo uso que sabe fazer delas. (La Bruyre)

SUMRIO

1 INTRODUO ....................................................................................................... 15 2 REFERNCIAL TERICO ..................................................................................... 19 2.1 GERNCIA DE PROJETOS ............................................................................. 19 2.1.1 O que um projeto? ................................................................................ 19 2.1.2 O que o Gerenciamento de Projetos? ............................................. 21 2.1.3 Ciclo de Vida do Projeto ...................................................................... 21 2.1.4 Partes Interessadas em um Projeto ..................................................... 22 2.1.5 Perfil de um Gerente de Projetos ......................................................... 24 2.1.6 Benefcios do Gerenciamento de Projetos .......................................... 25 2.2 PMBOK - Project Management Body of Knowledge ....................................... 28 2.2.1 O que o PMBOK? ............................................................................... 28 2.2.2 Grupos de Processos do PMBOK ......................................................... 29 2.2.3 As nove reas de Conhecimento do PMBOK ........................................ 31 2.2.4 Gerncia de Integrao do Projeto .......................................................... 32 2.2.5 Gerncia de Escopo do Projeto ............................................................... 33 2.2.6 Gerncia de Tempo do Projeto ................................................................ 35 2.2.7 Gerncia de Custo do Projeto .................................................................. 37 2.2.8 Gerncia de Qualidade do Projeto ........................................................... 38 2.2.9 Gerncia de Recursos Humanos do Projeto ............................................ 39 2.2.10 Gerncia de Comunicaes do Projeto .................................................. 40 2.2.11 Gerncia de Riscos do Projeto .............................................................. 42 2.2.12 Gerncia de Aquisies do Projeto ........................................................ 44 2.3 Desenvolvimento gil ........................................................................................ 45 2.4 Scrum ................................................................................................................ 47 2.4.1 Ciclo de Vida do Scrum ....................................................................... 48 2.4.2 Papis .................................................................................................. 50 2.4.3 Artefatos .............................................................................................. 52 2.4.4 Cerimnias........................................................................................... 54 3 ESTUDO COMPARATIVO: PMBOK x Scrum ..................................................... 56 3.1 PMBOK X Scrum: Ciclo de Vida ............................................................... 57 3.2 PMBOK X Scrum: Gerenciamento de Integrao ..................................... 58 3.3 PMBOK X Scrum: Gerenciamento de Escopo .......................................... 59 3.4 PMBOK X Scrum: Gerenciamento de Tempo .......................................... 59

3.5 PMBOK X Scrum: Gerenciamento de Custos ........................................... 60 3.6 PMBOK X Scrum: Gerenciamento de Qualidade ...................................... 60 3.7 PMBOK X Scrum: Gerenciamento de Recursos Humanos ...................... 61 3.8 PMBOK X Scrum: Gerenciamento de Comunicaes ............................... 62 3.9 PMBOK X Scrum: Gerenciamento de Riscos ............................................ 62 3.10 PMBOK X Scrum: Gerenciamento de Aquisies ................................... 63 3.11 PMBOK X Scrum: Concluso do Projeto................................................. 63 4 ESTUDO DE CASO: Viabilidade da utilizao do PMBOK e o Scrum ............... 64 4.1 Mtodos adotados para o estudo de caso ................................................... 64 4.2 Descrio das instituies analisadas.......................................................... 65 4.2.1 Instituio A ................................................................................................... 65 4.2.2 Instituio B ................................................................................................... 65 4.3 Proposta de utilizao de um framework hbrido ......................................... 66 4.4 Diagnstico das anlises realizadas ............................................................ 71 4.4.1 Instituio A ................................................................................................... 71 4.4.2 Instituio B ................................................................................................... 72 5 CONSIDERAES FINAIS ................................................................................... 75 REFERNCIAS BIBLIOGRFICAS .......................................................................... 78 ANEXOS ................................................................................................................... 80

RESUMO A presente pesquisa objetiva analisar a viabilidade de utilizao das prticas tradicionais em gerenciamento de projetos do guia PMBOK em conjunto com a metodologia gil Scrum, no setor de Tecnologia da Informao de instituies de Tefilo Otoni. Este trabalho demonstrou o uso dos benefcios proporcionados por um mtodo inovador, baseado na juno de prticas tradicionais e geis, com o intuito de apresentar uma nova forma de garantir qualidade e agilidade nos projetos desenvolvidos pelo setor de Tecnologia da Informao. Para tal objetivo ser alcanado, foi realizada uma anlise comparativa entre ambos os paradigmas estudados identificando seus pontos de compatibilidades e diferenas, e posteriormente a criao de um framework hbrido oriundo das prticas dos dois mtodos.

Palavras-chave: Scrum.PMBOK. Gerenciamento de Projetos. Metodologia gil.

ABSTRACT

This research aims to examine the feasibility of use of traditional practices in project management PMBOK in conjunction with the Scrum agile methodology, the Information Technology sector institutions of Tefilo Otoni. This study demonstrated the use of the benefits provided by an innovative method based on the junction of traditional practices and agile, with the intention of presenting a new way to ensure quality and agility in projects developed by the Information Technology sector. For this goal to be achieved, we performed a comparative analysis between both paradigms studied by identifying the points of compatibilities and differences, and subsequently the creation of a hybrid framework of practices derived from the two methods.

Keywords: Scrum.PMBOK . Project Management. Agile methodologies.

LISTAS DE FIGURAS

FIGURA 1 - Relao entre as Partes Interessadas e o Projeto................................ 24 FIGURA 2 - Os Grupos de Processos do Gerenciamento de Projetos .................... 30 FIGURA 3 - Viso Geral das reas de Conhecimento do PMBOK (2004) ............ 31 FIGURA 4 - Mapeamento do Gerenciamento de Integrao ................................... 32 FIGURA 5 - Mapeamento do Gerenciamento do Escopo ........................................ 34 FIGURA 6 - Exemplo de um EAP............................................................................. 35 FIGURA 7 - Mapeamento do Gerenciamento de Tempo ......................................... 36 FIGURA 8 - Mapeamento do Gerenciamento de Custos ......................................... 37 FIGURA 9 - Mapeamento do Gerenciamento de Qualidade .................................... 38 FIGURA 10 - Tipos de profissionais requeridos ao longo do projeto ........................ 39 FIGURA 11 - Mapeamento do Gerenciamento de Qualidade .................................. 40 FIGURA 12 - Mapeamento do Gerenciamento das Comunicaes ......................... 41 FIGURA 13 - Mapeamento do Gerenciamento de Riscos ........................................ 43 FIGURA 14 - Mapeamento do Gerenciamento das Aquisies ............................... 44 FIGURA 15 - Ciclo de vida do Scrum ....................................................................... 49 FIGURA 16 - Exemplo de um Product Backlog ........................................................ 52 FIGURA 17 - Cerimnias do Scrum ......................................................................... 54 FIGURA 18 - Comparao entre o ciclo de vida do PMBOK e do Scrum.............. 58 FIGURA 19 - Novo ciclo de vida: PMBOK e Scrum ............................................... 66 FIGURA 20 - Exemplo do Novo Product Backlog ................................................... 67 FIGURA 21 - Exemplo de uma EAP Especfica ....................................................... 68 FIGURA 22 - Product Backlog Priorizado ................................................................ 69

LISTA DE GRFICOS

GRFICO 1 - Evoluo dos Percentuais de sucesso, atraso e falhas ...................... 26 GRFICO 2 - Evoluo dos credenciados PMP no Mundo ...................................... 27 GRFICO 3 - Exemplo de um Burndown Chart ........................................................ 53

LISTA DE TABELAS

TABELA 1 - Definio das Partes Interessadas em um Projeto ................................ 23 TABELA 2 - Comparativo entre a abordagem Tradicional X gil .............................. 56

LISTA DE ABREVIATURAS E SIGLAS

PMBOK - Project Management Body of Knowledge TI - Tecnologia da Informao ONU - Organizao das Naes Unidas PMI - Project Management Institute PMO - Project Management Office PMP - Project Management Professional ANSI - American National Standard EAP - Estrutura Analtica de Projetos NFe - Nota Fiscal Eletrnica

15

1. INTRODUO Diante da evoluo dos meios tecnolgicos e o mercado cada vez mais globalizado e competitivo, surge necessidade das organizaes estarem se adequando a essa nova realidade, buscando obter o aprimoramento de suas habilidades e tcnicas, a fim de se submeter a uma constante atualizao, proporcionando assim a garantia de um diferencial competitivo. Contudo observa-se um crescente aumento na implantao de projetos nas organizaes, tendo em vista que os mesmos esto cada vez mais modernos requerendo uma alta diversidade de habilidades, grande complexidade tcnica, alm de ambientes cada vez mais exigentes em termos de recursos. Pesquisas realizadas pela Standish Group revelam que a maioria dos projetos tendem a falhar, seja porque no cumprem o cronograma, as funcionalidades no atendem s necessidades dos usurios ou porque no cumprem o oramento especificado. Apenas 26% dos projetos so bem sucedidos, o restante ou so abortados ou no cumprem os requisitos estabelecidos. Tendo como base esta realidade e visando melhorias nesses tipos de projetos, metodologias de gerenciamento e desenvolvimento surgiram no mercado com intuito de guiar todo o ciclo dos projetos, atuando com dois tipos de abordagens diferentes, as tradicionais e as geis. Dentre as abordagens tradicionais, o PMBOK (Project Management Body of Knowledge), desenvolvido pelo PMI (Project Management Institute) destaca-se atravs do fornecimento de um somatrio de conhecimentos de gerenciamento para diversos tipos de projetos. Em contrapartida, a abordagem gil vem se destacando e ganhando adeptos em todo o mundo. O Scrum constitui uma metodologia gil para gerncia de projetos inicialmente de software, porm pode ser aplicado a qualquer contexto onde pessoas precisem trabalhar juntas para obter um objetivo comum.

16

Mediante aos fatos supracitados, a presente pesquisa foi desenvolvida no 8 perodo do curso de Sistemas de Informaes, como requisito para obteno do ttulo de bacharel em Sistemas de Informaes, e abrange algumas reas do curso como a Engenharia de Software e a Gerncia de Projetos. A pesquisa em questo contempla minimizar os contratempos enfrentados pelas empresas de Tefilo Otoni, principalmente no setor de Tecnologia da Informao (TI), que devido acirrada concorrncia, se cada vez mais exigido uma maior produtividade e qualidade, e que freqentemente defronta com um dos seus maiores problemas que a falta de uma metodologia ou procedimento capaz de orientar de forma eficaz seus projetos. Este trabalho visa propor a utilizao de um mtodo inovador, baseado na juno de prticas tradicionais e geis para gerncia de projetos com o intuito de proporcionar benefcios para as empresas que o adotarem, como o controle efetivo dos prazos, custos e o constante monitoramento dos riscos e qualidade do projeto. Portanto, tendo como base este cenrio o problema motivador desta pesquisa foi: vivel utilizar o PMBOK e o Scrum em conjunto, como modelo de gesto de projetos no setor de TI de Instituies de Tefilo Otoni? As hipteses criadas para responder a essa pergunta problema foram: H1: vivel utilizar o PMBOK e o Scrum, pois proporcionar mais qualidade aos projetos desenvolvidos. H2: vivel, pois obrigar a documentao para melhorar a comunicao e conseqentemente o conhecimento da equipe sobre o projeto. H3: No vivel, pois a utilizao de testes em cada ciclo de desenvolvimento poder ocasionar atrasos na entrega do projeto Final. O objetivo geral desta pesquisa foi verificar a viabilidade de utilizao do PMBOK e o Scrum em conjunto como modelo de gesto de projetos no setor de Tecnologia da Informao de Instituies de Tefilo Otoni, onde permitir o uso dos benefcios proporcionados pelas prticas das duas abordagens em questo para auxiliar nos processos do setor de TI.

17

Os objetivos especficos pretendidos com este trabalho foram: Estudar a metodologia gil de gerncia de projetos Scrum. Estudar o guia de prticas em gerenciamento de projetos PMBOK. Realizar uma abordagem comparativa entre as reas de conhecimento do PMBOK com a metodologia gil de gerncia de projetos Scrum. Conhecer a realidade do setor de TI de Instituies de Tefilo Otoni. Criar um framework hbrido utilizando prticas das duas abordagens estudadas. Esta pesquisa foi de grande importncia, pois alm de verificar a viabilidade da utilizao das prticas em gerenciamento de projetos de um mtodo tradicional em conjunto com uma metodologia gil, tambm contribuir como fonte para tomada de decises no que se diz respeito ao desenvolvimento e implantao de futuros projetos, possibilitando um maior entendimento relacionado ao tema abordado, oferecendo uma gama de conhecimentos de como adaptar e usar as prticas em gerenciamento de projetos da melhor forma possvel, com o auxilio de um framework hbrido oriundo das duas abordagens estudadas. Este trabalho tambm proporcionou um estudo comparativo entre o modelo tradicional PMBOK e a metodologia gil Scrum, onde com base nos estudos realizados, contribuir na escolha entre qual a metodologia se enquadra mais adequadamente na sua organizao ou no projeto que ser desenvolvido, ou at na utilizao das caractersticas combinadas de ambas as abordagens que melhor adaptam-se ao seu projeto. Esta pesquisa classificada quanto aos fins como uma pesquisa exploratria por objetivar uma maior familiarizao com o problema e na construo de hipteses que possa resolv-los, e tambm constitui uma pesquisa aplicada, pois consiste em investigar, comprovar ou rejeitar hipteses construdas pelos modelos tericos.

18

Pode-se definir esta pesquisa quanto aos meios como uma pesquisa bibliogrfica, pois desenvolvida com base em materiais j elaborados oriundos principalmente de livros, artigos e revistas, e tambm como uma pesquisa de campo, caracterizada como um estudo de caso, pois complementada por um estudo de caso da utilizao de uma tcnica ou abordagem j estudada e na anlise aprofundada de instituies em particular. Este trabalho est dividido em quatro captulos, o primeiro captulo refere-se introduo da pesquisa, expondo o que o tema aborda a problemtica do trabalho, as hipteses criadas, e o objetivo geral e objetivos especficos pretendidos com o mesmo. No segundo captulo denominado referencial terico, aborda conceitos iniciais sobre projetos, gerncia de projetos e metodologias geis, dando enfoque principalmente a apresentao do PMBOK e do Scrum, dentre outras definies tcnicas que sero utilizadas no decorrer do trabalho. No terceiro captulo foi realizado um estudo comparativo entre as nove reas de conhecimento do PMBOK com as prticas adotadas pela metodologia gil Scrum, mostrando seus pontos de compatibilidade e diferenas. No quarto captulo foi apresentado um estudo de caso no setor de TI de duas instituies de Tefilo Otoni, com o intuito de verificar a viabilidade de utilizao das prticas em gerenciamento de projetos oferecidas pelo PMBOK em conjunto com a metodologia gil Scrum, e propor um framework hbrido atravs das prticas das duas abordagens. Por fim, no quinto captulo foram realizadas as consideraes finais sobre o trabalho e apresentao de propostas para trabalhos futuros.

19

2. REFERENCIAL TERICO

2.1 GERNCIA DE PROJETOS Este captulo tem como objetivo apresentar alguns conceitos iniciais sobre projetos, gerenciamento de projetos e metodologias geis dando enfoque principalmente as prticas de gerncia de projetos do PMBOK e do Scrum. 2.1.1 O QUE UM PROJETO? Segundo o PMBOK (2004), um projeto constitui um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. De acordo com BRAGA (2003), um projeto um empreendimento com caractersticas prprias, tendo incio e fim, conduzido por pessoas com a finalidade atingir metas estabelecidas dentro de parmetros de prazo, custo e qualidade. Para a Norma ISO 10006, um projeto um processo nico, consistindo de um grupo de atividades coordenadas e controladas com data de incio e trmino, voltados para alcance de um objetivo conforme requisitos especficos, incluindo limitaes de tempo, custo e recursos [STANLEIGH, 2005]. Segundo a Organizao das Naes Unidas (ONU), um projeto um empreendimento planejado, que conjulga-se em um conjunto de atividades intercaladas e coordenadas a fim de alcanar objetivos especficos dentro dos limites de um oramento e de um perodo de tempo estabelecido [I.S.A, 2001].

20

Um projeto consiste em um empreendimento com objetivo identificvel, que consome recursos e opera sobre condies de custo, prazo e qualidade. Para cada projeto deve-se definir uma misso, objetivos, uma estrutura de processos ou atividades e uma forma de funcionamento [TALLES, 2009]. Para MARTINS (2003), um projeto pode ser conceituado como plano, intento, propsito que se forma para realizar algo. Diferentemente das operaes baseadas em processos contnuos e repetitivos, projetos so temporrios e nicos, devido s suas caractersticas ou condies exclusivas. VARGAS (2009) define um projeto como sendo um empreendimento no repetitivo, caracterizado por uma seqncia clara e lgica de eventos, com incio, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parmetros predefinidos de tempo, custo, recursos envolvidos e qualidade. Para CLELAND (2009). um projeto constitui uma combinao de recursos organizacionais, colocados de forma conjunta para criar ou desenvolver algo que no existia previamente, de modo a proporcionar um aperfeioamento da capacidade de desempenho no planejamento e na realizao de estratgias organizacionais. A criao de um projeto requer uma estrutura organizacional adequada para desenvolvimento de novas idias, requer tempo e pacincia para que se possa trabalhar em conjunto, alm de algumas variveis importantes como a distino do papel do lder no grupo, que o profissional responsvel por descobrir talentos individuais de cada participante, ajudando no desenvolvimento da criatividade e na participao de todos. A capacidade tcnica outro fator de extrema importncia para se obter resultados positivos, proporcionando o desenvolvimento de boas idias e estratgias. E por fim a criatividade e o comprometimento, que so essenciais para que se tenham caminhos criativos para realizao das atividades e ao mesmo tempo comprometimento com as atividades que se est criando.

21

2.1.2 O QUE O GERENCIAMENTO DE PROJETOS? O Guia PMBOK (2004) define o conceito de gerenciamento de projetos da seguinte forma:
O Gerenciamento de Projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos realizado atravs da aplicao e da integrao dos seguintes processos de gerenciamento de projetos: iniciao, planejamento, execuo, monitoramento e controle, e encerramento. [PMBOK, 2004, p.8].

De acordo com BRAGA (2003), gerenciar projetos envolve tomar decises sobre: Escopo, Tempo, Custo e Qualidade. Diferentes necessidades e expectativas dos clientes e partes interessadas. Requisitos identificados (necessidades), e no identificados (expectativas). Segundo MARTINS (2003), a gesto de projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas na administrao eficiente das atividades do projeto. O conhecimento obtido com estudos e prticas dinamiza os processos de iniciao, planejamento, execuo, controle e encerramento que compem o projeto. VARGAS (2009) descreve o gerenciamento de projetos como sendo um conjunto de ferramentas gerenciais que proporcionam as empresas desenvolverem um conjunto de habilidades, incluindo conhecimento e capacidades individuais, voltados ao controle de eventos no repetitivos, nicos e complexos, dentro de um cenrio de qualidade, tempo e custo predeterminado.

2.1.3 O CICLO DE VIDA DO PROJETO. Os gerentes de projetos podem dividir os projetos em vrias fases com o intuito de obter melhor controle gerencial. Estas fases so conhecidas como ciclo de vida dos projetos. Segundo a PMI (2004). o ciclo de vida de um projeto foca basicamente em definir o comeo e o trmino do projeto, estabelecendo qual a atividade deve ser realizada em cada fase, e quem deve estar envolvido. O ciclo de vida tambm o

22

responsvel por definir o conjunto de processos que devem ser seguidos para que o projeto seja gerenciado com qualidade. Para VARGAS (2007), o ciclo de vida propicia uma gama de benefcios para qualquer tipo de projeto. Dentre eles, podem ser citados os seguintes: A anlise correta do ciclo de vida determina o que foi, ou no feito pelo projeto. O ciclo de vida avalia como o projeto est progredindo at o momento; O ciclo de vida permite que seja indicado qual o ponto exato em que o projeto se encontra no momento. As descries do ciclo de vida de um projeto podem ser resumidas ou muito detalhadas. As descries com alto nvel de detalhamento envolvem a criao de formulrios, grficos, e listas de verificao para oferecer uma melhor estrutura e controle gerencial. O ciclo de vida de um projeto tradicional dividido basicamente em quatro fases: a fase conceitual, a fase de planejamento, a fase de execuo e a fase de concluso ou encerramento. 2.1.4 PARTES INTERESSADAS EM UM PROJETO De acordo com o Guia PMBOK (2004), as partes interessadas em um projeto so as pessoas e organizaes ativamente envolvidas no projeto, cujos interesses podem ser afetados com o resultado da execuo ou do trmino do projeto. Baseado no guia PMBOK (2004), a Tabela 1 a seguir mostra a definio das principais partes interessadas em um projeto.

23

Tabela 1: Definio das Partes Interessadas em um Projeto PARTE INTERESSADA


GERENTE DE PROJETOS CLIENTE/USURIO ORGANIZAO EXECUTORA MEMBROS DA EQUIPE DO PROJETO EQUIPE DE GERENCIAMENTO DE PROJETOS PATROCINADOR

DESCRIO Consiste na pessoa responsvel pelo gerenciamento do projeto. Consiste na pessoa ou organizao que utilizar o produto desenvolvido pelo projeto. Consiste na empresa cujos funcionrios esto mais diretamente envolvidos na execuo do trabalho do projeto. Consiste no grupo que est executando o trabalho do projeto. Consiste nos membros da equipe do projeto que esto diretamente envolvidos nas atividades de gerenciamento dos projetos. Consiste na pessoa ou no grupo que fornece os recursos financeiros para o projeto. Consiste nas pessoas ou grupos que no esto diretamente relacionados aquisio ou ao uso do produto do projeto, mas que, devido posio de uma pessoa na organizao do cliente ou na organizao executora, podem influenciar, positiva ou negativamente, no andamento do projeto. Consiste no departamento ou grupo que define e mantm os padres de processo, geralmente relacionados com a gesto dos projetos , dentro da organizao.

INFLUENCIADORES

PMO

Fonte: Desenvolvido pelo autor.

O termo Stakeholders refere-se a todas as partes interessadas no projeto, incluindo prprio gerente de projetos. Dentre as partes interessadas, um dos mais importantes o patrocinador do projeto, que consiste na pessoa que financia ou defende o projeto dentro da organizao. A equipe de gerenciamento precisa identificar as partes interessadas, determinar suas necessidades e expectativas, e gerenciar sua influncia em relao aos requisitos para garantir um projeto bem sucedido. A Figura 1 descreve as principais partes interessadas e sua relao com o projeto.

24

Figura 1: Relao entre as Partes Interessadas e o Projeto

Fonte: PMBOK, 2004.

As partes interessadas em um projeto podem ocasionar influncias positivas e negativas em um projeto. As partes interessadas positivas beneficiam um resultado bem sucedido do projeto, enquanto as partes interessadas negativas criticam o projeto, enxergando resultados negativos a partir do sucesso do projeto [PMBOK, 2004]. 2.1.5 PERFIL DE UM GERENTE DE PROJETOS O gerente de projetos a pessoa responsvel pela realizao dos objetivos do projeto. Um gerente de projetos deve ter a capacidade de trabalhar em equipe, liderana, habilidade para aplicar seus conhecimentos na prtica, facilidade nos relacionamentos interpessoais e boa comunicao. De acordo com MARTINS (2003), a pessoa para alcanar o nvel de maturidade condizente com a funo de um gerente de projetos deve possuir conhecimentos de conceitos bsicos, tcnicas e ferramentas de gerenciamento, bem como a capacidade prtica e aplicvel destes conhecimentos. Para MARTINS (2003), o gerente de projetos se destaca dentro das organizaes devido evoluo e relevncia do gerenciamento dos projetos. A

25

profisso de gerenciamento de projetos bastante promissora mediante a gama de oportunidades que est surgindo atualmente. A escolha de profissionais capacitados fator crucial para sucesso dos projetos. Cada vez mais as organizaes esto designando pessoas sem qualquer formao e capacitao para exercerem a funo de gerente de projetos, que eventualmente possui remunerao inferior a de um profissional qualificado, ocasionando aumento do custo final do projeto, levando em considerao as deficincias na gesto de recursos, alm das entregas serem geralmente efetuadas fora dos prazos estabelecidos [MARTINS, 2003]. 2.1.6 BENEFCIOS DO GERENCIAMENTO DE PROJETOS Segundo MARTINS (2003), a gesto de projetos tem-se destacado nos ltimos tempos devido a sua eficcia, conseguindo alcanar resultados desejados dentro dos prazos, e oramentos definidos. O gerenciamento de projetos pode ser aplicado em empreendimentos de qualquer complexidade, e para qualquer tipo de negcio. Para MARTINS (2003), os benefcios proporcionados pelo gerenciamento de projetos so os seguintes: Controle efetivo de prazos, custos e recursos, permitindo a

identificao prvia de desvios, e imediata tomada de aes corretivas ou pr-ativas, podendo inclusive resultar em possveis redues; Eficcia na integrao e comunicao necessria durante todo o projeto; Monitoramento e controle dos riscos e da qualidade do projeto; Retorno do investimento, com entrega conforme a especificao; Segundo estudos realizados pela Standish Group em 2001, revelam que apenas 16% dos projetos so bem sucedidos, 28% so realizados no prazo e oramento especificados, 23% so cancelados, 94% so reiniciados pelo menos uma vez excedendo o oramento original em 188% e o prazo original em 222%, e apenas 61% mantm o escopo original [SOTILLE, 2004]. O Grfico 1 mostra a evoluo dos percentuais de sucesso, atraso e falhas de 1994 at 2008.

26

Grfico 1: Evoluo dos Percentuais de Sucesso, Atraso e Falhas

Um projeto bem sucedido aquele que realizado conforme o planejado. Se o projeto gastou menos recursos que o previsto, houve uma falha no planejamento que permitiu que os recursos fossem superestimados, e no uma economia de recursos [SOTILLE, 2004]. Diante deste cenrio, as organizaes esto cada vez mais optando por profissionais de gerncia de projetos que possuem algum certificado que comprove o conhecimento na rea, tornando um diferencial e requisito em relao especializao no assunto. A certificao PMP (Project Management Professional) comprova o conhecimento aprofundado sobre o PMBOK, e das regras impostas pela PMI para exercer a profisso de gerente de projetos [PMI, 2004]. O Grfico 2 a seguir mostra a importncia do gerenciamento de projetos vista atravs da evoluo do nmero de profissionais certificados PMP no mundo.

27

Grfico 2: Evoluo dos credenciados PMP no Mundo

Fonte: http://www.ietecnet.com.br/pmp/credenciados.asp

Para TORREO (2005), o sucesso na gesto de projetos pode ser mensurado atravs do alcance dos seguintes objetivos: entregas dentro do prazo estabelecido, dentro do oramento previsto com nvel de desempenho adequado, controle eficaz nas mudanas do escopo, respeito cultura da organizao e aceitao prvia do cliente. De acordo com VARGAS (2007), o gerenciamento de projetos proporciona inmeras vantagens em relao s demais formas de gerenciamento, tendo se mostrado bastante eficaz em conseguir os resultados desejados, dentro dos oramentos e prazos definidos pela organizao. A grande vantagem do gerenciamento de projetos o fato de no ser restrito apenas a projetos grandes, com alto nvel de complexidade, podendo ser aplicado a empreendimentos de qualquer natureza. A gesto profissional de projetos a forma mais indicada a ser aderida pelas organizaes para a realizao de projetos, utilizando recursos eficientes dentro das limitaes de custo, tempo e desempenho. O gerente de projetos a pessoa responsvel por guiar todas as atividades do projeto, devendo estar devidamente qualificado para exercer seu papel e garantir o sucesso do projeto.

28

2.2 PMBOK - Project Management Body of Knowledge


Esta seo objetiva demonstrar uma viso geral sobre a estrutura do PMBOK, abrangendo seus conceitos, objetivos, grupos de processos, e suas nove reas de conhecimento em gerenciamento de projetos.

2.2.1 O QUE O PMBOK? O PMBOK constitui um padro formado a partir de um conjunto de conhecimentos e melhores prticas sobre a gerncia de projetos. O PMBOK reconhecido pela ANSI (American National Standard), e foi desenvolvido pelo PMI (Project Management Institute), que a principal referncia para as organizaes que esto em busca de melhorias em seus processos de gerenciamento [NARDI, 2009]. O guia PMBOK (2004) descreve o seu principal objetivo da seguinte forma:
O principal objetivo do Guia PMBOK identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que amplamente reconhecido como boa prtica. Identificar significa fornecer uma viso geral, e no uma descrio completa. Amplamente reconhecido significa que o conhecimento e as prticas descritas so aplicveis maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relao ao seu valor e sua utilidade. Boa prtica significa que existe acordo geral de que a aplicao correta dessas habilidades, ferramentas e tcnicas podem aumentar as chances de sucesso em uma ampla srie de projetos diferentes. Uma boa prtica no significa que o conhecimento descrito dever ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos responsvel por determinar o que adequado para um projeto especfico. [PMBOK, 2004, p.3].

O PMBOK teve sua primeira publicao no ano de 1987. Logo mais tarde baseado nos comentrios positivos recebidos pelos membros da PMI foi publicada a sua segunda verso. A sua terceira verso teve publicao em 2004 com melhorias em sua estrutura original, adies aos processos, termos e domnios do programa e do portflio. Atualmente est em sua quarta edio, lanada em 2008, tornando-se a norma mundial relacionada ao gerenciamento de projetos, sendo um dos melhores e mais verstil documento disponvel para gerncia de projetos [PMBOK, 2004]. O PMBOK pode ser usado como uma guia, fornecendo aos gerentes alternativas para se obter sucesso nos projetos.

29

De acordo com o prprio Guia PMBOK (2004), ele se divide trs sees: Seo I: A estrutura do gerenciamento de projetos. Fornece uma estrutura bsica para o entendimento sobre gerenciamento de projetos. Seo II: A norma de gerenciamento de projetos de um projeto. Especifica todos os processos de gerenciamento de projetos usados pela equipe do projeto para gerenciar um projeto. Seo III: As reas de conhecimento em gerenciamento de projetos. Organiza os 44 processos de gerenciamento de projetos dos grupos de processos de gerenciamento de projetos. O Guia PMBOK (2004) reconhece 44 processos em cinco grupos de processos bsico e nove reas de conhecimento. Os cinco grupos de processos do PMBOK so: Iniciao, Planejamento, Execuo, Controle e Monitorao, e Fechamento. As nove reas de conhecimento em gerncia de projetos do PMBOK so: Integrao, Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicaes, Risco, Aquisies. Cada uma das reas de conhecimento do PMBOK contm os processos que precisam ser realizados para a gesto dos projetos, sendo que cada processo pode ser relacionado com uma rea de conhecimento e a um grupo de processos. 2.2.2 GRUPOS DE PROCESSOS DO PMBOK A base de conhecimentos em gerenciamento de projetos do guia PMBOK (2004) constituda por 44 processos estruturados, em 5 grupos bsicos e 9 reas de conhecimento. De acordo com o PMBOK (2004), a definio de processo : Um processo um conjunto de aes e atividades inter-relacionadas realizadas para obter um conjunto pr-especificado de produtos, resultados ou servios. [PMBOK, 2004, p. 38].

30

Figura

mostra

resumidamente

os grupos

de

processos

em

gerenciamento de projetos que compem o PMBOK. Figura 2: Os Grupos de Processos do Gerenciamento de Projetos

Fonte: PM Tech Capacitao em Projetos.

O Guia PMBOK (2004) caracteriza os grupos de processos estruturados da seguinte forma: Grupo de Processos de Iniciao: Define e autoriza o projeto e as fases do projeto. Grupo de Processos de Planejamento: Define e refina os objetivos, bem como a seleo da melhor alternativa para alcanar os objetivos do projeto, e o escopo para os quais o projeto foi realizado. Grupo de Processos de Execuo: Coordena pessoas e outros recursos para realizar o plano de gerenciamento de projetos. Grupo de Processos de Monitoramento e Controle: Assegura que os objetivos do projeto esto sendo cumpridos, e monitora

regularmente o progresso do projeto a fim de identificar variaes em

31

relao ao plano de gerenciamento de projetos, para que se possa tomar as devidas aes corretivas. Grupo de Processos de Encerramento: Formaliza a aceitao do projeto, servio ou resultado, e conduz o projeto ou uma fase do projeto a um final ordenado. 2.2.3 AS NOVE REAS DE CONHECIMENTO DO PMBOK O PMBOK (2004), possui em seu contexto nove reas de conhecimento. Cada uma dessas reas responsvel por uma parte do gerenciamento dos projetos, e abrange diversos processos de gerenciamento, sendo ao todo 44 processos. A Figura 3 a seguir mostra resumidamente as nove reas de conhecimento do PMBOK (2004) e seus respectivos grupos de processos. Figura 3: Viso Geral das reas de Conhecimento do PMBOK (2004)

Fonte: PMBOK, 2004.

32

As reas de conhecimento do PMBOK so os principais pontos a serem explorados a fim de garantir sucesso nos projetos desenvolvidos. A seguir ser apresentada cada uma das nove reas de conhecimento que compem o PMBOK, juntamente com seus grupos de processos. 2.2.4 GERENCIAMENTO DE INTEGRAO DO PROJETO O Gerenciamento de Integrao composto por processos e atividades necessrias para identificar, definir, combinar, unificar e coordenar os diversos tipos de atividades do gerenciamento de projetos, atravs dos grupos de processos que o compem [PMBOK, 2004]. O Gerenciamento de Integrao responsvel por fornecer processos necessrios para assegurar que todos os elementos do projeto esto sendo gerenciados de forma correta [PMBOK, 2004]. Para VARGAS (2009), o gerenciamento de integrao objetiva

principalmente garantir que todas as demais reas estejam integradas, estruturando todo o projeto de modo a possibilitar que as necessidades dos envolvidos sejam atendidas pelo projeto. A Figura 4 a seguir proporciona uma viso geral sobre os processos que compem esta rea de conhecimento. Figura 4: Mapeamento do Gerenciamento de Integrao

Fonte: Manual Prtico do Plano Do Projeto.

Termo de Abertura do Projeto: Constitui um documento que autoriza formalmente um projeto. O termo de abertura do projeto concede aos gerentes o privilgio de aplicar os recursos organizacionais nas atividades do

33

projeto. Trata principalmente da documentao das necessidades de negcio, do atendimento atual das necessidades do cliente, do novo produto e da justificativa do projeto [PMBOK, 2004]. Declarao do Escopo Preliminar do Projeto: Responsvel em fornecer uma descrio em alto-nvel do escopo do projeto. Plano de Gerenciamento do Projeto: Responsvel em incluir as aes necessrias em para definir, coordenar e integrar todos os planos auxiliares em um plano de gerenciamento do projeto. Orientar e Gerenciar a Execuo do Projeto: diretamente afetado pela rea de aplicao do projeto, e consiste na execuo de todo o trabalho definido pelo plano de gerenciamento de projetos. Monitorar e Controlar o Trabalho do Projeto: Tem o objetivo de monitorar e controlar todos os processos associados com a iniciao, planejamento, execuo e encerramento, atendendo aos objetivos definidos pelo plano de gerenciamento de projetos. Controle Integrado de Mudanas: realizado desde o incio do projeto at o seu trmino. Consiste na identificao, controle, reviso, gerenciamento, e manuteno das possveis mudanas que venham a ocorrer, rejeitando ou aprovando-as, de forma que as mudanas aprovadas sejam incorporadas a uma linha de base revisada. Encerrar o Projeto: Consiste na finalizao de todas as atividades e grupos de processos de gerenciamento de projetos, e posteriormente o

encerramento formal do projeto por completo.

2.2.5 GERENCIAMENTO DE ESCOPO DO PROJETO O Gerenciamento de Escopo inclui os processos necessrios para garantir que o projeto se complete somente com o trabalho necessrio. Trata principalmente da definio e controle do que est e do que no est incluso no projeto [PMBOK, 2004].

34

Segundo VARGAS (2007), o gerenciamento de escopo tem como principal objetivo definir e controlar os trabalhos a serem realizados pelo projeto, de modo a garantir que o produto ou servio requisitado seja obtido atravs da menor quantidade de trabalho possvel, sem deixar de realizar nenhum requisito estabelecido no objetivo do projeto. A Figura 5 a seguir ilustra os processos que compem o gerenciamento de escopo. Figura 5: Mapeamento do Gerenciamento do Escopo

Fonte: Manual Prtico do Plano Do Projeto.

Planejamento do Escopo: Define a criao de um plano de gerenciamento do escopo do projeto, visando documentar como o escopo do projeto ser definido. Verifica e controla como a estrutura analtica do projeto (EAP) ser criada. Definio do Escopo: Consiste na definio detalhada das entregas do projeto, e o trabalho necessrio para realizar essas entregas. A definio do escopo fornece um entendimento comum do escopo do projeto a todas as partes interessadas no projeto, descrevendo seus principais objetivos, alm de orientar o trabalho da equipe durante a execuo do projeto. Criar EAP: Consiste na subdiviso do trabalho a ser executado pela equipe do projeto, organizando e definindo o escopo total do projeto, e subdividindo todo o projeto em partes menores visando uma maior facilidade no gerenciamento. A Figura 6 a seguir exemplifica a estrutura de um projeto de software atravs de uma EAP de forma detalhada.

35

Figura 6: Exemplo de um EAP

Fonte: PMBOK, 2004.

Verificao do Escopo: Consiste na formalizao atravs de um documento consistindo entregas que foram aceitas e entregas que no foram aceitas, juntamente com os motivos da sua reprovao. Controle do Escopo: Consiste no controle das mudanas no escopo do projeto, com intuito de controlar o impacto que essas mudanas geram no projeto.

2.2.6 GERENCIAMENTO DE TEMPO DO PROJETO De acordo com o PMBOK (2004), o Gerenciamento de Tempo do projeto inclui os processos necessrios para garantir o trmino do projeto dentro dos prazos estabelecidos. Para VARGAS (2007), o gerenciamento de tempo juntamente com o gerenciamento de custos so as reas mais visveis do gerenciamento de projetos, tendo em vista que a maioria das pessoas que se interessam por projetos tem como objetivo inicial controlar prazos, confeccionar cronogramas e estabelecer custos.

36

Os processos que compem essa rea de conhecimento so os seguintes: definio de atividade, seqenciamento de atividades, estimativa de recursos de atividades, desenvolvimento do cronograma e controle do cronograma. A Figura 7 a seguir ilustra o mapeamento do gerenciamento de tempo de um projeto. Figura 7: Mapeamento do Gerenciamento de Tempo

Fonte: Manual Prtico do Plano do Projeto.

Definio da Atividade: Consiste em identificar e documentar as atividades especficas do cronograma, para produzir as entregas do projeto. Seqenciamento de Atividades: Consiste na identificao e documentao das dependncias entre as atividades do cronograma. Estimativa de Recursos da Atividade: Consiste na estimativa do tipo, e quantidade de recursos necessrios para realizar cada atividade do cronograma. Estimativa de Durao da Atividade: Consiste na estimativa do nmero de horas necessrias para se termine as atividades individuais do cronograma, a previso da quantidade de recursos necessrios para a finalizao da atividade e o nmero de perodos de trabalho necessrios. Desenvolvimento do Cronograma: Visa anlise dos recursos necessrios, restries do cronograma, duraes e seqncias de atividades para criar o cronograma do projeto. Esse processo determinara as datas de incio e trmino das atividades, podendo ocasionar a reavaliao das estimativas de

37

durao e recursos, gerando um cronograma para ser aprovado, servindo como linha de base para o projeto. Controle do Cronograma: Consiste no controle das mudanas no cronograma do projeto. 2.2.7 GERENCIAMENTO DE CUSTOS DO PROJETO De acordo com o PMBOK (2004), o gerenciamento de custos do projeto tem o objetivo de assegurar que o projeto seja concludo dentro das limitaes de oramento previstas. As definies oramentrias do projeto devem ser realizadas por quem ir realizar o projeto. O projeto pode entrar em execuo somente aps a aprovao prvia do oramento. Segundo VARGAS (2007), o principal objetivo do gerenciamento de custos de um projeto garantir que o capital disponvel ser suficiente para obter todos os recursos necessrios para se realizar os trabalhos do projeto. A Figura 8 ilustra os processos que compem o gerenciamento de custos. Figura 8: Mapeamento do Gerenciamento de Custos

Fonte: Manual Prtico do Plano do Projeto.

Estimativa de Custos: Consiste em desenvolver uma estimativa de custos necessrios para o trmino de cada atividade do projeto. Oramentao: Consiste em agregar os custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base de custos.

38

Controle de Custos: Consiste em controlar os fatores que criam variaes de custos no projeto, e as mudanas no oramento do projeto. 2.2.8 GERNCIAMENTO DE QUALIDADE DO PROJETO O objetivo mais importante desta rea de conhecimento assegurar que o projeto ser concludo dentro dos nveis de qualidade previstos, garantindo a satisfao das necessidades de todas as partes envolvidas. O principal responsvel pelo gerenciamento da qualidade o gerente de projetos, devendo proporcionar igual prioridade a gesto da qualidade, do custo e do tempo [VARGAS, 2007]. Para o PMBOK (2004), o gerenciamento de qualidade de um projeto preocupa-se exclusivamente com a satisfao do cliente, preveno de erros e a melhoria continua dos processos. Os processos que compem o gerenciamento de qualidade so ilustrados atravs da Figura 9 a seguir. Figura 9: Mapeamento do Gerenciamento de Qualidade

Fonte: Manual Prtico do Plano do Projeto.

Planejamento de Qualidade: Visa identificar os padres de qualidade relevantes para o projeto, e determinao de como faz-los. Realizar a Garantia da Qualidade: Consiste na aplicao das atividades de qualidade planejadas e sistemticas para garantir que o projeto emprega todos os processos necessrios para atender aos requisitos. Realizar o Controle da Qualidade: Consiste no monitoramento de resultados especficos do projeto com o intuito de determinar se eles esto de acordo

39

com os padres relevantes de qualidade, e identificao de maneiras para eliminar as causas de um desempenho insatisfatrio. 2.2.9 GERENCIAMENTO DE RECURSOS HUMANOS DO PROJETO Para VARGAS (2007) o gerenciamento de recursos humanos de um projeto tem como principal objetivo fazer o melhor uso possvel dos indivduos envolvidos no projeto. VARGAS (2007) afirma que as pessoas so a parte mais importante de um projeto, pois so elas que definem as metas, os planos, organizam o trabalho, coordenam e controlam as atividades do projeto, utilizando de suas habilidades tcnicas e sociais. De acordo com o guia PMBOK (2004) todos os membros da equipe devem ter intensa participao no processo de tomada de deciso do projeto, pois o envolvimento dos membros da equipe desde o incio proporciona o fortalecimento do compromisso com o projeto. Tendo em vista que os custos sofrem variao significativamente ao longo do ciclo de vida dos projetos, os recursos humanos so requisitados em vrios nveis de especialidade, dependendo da natureza do trabalho a ser realizado e do nvel de maturidade da equipe do projeto. A Figura 10 a seguir mostra os tipos de profissionais requisitados ao longo de cada fase do projeto. Figura 10: Tipos de profissionais requeridos ao longo do projeto

Fonte: Manual Prtico do Plano do Projeto.

40

O gerenciamento de recursos humanos possui quatro processos principais, dentre eles, o planejamento de recursos humanos, controlar ou mobilizar a equipe do projeto, desenvolver a equipe do projeto e gerenciar a equipe do projeto. A Figura 11 a seguir ilustra o mapeamento do gerenciamento dos recursos humanos do projeto. Figura 11: Mapeamento do Gerenciamento de Recursos Humanos

Fonte: Manual Prtico do Plano do Projeto.

Planejamento de Recursos Humanos: Consiste na identificao e documentao das funes, responsabilidades e relaes hierrquicas do projeto, elm de um plano pessoal de gerenciamento. Contratar ou Mobilizar a Equipe do Projeto: Objetiva obter os recursos humanos necessrios para terminar o projeto. Desenvolver a Equipe do Projeto: Consiste em garantir a melhoria de competncias e a iterao entre os membros da equipe para aprimorar o desempenho do projeto. Gerenciar a Equipe do Projeto: Visa o acompanhamento de desempenho de membros da equipe, fornecimento de feedback ,resoluo de conflitos e coordenao de mudanas 2.2.10 GERENCIAMENTO DAS COMUNICAES DO PROJETO Segundo o PMBOK (2004) esta rea de conhecimento emprega os processos necessrios que garantem a gerao, coleta, distribuio,

armazenamento, recuperao e destinao das informaes sobre o projeto de forma adequada.

41

O gerenciamento das comunicaes necessrio para assegurar que todas as informaes desejadas cheguem s pessoas corretas. O gerente de projetos utiliza a comunicao para garantir de que o time do projeto trabalhe de maneira integrada para resolver os problemas do projeto. Para VARGAS (2007) a comunicao deve ser vista nas organizaes como uma estratgia de crescimento, tendo em vista que o fluxo de informaes est exigindo cada vez mais agilidade e eficincia nas comunicaes, se tornado um dos fatores principais para garantir o sucesso de um projeto. O PMBOK (2004) subdivide o gerenciamento de comunicaes em quatro processos bsicos, dentre eles, o planejamento das comunicaes, a distribuio das informaes, o relatrio de desempenho, e gerenciar as partes interessadas. A Figura 12 a seguir descreve o mapeamento dos principais processos do gerenciamento de comunicaes. Figura 12: Mapeamento do Gerenciamento das Comunicaes

Fonte: Manual Prtico do Plano do Projeto.

Planejamento das Comunicaes: Objetiva determinar as necessidades de informaes e comunicaes das partes interessadas no projeto. Distribuio das Informaes: O processo de distribuio das informaes consiste em colocar as informaes necessrias a disposio das partes interessadas no momento adequado. Relatrio de Desempenho: Tem como principal objetivo coletar e distribuir as informaes sobre o desempenho do projeto, atravs de relatrios de andamento medio de progresso e previso. As informaes relacionadas

42

ao relatrio de desempenho podem incluir os recursos que esto sendo utilizados para garantir os objetivos do projeto, alm de informaes sobre o escopo, cronograma, custo e qualidade do projeto. Gerenciar as Partes Interessadas: Consiste no gerenciamento das informaes para satisfazer os requisitos das partes interessadas no projeto, e resolver problemas com os mesmos. O gerenciamento das partes interessadas aumenta a probabilidade do projeto no desviar o foco, devido a problemas com as partes interessadas. 2.2.11 GERENCIAMENTO DOS RISCOS DO PROJETO Segundo VARGAS (2007), o gerenciamento de riscos do projeto possibilita a oportunidade de compreender melhor a natureza do projeto, envolvendo os membros da equipe com intuito de identificar e responder aos possveis riscos que podem ocorrer geralmente associados ao tempo, custo, e qualidade. De acordo com o PMBOK (2004), o gerenciamento de riscos objetiva principalmente aumentar probabilidade de acontecer eventos positivos, e minimizar a probabilidade de ocorrer eventos negativos no projeto. Os riscos de um projeto constituem um evento incerto, ou seja, um evento que pode ou no ocorrer, e se por ventura vier a acontecer poder ter um efeito positivo ou negativo sobre pelo menos um dos objetivos do projeto, afetando principalmente as especificaes de tempo, custo, escopo ou qualidade do projeto. Os riscos podem ocorrer por vrias causas, uma das causas pode ser, por exemplo, a falta de pessoal designado para realizar alguma tarefa exclusiva do projeto. O PMBOK subdivide o gerenciamento de riscos do projeto em seis principais processos, descritos conforme a Figura 13.

43

Figura 13: Mapeamento do Gerenciamento de Riscos

Fonte: Manual Prtico do Plano do Projeto.

Planejamento do Gerenciamento de Riscos: Consiste na tomada de decises de como abordar, planejar e executar as atividades de

gerenciamento de riscos de um projeto. Identificao de Riscos: Consiste em determinar e documentar as caractersticas dos riscos que por ventura possam afetar o projeto. Anlise Qualitativa dos Riscos: Prioriza e avalia a probabilidade de ocorrncia e dos impactos dos riscos a partir de mtodos que priorizam os riscos identificados para uma anlise qualitativa. Anlise Quantitativa dos Riscos: a anlise numrica dos efeitos identificados nos objetivos gerais do projeto. Aps a priorizao dos riscos na anlise qualitativa, os mesmos so quantificados atravs da atribuio de valores numricos a estes riscos. Planejamento de Respostas a Riscos: Consiste no desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto. Monitoramento e Controle dos Riscos: Tem o objetivo de acompanhar e monitorar os riscos identificados, e a realizao de novas avaliaes em busca de novos riscos que possam afetar os objetivos do projeto.

44

2.2.12 GERENCIAMENTO DE AQUISIES DO PROJETO De acordo com o PMBOK (2004) o gerenciamento de aquisies inclui os processos necessrios para comprar ou adquirir produtos ou servios de fora da equipe do projeto, com a finalidade de realizar os objetivos do trabalho. Para VARGAS (2007) o gerenciamento de aquisies possui como caracterstica assegurar de que todo elemento externo participante do projeto ir garantir o fornecimento do seu produto ou servio para o projeto. O gerenciamento de aquisies possui tcnicas que possibilitam a compra de mercadorias ou a aquisio de algum servio especfico de forma adequada para dar andamento ao projeto. O gerenciamento de aquisies dispe de processos que propiciam o gerenciamento de contratos e o controle de mudanas necessrias para administrar os contratos e pedidos de compra emitidos por algum dos membros do projeto. A Figura 14 fornece uma viso geral dos principais processos que compem o gerenciamento de aquisies. Figura 14: Mapeamento do Gerenciamento das Aquisies

Fonte: Manual Prtico do Plano do Projeto.

Planejar Compras e Aquisies: Consiste na determinao do que comprar ou adquirir, e quando e como fazer isso. O planejamento de compras e aquisies identifica quais as necessidades do projeto podem ser melhor atendidas pela compra ou aquisio de algum produto. Este processo tambm inclui possveis fornecedores, especialmente se o comprador desejar ter influncia ou controle sobre as decises de contratao.

45

Planejar Contrataes: Consiste em documentar os requisitos de produtos e servios, a fim de identificar possveis fornecedores e solicitar respostas aos mesmos. As ferramentas e tcnicas utilizadas neste processo incluem contratos, descries padres de itens de aquisio, termos de

confidencialidade, listas de verificao de critrios de avaliao de propostas, ou verses padronizadas de todas as partes dos documentos de licitao necessrios, alm da obteno de opinies especializadas. Solicitar

Respostas

de

Fornecedores:

Consiste

na

obteno

de

informaes, cotaes, preos, ofertas ou propostas de produtos com os fornecedores. Este processo inclui reunies com licitantes, e reunies com possveis fornecedores, usadas com o propsito de garantir que todos os fornecedores possuem um entendimento claro sobre a aquisio.

2.3 Desenvolvimento gil

O desenvolvimento gil surgiu em meados da dcada de 90, quando um grupo de dezessete especialistas em processos de desenvolvimento de software se reuniu em uma estao de esqui nos Estados Unidos da Amrica, visando discutir formas de estabelecer princpios comuns compartilhados a todos os mtodos, com o objetivo de proporcionar melhorias no desempenho dos projetos [SOARES, 2008]. A partir desta reunio conhecida como Aliana gil foi estabelecido o Manifesto gil, cujos conceitos so: Indivduos e interaes ao invs de processos e ferramentas. Colaborao do cliente ao invs de negociao de contratos. Respostar rpidas a mudanas ao invs de seguir planos. Segundo SOARES (2008), as metodologias geis so apontadas como uma alternativa s abordagens tradicionais. Elas devem ser aplicadas exclusivamente a projetos onde os requisitos atuais so estveis e os requisitos futuros podem ser previstos. Entretanto, em projetos onde ocorrem constantes mudanas nos

46

requisitos, e as equipes so razoavelmente pequenas, as metodologias geis so as mais indicadas. O conceito de agilidade enfatiza responder aos problemas da equipe de forma rpida e efetiva, promovendo a unio entre a equipe e o cliente, fazendo com que o mesmo participe continuamente do processo de criao do projeto [SOARES, 2008]. Portanto, o conceito gil estabeleceu doze princpios para quem deseja trabalhar com metodologias geis, dentre eles so:

1. A prioridade satisfazer ao cliente atravs de entregas de software de valor contnuas e freqentes; 2. Entregar softwares em funcionamento com freqncia de algumas semanas ou meses, sempre na menor escala de tempo; 3. Ter o software funcionando a melhor medida de progresso; 4. Receber bem as mudanas de requisitos, mesmo em uma fase avanada, dando aos clientes vantagens competitivas; 5. As equipes de negcio e de desenvolvimento devem trabalhar juntas diariamente durante todo o projeto; 6. Manter uma equipe motivada fornecendo ambiente, apoio e confiana necessrio para a realizao do trabalho; 7. A maneira mais eficiente da informao circular dentro da equipe atravs de uma conversa face a face; 8. As melhores arquiteturas, requisitos e projetos provm de equipes organizadas; 9. Ateno contnua a excelncia tcnica e um bom projeto aumentam a agilidade; 10. Processos geis promovem o desenvolvimento sustentvel. Todos envolvidos devem ser capazes de manter um ritmo de desenvolvimento constante; 11. Simplicidade essencial; 12. Em intervalos regulares, a equipe deve refletir sobre como se tornarem mais eficazes e ento se ajustar e adaptar seu comportamento. [Reinert, 2008, p.3].

partir

do

conhecimento

dos

conceitos

supracitados,

inmeras

metodologias de gerenciamento e desenvolvimento que j existiam comearam a ganhar espao no mercado. Com o presente trabalho pretende-se priorizar o aprimoramento e compreenso das tcnicas do Scrum, onde foram apresentadas suas caractersticas e definies nas sees seguintes.

47

2.4 Scrum O Scrum uma metodologia gil de desenvolvimento e gerenciamento de projetos, criada por Ken Schwaber e Jeff Sutherland, e que possui como premissa estabelecer um processo de desenvolvimento iterativo e incremental, podendo ser aplicada no gerenciamento de qualquer atividade. O Scrum tem como base o desenvolvimento com foco na equipe e com ciclos de iterao curtos [GONALVES, 2008]. Segundo Maral (2007) o Scrum pode ser descrito da seguinte forma:
O Scrum um mtodo que aceita que o desenvolvimento de software imprevisvel e formaliza a abstrao, sendo aplicvel a ambientes volteis. Ele se destaca dos demais mtodos geis pela maior nfase dada ao gerenciamento do projeto. Rene atividades de monitoramento e feedback, em geral, reunies rpidas e dirias com toda a equipe, visando identificao e correo de quaisquer deficincias e/ou impedimentos no processo de desenvolvimento. [MAAL, 2007, p.3].

O Scrum aplicvel tanto a projetos pequenos como grandes, objetivando conseguir uma melhor avaliao do ambiente em evoluo. indicado ao desenvolvimento e gerenciamento de projetos em ambientes complexos, onde os requisitos esto em constante mudana, tornando-se uma alternativa para aumentar a produtividade das organizaes [GONALVES, 2008]. Segundo GONALVES (2008), o Scrum dispe de um conjunto de regras e prticas de gesto que devem ser adotadas para garantir o sucesso dos projetos, voltadas para o trabalho em equipe e melhoria da comunicao, permitindo que cada participante da equipe faa o seu melhor. De acordo com BOSSI (2007), existe um vocabulrio especfico utilizado na metodologia Scrum: Product Backlog: Lista de todas as funcionalidades a serem desenvolvidas durante o projeto completo. Sprint: Perodo no superior a 30 dias, onde o projeto, ou apenas algumas funcionalidades desenvolvido. Sprint Planning Meeting: Reunio de planejamento.

48

Sprint Review Meeting: Reunio de reviso. Sprint Backlog: Trabalho a ser desenvolvido numa Sprint de modo a criar um produto ou resultado a ser apresentado ao cliente. Dayling Scrum: Reunio diria. Scrum Team: Equipe de desenvolvimento de uma Sprint. Scrum Master: Elemento da equipe responsvel pela gesto do projeto. Apesar de ser gestor, no tem propriamente autoridade sobre os demais membros da equipe. Product Owner: Proprietrio do produto. Para PEREIRA (2005), o Scrum no um processo previsvel, no define o que fazer em todos os casos, utilizado para trabalhos com alto nvel e complexidade, no qual no possvel prever o que ir acontecer, dispondo de um framework que serve como um guia de boas prticas para gerncia de projetos. 2.4.1 Ciclo de Vida do Scrum O ciclo de vida do Scrum baseia-se no princpio da utilizao de equipes pequenas, no mximo sete pessoas, onde os requisitos so pouco estveis e as iteraes so curtas. O desenvolvimento dividido em intervalos de no mximo 30 dias, conhecidos como Sprints. Segundo SOARES (2008) o ciclo de vida do Scrum dividido em quatro fases: Planejamento: Visa estabelecer uma viso do projeto, garantindo recursos para sua execuo. Stagging: Consiste em avaliar as vrias dimenses do projeto criando itens para o Product Backlog. Desenvolvimento: Consiste na criao de vrias Sprints para o

desenvolvimento dos incrementos de funcionalidade do produto.

49

Releasing: Consiste na realizao da entrega final ao cliente. A Figura 15 a seguir ilustra de forma simplificada o ciclo de vida do Scrum. Figura 15: Ciclo de vida do Scrum

Fonte: http://paoloramos.com/blog/wp-content/uploads/2009/03/ciclo-de-vida.png

Antes da realizao de uma Sprint, feita uma reunio de planejamento chamada Sprint Planning Meeting, onde a equipe de desenvolvedores obtm contato com o cliente, que neste contexto chamado de Product Owner, para decidir como ser feito o trabalho e selecionar as tarefas que a equipe ir realizar dentro da Sprint [PEREIRA, 2007]. A prxima fase consiste na execuo da Sprint, onde a equipe controla o andamento do desenvolvimento do projeto, atravs da realizao das reunies dirias chamadas de Daily Meeting, com durao de no mximo 15 minutos. O progresso realizado no projeto pode ser visto atravs de um grfico chamado Sprint Burndown. Ao final da Sprint realizada uma reunio de reviso, denominada Sprint Review, onde o time demonstra a parte funcional desenvolvida na Sprint, visando assegurar que tudo ocorreu de acordo com os requisitos estabelecidos anteriormente no Product Backlog [PEREIRA, 2007]. Posteriormente realiza-se a reunio de retrospectiva, chamada de Sprint Retrospective, que consiste em uma reunio voltada para lies aprendidas, visando melhoria dos processos para a prxima Sprint [PEREIRA, 2007].

50

2.4.2 Papis De acordo com PEREIRA (2007), o Scrum implementa um processo iterativo e incremental, cujas pessoas envolvidas so divididas em trs grupos : o Product Owner, o Scrum Team, e o Scrum Master, cada um com s sua funo em especfico, e todos interagindo entre si. O Product Owner tem o papel de representar os interesses de todos no projeto, no sendo necessrio que tenha um conhecimento aprofundado sobre o Scrum, mas deve conhecer bem o trabalho que ser desenvolvido. Deve sempre estar disponvel para a equipe, principalmente durante as reunies de planejamento (Sprint Planning Meeting), e durante as reunies de

reviso (Sprint Review), com o intuito de priorizar as tarefas que sero realizadas na Sprint. Alm de ser o responsvel em dividir o trabalho em vrias partes menores e manter o Product Backlog em ordem, tambm so responsabilidades do Product Owner segundo PEREIRA (2007): Define os requisitos do produto, decide a data de release e o que deve conter nela. responsvel pelo retorno financeiro do produto. Prioriza os requisitos de acordo com o seu valor de mercado. Pode mudar os requisitos e prioridades a cada Sprint. Aceita ou rejeita o resultado de cada Sprint. Outro papel muito importante do Scrum o Scrum Mster, que consiste na pessoa que trabalha exclusivamente com a equipe. O Scrum mster o responsvel em garantir a boa aplicabilidade das prticas do Scrum no projeto, e a equipe deve enxerg-lo como a pessoa que tem conhecimento amplo sobre o Scrum, cuja funo corrigir qualquer contratempo na utilizao de suas prticas, e tirar dvidas referentes ao Scrum de qualquer pessoa envolvida no projeto [MAGNO, 2008].

51

Segundo MAGNO (2008), as principais responsabilidades do Scrum Mster so: Permitir que o time seja auto gerencivel. Garantir que os caminhos para a comunicao da equipe estejam abertos permanentemente. Garantir e auxiliar equipe a seguir as prticas do Scrum. Remover qualquer impedimento que a equipe encontre. Proteger a equipe de interferncias externas para garantir que sua produtividade no seja afetada. Por fim, o Scrum Team, que consiste na equipe de desenvolvimento composta de no mximo nove membros, responsvel por desenvolver as funcionalidades do projeto. Nele no existe uma diviso atravs de funes como na abordagem tradicional, tais como designer, analista, arquiteto, dentre outros. Todos os membros da equipe trabalham juntos no projeto com a inteno de atender aos requisitos do Product Backlog, sendo responsvel pelo sucesso de cada iterao e consequentemente do projeto como um todo. De acordo com PEREIRA (2007), as responsabilidades do Scrum Team so: Selecionar entre os itens priorizados os que sero executados durante a Sprint. Tem todo o direito de realizar o que quiser dentro da Sprint para cumprir seus objetivos. Auto - organizao do trabalho entre os membros da equipe de forma participativa. Ao final da Sprint, responsvel por realizar a verso de demonstrao do produto finalizado.

52

2.4.3 Artefatos Os artefatos do Scrum consistem nos documentos que auxiliam no entendimento do que deve ser feito no projeto, quando deve ser feito e como est o andamento do trabalho. Os Principais artefatos do Scrum so: o Product Backlog, a Sprint Backlog e o Burndown Chart. O Product Backlog o corao do Scrum. Consiste basicamente em uma lista de itens priorizados que inclui tudo o que precisa ser realizado no projeto, sendo associado ao valor de negcio do cliente. No h necessidade do Product Backlog estar totalmente completo antes do incio do projeto, pois com o tempo pode ser feito a incluso de novos requisitos, bem como a remoo de requisitos j existentes [PEREIRA, 2007]. A priorizao das atividades do Product Backlog deve ser feita pelo Product Owner, que geralmente deve ser a primeira tarefa a se realizar antes de iniciar uma Sprint. A Figura 16 a seguir exemplifica um Product Backlog. Figura 16: Exemplo de um Product Backlog

Fonte: Scrum e XP direto das Trincheiras.

Outro artefato de grande importncia no Scrum a Sprint Backlog, que consiste no conjunto de tarefas a serem executadas pelo time durante uma Sprint. A equipe juntamente com o Product Owner, prioriza os itens do Product Backlog e extrai os de maior relevncia para serem inseridos na Sprint Backlog.

53

A equipe de desenvolvimento tem a funo de estabelecer a quantidade de itens que sero inseridos no Product Backlog. Esse levantamento e seleo dos itens so feitos por meio da reunio de planejamento da Sprint [PEREIRA, 2007]. Segundo PEREIRA (2007), para cada item inserido na Sprint, o time inicia o detalhamento de suas atividades, estimando em horas a durao de cada uma delas, no permitindo que ultrapasse o limite mximo de tempo que de 16 horas para cada tarefa. Aps todas as tarefas estimadas, a equipe de desenvolvimento questiona se realmente consegue assumir o compromisso de realizar as tarefas dentro da Sprint, e finalizar o item priorizado. Uma vez decidido o item, a equipe passa para o prximo item, continuando o processo at que todos os itens da Sprint Becklog sejam concludos [PEREIRA, 2007] Por fim, o Burndown Chart, que consiste em um grfico que representa a quantidade de horas que faltam ser completadas para atingir o objetivo da Sprint. A sua principal funo mostrar o ritmo de trabalho que o time est desempenhando, facilitando a deteco de problemas no andamento da Sprint e a tomada de providncias para a resoluo dos mesmos. O Grfico 3 a seguir exemplifica um Burndown Chart. Grfico 3: Exemplo de um Burndown Chart

Fonte: Entendendo o Scrum para Gerenciar Projetos de forma gil.

54

2.4.4 Cerimnias As cerimnias do Scrum consistem nas reunies feitas durante todo o ciclo de desenvolvimento do projeto, tendo como principal objetivo auxiliar no monitoramento, gerenciamento e desempenho da equipe, possibilitando a deteco de falhas durante o desenvolvimento e execuo do projeto. O Scrum possui quatro tipos de cerimnias: Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review e a Sprint Retrospective, cada uma delas com objetivos bem peculiares e realizadas em momentos especficos do ciclo de vida, conforme demonstrado atravs da Figura 17 a seguir [ALMEIDA, 2009]. Figura 17: Cerimnias do Scrum

Fonte: Uma abordagem automatizada para monitorar o desenvolvimento gil com Scrum.

A reunio de planejamento ou Sprint Planning Meeting, uma reunio realizada durante o incio de cada Sprint, com durao de aproximadamente 8 horas, objetivando estabelecer o que ser feito na prxima iterao. Esta reunio opcionalmente pode ser dividida em partes, a Sprint Planning 1 e a Sprint Planning 2 cada uma com durao de 4 horas. Na Sprint Planning Meeting, devem estar presentes o Product Owner, o Scrum Master e todo o Scrum Team. Durante a Sprint Planning Meeting, de responsabilidade do Product Owner descrever as funcionalidades de maior prioridade para a equipe. No decorrer da Sprint Planning Meeting a equipe faz perguntas de modo que seja capaz de transformar as funcionalidades em tarefas tcnicas aps a reunio. Essas tarefas iro dar origem ao Sprint Backlog [ALMEIDA, 2009].

55

Outra cerimnia de grande importncia a Daily Scrum Meeting, que consiste em uma reunio diria feita no incio ou no fim de cada dia. Esta cerimnia tem como objetivo difundir o conhecimento a todos os membros da equipe, discutindo que foi feito no dia anterior, proporcionando a todos o conhecimento dos impedimentos que ocorreram no dia, e priorizando o trabalho que se inicia no dia em questo [ALMEIDA, 2009]. Segundo PEREIRA (2007), ideal que a Daily Scrum seja realizada sempre no mesmo lugar e na mesma hora do dia, geralmente na parte da manh, ajudando a estabelecer as prioridades do novo dia de trabalho. A Daily Scrum deve ter a participao de todos os membros da equipe, e no deve ser utilizada como uma reunio para resoluo de problemas, pois as questes abordadas devem ser levadas para fora da reunio e tratadas por um grupo menor de pessoas que tem um conhecimento maior sobre o problema discutido [PEREIRA, 2007]. Durante a Daily Scrum cada membro da equipe deve ter respostas para cada um destas trs perguntas: O que voc fez ontem? O que voc far hoje? H algum impedimento no seu caminho? Depois de detectados os impedimentos no Daily Scrum, os mesmos devem ser tratados o mais rpido possvel pelo Scrum Master. Outra cerimnia do Scrum a Sprint Review, que uma reunio feita ao final de cada Sprint, onde o Scrum Team mostra o que foi feito durante a Sprint. Nesta reunio consiste basicamente em apresentar a verso de demonstrao das funcionalidades do projeto j concludas. As pessoas que participam da Sprint Review so tipicamente o Product Owner, o Scrum Team, o Scrum Master. Ao final da Sprint, ocorre uma reunio chamada Sprint Retrospective, cujo objetivo identificar o que funcionou bem, o que pode ser melhorado, e quais as atitudes vo ser tomadas para melhorar.

56

3 ESTUDO COMPARATIVO: PMBOK X Scrum Neste captulo, foi apresentado um estudo comparativo entre e as nove reas de conhecimento tradicionais do PMBOK com a metodologia gil de gerenciamento e desenvolvimento de projetos Scrum, apresentado seus pontos de compatibilidade e diferenas. A Tabela 2 a seguir demonstra resumidamente uma comparao entre a abordagem tradicional e a abordagem gil. Tabela 2: Comparativo entre a abordagem Tradicional X gil ABORDAGEM TRADICIONAL Preditivo: detalhar o que ainda no bem conhecido. Rgido: seguir especificao predefinida, a qualquer custo. Burocrtico: controlar sempre para alcanar o objetivo. Orientado a processos: podem garantir a qualidade. Documentao gera confiana. Sucesso corresponde a entregar o planejado. Gerenciamento no estilo comando e controle,voltada para o trabalho em massa. nfase: papel do gerente, planejamento e disciplina fortes. Desenvolvedor hbil (variedade). Cliente pouco envolvido. Requisitos conhecidos e estveis. Retrabalho/reestruturao caros. Planejamento direciona resultados (incentiva controlar). ABORDAGEM GIL Adaptativo: conhecer o problema, resolver antes questes crticas. Flexvel: adaptar-se a requisitos atuais, que podem mudar. Simplista: fazer algo simples agora e alterar se necessrio. Orientado a pessoas: motivadas e comprometidas. Comunicao gera confiana. Sucesso corresponde a entregar o desejado. Gerenciamento no estilo liderana/ orientao, voltada para trabalhadores do conhecimento. nfase: criatividade/flexibilidade e ateno s pessoas. Desenvolvedor gil (colaborador). Cliente comprometido (com autonomia para decidir). Requisitos emergentes e mutveis. Retrabalho/reestruturao baratos. Resultados direcionam planejamento (incentiva mudar).

57

Conjunto de processos com metodologia definida. Premia a garantia da qualidade. Foco: projetos grandes ou que envolvam restrio de confiabilidade (exigem mais formalismo). Objetivo: controlar em busca de alcanar o objetivo planejado (em termos de tempo,custo e escopo). Responsabilidade recai sobre o processo da organizao (menos suscetvel a falhas) Foco na maturidade, decorrente da definio e uso de processos e modelos de maturidade. Foca em questes ligadas ao gerenciamento, tanto de projeto quanto de processo. Institucionalizao de processos crucial definidos, escritos, treinados, praticados, controlados e cobrados. Abordagem mais profunda para gerncia de projetos.

Conjunto de valores com atitudes e princpios definidos. Premia o valor rpido obtido. Foco: projetos de natureza exploratria e inovadores, com equipes pequenas /mdias (exigem maior adaptao). Objetivo: simplificar processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos. Responsabilidade recai sobre o envolvimento e a experincia dos membros da equipe. Foco na disciplina, seguindo valores, princpios e boas prticas documentados na literatura. Foca em questes ligadas ao trabalho tcnico e valor agregado ao produto (resultado). Utilizao das prticas crucial princpios e boas prticas devem ser levadas ao extremo. Abordagem ainda superficial para gerncia de projetos.

Fonte: Uma comparao entre o PMBOK e a XPM.

Tanto a abordagem gil quanto a abordagem tradicional possuem caractersticas positivas e negativas, a grande diferena entre as duas abordagens est no conjunto de propsitos de cada uma. 3.1 PMBOK X Scrum: Ciclo de Vida No PMBOK, o ciclo de vida do projeto dividido em vrias fases, e o planejamento feito no inicio de cada fase. As fases so executadas uma aps a outra, e a equipe de gerenciamento a responsvel por definir todo o ciclo de vida do projeto, estabelecendo quais so as ferramentas e tcnicas mais adequadas a serem utilizadas para determinado tipo de projeto. Define geralmente qual o trabalho deve ser realizado, quem est envolvido no trabalho e como controlar e aprovar cada fase do projeto [PMBOK, 2004]. No Scrum, o ciclo de vida do projeto composto em quatro fases: fase de planejamento, Stagging, desenvolvimento e Releasing.

58

O projeto dividido em Sprints, onde o planejamento feito no incio de cada Sprint e somente para aquela Sprint especfica [MACIEL, 2008]. A Figura 18 abaixo ilustra uma comparao entre o ciclo de vida do PMBOK e do Scrum. Figura 18: Comparao entre o ciclo de vida do PMBOK e do Scrum

Fonte: http://www.fokasearch.com.br/?p=229

3.2 PMBOK X Scrum: Gerenciamento de Integrao No PMBOK, a integrao refere-se os objetivos, planejamento e coordenao das atividades do projeto. O plano do projeto realizado de forma bastante formal e detalhada, e somente no incio do projeto. Na fase de integrao, o gerente o responsvel pelo projeto e tem o controle total sobre ele [PMBOK, 2004].

59

No Scrum, o plano do projeto representado pelo Product Backlog e a Sprint Backlog, onde so constantemente atualizados durante o decorrer do projeto. No Scrum o gerente de projetos representado pelo Scrum Master, e atua somente como um facilitador do projeto, minimizando que possveis impedimentos venham a ocorrer. 3.3 PMBOK X Scrum: Gerenciamento de Escopo O Gerenciamento de Escopo no PMBOK no compatvel com o Scrum. No PMBOK, o gerenciamento de escopo tem a finalidade de garantir que o projeto termine apenas com o esforo necessrio, definindo o escopo detalhado no incio do projeto. O gerenciamento de escopo deve ser realizado utilizando ferramentas centralizadas e processos de tomada de deciso, onde toda a informao levantada deve ser documentada na especificao de requisitos, que servir de base para a gesto de mudanas durante o andamento do projeto [PMBOK, 2004]. No Scrum, o escopo definido com um alto nvel de detalhamento, mas com a inteno de permitir um melhor entendimento do trabalho, onde aps sua definio os requisitos so estabelecidos e priorizados com a participao de toda a equipe do projeto, inclusive o cliente, que define e discute as funcionalidades durante cada ciclo de desenvolvimento. 3.4 PMBOK X Scrum: Gerenciamento de Tempo O Gerenciamento de tempo semelhante entre os dois mtodos. No PMBOK, os processos de definio, estimativa de esforo e durao das atividades so definidos atravs da elaborao de um cronograma detalhado contendo todas as atividades necessrias para a execuo do projeto [PMBOK, 2004]. No Scrum, o gerenciamento de tempo tambm realizado atravs da elaborao de um cronograma, mas com a peculiaridade de ser orientado exclusivamente ao produto que ser produzido em cada iterao, havendo uma participao direta do cliente que o responsvel em definir a prioridade funcional de cara iterao [VIANA, 2008].

60

3.5 PMBOK X Scrum: Gerenciamento de Custos No PMBOK, o gerenciamento de custos do projeto tem o objetivo de garantir que o projeto termine dentro do oramento estabelecido. As alteraes ocorridas durante o ciclo de desenvolvimento do projeto so crticas e afetam todo o projeto, para isso existe uma estimativa de custos dos recursos necessrios para terminar as atividades do projeto. O foco est em controlar, monitorar e documentar as mudanas para que no afete o custo planejado inicialmente no projeto [PMBOK, 2004]. No Scrum, as alteraes podem ser realizadas mesmo em fases avanadas do projeto, e so incorporadas na iterao mais apropriada, havendo total consentimento do cliente. No Scrum existe sempre a preocupao em atender o cliente, mas o valor final do projeto pode sofrer variaes muito grandes se no forem repassadas ao consentimento dos patrocinadores do projeto para

ressarcimento do custo adicional. 3.6 PMBOK X Scrum: Gerenciamentos de Qualidade Neste contexto, as duas abordagens so similares, tanto o Scrum como o PMBOK reconhecem a importncia em planejar a qualidade do projeto, a fim de garantir a satisfao do cliente, o diferencial entre os dois mtodos est na forma de garantir e controlar a qualidade. No PMBOK, o gerenciamento de qualidade voltado para criao de planos de testes a partir das especificaes de requisitos e nos processos de verificao e validao. Os processos de gerenciamento de qualidade destinam-se principalmente no monitoramento e controle da qualidade dos resultados do projeto, e assegurar que estes resultados estejam de acordo com o que o cliente deseja, e dentro dos padres de qualidade desejados. No Scrum, o gerenciamento de qualidade realizado durante todo o ciclo de vida do projeto, devido ao fato do projeto estar sendo elaborado de forma incremental a cada iterao desenvolvida, onde so realizados testes desde o incio do projeto.

61

Ao detectar um problema no projeto o Scrum Master juntamente com Product Owner so os responsveis em resolv-los. Durante a Sprint Review, as etapas que j foram concludas so entregues ao Product Owner, onde o mesmo tem o privilgio de aceitar ou recusar estas entregas realizadas caso elas no atendam aos requisitos especificados anteriormente. No Scrum, a cada trmino de uma Sprint feita a Sprint Review, onde so realizadas as entregas das partes do projeto que foram concludas durante a Sprint anterior ao Product Owner, que ir verificar se realmente as entregas atendem aos requisitos estabelecidos. Posteriormente, feita a Sprint Retrospective, que tem com principal objetivo melhorar os processos para a prxima Sprint, verificando quais as prticas sero mantidas e quais deixaro de ser feitas. 3.7 PMBOK X Scrum: Gerenciamento de Recursos Humanos Neste contexto as duas abordagens so compatveis, mas com

caractersticas bem peculiares. Tanto no Scrum como no PMBOK, as premiaes e comemoraes pela realizao de um projeto bem sucedido so comuns entre ambas as abordagens. No PMBOK, a definio coerente dos papis e responsabilidades dos integrantes da equipe um objetivo primordial dessa rea de conhecimento, pois cada membro treinado e guiado atravs dos processos na execuo de suas tarefas. O planejamento de recursos humanos no PMBOK visa organizar e gerenciar a equipe, identificando e documentando as funes, responsabilidades e as relaes hierrquicas entre seus integrantes, proporcionando o melhoramento da interao e o desempenho dos membros da equipe. No Scrum, a confiana e a colaborao dos integrantes da equipe um fator essencial no projeto. O planejamento e a tomada de decises so realizados em conjunto entre todos os participantes do projeto, exigindo profissionais habilidosos, no exigindo necessariamente que toda a equipe tenha o mesmo nvel. No Scrum, todos os integrantes da equipe tm a liberdade de fazer de tudo um pouco, e a equipe selecionada de acordo com as habilidades que cada pessoa desempenha visando atender aos requisitos do Product Backlog.

62

3.8 PMBOK X Scrum: Gerenciamento de Comunicaes Nesta rea de conhecimento o PMBOK e o Scrum se divergem. No PMBOK o gerenciamento de comunicaes realizado de maneira formal e documentada, com divulgao e acompanhamento dos resultados do trabalho feitos no decorrer do projeto. O objetivo primordial do gerenciamento das comunicaes no PMBOK documentar todos os fatos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto. No Scrum, devido ao fato de ser uma metodologia gil traz melhorias no processo de comunicao e na interao entre os envolvidos no projeto, promovendo um constante feedback durante o processo de construo do projeto. No Scrum o processo de comunicao feito de forma colaborativa e direta entre os envolvidos no projeto atravs das reunies dirias, na reviso das Sprints e em todo processo de desenvolvimento do projeto. O Scrum por no ter um nvel de formalismo mais abrangente como acontece no PMBOK, proporciona uma maior aproximao entre as partes envolvidas no projeto, mas necessita de que as mesmas tenham maturidade suficiente para que no haja conflitos. O nico ponto em comum entre o PMBOK e o Scrum neste contexto o fato de ambas as abordagens divulgarem e documentarem assuntos que so de extrema importncia durante o decorrer do projeto. 3.9 PMBOK X Scrum: Gerenciamento de Riscos Neste contexto, as duas abordagens so similares, tanto o PMBOK quanto Scrum a anlise, identificao e respostas aos riscos so comuns. No PMBOK, feito um plano formal para o gerenciamento de riscos, garantindo a identificao, avaliao, quantificao, planejamento de respostas, monitoramento e controle dos processos durante o ciclo de vida do projeto. No Scrum, a identificao, anlise, monitoramento e respostas aos eventos de riscos so realizados continuamente durante as reunies de planejamento de cada iterao. No monitoramento e controle dos riscos, feita uma reavaliao

63

durante as reunies de retrospectiva das iteraes, onde os riscos so analisados e revistos para que sejam eliminados para as prximas iteraes. 3.10 PMBOK X Scrum: Gerenciamento de Aquisies No PMBOK, todo o processo de aquisies realizado a partir do escopo e da documentao detalhada e bem definida, garantindo o controle e acompanhamento das atividades do projeto e do fornecedor, formalizando um contrato que obriga que tanto os representantes do projeto quanto os fornecedores cumpram o que foi combinado. No Scrum, h uma dificuldade muito grande em se estabelecer negociaes atravs de contratos, devido ao fato da ocorrncia constante de alteraes no escopo original do projeto. Neste contexto no ha preocupao em definir detalhadamente o processo de aquisio de mercadorias. 3.11 PMBOK X Scrum: Concluso do Projeto No PMBOK, o projeto s finalizado aps todas as entregas tiverem sido realizadas e documentadas. No Scrum, o trmino do projeto se da somente aps todos os requisitos do Product Backlog estiverem sido concludos.

64

4 ESTUDO DE CASO: Viabilidade de Utilizao do PMBOK e Scrum Neste captulo foi apresentado um estudo de caso com a finalidade de verificar a viabilidade de utilizao das prticas tradicionais do PMBOK em conjunto com a metodologia gil Scrum, como modelo de gesto de projetos no setor de Tecnologia da Informao de instituies de Tefilo Otoni, propondo um framework hbrido utilizando as duas abordagens. 4.1 Mtodos adotados para o estudo de caso O mtodo utilizado como estratgia de pesquisa neste trabalho foi o estudo de caso qualitativo, pois consiste em uma categoria que aborda a realidade de forma clara e objetiva, cujo principal foco a anlise de forma aprofundada e bem definida de um programa, uma instituio, um sistema educativo, uma pessoa ou uma unidade social [GIL, 2002]. A princpio, para a realizao do estudo de caso que esta pesquisa contempla, foi realizada uma anlise aprofundada a respeito do tema estudado, para posteriormente a construo de hipteses, e problematizar as situaes envolvidas no cenrio atual da organizao. O Estudo de caso em questo foi caracterizado como uma pesquisa descritiva e uma pesquisa de campo, pois foi realizado atravs da anlise presencial do setor de Tecnologia da Informao de instituies de Tefilo Otoni e de entrevistas realizadas atravs de questionrios aplicados aos responsveis pelo setor, para o levantamento e coleta de dados. Posteriormente a fase de coleta de dados, foi feita uma anlise e interpretao dos dados coletados, voltados aos objetivos da pesquisa, para em seguida a comprovao e validao do framework.

65

4.2 Descrio das Institues analisadas O estudo de caso proposto por esta pespesa foi realizado em duas instituies da cidade de Tefilo Otoni, sendo a primeira uma Instituio de Ensino Superior, e a segunda, uma cooperativa do ramo de laticinios, que por motivos de segurana no tiveram seu nome e nem localizao divulgados, por isso neste contexto sero denominadas respectivamente instituio A e instituio B. 4.2.1 Instituio A Fundada em 30 de setembro de 1953 por Juscelino Kubitschek de Oliveira, e federalizada em 17 de dezembro de 1960. A Instituio de Ensino Superior constituda de trs campus, abrigando seis faculdades e 23 cursos de graduao. O Campus Avanado da instituio localizado na cidade de Tefilo Otoni (MG) e abriga trs faculdades com nove cursos de graduao. A instituio conta com aproximadamente 500 servidores, entre professores, tcnicos administrativos etc. Desde a sua criao, a Instituio vem desenvolvendo um importante trabalho de ensino, pesquisa e extenso, priorizando sempre a prestao de servios s comunidades dos Vales do Jequitinhonha e do Mucuri. 4.2.2 Instituio B Fundada em 16 de dezembro de 1961, pelo idealismo de seus pioneiros, tem por misso disseminar princpios cooperativistas de produo, absorvendo e transformando os produtos agropecurios de seus associados em bens de consumo, de forma a satisfazer exigncias de mercado realizando obras que possam viabilizar o crescimento e desenvolvimento scio-econmico prprio e de seus cooperados, dotando-lhes de estmulos cultura, ao uso de novas tecnologias e da conscincia de cidado de um novo tempo. A Instituio contribui para o abastecimento de lcteos, principalmente, das regies nordeste e sudeste brasileira. Seus produtos industrializados, que levam a marca Cisne e Papagaio, tm o padro de qualidade reconhecido em todo o territrio brasileiro.

66

4.3 Proposta de utilizao de um framework hbrido Esta pesquisa demonstra que as diversas reas de conhecimento do PMBOK so completamente ou parcialmente adaptveis com a metodologia Scrum, porm existem algumas prticas que so conflitantes. A seguir foi apresentada uma proposta de utilizao de um modelo de gesto contendo as melhores prticas de ambas as abordagens atravs de um framework hbrido. A figura 19 a seguir ilustra o novo ciclo de vida do Scrum agregando algumas prticas tradicionais importantes do PMBOK. Figura 19: Novo ciclo de vida: PMBOK e Scrum

Fonte: Desenvolvido pelo Autor.

67

Etapa 1- Viso do Projeto: A primeira etapa do framework consiste em uma viso geral de como ser a estrutura do projeto, realizada atravs da primeira reunio de planejamento, neste contexto denominada Sprint Planning 1, onde sero reunidos o cliente que representado por uma pessoa responsvel pelo departamento que necessita dos servios do setor de tecnologia da informao da instituio, a equipe de desenvolvimento do projeto, e o gerente de projetos, que consiste na pessoa responsvel pelo setor de TI, cuja competncia garantir que os objetivos do projeto esto sendo compridos. Etapa 2 - Product Backlog: Na segunda etapa do framework, o gerente de projetos com base nas idias expostas pelos demais integrantes da Sprint Planning 1 cria uma lista inicial de necessidades que devem ser produzidas para que a viso do projeto seja bem sucedida, e posteriormente desenvolve um quadro, que neste contexto ser denominado Product Backlog, contendo todas as funcionalidades do projeto que precisam ser atendidas. O Product Backlog ser exposto no ambiente de trabalho para todos os integrantes da equipe tomar conhecimento do que ser feito no projeto. A figura 20 a seguir ilustra o modelo de um novo Product Backlog que ser utilizado neste framework. Figura 20: Exemplo do Novo Product Backlog

Fonte: Desenvolvido pelo Autor.

68

Etapa 3 - Documentao: Na terceira etapa do framework, o gerente de projetos juntamente com a sua equipe de desenvolvimento ir realizar a documentao da descrio detalhada do projeto, criar uma EAP com base no projeto que ser desenvolvido, detectar e documentar os possveis riscos que podem ocorrer durante o andamento do projeto, e ir realizar o planejamento de aquisies e o planejamento de recursos humanos do projeto. A figura 21 a seguir ilustra um exemplo de estrutura de uma EAP especfica que ser utilizada neste framework. Figura 21: Exemplo de uma EAP especfica

Fonte: Desenvolvido pelo Autor

Etapa 4 - Product Backlog Priorizado: Na quarta etapa do framework, o gerente de projetos, a equipe de desenvolvimento e o cliente realiza a segunda reunio de planejamento, chamada Sprint Planning 2, com o objetivo de priorizar os itens de maior importncia do Product Backlog, para ento criar a Sprint Backlog contendo os itens de maior relevncia, para posteriormente dar inicio ao ciclo de desenvolvimento.

69

Etapa 5 - Sprint Backlog: Nesta etapa do framework, a Sprint Backlog deve ser criada atravs de um quadro contendo os requisitos em ordem de maior importncia, juntamente com as atividades que devem ser realizadas em cada um destes requisitos, as atividades em andamento juntamente com o nome da pessoa responsvel por essa atividade, e as tarefas j concludas. A figura 22 exemplifica como dever ser o quadro de itens priorizados do Product Backlog para esse framework. Figura 22: Quadro de itens priorizados

Fonte: Desenvolvido pelo autor.

O quadro de itens priorizados deve ser colocado pelo gerente de projetos ao lado do Product Backlog, para que todos os integrantes da equipe tomem conhecimento dos requisitos e das tarefas mais importantes que devem ser desenvolvidas primeiramente. Aps a concluso de todas as atividades do primeiro requisito, automaticamente a equipe passa para o prximo requisito at que todos os requisitos sejam concludos e a finalizao do projeto ocorra.

70

Para auxiliar no gerenciamento das atividades das etapas 2 e 5 deste framework, foi proposto a utilizao da ferramenta de gerenciamento de projetos DotProject, como demonstrado a seguir atravs do seu tutorial de utilizao.

Tutorial de Utilizao do DotProject O DotProject um sistema de gerncia de projetos em software livre de fcil utilizao, com um conjunto de funcionalidades e caractersticas que o tornam indicado para implementao em ambientes corporativos, pois atende a diversas necessidades de gerentes e Escritrios de Projetos. O DotProject consiste em uma aplicao web e seu acesso feito atravs de um navegador, assim sua utilizao independe de sistema operacional e instalao na mquina do usurio, pois executado em um servidor. Em termos mais tcnicos, o DotProject um sistema escrito em PHP, que utiliza banco de dados MySQL. Aps utiliz-lo. instalado o DotProject, deve-se seguir os seguintes passos para

1 Passo: Fazer Login Fazer o login no sistema, por padro o DotProject utiliza o usurio admin e a senha passwd.

Preencha o nome do usurio e senha Clique em login

71

Ao clicar em login aparecer seguinte tela:

2 Passo: Criar Usurio Deve-se cadastrar os usurios administradores que iro utilizar o sistema, e adicionar os projetos em que os mesmos iro trabalhar. Para adicionar um usurio necessrio: Acessar o link Administrar Usurios Clicar em adicionar usurio

Preencher os campos Nome de usurio: deve possuir no mnimo quatro caracteres Grupo de usurios: selecione a categoria que este pertence - Coordenao geral (usurios vinculados exclusivamente a administrao da rede) - Doutorando - Iniciao cientfica - Mestrando - Ps doutorando - Tcnico administrativo ou informtica - Pesquisador (todos os outros usurios)

72

Senha: deve conter no mnimo quatro caracteres Confirm Password: repetir a senha Nome: nome do pesquisador Instituio: selecione a Instituio que o usurio possui vnculo Diviso: selecionar o n que o usurio possui o vinculo Clicar no boto

3 Passo: Cadastrar Empresa

Para cadastrar uma empresa no sistema DotProject basta clicar a aba empresa e posteriormente em nova empresa.

Aps clicar na aba nova empresa ir aparecer um formulrio contendo os campos que devem ser preenchidos com as informaes da empresa a ser cadastrada, basta preenche-los e clicar no boto enviar.

73

4 Passo: Criar um Projeto Para adicionar um novo projeto, basta clicar em empresa, selecionar a empresa que ser criado o projeto e em seguida clicar em novo projeto.

Aps clicar em novo projeto ir aparecer um formulrio que dever ser preenchido com as informaes referentes ao projeto que ser criado, basta preencher os campos e clicar em enviar.

5 Passo: Criando as tarefas. As tarefas devem ser vinculadas a um projeto e as informaes cadastradas nestas, como datas, dependncias e recursos humanos, definem o projeto em que estas esto vinculadas, ou seja, qualquer alterao nas tarefas, o projeto alterado. Para criar uma tarefa, necessrio acessar o projeto onde deseja inserir a tarefa, clicar em nova tarefa, preencher as informaes sobre a tarefa nas abas detalhes, datas, dependncias e recursos humanos, e em seguida clicar em salvar.

74

Para cadastrar uma nova tarefa necessrio acessar o projeto que deseja inserir esta tarefa. Clique no link empresa.

Selecione a empresa clicando sobre ela.

Clicar sobre o nome do projeto que deseja inserir a nova tarefa.

75

Clique sobre o link nova tarefa.

Etapa 6 - Sprint: Nesta etapa, aps a priorizao de todos os requisitos dado inicio ao ciclo de desenvolvimento, dentro do prazo estimado de 2 a 4 semanas para concluso de todo o projeto, ou de apenas algumas funcionalidades, ficando a critrio do gerente de projetos decidir o que melhor para aquele determinado projeto. Durante o ciclo de desenvolvimento da Sprint sero realizadas diariamente reunies de no mximo 20 minutos objetivando disseminar a todos os componentes da equipe as barreiras encontradas naquele dia de trabalho, para realizar a tomada de providncias.

Etapa 7 - Atualizao da documentao: Nesta etapa, aps a finalizao de cada ciclo de desenvolvimento realizado a atualizao de toda a documentao do projeto, descrevendo tudo o que foi feito na Sprint, quais foram s barreiras encontradas durante andamento do projeto, e o que pode ser melhorado para dar inicio a prxima Sprint.

Etapa 8 - Retrospectiva: Nesta etapa, o gerente de projetos juntamente com sua equipe realiza uma reunio de retrospectiva aps cada ciclo de desenvolvimento, neste contexto denominado Sprint Retrospective. O objetivo principal desta reunio promover melhorias para o prximo ciclo de desenvolvimento, pois os membros da equipe iro identificar e priorizar o que consideram que foi bem e o que pode se melhorado, traando planos de ao para realizar essas melhorias. Nesta reunio tambm so realizados testes funcionais no produto desenvolvido. Aps a reunio de retrospectiva o ciclo de desenvolvimento retorna a fase de priorizao das atividades, dando continuidade ao desenvolvimento at que todos os itens do Product Backlog tenham sido finalizados.

Etapa 9 - Entrega Final: Nesta fase realizado o fechamento e documentao do projeto a partir da concluso de todos os itens do Product Backlog, e o arquivamento

76

das lies aprendidas durante o projeto com o intuito de minimizar falhas em projetos futuros.

4.4 Diagnstico das anlises realizadas Para constatar a viabilidade ou inviabilidade da utilizao da proposta deste trabalho, foram feitas anlises presenciais no setor de Tecnologia da Informao de ambas as instituies citas anteriormente, e entrevistas aplicadas aos responsveis pelo setor TI, para o levantamento e coleta de informaes, onde foi constatado o seguinte: 4.4.1 Instituio A O setor de Tecnologia da Informao da Instituio de Ensino Superior analisada neste trabalho composto por 18 colaboradores, dentre eles, analistas de sistemas, tcnicos em informtica, chefes de diretoria de Tecnologia da Informao e monitores de Informtica. O setor de TI desenvolve projetos voltados aos interesses da instituio comumente em um perodo de 2 em 2 messes, tendo como principais projetos criados o desenvolvimento de sistemas, e projetos voltados para a rea de redes de computadores, chefiados por 2 analistas de sistemas responsveis pelo setor de TI. Aps a anlise do setor de TI da Instituio, constatou-se que o mesmo no utiliza nenhuma metodologia ou procedimento capaz de orientar de forma eficaz os seus projetos. Quando se requisitado um novo projeto, ocorre sempre uma tempestade de idias desorganizadas (brainstorming) entre os componentes da equipe, e posteriormente a organizao das mesmas para em seguida ocorrer o planejamento e desenvolvimento do projeto, sempre de forma bastante informal. Na fase de desenvolvimento de um projeto pelo setor de TI a equipe realiza reunies bem superficiais entes do incio de cada etapa, onde ocorre o detalhamento do projeto que ser executado, o mesmo feito de forma informal. Aps a reunio de planejamento do projeto a equipe define superficialmente o escopo do projeto para todas as partes envolvidas, ocorrendo sempre inconformidades nos resultados entregues ocasionadas pela falta de uma descrio detalhada do escopo.

77

Alteraes no escopo original do projeto desenvolvido pela equipe do setor de TI freqentemente so requisitadas, e realizadas sem algum tipo de documentao ou reviso. O cronograma do projeto na maioria das vezes possibilita um acompanhamento eficaz do projeto, mas tambm so feitos de forma informal sem nenhuma documentao ou controle de mudanas. As atividades realizadas pela equipe so feitas de forma seqencial, sem nenhum mecanismo capaz de priorizar as atividades de maior importncia para serem desenvolvidas primeiramente. Os custos relativos aos projetos geralmente so condizentes com o combinado, mas a equipe no emprega nenhuma ao para garantir a qualidade das atividades que so desenvolvidas no projeto. Os projetos realizados no possuem um prazo predeterminado para sua concluso, e no h uma forma eficaz de estimar com preciso o tempo de durao de cada projeto criado. Na fase de concluso de um projeto no so feitas documentaes de todo o trabalho que foi realizado. O setor de TI da Instituio de Ensino Superior analisada no possui polticas burocrticas para implantao de novos projetos e na maioria das vezes tm trazido resultados satisfatrios, porm com alguns contratempos ocasionados pela falta de um procedimento capaz de gerenciar suas atividades de forma eficaz. 4.4.2 Instituio B O setor de Tecnologia da Informao da cooperativa de laticnios analisada neste trabalho composto por 2 colaboradores, sendo 1 tcnico em informtica e 1 analista de sistemas. O Setor de TI desenvolve projetos voltados aos interesses da cooperativa mensalmente, e dentre os principais projetos criados esto o desenvolvimento de sistemas, implantao de sistemas, treinamentos de

funcionrios, e projetos relacionados a banco de dados. Aps a realizao da anlise no setor em questo, constatou-se que o mesmo tambm no utiliza nenhuma metodologia ou procedimento capaz de agilizar as tarefas relacionadas ao desenvolvimento dos seus projetos. Ao ser requisitado para o desenvolvimento de um novo projeto, o gerenciamento de suas atividades

78

feito apenas atravs da descrio superficial das tarefas a serem executadas por meio de editores de texto, planilhas eletrnicas e ferramentas de compartilhamento de arquivos. A fase de execuo foi baseada atravs da utilizao do framework proposto no projeto de implantao do sistema de nota fiscal eletrnica (NF-e) j desenvolvido pela equipe de TI da cooperativa, onde seguindo as etapas do framework constatouse o seguinte: Etapa 1- Viso do Projeto: No projeto NF-e foi realizada uma reunio inicial, conforme descreve a primeira etapa do framework, no qual os membros da contabilidade expuseram para o setor comercial e o departamento de tecnologia as determinaes legais e conseqncias fiscais da no realizao do projeto da nota fiscal eletrnica, onde se obteve uma viso geral de como seria a estrutura deste projeto. Etapa 2 - Product Backlog: Ao final da reunio descrita na etapa1 do framework, a equipe do setor de TI da cooperativa determinou quais as tarefas precisariam ser executadas para dar andamento ao projeto, caracterizando um Product Backlog. Etapa 3 - Documentao: No projeto NF-e no houve a construo de uma EAP, o gerenciamento de riscos no foi levantado formalmente, indicando os possveis riscos caso algum prazo fosse extrapolado. Houve o planejamento das aquisies na rea de TI e na rea contbil, entretanto nenhuma poltica de gesto neste sentido foi realizada. Etapa 4 - Product Backlog Priorizado: No projeto NF-e foram construdas listas de tarefas a serem executadas, observando critrios de prazo e custos, entretanto no houve documentao formal para acompanhar o desenvolvimento delas. Etapa 5 - Sprint: Os prazos para concluso de cada funcionalidade estavam balizados pelo tempo final da entrega de todo o projeto, sendo assim no houve determinao formal da entrega de cada uma das funcionalidades, gerando atrasos na iniciao das tarefas posteriores. As reunies dirias e a gesto de riscos nesta fase no foram realizadas.

79

Etapa 6 - Atualizao da documentao: No houve atualizao na documentao criada em funo da falta de procedimentos que monitorasse estas ocorrncias.

Etapa 7 - Retrospectiva: No projeto NF-e no ocorreu nenhuma reunio de retrospectiva objetivando realizar o levantamento dos pontos positivos e negativos em cada funcionalidade desenvolvida. Tambm no ocorreram testes funcionais no projeto visando corrigir possveis erros, evidenciando assim o atropelamento das outras tarefas em funo do pouco tempo para o cumprimento do projeto final, ocasionando erros freqentes na maioria das funcionalidades desenvolvidas.

Etapa 8 - Entrega Final: No projeto NF-e no foram aplicadas nenhuma das propostas apresentadas pelo framework para o fechamento do projeto, o mesmo foi entregue informalmente no incio da simulao do ambiente operacional.

80

5 CONSIDERAES FINAIS

Esta pesquisa apresentou um estudo sobre duas abordagens muito utilizadas atualmente para gerenciamento e desenvolvimento de projetos, com o intuito de auxiliar aos gerentes ou at mesmo as organizaes a entenderem um pouco melhor sobre estes paradigmas. Neste sentido, busca auxili-los a escolher qual o melhor se adapta a sua realidade ou at mesmo no uso combinado de suas prticas. Primeiramente este trabalho concentrou-se em estudar fundamentos tericos sobre o tema abordado, principalmente no que se diz respeito aos processos de gerenciamento de projetos do PMBOK e da metodologia gil Scrum. Em seguida, foi apresentado um estudo comparativo entre as duas abordagens estudadas, onde pode-se concluir que as nove reas de conhecimento do PMBOK so adaptveis com a metodologia Scrum. Entretanto existem algumas atividades que so conflitantes e apresentam particularidades, como o caso das reunies de planejamento, reunies dirias e reunies de retrospectiva apresentada pelo Scrum. Posteriormente, foi visto a criao de um modelo de gerncia de projetos atravs do uso combinado das prticas do PMBOK em conjunto com a metodologia gil Scrum atravs de um framework hbrido, revelando que o uso combinado dos dois paradigmas cria um mtodo de gerenciamento preventivo, que no onera os projetos em termos de documentao, s os torna mais geis, eficazes e preventivos. Porm o nico segredo esta em saber adapt-los corretamente. Conforme apresentado no inicio deste trabalho de concluso de curso, o objetivo geral do mesmo foi analisar a viabilidade de utilizao do PMBOK e o

81

Scrum, como modelo de gesto de projetos no setor de TI de instituies de Tefilo Otoni, onde foi levantada uma proposta de investigao que buscou responder a seguinte questo problema: vivel utilizar o PMBOK e o Scrum em conjunto como modelo de gesto de projetos no Setor de TI de instituies de Tefilo Otoni? Para tal modelo ser utilizado, foram mencionadas algumas hipteses onde pode-se chegar as seguintes concluses : H1: vivel utilizar o PMBOK e o Scrum, pois proporcionar mais qualidade aos projetos desenvolvidos. Essa hiptese foi validada, pois foi comprovado que com a utilizao do modelo proposto, o resultado final dos projetos satisfatrio, uma vez que atende as necessidades dos usurios, no ocorrendo inconformidades no que foi requisitado. H2: vivel, pois obrigar a documentao para melhorar a comunicao e conseqentemente o conhecimento da equipe sobre o projeto. Essa hiptese foi validada, pois foi comprovado que em nenhuma das instituies analisadas possui um processo de documentao eficaz dos projetos realizados, de forma a contribuir com a disseminao da comunicao entre a equipe de desenvolvimento. H3: No vivel, pois a utilizao de testes em cada ciclo de desenvolvimento poder ocasionar atrasos na entrega do projeto final. Esta hiptese no foi validada, pois foi demonstrado que a realizao de testes em cada ciclo de desenvolvimento garante a reduo do tempo final do projeto, uma vez que mais fcil corrigir erros em cada funcionalidade em particular do que no projeto como um todo. Aps a realizao deste trabalho, conclui-se que perfeitamente vivel a utilizao de ambos os paradigmas em conjunto, aplicados ao setor de Tecnologia da Informao de instituies de Tefilo Otoni. Neste contexto comprovarmos que o uso do modelo proposto ir acrescentar inmeros benefcios ao referido setor,

82

principalmente no que diz respeito ao gerenciamento de seus projetos, podendo-se destacar: o aumento do controle gerencial pela subdiviso das principais etapas do projeto em componentes menores e mais facilmente gerenciveis com uso de uma EAP; o envolvimento de todos os participantes do projeto em todas as fases; e o melhoramento de habilidades para atender as exigncias dos usurios internos da instituio, proporcionando uma prestao de servios mais gil, segura e eficiente. Porm, somente necessrio saber como aplicar os processos para cada projeto em particular. Para finalizar, fica a sugesto para trabalhos futuros o desenvolvimento de uma aplicao fundamentada nos paradigmas estudados, para auxiliar no desenvolvimento de projetos no setor de Tecnologia da Informao.

83

REFERNCIAS BIBLIOGRFICAS

BRAGA, Alcir Rodrigues. Gerncia de Projetos: Preparao para a Certificao PMP. Novembro 2003. DAVILA, Marcio. Sucessos e Falhas em Projetos de TI. 2010 FRANCO, Eduardo Ferreira. Um modelo de gerenciamento de projetos baseado nas metodologias geis de desenvolvimento de softwares e nos princpios da produo enxuta. 2007. GIL, Antonio Carlos. Como Elaborar Projetos de Pesquisa. 4 Ediao. So Paulo 2002. GONALVES, Andr Silva. Gesto de Projetos em Pequenas e Mdias Empresas: Principais dificuldades. 2009. Disponivel em:

http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/677. Ultimo acesso em 13/09/2010 s 10:00 MAGNO, Alexandre. Revista Viso gil Scrum Master por Ele Mesmo. Edio 4 2008. Disponvel em: www.visaoagil.com. Ultimo acesso: 11/10/2010. MARAL, Ana Sofia. Estendendo o SCRUM segundo as reas de processo de gerenciamento de projetos do CMMI. 2007 MARTINS, Leonardo Vieira. Gesto Profissional de Projetos. 2003. Disponvel em: http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/83. Ultimo acesso em 12/10/2010 s 09:40 MIRANDA, J. M. Metodologias geis para o Desenvolvimento de Software, Scrum eExtreme Programming X Metodologias Tradicionais RUP. 2008. NARDI, Kleber. PMBOK x SCRUM: Como gerenciar um projeto de software? 2009.

84

PMBOK - Project Management Body of Knowledge. Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. Guia PMBOK. Terceira Edio, 2004. PEREIRA, Paulo. Entendendo o Scrum para Gerenciar Projetos de Forma gil. Mundo PM. 2007. Disponvel: http://www.lapjor.cce.ufsc.br/elgg/html/pg/

file/benhur/read/349/entendendo-scrum-para-gerenciar-projetos-de-forma-gil. Ultimo acesso em: 25/09/2010 s 16:00 REINERT, Jonatas Davson. Estudo do uso de Metodologias geis no Desenvolvimento de uma aplicao de governo eletrnico. Departamento de Informtica e Estatstica Universidade Federal de Santa Catarina. SOARES, Michel dos Santos. Comparao entre metodologias geis e tradicionais para desenvolvimento de software. Disponvel em:

http://www.fatecinformatica.com/wp-content/uploads/2010/04/comparacaoentremetodologias.pdf. Ultimo acesso em 15/09/2010 s 15:10. STANLEIGH, Michael. Combinando a Norma ISO 10006 e o Guia PMBOK para garantir sucesso em projetos. 2005. TORREO, Paula. Ambiente Inteligente de aprendizado para Educao em Gerenciamento de Projetos. 2005. Dissertao (Ps-Graduao em Cincia da Computao) Universidade Federal de Pernambuco, Recife. VARGAS, Ricardo. Manual prtico do plano do projeto. 3 Ed.Rio de Janeiro. Brasport, 2007. Disponvel em:http://issuu.com/ricardo.vargas/docs/manualprat.

Ultimo acesso em 25/09/2010 s 14:20 VARGAS, Ricardo. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 3 Ed.Rio de Janeiro. Brasport, 2009. VIANA, Antonio Geraldo Gonalves. Gerenciamento de projetos em processo gil de desenvolvimento de software. 2008. Disponvel em: http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/393. ultimo acesso em 26/09/2010s 20:30.

85 ANEXO 1

Roteiro de Entrevista (questionrio utilizado para o levantamento e coleta de informaes) Identificao da Empresa Nome: Endereo: Cidade: Ramo de Atuao: Identificao do Entrevistado Nome: Email: Formao: Cargo na Empresa: Atividade que Desenvolve:

Questionrio

1 - Qual o nmero de colaboradores que trabalham no setor de Tecnologia da Informao da Instituio? 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5 ( ) Quantos?................... R: Instituio A. 18 R: Instituio B. 2 2 - Qual a formao das pessoas da equipe? ( ) Ensino Mdio: Quantos da equipe?....................... ( ) Ensino Tcnico: Quantos da equipe?..................... ( ) Ensino Superior: Quantos da equipe?............................ Em quais cursos?..............

86 R: Instituio A. 12 com ensino mdio, 2 com ensino tcnico, 3 com ensino superior em Sistemas de Informaes e 1 em cincia da computao.

R: Instituio B. 1 com ensino mdio, e 1com ensino superior completo em cincia da computao. 2 - Quantos so os responsveis pela gesto de projetos no setor de TI da instituio? R: Instituio A. 3 pessoas. R: Instituio B. 1 pessoa. 3 - Qual a freqncia mdia de implantao de projetos desenvolvidos pelo setor de TI da instituio? ( ) Semanal ( ) Mensal ( ) Bimestral ( ) Semestral ( ) Anual

R: Instituio A. Bimestral. R: Instituio B. Mensal. 4 - Qual o tipo de projeto mais desenvolvido pela equipe de Tecnologia da Informao da Instituio? ( ( ( ( ) Desenvolvimento de Sistemas. ) Implantao de Sistemas. ) Banco de dados. ) Treinamentos.

Outros? ..................................................................... R: Instituio A. Desenvolvimento de Sistemas e redes de computadores. R: Instituio B. Desenvolvimento de Sistemas, Implantao de Sistemas, Banco de dados, e treinamentos. 5 - O setor de TI utiliza algum tipo de metodologia para gerenciamento ou desenvolvimento de seus projetos? Se utiliza, o que levou a instituio a adotar esse modelo?

87 R: Instituio A. No. R: Instituio B. No. 6 - Como se da o gerenciamento de projetos no setor de TI da instituio? Cite as etapas, funes desempenhadas e ferramentas utilizadas. R: Instituio A. 1 - Tempestade de idias (brain storming), 2 - organizao da idias, 3 - Planejamento, 4 - Ao, 5 - Manuteno. R: Instituio B. O gerenciamento se pauta apenas em descries de tarefas a serem executadas utilizando-se de um editor de texto, planilhas eletrnicas e ferramentas de compartilhamento de arquivos. 7 - O setor de Tecnologia da Informao realiza alguma reunio de planejamento com todas as partes envolvidas no projeto antes do inicio de cada etapa do projeto? Justifique. R: Instituio A. Sim, antes de ter as idias iniciais so feitas reunies de planejamento. R: Instituio B. Apenas na etapa inicial, entretanto no h controle automatizado dos cumprimentos dos prazos, tarefas e custos estabelecidos nesta reunio. As demais ocorrem h medida que surgem problemas que impeam o andar do projeto. 8 - Como feito o detalhamento do projeto a ser executado? R: Instituio A. Deforma informal. R: Instituio B. Informalmente, utilizando-se de ferramentas eletrnicas ou no. 9 - Como so documentadas as etapas de realizao de cada projeto? R: Instituio A. No so, e quando so somente realizado eletronicamente. R: Instituio B. No h documentao. 10 - O Escopo do projeto definido claramente para todos os envolvidos, ou ocorrem inconformidades nos resultados entregues, ocasionados pela falta de uma especificao detalhada do escopo?

88 R: Instituio A. Sempre h inconformidades. R: Instituio B. O Escopo de projeto definido, entretanto no detalhado o suficiente para que os resultados dos entregveis produzam algo sem erros. 11 - Como so controladas as solicitaes de mudanas e alteraes no escopo do projeto e qual forma de registro destas alteraes? R: Instituio A. Informalmente, sem reviso. R: Instituio B. No so controladas e sim impostas, isto , as alteraes que surgem no decorrer do projeto geralmente so regidas por normativas legais e/ou estratgicas, sem que haja documentao formal para registr-las. 12 - A instituio possui algum tipo de cronograma para auxiliar no gerenciamento do tempo das entregas do projeto? R: Instituio A. Sim, bem informal e impresso. R: Instituio B. No possui. 14 - Como so controladas e documentadas as mudanas no cronograma do projeto? R: Instituio A. No so controladas. R: Instituio B. No so controladas. 13 - Se possui, o cronograma possibilita o acompanhamento eficaz do projeto? R: Instituio A. Na maioria das vezes sim. R: Instituio B. No possui um cronograma. 15 - Os projetos possuem algum prazo mximo predeterminado para sua concluso? Comente.

89 R: Instituio A. No possui um prazo mximo de concluso predeterminado devido ao fato de que nem sempre possvel estimar com preciso o tempo de durao de cada projeto. R: Instituio B. H claramente duas espcies de projetos na empresa: O Legal, inserido por alguma normativa Federal, Estadual ou Municipal, e o Estratgico, inserido por determinao da Direo da Empresa para fins de melhoria funcional. Todos os projetos tm prazos pr-determinados, entretanto a prioridade segue a orientao para os atos Legais em funo de penalizaes por descumprimento de prazos. 16 - Existe algum mecanismo utilizado para priorizar as funcionalidades mais importantes a serem desenvolvidas no projeto? Comente. R: Instituio A. No existe. R: Instituio B. Sim. O primeiro mecanismo externo, so as penalidades, no caso dos Legais. O segundo mecanismo vale para todos os projetos. Tratase de uma reunio semanal entre os Gerentes para deliberao de assuntos de todas as reas da empresa. Todos os outros mecanismos no so tratados formalmente. 17 - As atividades e os prazos de concluso apresentados so condizentes com o combinado? R: Instituio A. Geralmente sim. R: Instituio B. Sim. Os projetos Legais devem ter seus prazos confirmados uma vez que h penalizaes severas no caso de atrasos. Os projetos Estratgicos, mesmo com prazo pr-estabelecidos, geralmente no so completados dentro do cronograma. 18 - Os custos dos projetos so planejados e acompanhados adequadamente, ou ocorrem custos adicionais nos projetos ocasionados pela falta de uma gesto eficaz?

90 R: Instituio A. Geralmente os custos so adequados. R: Instituio B. Sim so planejados, entretanto podem surgir novas funcionalidades e o planejamento de custo alterado informalmente. 19 - Durante a fase de execuo de um projeto na instituio quais aes so realizadas com o intuito de garantir que o projeto emprega todos os processos de qualidade necessrios para atender aos requisitos especificados? R: Instituio A. Nenhuma ao empregada. R: Instituio B. So duas polticas claras adotadas pelo setor de TI: a) Testes das funcionalidades: Bateria de testes visando validar os resultados alcanados com os requisitos especificados; b) Simulao do ambiente operacional: Trata-se de execuo das tarefas implementadas no prprio ambiente de funcionamento das atividades, utilizando-se material e os recursos humanos que sero usados diretamente na produo. Nesta fase h treinamentos in loco deste ambiente. 20 - O responsvel pelo setor que necessita dos servios do Setor de TI da instituio participa ativamente no projeto. Se sim, como? R: Instituio A. Sim. Planejando, controlando, e algumas vezes controlando o projeto. R: Instituio B. Sim. Direcionando e cobrando as especificaes do Projeto. 21 - Os projetos desenvolvidos pelo setor de TI da instituio tem trazido resultados satisfatrios? R: Instituio A. Sim. R: Instituio B. Na medida do possvel sim. Entretanto acho que a TI deva passar por reformulaes nas suas atividades primrias, principalmente na

91 rea de desenvolvimento, para que haja maior produtividade funcional com ganhos reais para a empresa. 22 - Quais so as polticas adotadas pela instituio para a implantao de novos projetos? R: Instituio A. No h polticas. R: Instituio B. Poltica Legal e Estratgica. 23 - O Scrum e o PMBOK so metodologias de gerenciamento de projetos que vem ganhando adeptos em todo o mundo devido ao seu feedback positivo. Vo acha vivel utilizar algum destes modelos no setor de TI desta instituio?

R: Instituio A. Os dois, por auxiliarem na organizao e agilizarem as tarefas. R: Instituio B. Sim. Acho extremamente necessria algumas produes de artefatos do PMBOK em conjunto com interatividade e fluidez do Scrum.

92 ANEXO 2

Tutorial de Instalao do DotProject O dotProject um programa distruibuido sob licena GNU-GPL (http://www.gnu.org/licenses/gpl.txt) e tem seu desenvolvimento mantido principalmalmente pela a empresa qual australiana mantendo Saki Computers extras

(http://www.saki.com.au)

trabalha

servios

correlacionados ao mesmo, como customizao, suporte tcnico e etc. Como j foi dito anteriormente, o DotProject um software online, por isso ele vai precisar ser instalado em um servidor, e esse servidor tem de ter suporte a PHP e MySQL. Para usurios acessarem o DotProject eles devem usar um browser (Mozilla firefox, opera, konqueror, internet explorer e etc). Para resumir, o servidor que ter o DotProject dever ter: LAMP: Linux+Apache+MySQL+PHP WAMP: Windows+Apache+MySQL+PHP WIMP: Windows+IIS+MySQL+PHP Passo 1 - Download

As etapas de instalao do DotProject a seguir ser baseada na plataforma Linux. Para instalar o dotproject primeiramente precisa-se baixar o pacote. No site oficial voc ir achar o pacote. Se preferir clique no link abaixo.

http://ufpr.dl.sourceforge.net/sourceforge/dotproject/dotproject-2.0.4.tar.gz

Em seguida deve descompactar em algum diretrio que tenha acesso a web e permisso de escrita. No Debian esse diretrio seria o /var/www ou no public_html. Para outros sistemas existem diretrios diferentes. Voc pode tambm simplificar esse primeiro passo simplesmente com os comandos:

# apt-get install wget

93 # cd /var/www # wget -c -nd http://ufpr.dl.sourceforge.net/sourceforge/dotproject

/dotproject-2.0.4.tar.gz<LI< a> style="text-align:justify;"># tar xzvf dotproject2.0.4.tar.gz

Passo 2 - Configurando usurios Para poder ter privilgios de escrita, leitura etc, voc precisa configurar o usurio para que ele possa fazer o que precisa, para isso voc deve digitar os seguintes comandos no terminal:

Para configurar o root como dono de todos os arquivos digite:

o chown -R root dotproject

Para ajustar as permisses dentro do DotProject voc deve digitar no terminal: o chmod o+w dotproject/includes o chmod o+w dotproject o chmod o+w dotproject/files Feito isso as permisses esto liberadas para que voc instale o DotProject na sua mquina. Obs: Essas permisses sero modificadas posteriormente para assegurar a segurana do sistema.

Passo 3 - Acessando a pasta Depois que tiver baixado o pacote e modificado as permisses voc deve iniciar a instalao, para isso entre na pasta citada anteriormente usando o browser. Basta digitar o endereo seguinte na barra de endereo do seu browser: http://localhost/dotproject

Feito isso vai aparecer uma tela para voc clicar no link para iniciar a instalao e configurao do DotProject (Star Installation).

94

Passo 4 - Iniciando a Instalao Depois de ter clicado no link referido acima voc vai entrar numa nova pgina. Confira os detalhes da pagina, j que Algumas das configuraes podem resultar em falha parcial ou completa da instalao. Por exemplo, se voc no tiver modificado as permisses no passo 2 ter que faz-lo para suportar upload de arquivos ou para permitir escrita na configurao principal. Se precisar fazer modificaes as faa e depois atualize a pgina. Se voc j tiver criado o banco de dados para o dotProject basta colocar a senha escolhida no campo DATABASE USER PASSWORD e clicar em install db & write cfg e seguir para o passo 6, caso contrario siga para o passo 5. Passo 5 - Criando Banco de dados

Voc vai precisar criar um banco de dados para o DotProject, para isso basta voc abrir o terminal e digitar os seguintes comandos: mysql -u root CREATE DATABASE NOME_DO_BANCO_DE_DADOS GRANT ALL PRIVILEGES ON nome_do_banco_de_dados* to "dpuser"localhost" IDENTIFIED BY "SENHA" FLUSH PRIVILEGES Quit

Pronto, o banco de dados est criado com os privilgios necessrios. Feito isso v at o navegador que est na pgina de instalao e digite a senha que voc definiu na criao do banco de dados no campo DATABASE USER PASSWORD.

Clique no boto install db & write cfg

Das könnte Ihnen auch gefallen