PMI - Vale a pena?

Olá Pedro,

Se for Gerenciamento de Projetos com a metodologia do PMI - Project Management Institute, vale sim, se o seu foco for gerenciamento de projetos, claro.

Faça um curso básico e se gostar, depois que se formar, faça uma pós ou MBA.

O Capítulo do PMI no Rio de Janeiro oferece um Curso de Gerenciamento de Projetos Básico no formato Ensino à Distância - EAD de 20 Horas.

Quanto a Especialização ou MBA tem em vários lugares, na Estácio, na PUC, na FGV dentre outras.

[]´s

Olá

Se seu foco será gerenciamento de projetos bem sucedidos, isto é, pretende ser um PMP-Project Management Professional sem ser um Piloto de Microsoft Project, estude também SCRUM, LEAN e tudo sobre desenvolvimento ágil.

[]s
Luca

Se você pretende galgar o cargo de gerente de projetos, quanto mais qualificado (e preparado) você estiver melhor. Veja a certificação PMI como um investimento a médio prazo, prepare-se para obtê-la, e chegar ao pretendido coargo de gerente de projetos.

Um abraço, e muito sucesso!

Antigamente era mais fácil tirar a certificação PMP…era só estudar muito e passar…hj em dia o PMI está “impondo” uma comprovação em gerência de projetos de, se não me engano, 4200 horas. Precisa comprovar mesmo…dando telefones, por exemplo, do seu superior imediato do tempo que esteve gerenciando projetos. Existem formas de burlar isto, mas, para não ter problemas, só vá tentar PMP se vc tiver o que o PMI exige…é mais seguro.

ate mais…

richardpeder:

Antigamente era mais fácil tirar a certificação PMP…era só estudar muito e passar…hj em dia o PMI está “impondo” uma comprovação em gerência de projetos de, se não me engano, 4200 horas. Precisa comprovar mesmo…dando telefones, por exemplo, do seu superior imediato do tempo que esteve gerenciando projetos. Existem formas de burlar isto, mas, para não ter problemas, só vá tentar PMP se vc tiver o que o PMI exige…é mais seguro.

ate mais…

Esse antigamente é muito antigamente mesmo, pois a minha certificação PMI, tirada em 2002, já tinha esses requizitos.
Mas, como o Luca disse, a certificação PMI é boa, mas pra ser um GP bom, mas bom mesmo, hoje em dia, vc deve conhecer todas as metodologias, desde as ruins até as boas, com as ageis.

Ao meu ver, quem tem 4200 horas de gerência em projetos de software usando qualquer método ágil vai pensar 10 vezes antes de correr atrás de uma certificação de PMP

Bom, vale a pena sim, eu preferir logo fazer um MBA em gerenciamento de projetos com praticas do PMI para eu me aperfeiçoar.

Abraços

PMP+PMI+MBA+FGV+RICOS

parece que to lento a revista exame aqui rsrs

Não conheci um PM* bom até hoje na vida, por isso recomendo fortemente fazer essa certificação para trabalhar nas milhões de empresas ruins que se tem por ai que não tão nem ai para qualidade do profissional, e vai na fé pq eles pagam muito bem.

Já trabalhei na área e posso lhe dizer que é uma área maravilhosa. Assim como em outros cargos conheço gerentes de projetos que são excelentes e outros péssimos. Experiência conta muito mas não é tudo, já vi muita gente gritar que tinha 30 anos de experiência mas que no dia-a-dia era péssimas e terminavam atravancando os projetos. Acho essencial estudar para conseguir as qualificações exigidas para o cargo pois isso facilitará o teu dia-a-dia. O único problema que eu vejo hoje é meio a discriminação sofrida por que já está no cargo com menos de 30 anos de idade. Sofri bastante com isso mas se é essa a parte que você quer invista e vá em frente. Vale muito a pena!!!

Bom Pessoal,

Curso MBA em gestão de projetos e realmente o mercado é exigente, temos que nos qualificar a cada dia que passa, ser gerente de projetos não é tão simples assim. acredito que para ser um profissional qualificado na area temos que estudar, entender e praticar sobre o assunto.

Em questão da certificação, existem dois tipo de gerente de de projeto…

Aqueles que tem a certificação PMP porém não é bom… sendo bem claro…

Aqueles que não tem PMP mas que é ótimo.

Melhor ainda é aquele que é ótimo e com PMP.

Abraços

Olá

Cuidado onde investir sua grana.

