Este é um assunto no mínimo polêmico, pois muitos enxergam o Scrum e o PMBOK como coisas antagônicas. Na verdade, o que deve ser compreendido é que o PMBOK é um guia de boas práticas e o Scrum um framework, que nem sempre cobre todas as variáveis de um projeto.
O time Scrum é auto-organizado no que diz respeito a execução e aos seguintes itens de planejamento e monitoramento:
- Escopo (através do Product Backlog)
- Atividades (através do Sprint Backlog)
- Tempo (através do Iteration e Release Planning)
- Comunicação (através do Kanban e relatórios burndown)
- Expectativas dos Stakeholders (este é o item que mais me preocupa e que vivencio na prática, pois dependendo do tamanho do projeto e quantidade de stakeholders, o Product Owner pode ficar sobrecarregado, deixando de focar no que realmente é esperado dele – priorizar os requisitos, garantir valor agregado/ROI do requisitos e estar “corpo-a-corpo” com o Time Dev)
Mas, independente do framework utilizado, o projeto pode conter outros itens de planejamento e monitoramento, tais como:
- Custos
- Contratos
- Aquisições
- Formação de equipe (principalmente em estruturas matriciais)
Entendo que a gestão destes 4 itens não deva ser responsabilidade nem do Product Owner, nem do Scrum Master e muito menos do Time Dev.
Neste caso, um Gerente de Projetos é muito bem vindo, mas lembrando que seu papel deve ser suportivo e não controlador com relação ao Time Scrum (que é auto-organizado e gerencia os itens mencionados no início deste comentário).
Exemplo real de Scrum na execução e PMBOK na governança de um projeto
Em projetos cujo foco engloba apenas os itens de planejamento e execução cobertos pelo Scrum, sem sobrecarregar nenhum papel, não é necessário a figura do Gerente de Projetos.
A questão aqui não é ser PMBOK ou Scrum, agiilista ou não agilista, e sim considerar o melhor de cada abordagem (como uma caixa de ferramentas) e utilizá-las visando atingir sucesso nos projetos.
Lembrando que esta não é a verdade absoluta e sim minha visão pessoal sobre o assunto.
Abraços e até a próxima
7 Comentários
Compartilho suas idéias a respeito deste estado de rivalidade entre estes modelos. Tudo o que pode agregar de valor, facilitando nosso arduo”lavoro” vejo com muito bons olhos !
Abs
Edner
Entendo que as duas se complementam.
Tenho visto vários GPs exercendo também a função de Scrum Master, pois como você apresentou acima existem algumas funções que são de responsabilidade do GP (status report, controle de custo, prazo etc).
Eu tenho batido muito na tecla que você colocou no seu texto “o PMBOK é um guia de boas práticas e o Scrum um framework, que nem sempre cobre todas as variáveis de um projeto.”, mas vejo que muitos admiradores e seguidores do scrum ainda não entenderam.
Abraços
Alexandre Marques
Ótimo post e tudo a ver com a realidade!
Abraços Vitor!
Ótimo post, Vitor. Compartilho da mesma opinião.
Sou agilista e atuo como GP na equipe de uma forma muito parecida com a que descrevestes. Conheço o PMBOK na prática, aplico algumas áreas em especial de monitoramento, e muito também de CMMI e MPS.BR (já ajudei várias empresas a implantarem), e sabe que eu vejo que todos esses mundos se complementam.
Não tem um melhor que o outro, e só critica ou escolhe “a bala de prata” quem não domina ainda. Até porque não existe nenhuma solução estanque e nosso mundo de TI está em constante evolução – nada mais lógico que abrirmos nossa cabeça para evoluirmos também nosso modus operandi.
Obrigada!
Olá Priscila !
Muito obrigado pelo feedback !
É muito bom saber que essa filosofia é bem sucedida em outras empresas e experiências !
Abs.
Vitor Massari
Vitor,
Legal o artigo. Entretanto, me aventurei a fazer um pequeno estudo a respeito de qual seria o papel do GP em uma ambiente Scrum. Nesta minha proposta, procurei integrar PRINCE2, Scrum e FDD, e suponho que o GP teria o papel do dono do produto, pois ele tem funções mais “administrativas” em relação ao projeto quando olhamos para o PRINCE2 ou para o PMBOK.
Caso queria conferir o que escrevi, segue o link para o artigo. O quadro comparativo está na página 6, na seção “3.1 Relacionamento entre os papéis e responsabilidades”.
https://drive.google.com/file/d/0B7FLLhEiyJf1U3REd21MUWh0NlU/view?pli=1
Claro que, por se tratar de uma proposta, também é passível de críticas, melhorias e reavaliações, se são bem vindas para complementar o debate proposto pela sua postagem.
Obrigado pela atenção,
Hector Dufau
Olá Hector,
Muito bom o seu material! Obrigado por compartilhar!
Eu só tenho um pouco de restrição com o GP fazendo o papel de PO dentro do Scrum.
Vejo vantagens e desvantagens, mas particularmente não gosto.
Vantagens:
? Ser um Gerente de Projeto alinhado com o Triângulo de Talentos do PMI e usar seu conhecimento de estratégia de negócios para definir os requisitos do produto;
? Conhecer bem os custos envolvidos no projeto e definir uma boa estratégia para obtenção do ROI (Return Of Investiment – Retorno sobre o investimento);
? Gerenciar de forma adequada as necessidades e expectativas dos stakeholders do projeto.
Desvantagens:
? Ser um Gerente de Projeto que acredita na filosofia de que um bom Gerente de Projeto só deve “cobrar, cobrar e cobrar”;
? Sofrer sobrecarga de atribuições, tendo que gerenciar diversas áreas de conhecimento do projeto complementares ao Scrum (integração, stakeholders, aquisições, custos, recursos humanos), trabalhar constantemente no refinamento do Product Backlog e interagir frequentemente com a Equipe de Desenvolvimento para o esclarecimento de dúvidas e reuniões de planejamento, revisão e retrospectiva da Sprint;
? Pode existir conflito de papéis, uma vez que o Product Owner tem interesse no produto disponibilizado rapidamente e o Gerente de Projeto deve blindar a Equipe Scrum contra possíveis atitudes que visam acelerar a Equipe de Desenvolvimento, desrespeitando sua capacidade/velocidade.
Um grande abraço,
Vitor Massari