Planejamento de projetos em times Scrum com apoio do PMBOK Cassius Ferreira Leonardo

Transcrição

1 Planejamento de projetos em times Scrum com apoio do PMBOK Cassius Ferreira Leonardo RESUMO O mã todos à geis dentre, entre eles o Scrum, trouxeram um conjunto de prã ticas,â ferramentas e tã cnicas na tentativa de obter o retorno de investimento em projetos queâ precisam tratar com desenvolvimento de produtos complexos, porã m com um foco bastanteâ voltado para as etapas de execuã à o. Em paralelo temos o aumento da importã ncia dasâ utilizaã à o das boas prã ticas de gerenciamento de projetos que elevam a garantia de que oâ escopo, prazos, custos e qualidade do projetos sejam atingidos de acordo com os objetivosâ previamente planejados. Este trabalho se destinou a demonstrar como as tã cnicas deâ planejamento de projetos contidas no guia PMBOK, agregadas a utilizaã à o do Scrum cobriram uma parte importante nã o tratada pelo framework, trazendo benefã cios para oâ projeto como um todo. 1 INTRODUà ÃO Para atingir os objetivos estratã gicos as empresas precisam remover impedimentos eâ se adaptar de forma rã pida à s pressãµes impostas por um mercado em constante mudanã a eâ desenvolvimento. Uma das formas de remover essas restriã ões à o emprego de novosâ softwares e a evoluã à o de sistemas de informaã à o jã existentes. Nesse cenã rio entendemosâ a importã ncia dos projetos de softwares nas estratã gias organizacionais. Porà m, o altoâ à ndice de insucesso na entrega de projetos de desenvolvimento de software dentro doâ prazo, custo e escopo acordados caracterizam um grande desafio para à rea deâ gerenciamento de projetos. O conjunto desses problemas tem levado as empresas aâ repensarem sua forma de trabalho discutindo se as metodologias difundidas no mercado atendem o dinamismo que os projetos dessa à rea requerem por tratar de problemas complexos e adaptativos. Nesse contexto surgem os mã todos à geis de desenvolvimento de software, dentre eles o Scrum, formando um conjunto de prã ticas, ferramentas e filosofias na tentativa de anteder as expectativas de retorno de investimento nos projetos de software. Porà m, segundo Cruz (2013), o Scrum tem um foco muito profundo na etapa de execuã à o dos projetos, deixando em aberto vã rias das à reas que antecedem, sucedem ou os permeiam, e que dependendo das caracterã sticas do projeto sã o de extrema importã ncia para permitir sua entrega com o devido valor esperado. Este estudo destina a demostrar, atravã s de um estudo de caso em uma empresa com sede em Belo Horizonte, como o uso concomitante das tã cnicas de planejamento contidas no guia PMBOK com as tã cnicas do framework Scrum podem trazer benefã cios para os projetos dessa natureza visando aumentar a taxa de sucesso nesses empreendimentos. 2 REVISÃO DA LITERATURA 2.1 Gerenciamento de Projeto Um projeto à um empreendimento progressivo e nã o repetitivo, com inã cio e fim bem definimos para atingir um objetivo único ou especã fico, por exemplo a prestaã à o de um serviã o exclusivo ou criaã à o de um novo produto (PMI, 2008). Para Cruz (2013), o gerenciamento de projetos sã o tã cnicas, ferramentas, conhecimentos e habilidades aplicadas de forma coordenada e controlada visando atingir o objetivo do projeto durante sua existãªncia. Segundo Boyadjian (2012), o gerenciamento de projetos sã o tarefas prã ticas de carã ter operacional que sã o realizadas para que sejam atingidos os objetivos do projeto. Para que isto ocorra sã o necessã rias competãªncias nos grupos de processos de iniciaã à o, planejamento, execuã à o, monitoramento e controle e encerramento, assim como das à reas de conhecimento Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicaà ões, Riscos, Aquisià ões e Integraà à o. O manual de boas prã ticas aplicadas ao gerenciamento de projetos, o PMBOK, descreve o subconjunto de conhecimentos e boas prã ticas reconhecidos no gerenciamento de projetos (PMI, 2003). Ele funciona na maioria dos projetos e na maior parte do tempo, aumentando as chances de sucesso e reduzindo o problemas inerentes desse tipo de atividade, tornando-a mais eficaz e eficiente. (Cruz, 2013). Segundo o Guia PMBOK, (PMI, 2008), para o gerenciamento de projetos sã o estruturados cinco categorias de processos que integram e aplicam um total de 47 processos. Os grupos de processo agrupam atividades conforme a seguir:  * Grupo de processos de