Se o MBA em gestão de projetos, ensina a gerir projetos de software de forma igual a projetos de engenharia. Se não aborda a tendência mundial de reconhecer que desenvolvimento de sofware não é um processo definido. Se não prioriza a abordagem dos processos de desenvolvimento ágil, Scrum, XP, Lean e outras siglas da moda, o tal curso é um lixo anacrônico pré cambriano. Está totalmente defasado com o que recomendam os principais nomes da área nos últimos anos.

[]s
Luca

Quero lhe questionar…
Com base em que você afirma essas suas colocações?
Você tem metodologia de projetos em sua empresa?
Você tem conhecimento da Metodologia do PMI?
Você é gerente de Projetos?
Sua empresa esta em qual nivel de maturidade em gestão de projetos?

Abraços

mazinhospinter,

Acredito que o que o Luca colocou representa a opinião da maior parte de quem acessa esse fórum, talvez se você fizer uma busca aqui ou no google, você pode ter algumas respostas para sua 1º pergunta.

Olá

mazinhospinter:

Quero lhe questionar…
Com base em que você afirma essas suas colocações?
Você tem metodologia de projetos em sua empresa?
Você tem conhecimento da Metodologia do PMI?
Você é gerente de Projetos?
Sua empresa esta em qual nivel de maturidade em gestão de projetos?

Afirmo com base em tudo que leio nos últimos anos

Afirmo com base em mais de 35 anos que me interesso, estudo e uso diferentes metodologias de desenvolvimento de sofware

Afirmo porque já vivenciei diversas tentativas fracassada de desenvolver software como se fosse um processo definido tal como nós engenheiros temos nos nossos projetos de engenharia

Afirmo por já ter gerenciado muitos projetos usando ferramentas inadequadas como por exemplo MS Project e é claro que os cronogramas nunca bateram com a realidade.

Afirmo não porque despreze o PMI, mas porque não tem sentido usar só o que o PMI recomenda sem atentar para a onda ágil que varre o mundo e que certamente um dia o atingirá. Também não digo que valha a pena estudar o PMI mas usar os métodos ágeis por quem conhece PMI pode ser o melhor dos mundos.

Infelizmente o termo maturidade está completamente desgastado e virou quase sinônimo de desenvolvimento excessivamente burocratizado. Como ao contrário da engenharia, dificilmente dois projetos são parecidos, seguir as regras dos órgãos que recomendam modelos de maturidade nem de longe significa ter mais possibilidade de sucesso do que outras empresas que usam metodologias mais modernas. Portanto nível de maturidade em gestão de projetos normalmente não tem nada a ver com nível de satisfação do clientes com os projetos desenvolvidos.

[]s
Luca

Apesar de controlarmos as atividades com o Project ou mesmo o Primavera, software que sõa mais conhecidos, não quer dizer garantia de sucesso para o projeto.

O PMI apresenta as melhores práticas para também levar ao sucesso do projeto, não necessáriamente precisamos em um unico projeto impor os 44 processos distribuídos em 9 áreas de conhecimento. Cada um se encaixa com o nivel de complexidade do projeto, senão gastaremos mais tempo no gerenciamento doque na própria execução e esse não é a idéia.

Não sou nenhum defensor do PMI e por você dizer que a 35 anos que se interessa… posso te adiantar que você esta a 10 anos de conhecimento a mais doque o meu.

Abraços

Olá

É esta a frase chave e completamente errada. Desenvolvo software desde 1968. Já assisti o nascimento de todas as metodologias de desenvolvimento de software. Todas diziam ser as melhores práticas e os cliente continuavam insatisfeitos.

É óbvio que entre os principais motivos de insatisfação dos clientes há algo que não tem nada a ver com PMI mas que ainda é usado por muitas empresas burocratizadas até porque ainda é ensinado nas nossas faculdades por professores verdadeiramente vigaristas. Estou falando do desenvolvimento em cascata do tipo primeiro planeja tudo, depois executa e depois o que cliente é que se vire porque tudo foi feito de acordo com o contrato.

Mas mesmo que a empresa não use o tal desenvolvimento em cascata do milênio passado, se ela usa somente as práticas do PMI sem atentar pela onda mundial de desenvolvimento ágil, certamente estará caminhando para ser menos competitiva do que outras que seguem o que quase todos os grandes pensadores da área de TI estão recomendando há praticamente 6 anos.

