Seções iMasters
Agile + Gerência de Projetos

Agile e PMBoK: é possível unir ambos?

Um representa o modelo tradicional, pautado no conceito waterfall. O outro representa inovação e o valor às pessoas. Os mais tradicionais defendem o primeiro. A Geração Y é “fanática” pelo segundo. Estamos falando do PMBoK e do Agile, tão diferentes e tão próximos. Neste artigo, entenderemos o porquê.

Observação: O pré-requisito para leitura deste artigo é o conhecimento prévio dos conceitos básicos do PMBoK e de métodos ágeis.

Motivação para o artigo

Já venho pensando em escrever um artigo sobre esses dois mundos há muito tempo. A principal motivação é justamente por comentários absurdos que leio pela Internet, em que de um lado os PMPs se acham os inventores da roda e, de outro, os agilistas se sentem os defensores de uma causa milagrosa, capaz de transformar qualquer projeto fracassado em sucesso.

O ponto chave que me levou a escrever este pequeno texto foi um excelente artigo do Marcelo Zeferino, publicado na revista MundoJ (número 46), entitulado “Agile e PMBoK: Unindo dois mundos para otimizar um projeto”.

Na publicação, o autor aborda um caso de um projeto liderado por ele cujo sucesso se deu após a aplicação dos dois mundos, extremamente distintos.

Este artigo complementará o artigo do Zeferino, pois abordarei aqui os conceitos convergentes entre PMBoK e Agile, enquanto no outro artigo, você entenderá que essa união pode sim dar resultados positivos.

pmbok processes agile e pmbok: é possível unir os opostos!

Agile e PMBoK: mundos diferentes. Será?

Consultando a quarta edição do PMBoK, pode-se facilmente identificar vários pontos convergentes com os conceitos ágeis, a seguir:

  • O PMBoK não trata o gerente de projetos como o super-herói que manda e desmanda no projeto. “Cabe ao gerente de projetos e à equipe de gerenciamento determinar o método mais apropriado de execução do projeto”. (PMBoK 4ª edição).
  • O PMBoK afirma que o gerenciamento das expectativas das partes interessadas é papel do GP. “Uma parte importante da responsabilidade de um gerente de projetos é gerenciar as expectativas das partes interessadas”.
  • O PMBoK incentiva o envolvimento da equipe com as demais partes interessadas. “Parte da responsabilidade do gerente (…) é garantir que a equipe do projeto interaja com as partes interessadas de uma maneira profissional e cooperativa”.
  • O PMBoK sugere o envolvimento da equipe, até nas questões relativas à melhor escolha dos processos a serem utilizados. “O gerente de projetos, em colaboração com a equipe de projetos, sempre é responsável por determinar quais processos são apropriados”.
  • Assim como o ScrumMaster, o gerente de projetos deve ser um orientador da equipe. “A efetividade pessoal abrange (…) a capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge objetivos e equilibra as restrições do mesmo”.
  • O PMBoK estimula a interação das pessoas. “A equipe do projeto deve estimular o envolvimento de todas as partes interessadas apropriadas ao planejar o projeto”.
  • Há um incentivo claro ao desenvolvimento da equipe no processo Desenvolver a equipe do projeto. “Desenvolver a equipe do projeto é o processo de melhoria das competências, da interação da equipe e do ambiente global da equipe para aprimorar o desempenho do projeto”.
  • O PMBoK incentiva a valorização das pessoas, através de feedbacks realistas e de bonificações para a equipe – vide o processo Gerenciar a equipe do projeto.
  • O PMBoK também indica a iteração de entregas, através do planejamento em ondas sucessidas. “Planejamento em ondas sucessivas é uma forma de planejamento de elaboração progressiva em que o trabalho que será realizado a curto prazo é planejado em detalhes (…) e o trabalho distante no futuro é planejamento em um nível relativamente alto”.
  • O planejamento do projeto, segundo o PMBoK, deve ser feito pelo gerente e equipe – vide todos os processos de planejamento, em que sempre há a “Opinião especializada” como técnica para um melhor planejamento do projeto. Isso inclui definição e sequenciamento de atividades, estimativas, identificação dos riscos etc.