2 iniciaã à o: tem o objetivo de realizar a definiã à o de um novo projeto ou fase com o foco principal na obtenã à o de autorizaã à o formal para iniciã -los. * Grupo de processos de planejamento: Sà o processos sugeridos para definiã à o do escopo, definindo objetivos e aã ões necessã rias para atingi-los afim de concluir o projeto com sucesso. * Grupo de processos de execuã à o: processos realizados para executar o que foi definido durante o planejamento do projeto para atender suas necessidades e especificaã ões. * Grupo de processos de monitoramento e controle: processos recomendados para acompanhar, monitorar e revisar o andamento e comportamento do projeto gerenciando mudanã as quando sã o necessã rias. * Grupo de processos de encerramento: processos realizados para o encerramento formal do projeto ou fase, objetivando finalizar todas as atividades de todos os grupos de processos. Os processos tambã m sã o divididos entre dez à reas de Conhecimentos que definem as disciplinas observadas e praticadas no gerenciamento de projetos (Cruz, 2013). Sendo elas: * Escopo: atividades que garantem que todo o trabalho necessã rio, seja incluã do para entrega com sucesso do projeto, assim evitando o trabalho desnecessã rio. * Tempo: atividades que contribuem para o gerenciamento do cronograma e entrega do projeto ou fase dentro do prazo acordado. * Custos: atividades que permitem terminar o projeto dentro do orã amento previsto, atravã s processos de estimativas, controle de custos e orã amento. * Qualidade: determinam objetivos, responsabilidades e polã ticas de qualidade para satisfazer necessidades requeridas pelo projeto. * Recursos Humanos: procedimentos para gerenciar e organizar pessoas definidas para concluir o projeto, nesse caso a equipe designada para realizar o projeto. * Comunicaà ões: garante que as partes interessadas apropriadas tenham informaã ões do projeto previamente geradas, coletadas, armazenadas, organizadas e recuperadas quando for necessã rio. * Riscos: atividades para planejar, identificar, analisar, responder, monitorar e controlar riscos que geram ameaã as ou oportunidades para o projeto. * Aquisià ões: inclui atividades necessã rias para compras ou aquisiã ões de produtos, serviã os ou aquisiã à o de resultados que sã o externos à equipe de projetos. * Integraà à o: atividades necessã rias para integraã à o e coordenaã à o de dos vã rios processos contidos nos grupos de processos de gerenciamento de projetos. * Partes Interessadas: inclui atividades necessã rias para identificar, gerenciar e monitorar as partes interessadas envolvidas no projeto. 2.2 SCRUM Scrum à um framework interativo e incremental para o planejamento, gerenciamento e desenvolvimento de projetos que visam a criaã à o de produtos complexos (SCHWABER, 2011). O Scrum nã o tem o objetivo de ser uma tã cnica ou processo para desenvolver produtos complexos, e sim um framework dentro do qual se pode empregar vã rios processos, tã cnicas, ferramentas e boas prã ticas como as contidas no Guia PMBOK. O Scrum adota uma abordagem empã rica onde todas as variã veis de um processo sã o conhecidas previamente e podem sofrer mudanã as ao longo do processo, com base na experiãªncia e conhecimento de quem as executa.â Três pilares sustentam e apoiam o processo empã rico de desenvolvimento: * Transparência: Aspectos relevantes do processo devem estar visã veis aos responsã veis pelos resultados. * Inspeà à o: Aspectos relevantes devem ser inspecionados com uma frequãªncia adequada para detectar desvios no processo. * Adaptaà à o: se uma inspeã à o detecta que uma variã vel do processo desviou do limite aceitã vel e esperado, deve-se adaptar o que for necessã rio para que nã o volte a ocorrer. De acordo com o guia do Scrum, Schawaber (2011) afirma que todo o processo do Scrum se estrutura em um processo interativo e incremental executado em ciclos denominados Sprints, que devem ter duraã à o de um mãªs ou menos. No inã cio de cada Sprint, o time Scrum escolhe e planeja, a partir de uma lista de prioridades chamada Product Backlog, um conjunto de tarefas a ser executado. A esse evento damos o nome de Planejamento da Sprint. Encerrada essa fase de planejamento os trabalhos de desenvolvimento se iniciam e os membros da equipe de desenvolvimento se reãºnem diariamente para ajustar as tarefas de toda a equipe para as