Um conselho: leia. Leia muito. Procure autores famosos. Procure ver o que está acontecendo lá fora. E principalmente entenda que os maiores beneficiados pelas certificações de maturidade não são os clientes que usarão os sistemas e apenas os vendedores de certificações.

[]s
Luca

mazinhospinter:

Bom Pessoal,

Curso MBA em gestão de projetos e realmente o mercado é exigente, temos que nos qualificar a cada dia que passa, ser gerente de projetos não é tão simples assim. acredito que para ser um profissional qualificado na area temos que estudar, entender e praticar sobre o assunto.

Em questão da certificação, existem dois tipo de gerente de de projeto…

Aqueles que tem a certificação PMP porém não é bom… sendo bem claro…

Aqueles que não tem PMP mas que é ótimo.

Melhor ainda é aquele que é ótimo e com PMP.

Abraços

Pelo visto vc é mais um que esta jogando rios de dinheiro no lixo com esses MBA, Pós e outras tranqueiras que estão ficadas nas práticas e conceitos comprovadamente ruins para projetos de software.

Se vc tem dúvidas disso, pelas perguntar feitas ao Luca por exemplo, desculpa mas vc esta procurando informações em locais errados para moldar sua carreira, em 2008 vc deveria estar mais do que ciente do que represento Agile hoje no mundo.

Não leve para o lado pessoal, mas infelizmente vc esta perdendo seu tempo e seu dinheiro. Mas fique tranquilo porque ainda vai ter uns 10 anos de emprego bem remunerados pros PM* da vida.

Caros,

Entendo o que vocês estão querendo dizer, respeito sim suas opniões, o curso tem me acrescentado muito hoje utilizo as melhores práticas do PMI utilizo também ITIL que dá suporte a serviços de TI.

Não levarei pro lado pessoal de forma alguma, acho que o comentário do nosso amigo Moderador Luiz foi desnecessário, mas como estamos em um fórum e pessoas expressam palavras de acordo com o seu ponto de vista, respeitarei porque sou totalmete democrático.

Luca, voltando ao nosso assunto quando me referei que o “PMI apresenta as melhores práticas para também levar ao sucesso do projeto”, temos que levar em conta a forma de condução do projeto, estratégia… com base nisso disse meu argumento.

Abraços

PMI e “fábricas” de software são o inferno da nossa profissão, por tentar transformar trabalho intelectual em commodity.
É comum ver-se aberrações cuspidas por um software de PM, como 2 horas e 13 minutos pra fazer uma especificação, ou 3 horas e 21 minutos pra desenvolver um programa.
Espero suportar até que agile ou outra nova onda consiga mudar este panorama, ou terei que investir minhas economias numa banca de revistas, para tentar salvar minha sanidade mental.

Quando eu era desenvolvedor nas consultorias, meu ex-GP´s só delegavam a pressão que o cliente impunhava, ou seja, não tinham nenhum poder na decisão do projeto, só sabiam repassar a pressão do cliente. “É pra ontem e prazos e mais prazos ridiculos”

mazinhospinter:

Caros,

… utilizo as melhores práticas do PMI utilizo também ITIL que dá suporte a serviços de TI. …

… o “PMI apresenta as melhores práticas para também levar ao sucesso do projeto” …

Desculpe a implicância, mas a expressão m… práticas me parece muito perigosa, para
qualquer metodologia ou modelo. Dá a entender que essas práticas são sempre boas,
tipo balas de prata, o que pode não bater com a experiência de várias pessoas que já postaram aqui.

Não gosto de usar essa expressão nem para as coisas em que eu acredito.

Dito isto, concordo em linhas gerais com o que o Luca postou. Agrego que o modelo usado para a
certificação PMP, na experiência de quem trabalhou em uma organização com uma dúzia de PMPs,
costuma se traduzir em práticas nefastas para grande parte dos projetos: detalhamento precoce
em WBSs fossilizados, atividades 87,65 % prontas, gestão por números, desligamento do desconfiômetro dos gestores e endeusamento de ferramentas como MS Project e Primavera.

Lendo o material do PMI, você encontra muita coisa aplicável, e muita coisa que se sabe que não funciona
há décadas em outras áreas. De que maneira isso descamba para o pessoal pegar apenas a parte ruim
desafia meu entendimento.

Não digo que todo PMP aja assim, mas gato escaldado tem medo de água fria …

Jorge

"

"

