Como unir PMBOK e Scrum

Facilmente se ouve falar em gerenciamento de projetos hoje em dia, e muito se discute sobre gerenciamento ágil, ou Waterfall, mais conhecido como gerenciamento tradicional.

Muitos defendem que o uso do Ágil é a melhor solução, principalmente na área de tecnologia, e outros afirmam que o Waterfall funciona para qualquer projeto, e é muito mais seguro.

Já um terceiro grupo diz que os dois anteriores estão certos, e ao mesmo tempo também não estão. Por que um ambiente de projeto é muito mais complexo do que um modelo padrão, ou um conjunto de boas práticas, e o gerente de projetos precisa usar a inteligência para enxergar o que é melhor em cada momento da sua gestão.

Seguindo esta terceira linha, o ágil não é melhor do que o Waterfall, e muito menos o inverso é verdade. Nesta visão, a união dos dois traz mais força à equipe de gerenciamento de um projeto, e a crença de que só um pode resolver todos os problemas pode ser um grande risco.

A partir do pensamento que a junção de modelos é uma estratégia que pode dar melhores resultados do que o uso isolado de apenas um. Este artigo se propõe a mostrar como unir dois fortes modelos de gerenciamento de projetos do mundo moderno, o Guia PMBOK e o Scrum.

O Guia PMBOK é um dos conjuntos de boas práticas de gerenciamento de projetos tradicional mais conhecido e utilizado no mundo todo, porém muitos dizem que ele não é tão útil para projetos dinâmicos e imprevisíveis como os da tecnologia da informação.

O Scrum, por sua vez, é um dos frameworks de gerenciamento de projetos ágeis mais difundidos e aplicados nos dias atuais, além de ser mundialmente conhecido e usado na área da tecnologia da informação, principalmente em desenvolvimento de softwares. Porém, muitos dizem que ele não é seguro para projetos grandes ou fora da área de desenvolvimento de sistemas.

Buscando tirar vantagem dos pontos positivos de cada um destes modelos, e balancear os pontos negativos de um com as qualidades do outro, este artigo ilustrará como unir os dois em prol do sucesso de um mesmo projeto. Além disso, será mostrado como cada área de conhecimento e cada fase de um projeto podem ser apoiadas por esta união, e onde cada ferramenta e técnica do PMBOK e do Scrum poderão ser usadas com o objetivo de fortalecer a gestão de um projeto.

Pela ótica do Scrum

O Scrum tem um modelo mais simplificado e menor que o Guia PMBOK, por isso é mais fácil acompanhar a aplicação das boas práticas do Guia PMBOK a partir do ciclo do Scrum, e entender como encaixar e utilizar os processos do Guia PMBOK dentro do Scrum.

Em outras palavras, podemos dizer que rodando o Scrum podemos sentir exatamente onde os processos do Guia PMBOK podem ser encaixados na rotina do Scrum, formando apenas uma metodologia unificada de três formas distintas: internamente ao Ciclo do Scrum, externamente ao Ciclo do Scrum e paralelamente ao Ciclo do Scrum.

Especificamente para este artigo, será utilizada uma lista de legendas para facilitar o entendimento e mapeamento dos papéis, responsabilidades e atividades de cada grupo de processo. Esta terá o objetivo de contribuir para uma melhor assimilação de quais momentos serão realizadas as cerimônias do Scrum, os processos do Guia PMBOK e quem é o responsável por cada execução.

A seguir, listamos as legendas para identificação e distinção dos grupos de processos:

• [GP]: Atividades realizadas pelo gerente de projetos. Visão PMBOK;
• [PO]: Atividades realizadas pelo Product Owner. Visão Scrum;
• [SM]: Atividades realizadas pelo Scrum Master. Visão Scrum;
• [TM]: Atividades realizadas pelo Time. Visão combinada Scrum e PMBOK;
• [DC]: Atividades contidas dentro do ciclo Scrum, ou seja, realizadas durante as cerimônias do Scrum;
• [FC]: Atividades fora do ciclo Scrum, ou seja, não serão realizadas durante as cerimônias ágeis, mas paralelamente a elas e normalmente realizadas por um papel fora do conceito Scrum, tal como o gerente de projetos;
• [1..42]: Para referência, será colocado ao lado dos processos do Guia PMBOK um número para identificar que o processo pertence ao mesmo e para que ao final deste artigo se tenha uma ideia de quantos processos conseguem ser trabalhados em conjunto com o Scrum.

Observação: A maioria dos processos terá mais de um papel responsável, por exemplo [GP] e [PO]. Quando isso ocorrer, a ordem em que os papéis aparecerem nos processos representará a importância e grau de responsabilidade, ou seja, no exemplo acima o papel mais importante e com maior responsabilidade sobre a execução do mesmo seria o do gerente de projeto.