3 prã³ximas 24 horas em mais um evento chamado Daily Scrum ou Reunià o Dià ria. O Guia Scrum recomenda evitar alteraã ões das tarefas selecionadas para uma Sprint durante o ciclo (SCHWABER, 2011). Ao final de cada Sprint sã o realizadas mais duas reuniãµes chamadas respectivamente Revisà o e Retrospectiva da Sprint. Na revisã o da Sprint um incremento que foi produzido deve ser avaliado pelo Product Owner aceitando ou nã o o trabalho realizado e fazendo consideraã ões para a prã³ximaâ Sprint. A Retrospectiva da Sprint à o momento do Time Scrurm discutir e verificar o que deu certo ou errado e o que pode ser melhorado para a prã³xima Sprint. Na Figura 1 à possã vel visualizar as reuniãµes, papã is e artefatos do Scrum.  FIGURA 1 â Principais componentes do framework Scrum. Fonte: DEEMER, O Time Scrum à o responsã vel por realizar o seu ciclo conforme suas regras. Ele à composto por trãªs papã is denominados Scrum Master, Product Owner e Development Team ou simplesmente time (DEMMER, 2010). O Product Owner à quem faz o gerenciamento do backlog do produto, ou seja, determinar o que serã incluindo no produto e em que ordem, sempre buscando entregar o mã ximo de valor para o negã³cio. Segundo Schwaber (2011), o Scrum Master à o guardiã o do Scrum e deve garantir que a equipe esteja exercendo as prã ticas, regras e os valores do framework. Alà m de cuidar do time de desenvolvimento, garantindo que o time seja totalmente funcional e produtivo removendo os impedimentos que intervirem no trabalho tambã m deve auxiliar o Product Owner nas suas tarefas. O Time, por sua vez, à responsã vel implementar e entregar o produto pronto. Para isso ele deve ser multidisciplinar: possuir todo o conhecimento e habilidades necessã rias para desenvolver o produto. Individualmente os membros podem ter habilidades especializadas e à rea de especializaã à o, mas a responsabilidade pelo produto pertence ao time de desenvolvimento como um todo. O time à coletivamente responsã vel pelo sucesso de cada iteraã à o e do projeto como um todo (SUTHERLAND, 2012). 3 Desenvolvimento (Estudo de Caso) O mã todos à geis como o Scrum, baseando-se em um desenvolvimento interativo e incremental, com ciclos de interaã ões mais curtas e feedback constante dos clientes vieram como resposta as abordagens burocrã tica e lentas para os projetos tradicionais de software. Porà m mesmo em um ambiente à gil existe a necessidade de realizar processos do gerenciamento tradicional como as atividades de planejamento, para que seja garantidas formalizaã ões, comunicaã ões, controles e aã ões necessã rias e essenciais em qualquer tipo de projeto. Nesse contexto que entram o apoio das boas prã ticas e modelos de planejamento contidos no Guia PMBOK. O estudo de caso foi realizado em uma empresa que adota o Scrum para o desenvolvimento de seus produtos de software, mas que tem procurado o aperfeiã oamento das etapas de planejamento no gerenciamento de projetos atravã s das melhores prã ticas contidas no PMBOK. A empresa em questã o à uma empresa de consultoria, situada em Belo Horizonte, especializada em assessoria jurã dica, contã bil, fiscal, gestã o administrativa e financeira para segmento industrial e atacadista, que tambã m prove recursos em tecnologia da informaã à o. O projeto motivador desse trabalho foi a customizaã à o e implantaã à o de um software de automaã à o da forã a de vendas externas. A seguir serã o mostradas as adaptaã ões realizadas na empresa para viabilizar a planejamento do projeto atravã s das boas prã ticas do PMOK em consonã ncia com o Scrum. 3.1 Gerente de Projetos entra para o Time Scrum O guia PMBOK define o papel de gerente de projetos como sendo o responsã vel por uma sã rie de atividades de gerenciamento que visam atingir os objetivos de projeto. Para que essa abordagem fosse suportada foi necessã rio que o papel de gerente de projetos surgisse no contexto do framework Scrum, apoiando o Time Scrum nas à reas de planejamento do projeto. Ele passou a auxiliar antes mesmo do inã cio do ciclo do Scrum para atividades e iniciaã à o do projeto, prosseguindo com este apoio para atividades de gerenciamento do Backlog do produto