Planejamento, processos e métricas não são a solução para este problema. Envolver o cliente no projeto sim. Se você quiser fazer isso com todo o overhead do PMBoK, fique à vontade, mas te garanto que com uma abordagem Lean é bem mais fácil.

Já trabalhei como gerente algumas vezes e nas últimas semanas fui convidado a fazê-lo de novo e recusei. Quanto mais estudo gerência de projetos, mais acredito que num projeto de software no final das contas o sucesso depende dos desenvolvedores, então prefiro botar a mão na massa e fazer a diferença junto com eles.

Vamos ser pragmáticos. Vou levantar 2 questões típicas de qq projeto de software e gostaria que vc respondesse como um típico GP PMP…

• Quando o software deve ser testado no ciclo de desenvolvimento?

• O que o GP deve fazer caso o usuário/cliente deseje modificar o escopo do projeto?

Seria bom se vc pudesse colocar referências do PMBook que sustentem suas argumentações.

"

"

Nao acredito que isso seja relevante nessa discussao porque as ideias aqui discutidas (lean, scrum, agile) sao aplicadas com sucesso em outras industrias ao redor mundo. Lamentavelmente no Brasil as empresas de sw estao atrasadas para as metodologias ageis. O profissional agil brasileiro tem poucas opcoes de trabalho aqui e alguns ate deixam o pais por causa disso.

Agile nao e um guia sobre praticas e ferramentas mas um mindset. Isso que a diferencia, e diferente do que vc insinua ela contempla sim os diferentes tipos de colaboradores.

Gerência de projetos na teoria não deveria ter nada a ver com desenvolvimento de software de forma direta, a gerencia deve estar um nível abstrato acima. Coordenando o projeto sem interferir nos aspectos técnicos do projeto.
Metodologias ágeis não são gerência de projetos em regra.
A confusão se dá porque a turma insistiu em adotar PMBOk aliado a CMMi [potencializando a ineficiência da cultura CMMi] como modelo de desenvolvimento de softwares, as vezes junto de RUP [aí se tem a tragédia completa].

Escrevi no meu blog recentemente que Gerente de projetos não necessariamente deve ser um técnico, tem um pouco a ver com essa discussão, http://www.milfont.org/tech/2008/09/25/gerentes-de-projetos-nao-sao-tecnicos/
Acredito que hoje é até melhor que o gerente não seja técnico para não ter perigo de assumir papéis dentro da equipe.

"

Referência muito genérica. É vc quem está tentando provar q PMI está alinhado com Agilidade.

Solicitação integrada de mudança=Burocracia?

Avaliar o impacto das mudanças no cronograma que determina a entrega para daqui a X meses?

Isso me cheira a algo para esfregar na cara do cliente, caso vc precise justificar um atraso na data de entrega do projeto.

Eu conheço: waterfall.

Prédios, pontes e estádios são construídos utilizando o modelo waterfall e é isso o que o PMI ensina.

Software é completamente diferente.

pmbok tem nada a ver com waterfall

"

Por que PM* não funciona então pra software?

Porque a cultura PMBOK vai de encontro com o próprio PMBOK, a maioria dos profissionais PMP que conheço misturam a atividade de gerencia que é algo abstrato com o desenvolvimento do software, quando não muito assumindo ações que não são dele e interferindo na equipe.

"

"

E o projeto segue uma metodologia eficaz, qual a importância do guia? Meu problema com o PMI é que a gerência vira o centro das atenções do projeto. E como você mesmo disse, pra um gerente pisar na bola é fácil fácil.

"

Vou perguntar mais uma vez… porque então temos anos e mais anos de números elevadíssimos de fracasso de uso desse guia em projetos de software então?

O manifesto ágil seria o PMBok da agilidade então? rs

Luiz Aguiar:

Vou perguntar mais uma vez… porque então temos anos e mais anos de números elevadíssimos de fracasso de uso desse guia em projetos de software então?

O manifesto ágil seria o PMBok da agilidade então? rs

Pode parecer que eu estou defendendo o PMBOK, mas longe disso, na teoria deveria ser algo acima da equipe de desenvolvimento, na prática intercede sempre, faz parte da cultura, todos os PMPs que conheço estragam os projetos.
Projeto de software ágil não precisa de PMBOK.

cmilfont:

Luiz Aguiar:

Vou perguntar mais uma vez… porque então temos anos e mais anos de números elevadíssimos de fracasso de uso desse guia em projetos de software então?

O manifesto ágil seria o PMBok da agilidade então? rs

… na teoria deveria ser algo acima da equipe de desenvolvimento…

