PMBoK e Agile… Pode?

Essa é uma questão me fazem vez ou outra. Me senti na dívida de explicar melhor o assunto, e cá estamos. A questão ocorre como se ao adotar uma metodologia ágil, a pessoa estivesse de alguma forma “subvertendo os preceitos do PMBoK”, e isso poderia estar indo contra o “código de ética dos PMP’s”, como se um padre pregasse sem seguir a Bíblia ou coisa assim. Que pecado!

pecado

A má interpretação mais recorrente é que o PMBoK é um processo, assim como seriam as metodologias ágeis, e que esse processo deve ser seguido fielmente pra seu projeto dar certo, pra você ser um bom gerente de projetos, ter sucesso, etc. O PMBoK não define um processo, é um conjunto de conhecimentos e as ditas melhores práticas.  Da introdução:

“O Conjunto de conhecimentos em gerenciamento de projetos é a soma dos conhecimentos intrínsecos à profissão de gerenciamento de projetos. (…) inclui práticas tradicionais comprovadas amplamente aplicadas, além de práticas inovadoras que estão surgindo na profissão, inclusive materiais publicados e não publicados. (…) está em constante evolução.” (PMBoK pág. 3)

Tenho visto cursos que ensinam gerência de projetos através dos processos descritos no PMBoK, inclusive passando aquela noção errada de que gerenciar é seguir fidedignamente todos aqueles processos, preenchendo toda documentação de cada caixinha, suas entradas e saídas. (O próprio livro diz que os processos podem interagir de diversas formas, como definir uma ordem?)
Ora, gerenciar não é preencher papel! Imagina ter que fazer tudo que o livro traz em cada projeto em todas os tipos de projetos? Seria o segredo para o fracasso na verdade! Já pensou? Por exemplo, já vi projetos simples de sites que deveriam ficar prontos em 15 dias, um mês às vezes… Não daria pra fazer nem metade dos formulários! Imagina os recursos gastos, mesmo reaproveitando os textos! Ou você sempre estouraria o orçamento, ou seria caríssimo, logo pouco competitivo. De qualquer forma terminaria fora do mercado.

Outro exemplo: pra desenvolver um sistema em tempo real, digamos para um avião, você tem que dedicar muita atenção ao gerenciamento de riscos. Realmente cabe documentar bem, várias análises, gente preocupada só com isso pra assegurar que gente não morra. Imagina fazer isso tudo pro simples site exemplificado anteriormente…

O PMBoK traz resposta pra isso, na mesma página, quando se refere a seus objetivos:

“O principal objetivo do Guia PMBoK é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. “Boa prática” significa que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico.” (PMBoK pág 3, destaque do livro).

E isso é reforçado na página 37:

“Isso não significa que o conhecimento, as habilidades e os processos descritos devam ser sempre aplicados uniformemente em todos os projetos. O gerente de projetos, em colaboração com a equipe do projeto, é sempre responsável pela determinação dos processos adequados e do grau adequado de rigor de cada processo, para qualquer projeto específico.” (também em negrito no livro)

Esses parágrafos esclarecem toda a questão, não? O próprio livro as destaca! A equipe é responsável por determinar quais áreas de conhecimento devem ser aplicadas, quais processos, em que grau, rigor, com quais entradas e saídas e em que nível de formalismo. A equipe que deve escolher as ferramentas mais adequadas para cada situação!


Está sendo atribuída ao PMBoK a mesma responsabilidade que muitas vezes é atribuída ao RUP. Nem no RUP, que é de fato um processo, você deve usar toda documentação, completa, com todas atividades, na ordem determinada, com cada pessoa pra exercer um papel, etc. Alguém, exercendo o papel de engenheiro de processo, deveria customizar o processo, selecionar artefatos e adequar tudo aquilo que se tem à disposição para o projeto em particular.

Isso não era feito, o processo virava um cascatão super burocrático, complicado, cheio de atropelos, cheio de gente e a culpa ia pro RUP (que também tinha melhores práticas e conhecimento agregado de anos de experiência da Rational em desenvolvimento de software).

Talvez o RUP tenha sido apresentado como um remédio para todos os males das organizações, traumatizadas pelos projetos que não tinham documentação nenhuma, ficavam na mão de analistas do mau, que às vezes às chantageavam, sabendo que eram insubstituíveis pois levariam consigo todo conhecimento dos sistemas. Projetos eram jogados inteiros no lixo porque ninguém conseguia entender ou dar manutenção, milhões eram perdidos…

Mas como todo remédio, dependendo da dosagem, pode fazer mal. E partimos dum extremo sem documentação nenhuma pra outro com documentação demais!