4 atã o planejamento da Sprint, tornando-se um papel extra ao Time Scrum. 3.2 Iniciando com a TAP Após a autorizaã à o do projeto o gerente de projetos deve formalizar seu inã cio, ou o inã cio de suas fases, atravã s do Termo de Abertura do Projeto ou Project Charter. Este documento registra as necessidades iniciais do projeto. No ambiente estudado alã m dasâ informaã ões bã sicas da TAP como tã tulo do projeto, objetivos, critã rios de sucesso, requisitos de alto nã vel, riscos iniciais, marcos, resumo do orã amento, gerente de projetos e nome e autoridade do patrocinador, tambã m foram incluã dos os papã is e responsabilidades do Time Scrum com o objetivo de definir para as partes interessadas um resumo de alto nã vel do o que e como seria realizado. Trata-se de uma documentaã à o que serviu para melhorar a transparãªncia do gerenciamento do Scrum atravã s datas de marcos, recursos, orã amento, riscos e requisitos, garantindo seguranã a ao Time para comparar o previsto com o realizado nas reuniãµes de revisã o das Sprints atravã s das entregas incrementais de um produto de software pronto. 3.3 Planejando o Gerenciamento do Projeto Para documentar as aã ões de planejamento escolhidas para projeto deste estudo foi necessã rio elaborar o Plano de Gerenciamento do Projeto, explicitando quais tã cnicas, ferramentas, atividades e prã ticas do PMBOK foram utilizadas em conjunto com o framework Scrum. O objetivo principal do Plano de Gerenciamento do Projeto foi divulgar para todos os envolvidos no projeto o ciclo de vida do projeto juntamente com o ciclo de execuã à o do Scrum, definindo como o trabalho seria feito atravã s das Sprints e como o gerenciamento deveria atuar nas mudanã as necessã rias, configuraã ões do projeto, requisitos do projeto e da divulgaã à o das comunicaã ões aos que dela necessitavam. Afim de obter um melhor planejamento do projeto antes do inã cio da sua execuã à o, visando os benefã cios esperados pelo uso das boas prã ticas do PMBOK atravã s do planejamento prã vio do projeto, o Time Scrum com apoio do Gerente de Projetos, executaram as atividades de planejamento do escopo, tempo, qualidade, comunicaã ões, riscos e partes interessadas Planejando o Escopo Para o planejamento do escopo do projeto deste estudo a equipe realizou os processos de coleta de requisitos e definiã à o do escopo do guia PMBOK, que na verdade sã o processos essenciais para qualquer projeto tipo de projeto. Porà m no Scrum sabemos que o processo de coleta e definiã à o de requisitos à de responsabilidade inicial do Product Owner, que deve criar o Backlog do Produto. O Backlog do Produto à um artefato vivo que à constantemente alterado e detalhado juntamente com Time Scrum durantes as Sprints, de acordo com a entrega de valor acordada com o cliente. As Sprints se adaptam muito bem ao conceito de ciclo de vida interativo e incremental em conjunto com o ciclo adaptativo descrito no Guia PMBOK, que permite que o projeto seja planejado e entregue em etapas, e queâ sofram mudanã as controladas em seu escopo com objetivo de gerar melhor valor para o cliente. Neste cenã rio apenas os requisitos que fazem parte da Sprint sã o detalhados, os demais devem ser entendidos de forma macro apenas para considerar seu impacto no projeto. Nesse trabalho inicial para criar Backlog do Produto o Product Owner envolvia o gerente de projetos para que por sua vez verificava possã veis atualizaã ões no plano do projeto e divulgava essas novas informaã ões as partes interessadas, fortalecendo a transparãªncia exigida no Scrum. Outro ponto que merecia atenã à o era que para iniciar uma Sprint se fazia necessã rio a existãªncia de um Backlog do Produto consistente com as necessidades do cliente. Porà m para que o Backlog do Produto tomasse uma forma inicial foi fundamental coletar os requisitos e definir o escopo do projeto. Um plano de escopo foi formalizado para definir como o escopo seria planejado durante o projeto definindo claramente as responsabilidades do Product Owner e do Time Scrum na definiã à o do escopo, como esse trabalho seria realizado antes e durante as reuniãµes do Scrum, como seria a documentaã à o do escopo atravã s do Backlog do Produto Planejando o Tempo Geralmente os projetos tem datas atreladas à entrega dos seus pacotes de trabalho ou o produto final em si. No estudo realizado foi utilizado o conceito de velocidade do Development Team para realizar o planejamento do cronograma e quantos ciclos seriam necessã rios para entregar o

