Rate:
1 Star2 Stars3 Stars4 Stars5 Stars 35 vote(s)
Loading ... Loading ...
28 Comments

This week Ricardo continues the talk about agile project management and Scrum. In this podcast, Ricardo shows his perceptions about the use of agile and how this can be used in conjunction with PMBOK Guide and other aprroaches to a successful Project Mangement practice. Second podcast about the subject.

 
[8:24m] Download

(This podcast is also avaiable in Brazilian Portuguese. Listen to the Portuguese version)

Generate PDU Report

  1. Ana Paula Rodrigues Pereira says:

    Ricardo,
    Tive o grande prazer de obter a minha certificação mes passado e receber meu certificado com a sua assinatura. De um brasileiro que apesar de tudo continua muito preso as suas raízes e a seu sotaque deliciosamente mineiro.
    Adoro os seus podcasts e quanto a este do Scrum apesar de não ser muito a sua praia concordo em muitos pontos contigo.
    Este antagonismo que fazem entre PMBoK e o SCRUM (lento e ágil) é a total demonstração da ignorancia normalmente advinda dos pessoal de TI, como eu mesma. Faço uma comparação as boas praticas do PMBoK com as ferramentas de UML. Gostaria de saber qual o analista que algum dia implementou todos aqueles diagramas e modelos que a ferramenta oferece? Nenhum. E nem por isso, se descute que ela não seja a ferramenta de analise de sistemas orientado a objeto. Deveriamos pensar o mesmo dos 42 processos do PMBoK, ultima versão.
    Mas confesso que o pouco do que li sobre o SCRUM não sei onde fica registrado lições aprendidas e o proprio planejamento em si. Por acaso é em post-it???
    Abraços
    Paula
    skype paula.rodrigues

  2. Olá Ricardo,

    Sobre a parte de times auto-gerenciáveis, na verdade não significa que não há acompanhamento nem controle no Scrum, muito pelo contrário. Durante as reuniões diárias o antigo “gerente de projetos” age como um facilitador, um líder que ouve, que ajuda o time a se comunicar e a criar comprometimento entre as tarefas que estão distribuídas entre os membros, além disso, garante que a produtividade seja sempre alta ao entender as necessidades e retirar impedimentos que surjam pelo caminho.

    Acreditamos que o time é formado por especialistas, desta forma, ninguém melhor do eles para quebrar um objetivo em tarefas (o que x como). Outro ponto interessante é que cada indivíduo escolhe a tarefa que fará (trabalhos nunca são atribuídos). Eles se organizam para resolver um determinado problema da melhor forma possível, seguindo sempre a prioridade. Todos estão orientados a metas.

    O que precisa ser enfatizado são os valores do Agile (que não é só velocidade), afinal os indivíduos e a interação entre eles tem mais valor que processos e ferramentas. Tudo é baseado na transparência, confiança e colaboração :)

    Sei que o Scrum funciona extremamente bem em projetos onde há uma alta quantidade de mudanças, como software, por exemplo, além de diversas outras áreas. Nunca trabalhei em plataformas de petróleo nem em projetos de engenharia, mas se você conseguir logo no início planejar tudo e fechar o escopo, talvez nem seja necessário adotar o Scrum. É um caso a se estudar.

    Abraços,
    Henrique

    • Henrique

      Obrigado pelo comentário. Quando vc tem o que chamamos de SDWT (Self Directed Work Team) o gerente de projetos ou scrum master atua como facilitador do processo de comunicação, sem autoridade para fazer o processo “acontecer” de modo direto. Esse foi meu comentário. Nos mais de 150 projetos que eu ja fiz eu nunca tive a felicidade de trabalhar com um SDWT.

      Quanto ao conceito de agilidade, realmente eu não tive a intenção de falar em agilidade como “velocidade”. Foi perfeita a sua complementação sobre agilidade.

      Quanto a empregabilidade em outros setores além do de TI, vou me dedicar intensamente a estudar esse assunto. Quem fizer isso vai sair na frente demais. Opinião de quem ama agilidade, mas nem de longe é expert em software. Abs

      • Oi Ricardo,

        Parabens pelo material.

        Mas deixa eu completar a parte de equipes auto-gerenciáveis.

        Existe autonomia da equipe? Sim. Mas esta autonomia é restrita.

        Em Scrum a equipe participa do projeto desde a sua Iniciação, com o recebimento da visão do projeto e os itens de backlog.

        Depois a equipe vai para o planejamento, que chamamos em Scrum de Sprint Planning, onde um conjunto de requisitos entra como atividade da Sprint.

        Os requisitos que vão ser executados na Sprint foram priorizados pelo Product Owner e a equipe faz o trabalho de analise de sistemas.

        Uma vez feito o entendimento dos requisitos que vão ser trabalhados na Sprint, a equipe quebra estes requisitos em tarefas.

        Estas tarefas são adicionadas em um quadro de Kanban em forma de post-its(para quem não utiliza software de gerenciamento).

        E ai que entra o auto-gerenciamento, a equipe pode escolher qual a ordem de execução dos requisitos que estão na Sprint e para cada requisito qual tarefa ela vai executar.

        Não existe o esquema manda-faz para as tarefas, a equipe dentro da Sprint se organiza e executa.

        Amplexos,

        Abu

      • rildo polycarpo says:

        Caro Ricardo Vargas, estou dando início à minha atividade no campo do gerenciamento de projetos e, interessado em agilização, contudo sem a depauperação de uma complexidade muitas vezes inerente a projetos por serem desenvolvidos, o conceito de “agile project management” prontamente me capturou a atenção. Também tenho me iniciado em PMBoK e partilho com Você o interesse na “empregabilidade [do Agile PM] em outros setores além do de TI”. Acredito que o seu site será um bom espaço para me manter informado e, na medida de minhas possibilidades, para a troca de idéias. Parabéns por seu trabalho.

      • rildo polycarpo says:

        Ricardo e demais interessados no tema “Agile PM” + “Project Management (in general)”.
        Recebi, ainda ontem, esta newsletter de Bas de Baar, abaixo reproduzida. O Video Podcast pode ser visto nesta página: http://blog.softwareprojects.org/the-pmi-agile-community-of-practice-1849.html

        “Different circumstances require different project approaches. Sometimes we need a piece of plan-driven, other times we need a bucket of agile. But we are always in need of Project Leaders that know how to handle all available project strategies”.

        “That is why I am very excited about the recently founded PMI Agile Community of Practice. It’s one of the latest communities of the Project Management Institute, the largest Project Management organization with a strong “plan-driven” tradition. The new community aims to equip PMI Members with Agile skills and knowledge”.

        “In this episode of The Project Shrink Podcast I am talking to Jesse Fewell, one of the people involved in starting the community”.

        “We discuss what PMPs can learn from agilist and vice versa; and what people can expect from the new community”.

        […]

        Bas de Baar
        http://ProjectShrink.com

      • Raul Antunes says:

        Ricardo, boa noite.
        Primeiro, agradecer por todos os comentários que se pode ler e absorver conhecimento..muito legal. Segundo, aproveitando o comentário do caro Henrique Imbertti Jr., e com sua rica resposta, quero dizer-lhe que também venho estudando a aplicação do SCRUM para gerenciar atividades das fases de um ciclo de vida no BPM, cujo o objetivo é promover não só rapidez na produção das atividades, mas também a integração das áreas de negócio com o Escritório de Processos. Neste caso, ao Escritório de Processos acredito deva ser atribuído o papel do SM, porém o ST deva ser instruído pelos membros da área de negócio, supervisionados por um Analista de Processo.

        Bom, não vou alongar-me na reflexão, pois o motivo foi mesmo compartilhar a mesma linha de estudo sobre as aplicabilidades do SCRUM, exclusivamente, em outras áreas.

  3. Edivandro C. Conforto says:

    Olá Ricardo,

    Muito oportuno este podcast. Tenho acompanhado já tem um tempo seus posts e este veio no momento que este assunto “agile project management” está no foco das discussões sobre gerenciamento de projetos. Já estudo o assunto a mais de 2 anos, porém com enfoque no desenvolvimento de produtos inovadores e complexos que envolvem hardware e software, e percebo a evolução das discussões sobre o assunto, pois quando falei sobre gestão ágil pela primeira vez não tive um bom feedback e encontrei resistência por parte de alguns membros da platéia. Vejo o assunto de extrema importância assim como o Lean Thinking foi para a evolucão da indústria automobilística na década de 80.

    Do meu ponto de vista os princípios e valores do pensamento ágil são válidos para todo tipo de projeto, independente do setor, software, petróleo, bens de capital, etc… Ainda não consigo definir se este é o termo correto, é preciso estudar mais, poderia ser Lean Project Management, quem sabe?

    Acho que são complementares, as melhores práticas contidas no PMBoK e os princípios do pensamento ágil. Se analisarmos o manifesto ágil, 2001 que tornou o termo mais difundido na área de software iremos perceber que trata-se de dar mais enfoque no desenvolvimento de equipes, na liderança, e o aprendizado contínuo, proporcionando um ambiente de projetos mais sustentável e de alto desempenho, o que não é tarefa fácil.

    No entanto, vejo isto como a evolução da gestão de projetos, pois técnicas e práticas de como planejar e controlar um projeto estão bem difundidas e são bem conhecidas da maioria dos gerentes de projetos. Entendo que é necessário desenvolver melhor a questão da liderança na gestão de projetos, a gestão de pessoas, como gerenciar conflitos, motivar a equipe, e torná-la auto-disciplinada e auto-gerenciável, papel fundamental para que a equipe de projetos tenha melhores resultados, principalmente no cenário econômico que estamos enfrentando atualmente. Nesse aspecto acho que o pensamento ágil pode ajudar, além é claro, de buscar a simplificação do do processo de gerenciamento de projetos, pois sem dúvida, conforme você mesmo disse, o que importa é resultado, e agregar valor para o cliente e para o negócio, e um ponto importante, não se trata apenas de rapidez, agilidade.

    Sem dúvida este é um assunto que gera muitas discussões, e um assunto do qual temos muito que aprender, porém temos que estar com a mente aberta e quebrar paradigmas. Prova disso é a preocupação das associações de gerenciamento de projetos em abordar o tema. Eu mesmo estou tendo a oportunidade de falar sobre o assunto em diversas ocasiões, principalmente em congressos internacionais, e o feedback está sendo positivo! Sem dúvida quanto mais discutirmos e trocarmos experiências melhores serão os resultados, e estaremos contribuindo para a evolução e melhoria contínua da disciplina de gerenciamento de projetos.

    Grande abraço,
    Edivandro C. Conforto

  4. Daniel de Amaral says:

    Olá Ricardo, deixo como recomendação a leitura dos seguintes livros:

    – Agile Project Management: Creating Innovative Products. (Jim Highsmith).
    – Agile Project Management: How to Succeed in the Face of Changing Project Requirements (Gary Chin).
    – The Software Project Managers Bridge to Agility (Michele Sliger; Stacia Broderick).

    Todos tratam de forma muito interessante o conceito do gerenciamento ágil de projetos. O último, inclusive, aventura-se em ligar os processos do PMBoK com as práticas do gerenciamento de projetos frente a utilização de metodologias ágies de desenvolvimento de software.

    Minha monografia de graduação (qual estou acabando neste exato instante, trata exatamente deste tema – o gerenciamento ágil de projetos). Coincidência não?

    Grande abraço.

    • Paulo de Tarso Bittencourt Cunha says:

      Oi Daniel de Amaral,

      Sou Gerente de Projetos há muito tempo e PMP. Trabalho em pequena empresa de Consultoria de TI e a maioria dos nossos projetos são pequenos (4 a 6 meses).
      No acompanhamento destes projetos sempre procuro implantar alguns processos do PMBoK. Ultimamente tenho lido e participado de grupo de discussões a respeito do Scrum, para procurar aplicar no meu trabalho, ou seja, aplicar o conceito do gerenciamento ágil de projetos junto com as práticas do gerenciamento de projetos – os processos do PMBoK.
      Paralelo a isto, estou começando a fazer uma monografia final do meu curso de pós de graduação sobre os pontos de convergência e divergência do PMBok e Scrum, e participando deste Podcast, li que a sua monografia de graduação trata deste tema. Gostaria de ter contato com você para obter subsídios, dicas de livros, etc. É possível?

      abraços,

      Paulo

  5. William Sbordoni says:

    Apesar de Scrum ser inventado e utilizado primeiramente em uma empresaautomobilística, ele se enquadra perfeitamente em engenharia de software.

    Existem algumas premissas para se utilizar SCRUM na elaboração de um software, entre elas são:
    – primeiramente deve ser uma solução com baixa, média complexidade de regras de negócio;
    – deve ter uma pessoa conhecedora do negócio disponível para esclarecimento de dúvidas.

    Quando estiver falando de um projeto muito grande ou complexo, eu acredito que seja mais interessante utilizar uma metodologia mais documental como o UP (Unified Process). O UP e o Scrum possuem uma característica em comum, entrega iterativa, mas é viável a utilização do Scrum dentro da metodologia UP, você pode até perguntar como, dentro de cada disciplina do UP, cada equipe pode utilizar Scrum para o desenvolvimento de suas atividades, é provável que seja eficaz a utilização desta idéia em outras engenharias de projetos mais complexos que possam ser entregues resultados de forma iterativa.

    Com experiência voltada para software, a qualidade de seu software utilizando Scrum vai depender da qualidade de sua equipe. Se você tiver uma equipe com Juniores, é obvio que o software vai ter uma péssima arquitetura e que terá um maior tempo de desenvolvimento.

    Em uma fábrica de software, você consegue manter uma boa qualidade com uma equipe de juniores por causa dos artefatos de entrada para o desenvolvimento.

    Quando se pensa em uma equipe auto gerenciável, auto disciplinar, isso não é impossível, na verdade esse conceito é utilizado de uma forma diferente, cada um escolhe a atividade que irá desenvolver, ou seja, qual atividade ele tem mais facilidade dentro das prioridades estabelecidas. A equipe Scrum possui um gerenciamento, ela é gerenciada pelo Scrum Master, pode-se considerar que ele é um gerente de projeto e um facilitador, ele que resolve os problemas e abre os caminhos para a equipe e ele que repassa as prioridades, outra evidência de gerenciamento são as reuniões diárias, onde cada um reporta o que fez no dia anterior, dificuldades enfrentadas e como foram resolvidas.

    É claro que dependendo do tipo de projeto, como exemplo uma construção civil, não se espera que os operários da obra sejam auto gerenciáveis, e você não colocará engenheiros para levantar paredes, neste caso Scrum não serve, mas para a elaboração de plantas, levantamento de custos você até pode ter equipes que trabalham com Scrum.

    O exemplo acima é semelhante o da fábrica de software, você tem equipes paralelas auto gerenciáveis gerando insumos, documentos, para a fábrica colocar a mão na massa e desenvolver.

    Atenciosamente.
    William A. Sbordoni

  6. Rafael Leite says:

    Obrigado pelo podcast Ricardo!

    Vejo que um dos pontos importantes sobre Agile (mais especificamente SCRUM) em um contexto PMI é o time auto gerenciável.

    No meu entendimento, no contexto onde trabalho e nos quais já trabalhei (sempre desenvolvimento de software), o papel do Scrum Master é diferente do papel do Gerente de Projetos. Para mim são pessoas diferentes. Explico:

    1. O Scrum Master deve fazer parte da equipe, para não ser mais um “frango”. Assim, também é um desenvolvedor e deveria passar pelo menos 50% do tempo atacando os itens do backlog para não se afastar dos outros membros, “sentir” o ritmo e as dificuldades e para mostrar comprometimento (“porco”);

    2. Muitas vezes o projeto não é só desenvolvimento de software, portanto necessita de alguém para gerenciar a execução dos demais pacotes de trabalho. Se o Scrum Master também se responsabilizasse por isso, se afastaria ainda mais da equipe, quebrando o item acima;

    3. Um detalhe importante citado pelo Ricardo foi o “fazer acontecer”. Acho que podem existem equipes com maturidade suficiente para tomar decisões importantes, assumir responsabilidades, mas pelo que conheço todas precisam de uma interface com o meio externo. Alguém para dizer “não” e assumir a responsabilidade, alguém para filtrar “broncas” e para cobrar ritmo.

    4. Muitas vezes as equipes de TI são um recurso compartilhado entre vários projetos. Aqui é mais clara a necessidade do Gerente de Projetos ser alguém diferente do Scrum Master: estes gerentes vão negociar a alocação da equipe de TI nos seus projetos, conforme as mudanças forem ocorrendo.

    Nos itens acima eu não entrei no mérito da gestão de projetos vs. a gestão funcional. Esta última pode responder por algumas coisas, como filtrar as “broncas” e cobrar ritmo. Mas tratar desta diferença complicaria ainda mais o comentário, pois seria necessário analisar muitos outros pontos.

    Em projetos de desenvolvimento de software eu sou favorável da união de forças: PMBoK + SCRUM.

    Um abraço!

  7. Ola Ricardo,

    Uns 02 anos acompanho você bem mais de perto. E todo vez acabo esquecendo de comentar seus posts ou mesmo mandar e-mail para você(que vou mandar esse semana). Mas vamos ao foco no podcast.
    Você entrou numa questão muito interessante, essa visão de “leve” do SCRUM e o “pesado” PMBOK. E desculpe-me a petulância, mas vou complementar com o uso do termo “metodologia PMBOK ou PMI” como queira, pelos profissionais em Geral, principalmente PMP´S. Particularmente aconteceram 02 casos bem interessantes ontem.
    01. Estou com um projeto grande de um SIG(sistemas de informações gerenciais) e empresa parceira de desenvolvimento de software ontem me abordou dizendo que iria colocar o valor que possuo “dentro” da metodologia SCRUM com isso teriamos se o valor financeiro que o cliente possui inicial daria ou não para executar o escopo. Na minha cabeça vieram tantas coisas sobre como isso estava incoerente, que de perguntei, mas porque você não usa as melhoresa práticas de GP(Guia PMBOK), responderam-me que era “muito demorado” e “pesado” e nunca iriamos conseguir mensurar isso.
    02. Estou orientado um aluno no curso de SI, que vai fazer um estudo de caso para indentificar qual a melhor forma de Gerenciar Projetos numa pequena Software house local. Mas que em uma de suas hipostes está colocando a questão do SCRM, XP, etc., ou seja, esses metodos ágeis. Por mais que o referencia teorico dele seja o PMBOK, baseando num camarada chamado Ricardo Vargas.:). Achei interenssante sua abordagem pois o resultado pode ser interessante e provar algumas coisa que penso.
    Bem enfim, vejo isso no dia a dia de aula ou consultoria os profissionais agindo e falando dessa forma. Menos quando estava na curando o MBA da FGV(com alguns companheiros seus como: carlos augusto, Carlos Magno e Finochio Jr. etc.), nos passaram outro nivel de compreensão(correta).
    Particularmente trabalho com TI(TI e não informatica), mas minha formação acadêmica é de Gestão, sou administrador, especialização em gestão, MBA em GP e mestrando em Gestão. Então Ricardo isso sempre foi para mim bem claro. “Sofro” sempre um certo preconceito no mercado de TI, pois não sou “tecnico”, mas consigo reverter isso no prática ou demonstrando isso em aulas etc. Enfim lembro muito daquele seu DVD em que você diz que agora é um admnistrador…, bem como nesse último podcast os seus comentários sobre questões como essa, percebo que não estou “louco” por pensar assim, como diria o poeta.
    Espero ter um mesmo prazer na nossa amiga Ana Paula em receber, caso passe, meu certificado com sua assinatura BRASEILEIRA MINEIRA.
    Tudo de bom e sucesso.

    Eduardo Freire

  8. Ricardo,

    Como sempre instigante e provocador. Muito bom mesmo! Sem entrar em maiores detalhes sobre conteúdo ou perfeccionismos exagerados, o que tenho é dizer é parabéns.

    E nesse caso especificamente pela tua coragem. Porque a maioria das pessoas no seu lugar, com uma posição de destaque dentro de um universo que você domina (Gestão de Projetos tradicional, vamos chamar assim), jamais iria “dar a cara a tapa” e falar de agile.

    Então meu caro, não é a toa que você está onde está.

    Parabéns!!!

    • Ei Andre

      Valeu demais pelo comentário. Realmente esse podcast deu o que falar. Mas é legal mostrar a opinião e pelo menos provocar a discussão. Assim que eu virar Scrum Master eu faço outro… Abraços.

  9. Ricardo,

    Sensacional a série Gerenciamento ágil de projetos. Penso exatamente como vc. A agilidade SCRUM não é antagônica ao que prega o PMBOK.

    Trabalho com gestão de projetos, e aplicamos conceitos e princípios ágeis junto com processos e recomendações propostas pelo PMBOK, e em aderência aos processos definidos pelo CMMi.

    Parabéns!

  10. Gabriela says:

    Excelente podcast! Já li alguns artigos sobre scrum e acho que a metodologia tem várias vantagens para quem trabalha com desenvolvimento de softwares. Também já vi muita gente criticando o PMI por causa do grande número de processos e áreas de conhecimento, porém concordo quando você diz que se a pessoa não quer trabalhar com o processo X que não trabalhe, se quer mudar que mude. O PMI não “nasceu” para engessar nenhum projeto e sim para melhorar as práticas no gerenciamento, cada um deve ajustar o que quer para suas necessidades.
    Abs,
    Gabriela

  11. Douglas says:

    Ricardo, como primeiro ponto dou o parabéns pelo compartilhamento de informação que vc realiza por este meio.
    Sou principiante na área de gestão de projetos tenho a seguinte visão aqui no Brasil sobre as técnicas utilizadas e a cultura organizacional , pois acho que o gerente de projeto deve ter a capacidade de analisar a cultura organizacional (conhecer a cultura da equipe e da empresa ) para assim futuramente poder avaliar quais as melhores técnicas que podem ser utilizadas no projeto para assim atingir o máximo de produtividade , como eu disse previamente ainda sou um pouco leigo nesta área , mais a meu parecer aqui no Brasil não podemos usar uma única linha de raciocínio, creio que para atingir os melhores resultados aqui a solução seria a criação de algum modelo híbrido tomando a união das técnicas formais e as técnicas informas de cada empresa.

    Att.

    Douglas Z. Piva

  12. Kathleen says:

    Olá Ricardo,

    Sou da área de TI e também PMP, atuo em gerenciamento de projetos, definição de metodologia (PMO) e vejo como nos últimos tempos há uma certa aversão das equipes de desenvolvimento com relação ao uso das melhores práticas de gerenciamento PMBOK. Acredito que muito das práticas que são usadas na metodolofia ágil são práticas citadas no PMBOK. Exemplo: Lições Aprendidas (PMBOK) durante/fim do projeto, são as reuniões de retrospectiva, as reuniões de acompanhamento do projeto (PMBOK)- reuniões de stand-up – não nada no PMBOK que diga a frequencia e nem se será sentado ou feito de pé as reuniões de acompanhamento do projeto, registro de problemas e verificação de impeditivos. Acho que a grande problema/diferença é o fato de não haver cronograma, estimativas, dependência técnica, análise de caminho crítico e levar em consideração que a equipe será sempre homogenia, que sabemos que não é uma verdade, as pessoas são diferentes umas das outras e precisamos identificar e ajudar a se desenvolve-las. Outros pontos que torna-se difícil é avaliar o custo do projeto, a produtitvidade da equipe e se o resultado gerado é a melhor forma de ser feita.

  13. Ivania says:

    Muito obrigada Ricardo, até que enfim encontrei uma opnião inteligivel sobre estas metologias distintas e ao mesmo tempo paralelas que levam ao mesmo destino simultaneamente!

    Adorei o “para que serve uma banda larga se a sua mente é pequena” Esse recado deve servir para muita gente que critica o PMBok!

    Abração e até semana que vem no PMDome…

  14. I have recently started a site with topics about diseño web profesional, the information you provide on this website has helped me tremendously. Thanks for all of your time & work.

  15. Jorge Aguiar says:

    Caro Ricardo,

    Abusando um pouco de seu conhecimento, é possível aplicar o SCRUM em uma empresa de construção civil que gerencia muitas obras ao mesmo tempo? Tenho buscado uma ferramenta que permita visualizar rapidamente o estágio em que se encontra cada obra e quais equipes (projetos, compras, instalação, comercial,…) estão realizando tarefas em cada uma dessas obras. Pelo que tenho lido estou pensando em implantar um sistema baseado no SCRUM e aí cada líder de equipe lançaria as tarefas já executadas e aquelas que estão em andamento. Dessa forma a reunião semanal que se faz para esta análise seria tremendamente agilizada, o que vc acha?

  16. Karin says:

    Em primeiro lugar, eu respeito muito você, porque desde o primeiro momento em que me deparei com gerenciamento de projetos, sempre escutei os seus podcasts e sempre concordei com as suas ideias.

    Mas sobre agile… pra mim é muito importante no mundo web e eu já tive o prazer de ter uma equipe auto gerenciável e isso é demais!

    Mas no seu caso, falando sobre processo de anos, acho complicado mesmo alguns pontos de agile, mas gostaria sim de ver a comunhão de conhecimentos de PMI e Agile para um bem maior e deixar essa “mente estreita” de lado.

    Ainda vou ter que escutar muitas vezes esse podcast e desenvolver mais esse assunto na minha mente, mas nunca pensei sobre agile e petróleo juntos =D Mas é sempre bom quebrar barreiras.

    Sucesso sempre!

  17. […] longo “namoro” que incluiu a criação de um grupo de estudo e declarações de pessoas influentes do PMI sobre Agile e […]

Leave your comment ( * Required fields )

Disclaimer
We reserve the right to exclude any comment with offensive, pejorative, promotional or out of the context content. Read the full disclaimer.