“Adotar o RUP” não adiantou. Projetos continuavam falhando. As organizações então devem ter pensado: “Deve ter sido por falha de gerência…” Que venham os PMPs!
E quando virem que só isso também não vai bastar, quais letrinhas serão adotadas?
A culpa vai ser sempre dessa sopa de letrinhas!

Pessoal, claro que isso tudo foi só uma brincadeira…

E as metodologias ágeis? Ser ágil é seguir os valores do manifesto. Só! Só que é o que faz toda a diferença nos projetos. O XP traz práticas alinhadas aos valores, mais focadas na engenharia, o SCRUM traz um framework para gerenciar projetos favorecendo os valores e assim por diante.

Logo, casar as duas coisas é totalmente possível! Não está ferindo nada!


Se ainda não se convenceu, seguem aqui mais algumas fontes de leitura que achei interessantes, (já devem até ter surgido outras desde que fiz essa pesquisa):

  • Aqui, uma relação das áreas de conhecimento de integração, escopo, risco e qualidade, do PMBoK, com práticas ágeis de uma autora, Michele Sliger, que é PMP e CSM. Recomendo!
  • Nesta apresentação, ela traz, além do mapeamento das áreas de conhecimento, Evidências de que as Metodologias ágeis são aceitas pelo PMI como  revistas do PMI com publicações sobre Agile, fala de mais gente do PMI que adotam Agile, etc.
  • Uma interessante apresentação do Alan S. Koch, do PMI de Pittsburg, em que ele analisa cada processo do PMBoK e aponta suas compatibilidades e incompatibilidades, concluindo que nada nas metodologias ágeis é incompatível ao PMBoK, e adicionar alguns processos do PMBoK pode ser recomendável, mas só onde realmente necessário e de preferência que não comprometa a agilidade.

Faltam iniciativas do Brasil, né? O que está faltando pra nos convencermos?

Abraços,

Trabalho como gerente de projetos de desenvolvimento de software na SEA Tecnologia, atualmente utilizando e divulgando metodologias ágeis em Brasília.
Formado em Computação na UnB, Pós-Graduado em Software Livre pela UNISUL e cursando MBA em Projetos pela FGV. Certificado como PMP, ITIL Foundations, Java Programmer, IBM RMUC e IBM RUP Specialist.