5 escopo do projeto. Podemos traduzir de maneira simplificada a velocidade Development Team como a quantidade de atividades, previamente estimada, que à possã vel entregar dentro de uma Sprint. No Scrum, as Sprints tem normalmente entre duas a quatro semanas e as tarefas que sã o selecionadas para serem realizadas dentro da Sprint sã o denominadas Backlog da Sprint. Para saber o nãºmero adequado de tarefas ou atividades que deveriam ser selecionadas para o Backlog da Sprint foi necessã rio defini-las e estima-las, e uma vez que a Sprint inicia o Time Scrum passa a se preocupar com o restante do trabalho a ser realizado, atravã s de tã cnicas como o grã fico Burndown. As tã cnicas utilizadas para estimar as atividades foram a de pontos por estã³ria, opiniã o especializada, e estimativa bottom-up, que eram traduzidas em horas de trabalho. Ficou convencionado que na reuniã o de planejamento da Sprint a definiã à o das atividades seriam avaliadas usando Backlog do Produto priorizado e velocidade do time, o que permitiu saber quantas atividades comporiam o Backlog da Sprint. Esse trabalho era informado ao gerente de projeto que devia atualizar o plano de gerenciamento do projeto e tambã m permitia a montagem do cronograma. O gerente de projetos tambã m era responsã vel por formalizar como esse trabalho era feito definindo assim todo o planejamento do tempo do projeto Planejando a Qualidade O guia Scrum nos fala que este à um framework em que uma equipe lida com problemas complexos e adaptativos, de forma criativa e produtiva, desenvolvendo produtos com o mais alto valor possã vel (SCHWABER, 2011). Uma medida de alto valor de um produto ou serviã o sã³ pode ser dada se ele tiver qualidade, ou seja, satisfazer os requisitos para qual eles foram propostos. Em outras palavras um projeto satisfaz a qualidade quando ele à entregue em conformidade com seus requisitos atendendo as necessidades e expectativas do cliente. Ao executar esse processo foi possã vel identificar e formalizar um documento com os padrãµes de conformidade e qualidade esperados no projeto pelo cliente. Para isso o time discutiu com base nas informaã ões iniciais do projeto e seus ativos organizacionais, o que permitiu esclarecer para todos os envolvidos quais eram os padrãµes requeridos e como se pretendia atingi-los e como eles seriam medidos para posterior aprovaã à o do cliente. Mais uma vez foi demonstrado nesse documento como o Scrum apoiaria esses objetivos.â Toda a equipe participou desse processo com o intuito de registrar a visã o geral da qualidade, cerimã nias e a artefatos do Scrum utilizadas no gerenciamento da qualidade, papã is e responsabilidades, mã tricas e controle da qualidade Planejando as Comunicaà ões Segundo o Manifesto à gil, devemos focar mais em indivã duos e interaã ões mais que processos e ferramentas, colaborar com o cliente mais que negociar contratos e se adequar as mudanã as mais que seguir um plano. Isso deixa claro o papel que a comunicaã à o exerce nas metodologias à geis. Aqui entendemos que as prã ticas de comunicaã ões do PMBOK sã³ tem a agregar no Scrum ou qualquer outra metodologia à gil. Ficou decido no inã cio do projeto a utilizar esse processo para definir que informaã à o seria relevante para o projeto, como e de quem ela deveria ser coletada, como armazena-la e posteriormente como distribuã -la de forma eficaz as pessoas corretas durante o projeto. No final deste processo do PMBOK foi elaborado o Plano de Comunicaà ões onde ficou estabelecido para todas as partes interessadas como a comunicaã à o seria executada durante o projeto. Divulgados os mã todos, propã³sitos e objetivos de como ela se daria noâ framework Scrum atravã s do planejamento do Backlog do Produto, cerimonias de reuniãµes de planejamento, revisã o e retrospectiva da Sprint, reuniãµes diã rias e das tã cnicas à geis, que no caso da empresa em questã o utilizava o grã fico Burndown Planejando os Riscos Um dos pilares do Scrum à a inspeã à o. Esse conceito de inspeã à o foi crucial para engajar o time Scrum a realizar os processos de planejamento dos riscos do projeto. E podemos verificar no PMBOK que a maioria destes processos de se encontram na fase de planejamento. Um evento ou condiã à o incerta que, se ocorrer, causarã um efeito positivo ou negativo nos

