Gestão de Projetos: Combinação entre PMBOK e Scrum

Para a obtenção dos resultados, foram analisadas obras de autores clássicos e contemporâneos. Os resultados apontaram vantagens quanto à combinação dos dois métodos estudados, visando o ganho de desempenho e eficiência à partir da união de técnicas de gestão e execução de projetos. Palavras-chave: Gestão de Projetos, PMBOK, Scrum, Junção de PMBOK e Scrum. Introdução Nunca houve um consenso muito claro acerca da combinação entre o PMBOK e o Scrum. Isso porque muitos gestores acreditam que devem, necessariamente, optar por um dos dois. Já o PMBOK trabalha, sobretudo, com riscos, admite a priorização de entregas e a realização de ciclos de entregas (planejamento em ondas sucessivas). PMBOK x Scrum O Scrum pode ser mais recomendado para projetos complexos, porque não há determinação exaustiva de processos a serem seguidos para que a equipe possa chegar aos objetivos do projeto.

Ou seja, o Scrum propõe apenas algumas etapas que fornecem uma base para que outros processos sejam realizados, fazendo com que o projeto tenha sucesso para a organização e agregando valor de negócio. Resumindo, projetos não tão simples, envolvendo processos empíricos são um ambiente ideal para a experimentação e adaptação de processos no Scrum — assim os objetivos do projeto, mesmo que definidos de maneira incremental, são atingidos. Por outro lado, o PMBOK é mais apropriado para projetos com um menor nível de complexidade. Comparativo PMBOK e Scrum Sempre houve muita polêmica entre os “partidários” do PMBOK e Scrum, muitos acreditam precisar optar, mas as diferenças começam no entendimento da natureza distinta, mas não excludente que os permeia.

O PMBOK é um guia de boas práticas, dividido em grupos e processos: • a) Já o Scrum é um framework (estrutura) com cerimônias, artefatos e papéis definidos; • b) Como comparar um guia a uma estrutura? Sendo uma estrutura, o Scrum permite adições e exclusões, desde que não interfiram em seus 3 princípios: Transparência, Inspeção e Adaptação. Desse modo, pode-se dizer que tecnicamente seria possível adicionar processos adaptados do PMBOK ao Scrum, mas vale a pena? O Scrum se adapta mais a projetos cujo escopo é mutável e/ou parcialmente desconhecido. No PMBOK não conhecer o escopo (ou pelo menos parte dele) inviabiliza o planejamento e assim, a execução do projeto. O Scrum aceita incertezas, trabalha com priorizações (valores de negócio) e ciclos curtos de entregas.

Execução O PMBOK estabelece que é preciso identificar e gerenciar as expectativas das partes interessadas, gerenciar os recursos humanos do projeto, assegurar a qualidade e compartilhar as informações do projeto. O Agile tem os Product Owner como “representantes do cliente”, sensibilizando-se com as necessidades e expectativas dos stakeholders, o Scrum Master como o grande líder servidor e coach do time, a qualidade sendo validada através do Daily Scrum e a tramitação de informação do projeto sempre disponível através dos relatórios BurnUp/BurnDown. Monitoramento e Controle O PMBOK cita o monitoramento do escopo, tempo, custos, qualidade e riscos. No Scrum, há a figura do Product Owner revisando sempre o Product Backlog (Product Backlog Refinement ou “Grooming”), monitorando e revisando o prazo no Release Plan, por meio do Release Burndown, qualidade e riscos identificados sempre por intermédio das cerimônias diárias (Daily Scrum), de demonstração (Sprint Review) e de lições aprendidas (Sprint Retrospective).

O PMBOK afirma que o escopo precisa ser validado, no Scrum isso é realizado na Sprint Review. A Figura1 apresenta o atendimento percentual de cada uma das nove Área de Conhecimento, ficando clara a ausência de processos para tratativa de Custos, Riscos e Aquisições no Scrum e a forte ênfase em Integração, Escopo, Tempo e Recursos Humanos. Para a área de Riscos foi considerado 1 ponto, referente ao “Mapeamento de Impedimentos” (prática diária de responsabilidade do Scrum Master), pois se a equipe levantar os impedimentos com antecedência, pode-se evitar problemas, uma forma “primitiva” de gerenciamento de riscos. No entanto, acredito que certas características do Scrum previnem problemas comuns e isso seria uma forma de gerenciamento de riscos (I. E. Sprints com tempo pré-definido, revisões de entregas, reuniões de retrospectiva, ter um SPOC2, ter um plano de comunicação etc).

Test Driven Development: Teste e Design no Mundo Real. São Paulo: Casa do Código. ARANHA, E. H. BORBA, P. BECK, K. Test-Driven Development: By Example. Boston: Addison-Wesley Professional. BERNARDO, P. C. Software Engneering. Manuscript received June 24, 1976; revised August 16, 1976. Disponível em: < http://csse. usc. edu/TECHRPTS/1976/usccse76-500/usccse76-500. Refatoração: Aperfeiçoando o Projeto de Código Existente (tradução autorizada). Porto Alegre: Artmed. GEORGE, B. WILLIAMS, L. An Initial Investigation of Test Driven Development in Industry. F. Agile: Desenvolvimento de software com entregas frequentes. São Paulo: Casa do Código. LARMAN, C. BASILI, V. researchgate. net/publication/228658128_Cost_effective_software_test_metrics>. Acesso em: 06 de março de 2018.