Na prática, o mais importante é a equipe… o PMBook fala sobre isso?

Ainda não provou nada. Se vc prefere continuar no senso comum, a discussão termina aqui.

uma cosia que acho legal são os grupos como os jug’s. nunca participei e nada, mas acho legal o voluntariado e grupo de estudos que, pelo menos o pessoal daqui de pernambuco vem trabalhando. vi uma apresentacao e achei legal.

http://www.pmipe.org.br/

"

A menos que vc me fale que vive em Marte, eu me recuso a responder essa pergunta sua, desculpe mesmo.

"

"

"

A menos que vc me fale que vive em Marte, eu me recuso a responder essa pergunta sua, desculpe mesmo.

Bom, então vamos acreditar na sua opinião como verdade absoluta. hmmm
Depois é o PMBok que não funciona. :lol:

O Chaos Report tem mais de 10 anos, mas segundo ele, a grande maioria dos projetos de software estouram prazos, estouram orçamentos e não cumprem os seus propósitos. Não estou lembrado de nenhum estudo mais recente.
Mas é digno de nota que a maioria dos projetos usam os métodos tradicionais para desenvolver software. Fazendo uma união burra dessas duas estatísticas, chegamos a conclusão que os métodos tradicionais não prestam.

"

Eu também não disse que a culpa é do PMBok
Nunca estudei PMBok mas infelizmente tive péssimas experiências com PMPs certificados que tentaram usar os seus conhecimentos do PMBok e do PMI e nenhuma boa experiência. E as boas experiências não envolveram PMPs tentando aplicar PMBok e PMI.

A minha amostragem não esta muito boa, mas já ouvi muita gente falar a mesma coisa.

Talvez seja o mesmo caso do RUP, o que aplicam no mercado não é o que esta escrito no “livro”.

"

Mudando a dinamica da discussão, quais projetos de software visíveis foram feitos usando 100% PMI (bonus se for junto com CMMI-5), estão em produção hoje ?

Links plz… contem um pouco da experiencia nesses projetos também…

Melhor do que atacarmos o livro e a metodologia, vai ser atacar o software feito usando ele

"

XP implementa PMBoK?

Eu nunca vi, nem ouvi falar um projeto com xp que usa uma WBS, idolatrada no PMBoK

Também ainda não vi projeto xp com aquele project charter detalhado …

Acho que dizer que xp/agile é uma forma de implementar PMBoK, é forçar demais

Lean, XP e Scrum não são métodos para implementar o PMBOK

Voltando a discussao:
quais projetos de software visíveis foram feitos usando 100% PMI (bonus se for junto com CMMI-5), estão em produção hoje ?

"

XP e Scrum está muito mais pra Lean do que pra PMBOK

“Starting about 1910, Ford and his right-hand-man, Charles E. Sorensen, fashioned the first comprehensive Manufacturing Strategy. They took all the elements of a manufacturing system-- people, machines, tooling, and products-- and arranged them in a continuous system for manufacturing the Model T automobile. Ford was so incredibly successful he quickly became one of the world’s richest men and put the world on wheels. Ford is considered by many to be the first practitioner of Just In Time and Lean Manufacturing.”

Não acredito que PMBOK seja mais antigo que 1910… entao vc nao pode dizer que pmbok contem lean… muito menos que ele contem scrum e xp

Aliás, o seu exemplo é perfeito, onde entram as pessoas aí ?

"

"

Alguém poderia pelo amor de Deus, dos ETs, dos Orichas e tudo mais, citar uma, apenas uma empresa que tenha um renome bom, que seja um exemplo de qualidade em projetos de software usando PMBox e sua trupi?

Bom,
lendo o topico descobri que o motivo de todos os projetos que eu ja participei usando algum “guia”(CMM, MPSBR…etc) não deram certo pq as pessoas não souberam aplicar esse guia(e não foram poucos).
Com isso eu fico com a ideia dos metodos ageis. Pq ela foca nas pessoas, não em recursos. E sem pessoas não importa o que vc use, vai dar errado.
E pensando agora… os projetos que eu participei sem guias, mas focado nas pessoas foram os que deram certo.

[]´s

"

"

Pessoas são recursos? Esse tipo de mentalidade costuma afundar projetos.
Principalmente em projetos de software, não dá para achar que você pode usar um guia milagroso e processos “bem definidos” tornando as pessoas totalmente descartáveis, podendo ser trocada a qualquer momento por outra e manter a mesma produtividade e qualidade.