6 objetivos de um projeto à a definiã à o de risco (PMI, 2013). No projeto deste estudo o gerente de projetos e o Time Scrum trabalham de forma conjunta para identificar, analisar e planejar respostas e controle para os riscos provã veis. No final deste processo foi elaborado o Plano de Riscos, que definiu como seriam abordadas as atividades de gerenciamento de riscos do projeto. No entanto, para que o Time Scrum e gerente de projetos chegassem à formalizaã à o desse documento foram realizadas reuniãµes com o objetivo exclusivo de planejar os riscos. Nessas reuniãµes foram extraã das informaã ões referentes aos riscos do projeto e foi explicitado como as do Scrum beneficiariam na identificaã à o e tratamento dos riscos uma vez que o processo de inspeã à o e adaptaã à o fazem parte das reuniãµes de planejamento, revisã o e retrospectiva da Sprint e das reuniãµes diã rias.â No plano de gerenciamento de riscos ficaram evidenciado, metodologias, papeis e responsabilidades, tipo do risco, probabilidade e impacto. Esse plano tambã m agregou outro pilar do Scrum que à a transparãªncia Planejando o Gerenciamento das Partes Interessadas Gerenciar as partes interessadas de um projeto à fundamental para qualquer tipo de abordagem, mesmo em ambientes à geis como o Scrum. Ao se preocupar com isso o gerente de projeto e o Time Scrum criaram formas para lidar com as partes interessadas, planejando e analisando como eles poderiam influenciar de forma positiva ou negativa no projeto. Desta forma, a criaã à o do plano de gerenciamento das partes interessadas permitiu visualizar meios de engajar as partes interessadas no projeto. Ao realizar o levantamento de caracterã sticas, influãªncia, poder e interesses, obteve-se um entendimento melhor sobreâ qual abordagem realizar com cada uma delas, focando no objetivo de gerenciar o impacto que eles poderiam ter no sucesso ou fracasso do projeto. Apesar do Time Scrum ter um ambiente fechado de envolvimento durante a execuã à o do ciclo do Scrum, o plano de gerenciamento das partes interessadas permitiu melhorar o relacionamento entre a equipe do projeto e as partes interessadas. Os benefã cios foram imediatos para o Product Owner e Scrum Master que puderam desempenhar melhor seus papeis ao ter conhecimento de estratã gias prã -estabelecidas sobre as partes interessadas do projeto com quem eles deveriam interagir. Tambà m foi possã vel mapear quais reuniãµes, ferramentas e informaã ões geradas pelo Scrum poderiam ser relevantes ou descartadas para as quais partes interessadas, quem teria a capacidade tã cnica de entender grã ficos e relatã³rios do Scrum e quais envolvidos deveriam participar de reuniãµes como por exemplo as Revisões da Sprint e quais nã o deveriam. 4 Conclusà o Este trabalho demonstrou que existe uma lacuna nas atividades de planejamento de projetos no framework à gil Scrum que tem um forte embasamento na execuã à o, e a importã ncia das atividades de planejamento, para que seja garantidas processos e aã ões necessã rias para o cumprimento dos objetivos dos projetos. Foi proposta a utilizaã ões de tã cnicas, processos e ferramentas do PMBOK voltados para o planejamento como um complemento ao Scrum. Concluiu-se que com o apoio das prã ticas de planejamento do PMBOK, que neste estudo resultou na elaboraã à o do plano de projeto contendo o planejamento das à reas de conhecimento de escopo, tempo, qualidade, comunicaã ões, riscos e partes interessadas, obteve-se uma contribuiã à o positiva que aumentou os valores de transparecia, inspeã à o e adaptaã à o do Scrum. A inclusã o do papel do Gerente de Projetos no Time Scrum, que trabalhou em parceira com Product Owner, Scrum Master e Development Team nas atividades que nã o estã o contempladas pelo framework, resultou em maior organizaã à o no planejamento do projeto. Os mã todos à geis valorizam mais o produto funcionando do que documentaã à o extensiva. Nesse ponto podemos analisar que a proposta deste estudo tende a burocratizar o planejamento do projetos em times Scrum. Apesar desse fato, identificou-se que estã documentaã à o do planejamento agregou valor junto ao cliente que pode ter um maior visibilidade do que seria realizado, aumentado a interaã à o com partes interessadas e aumentando o controle gerencial sobre o projeto. Nà o foi objetivo deste trabalho fazer cobertura total do assunto. Desta forma, sabe-se que ainda existe um grande espaã o para outras pesquisas a serem realizadas sobre este tema. Como

7 trabalhos futuros à possã vel dar continuidade na uniã o dos processos deâ execuã à o, controle e encerramento do PMBOK dentro de projetos que utilizam o framework Scrum. REFERÊNCIAS BOYADJIAN, Joà o C. e outros - Gestà o de Projetos Brasil - Conceitos e Tà cnicas. Belo Horizonte: IETEC, CRUZ, FABIO; Scrum e PMBOK Unidos no Gerenciamento de Projetos. 1. ed. Brasport: DEEMER, P.; BENEFIELD, G.; Scrum Primer Version Disponà vel em PROJECT Management Institute. Um Guia do conhecimento em gerenciamento de projetos: Guia Pmbok. 4. ed. Editora Saraiva: PMI, SCHWABER, K.; SUTHERLAND, J.; Um guia definitivo para o Scrum: As regras do jogo. Outubro de Disponà vel em