Conclusões (para pensar)

CERTEZAS duvidas 279x300 agile e pmbok: é possível unir os opostos!

Apesar de possuir a certificação PMP e de gerenciar os meus projetos seguindo os conceitos do Agile, não sou defensor ferrenho de nenhuma das duas causas.

Em meus projetos, o melhor de cada método (ou conjunto de conhecimentos) é aplicado. Acima de qualquer método, metodologia ou conjunto de conhecimentos está cada projeto, que são caracterizados justamente por sua natureza única.

Sendo assim, seria ingenuidade afirmar que apenas uma técnica irá conseguir atender todas as particularidades de projetos de TI. Ambas possuem seus méritos e seus defeitos e, por isso, é nosso dever selecionar o melhor de cada técnica.

Você identifica mais alguma semelhança entre PMBoK e Agile? Você discorda do que foi dito aqui? Colabore com a discussão. Deixe seu comentário com a sua experiência!

Comente também

19 Comentários

Vinicius Serpa

x

Vinicius Serpa

Por aqui usamos o PMBOK para fazer a identificação da oportunidade e trabalhar junto ao cliente nas fases iniciais, levantando requisitos, fazendo estimativas, compondo um documento de abertura do projeto com EAP, prevendo um cronograma, escopo, prazo e custo. Esse documento passa por diversas avaliações e aprovações.

Quando o trabalho entra em execução, nós utilizamos Scrum. Passamos o escopo para um backlog, priorizamos e entregamos por pacotes até fechar todos os entregáveis da EAP. Quando ocorrem mudanças, as alterações podem ou não refletir no planejamento do projeto.

Fazem aprox. 2 anos que trabalho dessa forma, unindo os dois mundos, e tem atendido tanto o cliente que precisa de algo palpável para poder aprovar e investir como a equipe que precisa de ciclos iterativos de trabalho e uma maior liberdade nos processos.

    Flavio Ferreira

    tai um exemplo em uso !! Que mostra que é a união é viável

    Felipe Franz

    Também usamos assim aqui. Usamos conceitos do Prince2 e do Scrum para formular nossa metodologia para a fábrica de software e comparamos com as melhores práticas do PMBOK para ver se estamos fazendo o mesmo que tem dado certo nas empresas (essa é a função do PMBOK, não é uma metodologia, muita gente confunde isso, inclusive PMP’s)

Flavio Ferreira

Simplesmente magnifico o texto, uma ótima abordagem.

Realmente essa é uma união em que ambos os lados ganham, pois cada metodologia é usada por possuir pontos fortes, então porque não uni-los pegando esses pontos.

Paula Espíndoloa

Adorei o artigo, o achei muito rico.
Já vinha pensando “nesta união” a algum tempo. E o artigo me orientou.
Muito obrigada.
Você está de Parabéns.

Bruno

Muito bom o texto… eu havia sentido convergência em alguns pontos mas nunca parei para pensar e pontuar!

Parabéns!

Bruno Giannella de Melo

Muito bom o texto. Hoje já estamos conseguindo perceber as duas técnicas sendo usadas em conjunto em algumas empresas, no momento da venda, analise de requisitos, cronograma, escopo e alguns outros fatores para aprensetar aos clientes utilizando o PMBoK e quando o projeto inicia seu desenvolvimento muitas empresas usando metodologias agile, na maioria dos casos o SCRUM. Para mim podemos sim utilizar em conjunto as duas técnicas.

Abraço.

Luiz