Se é tão ampla, qual é o valor além do didático? Porque na prática dá pra dizer que qualquer método segue o guia.

Não, pessoas não são recursos. Recursos são descartaveis, pessoas não.
Acho que nesse ponto esta a diferença entre os “guias” e as metodologias ageis.
Todas as fabricas de software que utilizam “guias”, tratam pessoas como recursos. Inclusive quem aplica os “guias”.
É nesse momento que as coisas começam a dar errado.
Por isso ainda fico com metodos ageis. E não pq li na Info uma materia a respeito. Mas pq e todos projetos que participei nesses ultimos 8 anos que utilizaram metodos ageis as coisas correram bem melhor do que qunado usamos algum desses famosos “guias”.

[]´s

Pessoas são pessoas, pensar em um ser humano apenas como um número, um custo, um objeto necessário para algo funcionar, como um parafuso, é o que fizeram até hoje as “fábricas de softwares”, e elas são os melhores exemplos do fracesso do PM* e suas crenças ultrapassadas e equivocadas. Software é trabalho empírico, não é uma ciência mensurável por algumas formulas matemáticas como em engenharia.

vc conhece Lean? conhece o manifesto ágil? scrum?
Se a resposta for sim, vc acaba de atestar que escreveu uma grande baboseira, se for não, esta perdoado pela baboseira que escreveu rs

"

"

marcosalex:

Quem te falou que recursos são descartáveis? Onde está escrito isso? Vamos mudar o nome dos departamentos de RH então? “Pessoas humanas” hheheheh

Você não está colocando recursos materiais e recursos humanos no mesmo balaio? O PMBok não fala isso, acho que aí é um dos motivos da confusão. Se alguém faz isso na empresa onde você trabalhou, não, ele não segue o PMBok.

Com certeza, tanto que ja existem empresas que nem usam mais o nome Recursos Humanos para essa area. De uma olhada se o Google tem a area de Recursos Humanos por exemplo.

Outra coisa, acho meio simples isso de dizer que o “guia” falhou pq não foi bem aplicado. Acho muita coincidencia todas as empresas que ja vi utilizarem isso nao ter ninguem capaz de fazer-lo.
Se é dificil de aplicar, p/ mim ja não tem uso. No minimo consigo o mesmo resultado que os “guias” prometem(e ate agora não vi cumprirem) com muito mais simplicidade.

[]´s

"

"

Faço minhas suas palavras… onde estão os dados (estatística) mostrando isso?

E ainda não citou uma empresa, como lhe pedi anteriormente… deve estar difícil encontrar alguma no google né rs

"

eu sou apenas um smaltalk ainda hehe
mas… no tempo que eu trabalhei em uma filial da IBM, um gerente nos disse que quem quisesse subir era estudar ITIL e PMBok…

a eficiencia talvez seja discutivel mas se 2 pessoas com conhecimentos e experiencia bastante semelhantes, uma tem o certificado e a outra nao? :roll:

Provavelmente ler o PMBOK e outros guias da vida servem, também, para vocabulario, permitindo troca de ideias entre PMs.

Da mesma forma que, mesmo que não vá usar Scrum um PM deveria conhecer Scrum para saber o que é um Sprint, caso uma parte da empresa esteja adotando, senão terão serios problemas (imagine um PM depender de um recurso que esta em uso por uma equipe Scrum? Se o Sprint está em andamento não é bem assim para partilhar recursos, o correto seria sinalizar o quanto antes para isso ser debatido num Sprint Planning da Vida). Da mesma forma que conhecer RUP não significa que devemos seguir feito ^C ^V

De todas as adoções de agile que eu já vi e li sobre, nenhuma afirmou seguir as práticas do PMBok, muito pelo contrário. Também já ouvi que as práticas do PMBok são aplicáveis tanto em projetos de software como em projetos de construção civil. É difícil acreditar que algo que se propõe a fornecer as melhores práticas para tipos de projetos tão diferentes tenha realmente as “melhores” práticas.

O que é legal do Scrum, XP, etc, é que eu consigo rapidamente e de forma bem prática como eles podem agregar valor. Já no caso do PMBok nunca encontrei uma explicação rápida e prática de como sua aplicação pode agregar valor.

Depois que comecei a estudar Scrum eu não acho tão rapido de implantar e extrair resultados: se a equipe é verde e a diretoria não confia vc tem N problemas.

