mas então… PMBOK® e Scrum, qual é a diferença?

Olá Pessoas,

Antes de mais nada eu gostaria de agradecer o WordPress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Em certa ocasião fui perguntado sobre a diferença (na minha opinião) entre o PMBOK® e o Scrum. Confesso que na hora tive um certa dificuldade em encontrar a melhor resposta de forma sucinta, clara e objetiva, pois a ocasião, tratava-se de uma exigente entrevista de emprego, para atuar como Agile Project Manager em uma multinacional norte-americana; e naquele momento, confessadamente, não estava muito confortável com a situação.

Nota: naquele ambiente encontravam-se 6 “entrevistadores” e eu — sem advogado — e todos eles estavam sedentos por extrair todas as informações que os convencessem de que eu era uma boa escolha… fato é que hoje posso dizer que ao menos uma vez na vida, me senti como se estivesse no programa Roda Viva da TV Cultura.

Contudo, e independente do desfecho da referida entrevista, respondo novamente esta pergunta aqui no blog (debruçado no macio e iluminado teclado do meu laptop, gozando da tranquilidade do meu lar…) :mrgreen:

Em primeiro lugar precisamos entender o que é esse tal de PMBOK® e o que é esse tal de Scrum…

 

O PMBOK® é um guia (leia-se livro) que contém uma série de boas práticas, (processos, ferramentas e técnicas) que, uma vez aplicadas no gerenciamento de um projeto, reduzem-se drasticamente suas chances de insucesso.

“Ah mas pra qual tipo de projeto?” — Qualquer tipo de projeto. – TI, construção civil, engenharia, indústria naval, aerospacial, automobilística… enfim, qualquer tipo de projeto.

Importante: Pronuncia-se “PMBÓK” (acento agudo no ó) e não “PMBUK”. — O PMBOK® é um acrônimo que significa Project Management Body of Knowledge, portanto é errado concluir que o BOK refere-se a livro em inglês. (livro = Book)

O Scrum é um framework, ou seja, um modelo que inicialmente foi idealizado para gerenciar a construção de produtos complexos, imersos em ambientes complexos. O Scrum Guide — o corpo de conhecimento do framework Scrum — possui cerca de 18 páginas (bem diferente das cerca de 600 páginas contidas no Guia PMBOK®) e nele estão descritas todas as regras, papéis, artefatos e eventos que compõem o framework.

Exposto isso, posso agora refletir sobre as diferenças que entendo ter as duas abordagens. 😛

PMBOK®

  1. Aplicável no gerenciamento de qualquer tipo e tamanho de projeto;
  2. Mais adequado para projetos de grande porte (Ex.: projetos com custo acima de 1 milhão, stakeholders em diferentes partes do mundo e etc). O que quero dizer é que em projetos com essas características, aplicam-se mais técnicas, ferramentas e processos contidos no PMBOK®, do que em projetos menores;
  3. Foco no planejamento, a fim de se prever riscos e evitar mudanças excessivas no plano do projeto;
  4. Centraliza sobre o gerente do projeto, alto grau de “responsabilização” pelo sucesso ou fracasso do projeto;
  5. Recomenda fortemente que o gerente de projeto, monitore e controle de perto o projeto, possibilitando ações corretivas, com o objetivo de se evitar desvios nas linhas de base (escopo, custo e prazo);
  6. Necessita de maior (comando e) controle.

Scrum

  1. Aplicável para projetos de desenvolvimento de softwares, embora já existam movimentos no sentido de se aplicar Scrum em projetos de outras naturezas;
  2. Pode e deve ser aplicado em projetos de desenvolvimento de softwares de qualquer tamanho, porte e nível de complexidade;
  3. Foco na entrega de valor, planeja-se apenas o suficiente (no máximo duas ou três sprints) e responde melhor a mudanças;
  4. Pulveriza a responsabilidade pelo sucesso ou pelo fracasso do projeto por todo o Time Scrum (PO, Scrum Master e Time de Desenvolvimento);
  5. Utiliza fortemente seus pilares; transparência, inspeção e adaptação, para corrigir desvios no projeto. Isso é feito diariamente por todos os envolvidos (Time Scrum), e não por apenas uma pessoa;
  6. Estimula um ambiente mais colaborativo;
  7. Depende menos de gestão, e mais de auto-organização.

Conclusão

Temos hoje uma imensa gama de frameworks, guias e métodos e etc… cada qual com suas características, especificidades, vantagens e desvantagens. Nenhuma delas, porém, é panaceia. Devemos, para se obter sucesso nos nosso projetos, adequá-los as nossas necessidades, extrair e por em pratica o melhor de cada uma deles.

E sempre devemos nos lembrar que:

Todas os modelos são bons… entretanto, para se obter o máximo de proveito e benefício, é preciso ter muito comprometimento, profissionalismo e disciplina! 😉

Saudações. Ψ

Deixe um comentário