17 thoughts on “PMBoK e Agile… Pode?

  1. Muito bom o artigo.. Estou fazendo um MBA em Gerencia de Projetos e é engraçado como mesmo os professores muitas vezes nem sabem o que é o Scrum ou desenvolvimento ágil.

  2. Agradeço Willi pelo ótimo resumo no enfoque que foi dado, hoje a noite e até amanhã estou indo participar de um workshop sobre governança em TI, onde discorrerá sobre PMBOK, ITIL, COBIT, ISO, CMMI, MPS-Br e outros detalhes, porém nada tem de Agile. Estamos implantando na nossa software house o XP e SCRUM e já fiz curso de PMBOK e estou estudando ITIL. Achei muito oportuno ler o seu post e as referências que colocou pois agora estou “vacinado” para não fazer esta confusão entre boas práticas de gerência e agile. Um grande abraço.

  3. Olá Willi, legal seu artigo, porém gostaria de frisar que este casamento não é tão simples assim. Veja, os problemas não estão nas práticas…elas podem se integrar sim, mas e os valores? Infelizmente os valores e comportamento que são defendidos hoje por grande parte dos gerentes tradicionais são completamente conflitantantes com Agile, por isso que, o que sempre digo é:
    1. Pergunte-se primeiro: por que misturar? (e não: pode misturar?)
    2. Quais valores defenderei daqui em diante dentro do projeto? Mudarei meu comportamento ou só misturarei práticas?

    Vamos a um exemplo, aqui em São Paulo vez em quando é realizado um evento chamado “PMDome”, provavelmente você já ouviu falar, ele é ministrado por 2 dos maiores nomes do mundo PMI do Brasil. Neste evento ouvi coisas do tipo “Toda tarefa tem que ter uma cabeça, pois caso algo der errado temos que saber quem enforcar!” e “O pior burro é o ‘burro pró-ativo’, terminou suas tarefas parta para suas próximas tarefas pois certamente você não terá conhecimento específico para ajudar quem está alocado em outras tarefas”. Veja: ambas as declarações são COMPLETAMENTE O OPOSTO do comportamento de times e gerentes ágeis. A primeira assassina o conceito de unidade do time, e a segunda o conceito de equipes multidisciplinares. Percebe?
    Portanto volto a falar, unir práticas é realmente simples – mas é a ponta do iceberg, quando você pecebere uma diferença entre os valores envolvidos, percebe que não é só “juntar” ou “encaixar”, mas sim “atravessar a ponte” (como disse Michelle) ou “mudar”.

    No Falando em Agile farei uma palestra com o título “Scrum em ambiente PMBok: qual caminho a ser seguido?” onde tocarei bastante nesses pontos!

    Grande abraço.

  4. Olá Alexandre!
    Gostei do seu comentário. Eu concordo! Há uma mudança de paradigma grande a ser feita antes de se adotar as práticas ágeis. Mas o paradigma não está no livro. Tá na cabeça dos gerentes. (Você mesmo colocou isso muito bem.)

    Pra entender isso, basta a gente se colocar no lado deles: é provável que vejam essas mudanças como uma ameaça. O fato de existir uma entidade mundial, uma certificação valorizada, uma posição superior – tudo isso dá ao gerente certo poder e status.
    Independente de isso ser verdade ou não, há o receio de perda de poder, status, emprego. Há um comprometimento com o “modelo”, e talvez seja esse o X da questão.

    Outra coisa: nossa atividade é coisa nova no mundo. Somos trabalhadores do conhecimento. Ainda não se sabe direito como lidar com isso, mas estamos trilhando um caminho mais promissor. O PMBoK é genérico – trata desde projetos onde valem essas declarações hierárquicas (aliás, ECA!), até nossos projetos com trabalhadores do conhecimento. Nos nossos, aquilo não vale.

    Enfim, a grande maioria das mudanças de status quo é difícil. É difícil mudar quem “está na vantagem”, mandando. Eles têm que ver uma vantagem na mudança, e se adaptar.

    “Não é o mais forte da espécie que sobrevive, nem o mais inteligente; mas sim, o que melhor se adapta às mudanças.”
    (Charles Darwin)

    Abraço,
    Agradeço os comentários de todos!
    Willi

  5. Alexandre e Willi, vamos criticar um pouco mais essa questão.

    Penso que as duas frases (da cabeça e do burro) foram extremamente infelizes. Claro que elas ferem totalmente os valores ágeis, por outro lado, pode ter certeza que também ferem totalmente os valores de bons gerentes de projetos que utilizam metodologias mais estruturadas, complexas e que incluem as boas práticas do PMBoK. Ou alguém tem coragem de dizer que essas frases representam os valores defendidos pelo PMI???

    Penso que existe um falso dilema quando se colocam as metodologias ágeis como incompatíveis com os princípios do PMBoK. Na minha opinião esse é um fundamentalismo que não agrega para ninguém e que não existe de maneira tão forte por parte do PMI – é mais forte justamente por parte dos agilistas. Já vi muitos PMPs que dizem justamente isso: as metodologias ágeis tem seu valor real e em muitos contextos serão com certeza as mais adequadas. Talvez o que falta é conhecimento para outros gerentes que justamente por somente terem um martelo (PMBoK) enxergam tudo como sendo prego (projetos nos quais seriam mais úteis metodologias ágeis).

    Além disso, temos que lembrar que o PMBoK atende um público muito maior do que o da tecnologia da informação. Por exemplo, no ápice da obra de contrução da usina hidrelétrica de Itaipu havia 40.000 (quarenta mil!) pessoas trabalhando no canteiro de obras. Vocês consegues conceber tal obra sendo gerenciada por uma metodologia ágil??? Eu acho que em muitos momentos poderia ser envolvidos valores e boas práticas das metodologias ágeis, mas com certeza tal obra não seria gerenciável de outra maneira que não envolvendo muito formalismo, documentação, estruturação e planejamento prévio.

    Um abraço a todos!

  6. Vamos lá Jorge:

    1. Veja, em momento algum disse que não há “compatibilidade”, o que disse é que a questão vai bem mais além do que juntar práticas…foi muita mais uma alerta do que crítica! (E creio que o Willi entendeu muito bem o ponto que pretendi tocar) Sugiro a leitura do livro “O Modelo Toyota”…lá o autor ilustra porque grande parte das empresas que vem tentando usar Lean não tenham conseguido obter o mesmo sucesso que a Toyota…a maioria não muda de comportamento/postura, mas sim apenas de práticas.

    2. Uma coisa é engraçada: em quase todos os lugares eu escuto a mesma coisa “comportamento X não é imposto pelo PMBok mas sim por profissionais ruins”, eu concordo! Mas é impressionante como em quase todos os lugares a coisa tem funcionado desta forma, e os resultados tem sido o mesmo (Plano deu certo, mas cliente insatisfeito com resultado final; Equipe estressada; Alta rotatividade de profissionais; gerentes odiados; gantt/cronograma fake; etc.). Então, se todos os gerentes de projeto dizem que “possuem um comportamento adequado” e os resultados não tem sido bons (Standish Group é quem diz), há alguém mentindo.

    3. Olha, tenho um bom tempo nessa área…sou PMP pelo PMI e CST pela Scrum Alliance e veja: não me considero apto a gerenciar um projeto que não seja da área de TI, deixo isso para os profissionais destas áreas. Portanto modelos/cases da engenharia civil, naval, espacial, etc. não servem muito pra mim, são realmente mundo muito diferentes (Em TI não temos pedreiros, nem apertadores de parafuso…temos – e precisamos – de profissionais criativos) Agora…exemplos de projetos de TI na Google, Microsoft, Yahoo!, BT, Siemens, IBM, Borland, CapitalOne, etc. me servem muito…e esse caras vem se dando muito bem com práticas ágeis. Veja na área de Resources do site da ScrumAlliance (www.scrumalliance.org) sobre cases do uso de Scrum em projetos bem grandes, multi-site, etc.

    4. Assim como PMBok não é uma metodologia, Scrum (por exemplo) também não é. Portanto não o enquadro no termo “metodologia ágil”.

    5. Na Harvard Business Review de maio – acho – saiu uma matéria sobre os líderes do futuro, muito boa por sinal – sugiro a leitura. Uma frase interessante “Se você quer um comportamento diferente, ao invés de trocar de líder por que não troca o ambiente?” e aí que vem a questão: o que vem fazendo com que a maioria dos gerentes de projeto do mercado atuem de forma comando-controle? Os profissionais ou o ambiente? É este o ponto.

    []s

  7. Uma coisa importante é que Métodos ágeis não são somente para TI. nem sequer são para qualquer tipo de TI.

    O Scrum não foi criado para desenvolver software e não é usado somente para isso.

    É claro que um elemento fundamental é que estamos falando de processo de desenvolvimento. Desenvolvimento é importante diferente de, por exemplo, construir um usina, porque temos o elemento criativo como predominante. Desenvolvimento é porque estamos criando uma coisa com características novas. Todo o desenvolvimento de software (salvo raras exceções) é desenvolvimento. Temos requisitos incertos e precisamos da criatividade no processo. A construção de software é um problema já resolvido (eu, por exemplo uso Maven) e totalmente automático.

    Sei que o PMBok não tem nenhuma contradição com o Scrum (por exemplo). E não é possível escolher entre um e outro. Ninguém desenvolve um carro ou um avião especificando o carro todo no papel no início do projeto. Você precisa de iterações, tentativas evolução (e geralmente o projeto tem tempo fixo e escopo variável).

    Concordo com o autor do artigo. Ótimo artigo!

  8. Prezados,

    Pessoalmente não sou fã, adepto, crente ou praticante com exclusividade de uma metodologia, processo, atitude ou o que seja em detrimento de outra. Mas algo que prezo muito é pensar por por mim mesmo e exercitar a crítica daquilo com o que me deparo (Atenção: com isso não estou dizendo que os outros aqui não o façam, ok?! Nada de melindres!).

    Também não sou da área civil, (trabalho com TI) mas conheço o suficiente para reconhecer uma tendenciosidade clara no que está sendo argumentado nos comentários anteriores. A obra de Itaipu, por exemplo, permitiu ao Brasil dar um salto no domínio da tecnologia do concreto a ponto de que a China, ao construir a barragem das três gargantas, atualmente a maior do mundo, veio ao Brasil para aprender como foi feito com Itaipu. Na época, soluções inovadoras das mais diversas que vocês possam imaginar foram criadas para solucionar os problemas específicos encontrados na obra. Alguém ainda acha que não há criatividade nesse trabalho??? Tem muitíssima pesquisa, desenvolvimento e inovação, talvez mais do que muitos e muitos sistemas jamais terão!

    Abs.
    Jorge

  9. Bruno,

    “E quais seriam mesmo os valores defendidos pelo PMI ?”

    É só procurar pelo código de ética e conduta profissional do PMI que você terá uma descrição detalhada dos mesmos.

    Abs.
    Jorge Ivan

  10. Oi Jorge,

    desculpe, mas acho que você não entendeu minha colocações. É o mal da comunicação excessivamente escrita…gera interpretações ruidosas. Vou deixar pra esclarecer melhor meu pensamento quando tivermos a oportunidade de falar pessoalmente, ok? Para não crirar mais ruídos.
    Só queria esclarecer que em momento algum disse que projetos da eng. civil, por exemplo, não precisam de criatividade. O que tentei expor é que o trabalho “mão-de-obra” nesses cenários são bem diferentes do que consideramos “mão-de-obra” em TI. Dentre outras muitas coisas que são muito diferentes entre esses cenários…projetos em TI não são melhores que os de outras áreas (apenas diferentes), pelo contrário, como você mesmo falou: há projetos nessas outras áreas MUITO maiores do que precisamos em TI. Por isso precisamos de simplicidade!

    Um abraço.

  11. Pingback: PMBok x Agile: análises e manuais « Blog Visão Ágil

  12. Pingback: Blog do Barbeita » PMI X Agile

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s