Eu diria que os frutos do Scrum e do PMBok vem com o tempo, sejam eles quais forem.

Eu dúvido vc e qualquer pessoa desse planeta achar apenas UMA citação de algumas das pessoas que contribuiram para a criação do scrum, do xp, fdd, dos formadores do manifesto ágil, falando essa afirmação que vc fez!

Esta difícil mesmo dar um exemplo hein, vc citou o caso do UOL usando PMBok no Scrum, aqui mesmo no guj tem funcionários do UOL e eles podem te desmentir quanto a isso. Porque é isso que vc afirmou, que quem usa Scrum esta com o PMBok debaixo do braço, qualquer um que estudou um mínimo sobre Agilidade sabe que isso é exatamente o oposto.

Try again!

Se é tão ampla, qual é o valor além do didático? Porque na prática dá pra dizer que qualquer método segue o guia.

Não, não é qualquer método que segue o guia, mas a grande maioria das metodologias o seguem. Creio que você entende o que quero dizer, só não está concordando.

Engraçado… ninguém te entende? Ou c viaja nas idéias e tenta forçar as coisas falando que laranja = banana?

Faço minhas suas palavras… onde estão os dados (estatística) mostrando isso?

E ainda não citou uma empresa, como lhe pedi anteriormente… deve estar difícil encontrar alguma no google né rs

tsc…tsc…tsc … ele não encontra nem as referências no Grande Guia e Oráculo dos Projetos…

Tenta no cuil rss…

"

"

"

"

"

Ok, eu não sou especialista em PMBok, mas eu menos de 5 minutos de leitura eu encontrei:

Isso vai totalmente de encontro com o manifesto ágil. Aliás, se dá muita enfase a um planejamento cabal de tudo o que vai acontecer no projeto.

Isso foi só um exemplo bem simples em menos de 5 minutos de pesquisas sobre PMBok. Tenho certeza se eu estudar um pouco mais sobre PMBok vou encontrar mais coisas que não são totalmente compatíveis com o manifesto ágil.

Ele é base de quais metodologias? Tem algum lugar que diz isso?

"

Marcos,

vc misturou as coisas novamente. O Azenha falou sobre PROJETOS DE ESCOPO ABERTO e vc está falando sobre DESENVOLVIMENTO ITERATIVO.

marcosalex:

Luiz Aguiar:

Eu dúvido vc e qualquer pessoa desse planeta achar apenas UMA citação de algumas das pessoas que contribuiram para a criação do scrum, do xp, fdd, dos formadores do manifesto ágil, falando essa afirmação que vc fez!

Bom, até agora você não encontrou nada delas que contrariem o PMBok

Não não… vc esta fazendo isso o tópico todo, invertendo os “valores”, vc que veio com o papo de que as metodologias ágeis seguem o PMBox, pedi citados dos autores eu pessoas bem influentes do “movimento ágil” e vc não deu, pedi referências de qualquer coisa relacionada a isso, mostrando isso e vc não deu. Então prove isso!
Não venha com esse papinho de que quer prova o contrário, porque até agora vc não deu prova de nada.

Pessoal, por favor, ajudem o Marcos procurar uma empresa, até agora ele não conseguiu, realemnte acredito que esteja defícil, se der um tempinho mais tarde te ajudo com isso Marcos.

"

Estamos esperando suas citações… vou almoçar pra dar um tempinho pra vc procurar no google rs

Não precisa chegar a tanto .Mais vou citar um link para vc. usar como suporte à sua opinião:

Ps. mais é para ler com calma ok.
Boa sorte.

Marcos,
na boa, eu nuca vi nenhuma pessoa/artigo/livro sobre agilidade mencionar alguma coisa sobre PMBock. Logo se vc diz que eles utilizam, vc deveria apontar exatamente aonde.

Outro ponto é vc mencionar que PMBock é um guia, mas não diz como fazer. Assim eu posso dizer que qualquer sistema que use alguma coisa citada de maneira superficial no PMBock o esta utilizando.E como ele não diz como fazer, deixa na mão de quem vai implementar. Se der errado, foi culpa de quem implementou, se der certo foi pq deguiu o guia. Assim fica facil, um guia que não se compromete com o resultado. Eu mesmo vou criar um guia bem abstrato em alto nivel e vou começar a vender consultoria e certificação sobre ele.
Acho que guias introduzem burocracia, e com isso prejudica o desenvolvimento. Não existe receita de bolo no desenvolvimento de software. Não adiante vc me dizer que vc vai usar as partes que quiser. Se eu estou usando um guia, gostaria que ele me guiasse ao resultado que eu espero. Como vou saber o que é certo p/ meu projeto? Contratando um consultor? Ja vi isso acontecer e o projeto tmb não deu certo. Sera que todas as pessoas que eu ja vi tentando implementar isso não tinham capacidade?