Este artigo não se propõe a detalhar, explicar ou ensinar o que é, como é composto, e como pode ser aplicado o Scrum ou o Guia PMBOK. Para este artigo o autor considera que os leitores conhecem e já possuem uma experiência com a aplicação de ambos.

O objetivo principal aqui é apresentar uma forma de unir o Scrum ao Guia PMBOK, aplicando cada um em um ponto específico de um mesmo projeto, evidenciando as maiores forças de cada um, e ao mesmo tempo apoiando as fraquezas do outro.

Ciclo de vida Scrum

Há mais de uma abordagem para união das técnicas, ferramentas e papéis do Guia PMBOK com o Scrum. Porém, aqui partiremos do entendimento que o Scrum é mais simples e possui um ciclo menor e mais fácil de acompanhar.

Com isso, o objetivo é visualizar o Scrum sendo aplicado, e principalmente rodando segundo suas regras, e encaixar o Guia PMBOK conforme o Scrum acontece, porém, para o ciclo do Scrum iniciar é preciso que alguns processos sejam executados antes, bem como outros depois do seu término.

Reforçando o entendimento, para um time começar a rodar o Scrum em um projeto, atividades anteriores contidas no Guia PMBOK precisam ser realizadas. Durante a execução do Scrum e de suas várias cerimônias, outras atividades do Guia PMBOK devem ser aplicadas, e por fim, após o encerramento de um ciclo Scrum, mais tarefas ligadas ao Guia PMBOK também podem ser utilizadas.

Será possível visualizar como é fácil e benéfico unir estas duas práticas, principalmente porque algumas das ferramentas e técnicas do Guia PMBOK se encaixarão perfeitamente dentro do ciclo Scrum, e outras farão total sentido fornecendo pleno apoio à equipe de gerenciamento quando utilizadas paralelamente ao Scrum.

Ainda com esta união, poderá ser respondida uma pergunta que muitos ainda se fazem sobre qual o papel do gerente de projetos com a chegada das metodologias ágeis, e até mesmo para que continuar utilizando o gerenciamento Waterfall quando o ágil fornece quase tudo que é preciso.

A proposta deste artigo é mostrar justamente o quanto é importante não deixar de lado o gerenciamento Waterfall mesmo em ambientes ágeis. Quando pensamos em gerenciamento ágil, visualizamos a execução de um projeto tirando um pouco do foco dos outros grupos de processos, e não prevendo o controle de áreas como custos, aquisições, riscos e outras.

É a partir deste momento que o gerente de projetos entra em um ambiente ágil, sem interferir na execução propriamente dita do Scrum, mas apoiando todas as outras áreas que o Scrum não suporta diretamente.

Início do projeto

Mesmo em um ambiente ágil é preciso realizar algumas atividades formais, principalmente para registrar certas passagens importantes do projeto, como a oficialização do seu início.

A maioria dos médios e grandes clientes aceita bem a implantação de metodologias ágeis, mas não abre mão de processos contidos no gerenciamento tradicional, principalmente no que diz respeito a formalizações, controles de alto nível para visão da gerência sênior, incluindo alternativas para garantir legalmente que certas ações são realizadas e outras não. Por isso precisamos do apoio de boas práticas e modelos mais tradicionais como o Guia PMBOK.

Seguindo o mesmo princípio não podemos nos iludir que o gerenciamento ágil puro irá resolver tudo e será plenamente aceito como metodologia de gestão, e precisamos levar em conta sim, a aplicação de ferramentas e técnicas do gerenciamento tradicional, como as contidas no Guia PMBOK.

As primeiras formalizações acontecem antes do início do projeto, e continuam durante a etapa de iniciação. Dessa maneira, abaixo começaremos a listar os processos da fase de iniciação de um projeto, e desta mesma maneira continuaremos a listar todos os processos que precisam ser realizados durante todo o projeto, separados por etapa ou fases do projeto.

Termo de Abertura do Projeto [1]

O termo de abertura do projeto formaliza oficialmente o início do mesmo, permitindo e liberando a equipe para começar os trabalhos, e independente do ambiente do projeto, é altamente recomendável se publicar um termo de abertura do projeto que contenha pelo menos o seguinte conteúdo:

1. Propósito ou justificativa do projeto;
2. Requisitos de alto nível;
3. Riscos de alto nível;
4. Resumo do cronograma de marcos;
5. Resumo do orçamento;
6. Requisitos para aprovação do projeto e quem é responsável por decidir se o projeto é bem sucedido ou não;
...
Quer ler esse conteúdo completo? Tenha acesso completo