Eu notei que os norte-americanos sempre criam teorias faraônicas e modelos que prometem incríveis rendimentos, logo depois surgem gurus dizendo as suas experiências. Sempre depois do surgimento dessas metodologias tanto no mundo corporativo quando na are de TI, todos os conhecimentos anteriores são colocados de lado. Eu acredito que o conhecimento adquirido pelo PMBOK deve ser integrado e não descartado. Eu acredito que o bom senso e tudo tem as suas qualidades e defeitos. E essas qualidades e defeitos devem ser analisados com cuidado para não atrapalhar o andamento do projeto. Esse povo extremista que não analisa a situação para mim e todo mundo cego. Inclusive na minha empresa durante as entrevista de emprego eu tento identificar quem é desses cegos para não estragar as equipes.

    Vinicius Serpa

    Também percebi isso e até fiz uma brincadeira com o pessoal de projetos daqui dizendo que eles teriam perdido tudo o que já haviam estudado sobre o PMBoK, porque o Scrum havia chegado rs.

    Nos ultimos dois anos trabalhamos em conjunto para customizar uma metodologia de desenvolvimento e olhando pra trás, o que dá pra perceber é que os conceitos, os fundamentos, não mudam, exceto o cenário – e com ele os nomes.

    Percebemos, por exemplo, que o papel do Gerente de Projetos no Scrum continua sendo muito importante, mas ele vêm com outra denominação: Product Owner. Fora isso, há diversos outros paralelos sobre as duas metodologias (algumas já tratadas pelo texto) e no final das contas, o conta para uma decisão no projeto acaba sendo sempre o bom senso.

    Vinicius Serpa

    *o que conta

Gerson

Só alguns comentários, mas talvez eu seja um desses “cegos” que vc cita…

*GP não é equivalente ao PO do Scrum, nem de perto.

*Bonificações não valorizam as pessoas, e as pessoas vão enganar qualquer métrica que vc tenha para ganhar sua bonificação. Veja mais em http://www.ted.com/talks/lang/por_br/dan_pink_on_motivation.html

*O PMBOK sugerir ou incentivar algo não quer dizer que será seguido. Por mais que você “incentive” as pessoas a serem comprometidas com a geração de valor daquele projeto, elas podem simplesmente não ser. E isso tem haver com o tal do Comando e Controle que o PMBOK coloca na mão do GP.

Acredito que você não tenha percebido que scrum, lean, xp, crystal ou qq outro framework ágil não é nada. O processo “não importa” (entre aspas), o importante é a cultura de geração de valor que toda a agilidade propõe. Os frameworks são caminhos para chegar a esta cultura.