Como falei antes, não sei dizer que utilizar um guia é bom ou ruim, mas sei que consigo o mesmo resultado que eles prometem de manera bem mais simples. E falo isso baseado nas minhas experiencias.

[]´s

"

marcosalex:

mueller:

XP implementa PMBoK?

Eu nunca vi, nem ouvi falar um projeto com xp que usa uma WBS, idolatrada no PMBoK

Também ainda não vi projeto xp com aquele project charter detalhado …

Acho que dizer que xp/agile é uma forma de implementar PMBoK, é forçar demais

PMBok não diz que todo mundo é obrigado a usar WBS, ele é um escopo macro, nada mais que isso. Na maioria das vezes ajuda, principalmente quando não dá pra saber um escopo detalhado no início do projeto, mas não é obrigatório e o PMBok deixa claro isso.

Retirado do PMBoK, 3ªed.
Chapter 5, Project Scope Management, describes the processes involved in ascertaining that the project includes all the work required, and only the work required, to complete the project successfully. It consists of the Scope Planning, Scope Definition, Create WBS, Scope Verification, and Scope Control project management processes.
…
Create WBS. This is the process necessary for subdividing the major project deliverables and project work into smaller, more manageable components.

Então o PMBoK diz que é sim obrigatório criar um WBS. Além disso, para criar a WBS você vai utilizar
1. Organizational process assets
2. Project scope statement
3. Project scope management plan
4. Approved change request

E terá como resultado
1. Project scope statement
2. WBS
3. WBS dictionary
4. Scope baseline
5. Project scope management plan
6. Requested changes

Voltando ao que tinha comentado, isso não me parece muito agile

http://www.agile-software-development.com/2008/06/agile-teams-dont-need-managers.html

Engraçado…

“Times ágeis não precisam de gerentes”…

e eu acrescenteria: “… muito menos de PMPs”.

"

"

Marcos Alex,

Vejo que a discussão tá ficando quente e vejo que você é muito bem informado sobre o PMBOk e entende de metodologias ágeis e Scrum. Provavelmente se você estiver a frente de um projeto de software você conseguirá gerir ele de maneira eficiente, pois no mínimo você se interessa. Parabéns

Agora, vamos por partes:

“Planejamento em ondas sucessivas / Rolling Wave Planning [Técnica]. Uma forma de planejamento de elaboração progressiva em que o trabalho que será realizado a curto prazo é planejado em detalhes em um nível baixo da estrutura analítica do projeto, enquanto o trabalho distante no futuro é planejado em um nível relativamente alto da estrutura analítica do projeto. Porém, o planejamento detalhado do trabalho a ser realizado dentro de mais um ou dois períodos no futuro próximo é feito conforme o trabalho está sendo terminado durante o período atual.”

Peguei essa descrição que voce colocou aí. O ponto maior é: Nas metodologias ágeis, quem planeja o trabalho a ser realizado (o que vai ser entregue e o como será feito) é o TIME não o GERENTE. Essa é a maior e mais significativa contradição entre PMBOK e Metodologias ágeis. Isso não tem no PMBOK. Pros PMPs da vida, quem planeja o trabalho é o gerente

Falou, espero ter contribuído e que continue a discussão pacífica, como o Marcos já disse, sem argumentum ad hominem

Frentic:

Nas metodologias ágeis, quem planeja o trabalho a ser realizado (o que vai ser entregue e o como será feito) é o TIME não o GERENTE.

É verdade… e foi nisso que pensei quando vi o título do artigo que citei (sem lê-lo na íntegra). Mas fui traído … hehehe

Um gerente de projeto não precisa ter anos de experiência a área técnica (trabalhar na área técnica durante um bom tempo) ?

Pessoal há quem possa interessar, sigo o grupo e estou estudando arduamente e adquiri recentemente o simulado e livros para reforço e melhorei muito.
Segue link para quem tiver interesse.
http://produto.mercadolivre.com.br/MLB-575419367-rita-mulcahy-pmp-livro-fastrack-v8-pmbok-5ed-_JM
Abs
Flavio