Olá amigos do PTI,
Neste artigo vou abordar um assunto considerado um tanto quanto polêmico no gerenciamento de projetos: Como o Scrum e o PMBOK podem andar juntos em um projeto.
Workshop – Scrum e o Gerenciamento de Projetos. Inscreva-se em bit.ly/1pe5zpE
Imagem via Shutterstock
Muitos consideram Scrum e PMBOK como coisas antagônicas, ou seja, seguir a filosofia de um significa ir totalmente contra a filosofia do outro. Existe muito xiitismo por defensores extremos de ambos os lados e, além do uso equivocado da palavra “metodologia”, é comum para justificar esta falta de aderência. Veja o diálogo abaixo:
– “Mas Vitor, a metodologia Scrum vai totalmente na contramão da metodologia PMBOK!!!”
– “Metodologia PMBOK? O que seria a metodologia PMBOK?”
– “É aquela metodologia do PMI que diz que um projeto tem que passar por 47 processos e todos eles muito bem documentados. Que projeto não permite mudanças e que devemos ter longas fases de iniciação e planejamento para depois começarmos a execução do projeto”
– “Vamos lá. Primeiro, o que você me descreveu é um projeto com abordagem Waterfall (“cascata”) utilizando metodologia RUP que exige muita documentação. Segundo, o PMBOK não é uma metodologia (leia mais neste artigo), e sim um conjunto de boas práticas sugeridas para serem utilizadas em um projeto. Se a metodologia implantada é pesada e burocrática a culpa é do gerente de projetos ou da organização, e não do coitado do PMBOK. Por fim, Scrum também não é uma metodologia e sim um framework”.
– “Mas Vitor, qual a diferença entre metodologia e framework?”
– “Encare a metodologia como uma receita de bolo, ela te diz o que fazer e como fazer. Você deve seguir na risca o que está escrito. Agora encare o framework como uma partida de futebol: existem regras, diretrizes e uma meta: fazer o gol. Agora como os jogadores irão fazer o gol vai depender do talento dos jogadores dentro das regras, diretrizes e metas existentes.”
De acordo com o PMBOK todo o projeto possui cinco grupos de processos dentro de um projeto: Iniciação, Planejamento, Execução, Monitoramento e Controle e Encerramento. Agora vamos traçar um paralelo com o Scrum:
Iniciação – Todo o projeto precisa ter um objetivo e uma justificativa (seja de negócio ou regulamentar) para ser feito. No PMBOK falamos que é o Business Case e o Project Charter. No Agile chamamos isso de Visão do Produto.
Planejamento – O PMBOK diz que todo projeto precisa ter seu escopo, tempo e custo planejados. No Agile o escopo do produto é feito através do Product Backlog e o escopo de cada Sprint (ou iteração no PMBOK) é feito através do Sprint Backlog, a estimativa de prazo do projeto é determinada através do Release Plan (seja via Planning Poker ou Ideal Days). O custo é uma consequência do escopo x prazo x recursos.
Execução – O PMBOK diz que precisamos identificar e gerenciar as expectativas dos stakeholders (partes interessadas), gerenciar os recursos humanos do projeto (através de motivação, treinamento, coaching), garantir qualidade e comunicar as informações do projeto. No Agile temos Product Owner como a “voz do cliente” captando as necessidades e expectativas dos stakeholders, o Scrum Master como o grande líder servidor e coach da equipe, a qualidade sendo inspecionada diariamente através do Daily Scrum e a comunicação do projeto sempre disponível através dos relatórios BurnUp/BurnDown.
Monitoramento e Controle – O PMBOK diz que precisamos monitorar escopo, tempo, custos, qualidade e riscos. No Agile sempre tempos o Product Owner constantemente revisando o Product Backlog (Product Backlog Refinement ou “Grooming”), monitorando e revisando o prazo no Release Plan através do Release Burndown, qualidade e riscos sempre identificados nas cerimônias diárias (Daily Scrum), de demonstração (Sprint Review) e de lições aprendidas (Sprint Retrospective). O PMBOK diz que todo o escopo deve ser validado, no Scrum isto é feito na Sprint Review!
Encerramento – No PMBOK a grande ênfase do encerramento, além do arquivamento dos documentos do projeto, é nas lições aprendidas. E no Scrum temos isso fortemente disseminado na retrospectiva da iteração (Sprint Retrospective).
Então perceba que de forma intuitiva você já utiliza as boas práticas do PMBOK em seus projetos executados com Scrum!
– “Mas Vitor, o PMBOK fala muito da figura do Gerente de Projeto! Quem representa esta figura no Scrum? O Scrum Master?”
– “Depende! Depende do cenário do seu projeto, da estrutura organizacional da sua empresa, do poder e autonomia que o Scrum Master possui fora da equipe”
– “Tá bom Vitor, mas e aí? Se não é o Scrum Master quem representa o Gerente de Projeto?”
– “Ora, o próprio Gerente de Projeto!”
– “Mas como assim, li em uma revista famosa um artigo de um agilista que disse que nunca existe Gerente de Projetos no Scrum!”
– “Bom, se você levar ao pé-da-letra o que está escrito num guia de 10 páginas (Scrum Guide) você tem razão! Trazendo isso para o mundo real, nem sempre é uma verdade!”
O assunto de Gerente de Projeto no Scrum é um muito controverso e já o abordei anteriormente neste artigo.
– “Tá bom Vitor, e na prática? Quero ver isso na prática!”
– “Te convido a assistir o Workshop online e ao vivo “Scrum e o Gerenciamento de Projetos” organizado pela Hiflex Consultoria e o PTI. Inscreva-se agora mesmo em bit.ly/1pe5zpE”
Ao invés de buscar diferenças e antagonismos, aprenda a utilizar o melhor de sua “caixa de ferramentas” de gerenciamento!
Abraços e até o próximo artigo
3 Comentários
Discordo quando você diz que uma metodologia é uma receita de bolo e que deve ser seguida a risca, ela tem como objetivo captar e analisar as características dos vários métodos indispensáveis, avaliar suas capacidades, potencialidades, limitações ou distorções e criticar os pressupostos ou as implicações de sua utilização.
Logo uma metodologia sofre sim alterações, aperfeiçoamentos, adaptações, e isso é fundamental para o processo de desenvolvimento.
Você disse:
Agora encare o framework como uma partida de futebol: existem regras, diretrizes e uma meta: fazer o gol. Agora como os jogadores irão fazer o gol vai depender do talento dos jogadores dentro das regras, diretrizes e metas existentes.”
Eu prefiro acreditar que o FRAMEWORK é o esquema tático, mesmo havendo um padrão, um objetivo e uma meta ele pode alterar conforme o o talento da equipe podendo estar fortemente influenciado pela metodologia aplicada!
Caro Adilson,
Dando continuidade ao trecho onde você menciona: “ela (metodologia) tem como objetivo captar e analisar as características dos vários métodos indispensáveis, avaliar suas capacidades, potencialidades, limitações ou distorções e criticar os pressupostos ou as implicações de sua utilização”, trecho este idêntico à descrição de Metodologia que consta no Wikipedia (http://pt.wikipedia.org/wiki/Metodologia), podemos verificar que: “A Metodologia é a explicação minuciosa, detalhada, rigorosa e exata de toda ação desenvolvida no método (caminho) do trabalho de pesquisa. É a explicação do tipo de pesquisa, dos instrumentos utilizados (questionário, entrevista etc), do tempo previsto, da equipe de pesquisadores e da divisão do trabalho, das formas de tabulação e tratamento dos dados, enfim, de tudo aquilo que se utilizou no trabalho de pesquisa”.
Por esta razão é que o PMBOK jamais deve ser encarado como metodologia, pois não representa a “regra minunciosa, detalhada, rigorosa e exata” a ser aplicada no gerenciamento de projetos.
Com relação ao Framework, seguindo seu exemplo e recorrendo ao Wikipedia, podemos constatar que: “Em administração, um framework é uma estrutura conceitual básica que permite o manuseio homogêneo de diferentes objetos de negócio. Serve para incrementar a disciplina de gestão e predefinir entregáveis comuns de e para cada objeto de negócio.
Pode ser visto também como uma tática bem definida para manipular com destreza ambientes organizacionais complexos. Um framework deve prover sugestões de solução para uma família de problemas semelhantes.”, onde podemos fazer a analogia entre “tática bem definida” com os jogadores de futebol e os “ambientes organizacionais complexos” com a partida de futebol em si e suas regras.
Porém muito mais importante do que revisar conceitos teóricos dos termos, é entendê-los na prática e a falha deste entendimento é, ao meu ver, uma das grandes causas de gestões de projetos que beiram a catástrofe.
Caro Vitor,
Seus comentarios sao plausiveis a respeito Scrum e PMBOOK. Tendo em vista aos metodos utiliados para a execução do projeto.