O gerenciamento de um projeto é realmente algo muito complexo, divida esta responsabilidade com a equipe.

    Vinicius Serpa

    Oi Gerson, qto a questão do PO e do GP não serem semelhantes….

    Eu entendo que o PO representa as necessidades do cliente perante a equipe do projeto, e que é responsável pelo ROI, então está extremamente ligado ao escopo, prazo, custo e qualidade. Conforme o Guia do Scrum, ele deve garantir o valor do trabalho da equipe, e todos devem respeitar sua decisão. Ele tem a palavra final sobre um conjunto de tarefas e ninguém pode contrariá-lo.

    Isso para mim está muito ligado ao trabalho do GP. E o nosso GP realmente é o Product Owner na empresa.

    Em quais aspectos vc acha que eles não teriam ligação?

    Gerson

    Vinicius, na verdade o PO deveria ser o cliente. Se ele é um analista de negócios da consultoria ou é um representante do cliente é outra discussão, mas veja, o PO é realmente o dono do dinheiro, aquele que diz o que é mais prioritário e gerará maior valor para ele. É dever do PO priorizar o backlog, dizendo o que deve vir primeiro ou depois. O PO controla a geração de valor, os objetivos do software.

    O PO não controla prazo nem qualidade, primeiro pq qualidade é assunto do time que não deve abrir mão de fazer um bom trabalho e ter uma boa definição de pronto (claro que o PO depois pode solicitar melhorias no trabalho feito). Tão pouco o prazo é responsabilidade do PO pq em projetos ágeis essa história de escopo, prazo e custos fechados é rejeitada. O Time diz quantos pontos ele consegue fazer por sprint e em cima disso o Time (não o GP, não o Scrum Master) e o PO negociam quantas histórias irão entrar naquela Sprint. O time se compromete com aquela quantidade de trabalho para a Sprint e corre atrás para cumprir. E a partir daí o Time é responsável pela divisão de tarefas, organização do trabalho e tudo mais que for necessário. O Scrum Master entra garantindo o processo e blindando a equipe de interferências externas.

    Se o seu GP tem um ótimo conhecimento do negócio, ele pode até ser o PO. Mas veja, o PO, essencialmente é o dono do dinheiro e somente sendo ele a “por a mão no bolso” que ele irá conseguir fazer o ROI ser o mais alto possível.

    E cuidado, o papel de PO está mais ligado ao de um Analista de Negócios do que ao de um GP.

    E só para deixar claro…. Caso na terceira sprint o PO disser que o objetivo foi cumprido, que o software já gera o valor que ele esperava, nada o impede de dar o projeto como finalizado, mesmo que inicialmente eu tivesse previsto 20 sprints. Assim como após 30 sprints o projeto pode vir a continuar numa boa.

    É outro paradigma que não consigo ver se encaixando com esses pontos apresentados do PMBOK. Talvez técnicas de controle de custo e outras coisas sejam realmente bem vindas, mas os pontos apresentados, não são. A cultura é diferente.

    Vinicius Serpa

    Entendi, então posso dizer que o que conheço como PO é na verdade uma adaptação do mesmo para a realidade atual na empresa.

    Mas mesmo assim tem alguns pontos que vc disse que acabam se encaixando no paradigma “tradicional” (imaginando que o do agile seja o novo), como esse por exemplo “Tão pouco o prazo é responsabilidade do PO”, porque na verdade quem define o prazo é o Especialista Técnico junto com a equipe, pois imagina-se que o GP não tem conhecimento técnico suficiente para conhecer em detalhes a execução do trabalho para se obter o produto do projeto. Ou seja, GP e Especialista Tecnico trabalham juntos e de igual pra igual na maioria das decisões do projeto.

    Acho que esse Post poderia render muita discussão e troca de experiência, principalmente para quem não vive num ambiente ágil “puro” como o meu caso, somos forçados a trabalhar com escopo fechado simplesmente porque o cliente não aceitaria aprovar um orçamento para o trabalho onde ele não entenda claramente os limites.

    Aos poucos vamos avançando…

    Gerson

    Vinicius, no “novo” paradigma não há a figura do especialista técnico, as estimativas são feitas por todo o time (geralmente utilizando a técnica do planning poker) e mesmo a visão do estagiário do time dizendo “cara, eu não faço a mínima idéia de como fazer isso!” é útil para que o time chegue a um consenso e a uma estimativa mais apurada do que na confiança de um “especialista” que pode até acha que sabe como fazer determinada funcionalidade, porém não será ele a implementá-la. O time todo discutindo a estimativa para determinadas tarefas gera um comprometimento muito grande para que aquilo de certo, pq ninguém quer chegar depois de duas semanas pro PO e falar “olha, a gente prometeu essas coisas mas não conseguimos cumprir…”

    Felipe Franz

    O PMBOK só vai sugerir e nunca vai dizer o que fazer por uma simples questão: O PMBOK é um guia de conhecimentos (boas e melhores práticas), só indica o que você deveria fazer enquanto o SCRUM é uma metodologia e indica como fazer. São coisas distintas. O SCRUM deveria ser comparado ao Prince2, nunca ao PMBOK

    Paulo Françã

    Felipe da mesma forma que você citou que o PMBOK é um guia de conhecimento, só indica o que deve-se fazer. O SCRUM como um conjunto de práticas (framework) não como uma metodologia também somente indica. Por exemplo se a equipe como um todo se sente segura de pular algumas cerimônia do SCRUM é perfeitamente viável, apesar de não aconselhável.

Iasmim Ribeiro

Adoreii o texto.. sou estudante de Engenharia de Software, e sempre ouvimos falar somente do PMBOK, enfiim… não vou entrar na discussão de quem é melhor…

Só acho interessante ressaltar, quê, o que realmente importa no projeto, “é o produto final”, as melhores técnicas utilizadas são importantes, mas para beneficio do ”projeto’..e cabe ao gerente ,selecioná-las e aplicar na sua real necessidade… visando o produto que será entregue.

Parabéns pelo artigo.. ;)

*“O lider faz aquilo que é certo e não aquilo que é conveniente.” Bernardinho

Qual a sua opinião?