Pessoal, recentemente, navegando pela NET, encontrei um post fantástico! Uma paródia sobre um mundo melhor para todos nós que trabalhamos com projetos, sejam eles de qualquer porte e qualquer setor.
Peço então licença para abaixo replicar, na íntegra, o referido post. Desde já, meus cumprimentos Claudiobr e Gustavo Sato
Imagine Agile by @oCladuibr and Gustavo Sato (Japa)
Sempre gostei muito do John Lennon. Todo dia oito de dezembro bate uma tristeza, queria muito saber o que ele acharia do que aconteceu de 1980 pra cá.
Acho que a sua obra prima é Imagine. Acredito que essa música é uma forma linda de vender a ideia de um mundo melhor e também de nos lembrar que esse mundo melhor não está tão longe ou é tão difícil quanto pensamos.
Tenho visões de mundo melhor em várias áreas, com destaque para a mobilidade nas cidades e o trabalho na área de TI, duas situações que agonizam. Tomei a liberdade de fazer uma adaptação para uma visão de mundo melhor dentro da TI. Que os músicos me perdoem. A paródia pode ser melhorada e muito, e conto com sugestões, do pessoal de TI, claro. Aí vai:
No blog do autor vocês podem econtrar a letra em ingles e portugues para a paródia.
Muito bacana!!!!
Abraços a todos e, que o mundo melhor venha até nós ;)
Scrum é um framework (conjunto de modelos) utilizado no desenvolvimento de produtos. Como todo framework, traz um conjunto de padrões/definições de processos e ferramentas, que, no caso do SCRUM, estão focados no desenvolvimento de produtos. Utilizado desde a década de 90 está amplamente difundido entre as empresas de desenvolvimento de software e objetiva melhorar os resultados das empresas através do uso de processos e práticas eficiente e eficaz.
Até aqui, a diferença do SCRUM para o PMBOK - padrão/conjunto de conhecimentos (por que não dizer também framework) do PMI para a gestão de projetos está no foco do SCRUM para a área de desenvolvimento de produtos. O PMBOK, conforme definição do própria guia, é um padrão amplamente reconhecido, o que significa que o conhecimento e práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo e que existe um consenso em relação ao valor e sua utilidade.
Outra diferença considerada pela maioria das pessoas, principalmente aquelas que criticam "cegamente" o PMBOK está na iteratividade/dinamicidade do SCRUM que gera a cada sprint, incrementos de funcionalidades entregáveis do produto final. De fato, um diferencial e tanto para a maioria das empresas de software que até então (ou ainda hoje) trabalham com os velhos modelos de engenharia como, por exemplo, o modelo em cascata, no qual o software só era apresentado ao cliente após longo período de desenvolvimento, não tendo assim avaliações/validação de cada módulo (entrega). O ganho que o SCRUM leva às organizações através da iteratividade/dinamicidade é realmente fantástico.
No entanto, iteratividade e agilidade não é uma característica apenas do SCRUM. Estão presentes também, e em vários momentos, dentro do PMBOK, como, por exemplo, no detalhamento progressivo, realimentações periódicas, planejamento em ondas sucessivas e construções de protótipos. E claro, no processo de verificação do escopo que também fala da importância para o sucesso do projeto da validação das entregas pelo cliente à medida que são produzidas. Enfim, se há gerentes de projetos que não adotam a iteratividade, creio ser muito mais uma característica ou maturidade destes, do que restrição do PMBOK.
Assim, está é uma "diferença" que para mim é atribuída de maneira incorreta. Para mim, além de estar focado em um tipo de projeto em específico - o que a torna de certa forma mais simples e "enxuto", a grande diferença entre SCRUM e PMBOK é o fato de o SCRUM considerar que as pessoas que fazem parte do projeto - o time - é auto gerenciável e auto organizável. O que seria o sonho de muitos gerentes de projetos é na prática muito raro de acontecer em projetos no qual a equipe é composta por dezenas e centenas de pessoas com muitas e diversas responsabilidades, atuações, interesses e até mesmo, localização geográficas. Talvez o SCRUM considere o time autogerenciável e autoorganizável porque o limita às pessoas internas à software house. E os clientes? E os usuários? E o governo com suas mudanças em legislação!? Etc. Etc. As pessoas “lá fora” não são tão organizadas e disciplinas e automotivadas como os “porcos” do SCRUM. Quando se amplia a visão, as coisas ficam um pouco mais complexas. Por isso, dada a importância de bem gerenciarmos a equipe do projeto, o PMBOK possui uma área de conhecimento específica para tratar dos assuntos relevantes à gestão de RH.
Por fim, e complementar ao tópico anterior, um último ponto de divergência que vejo é a maior abrangência do PMBOK, por exemplo, considerando também a gestão de comunicação com os demais envolvidos do projeto que não o time (mercado, governo, concorrente, etc. etc.). É como se o SCRUM estivesse centrado apenas do processo de desenvolvimento interno do produto e se "esquecido" do mundo externo. O que o PMBOK não esquece! Lembrando o PMBOK trata de nove áreas de conhecimento que são elas: Escopo, Tempo, Custo, Qualidade, RH, Comunicação, Riscos, Aquisição e Integração e nem todas estão presentes do SCRUM, o que, por si só, já o torna mais ágil. Porém, será que podemos mesmo ignorar estas áreas?! Qual o impacto desta decisão no projeto?
Em um post rápido, penso ser estas as três grandes diferenças entre SCRUM e PMBOK. E concluo dizendo que todo Gerente de Projeto deveria, se ainda não o faz, gerir seus projetos utilizando o conceito ágil (abordagem iterativa e incremental) fortemente presente no SCRUM e registrado também no PMBOK. Ou seja, podemos aproveitar as boas práticas do SCRUM para "apimentar" a gestão dos projetos, sem, no entanto, abrir mão de nenhuma das nove áreas de conhecimento do PMBOK ou de seus processos - claro, desde que necessários ao seu projeto. Digo isso por não sou a favor do uso full do PMBOK, apenas por usar.
E, diferenças a parte, encaro que a característica de agilidade muito mais um filosofia – um modus operandi – do que uma algo que só está presente em um ou outro framework. E creio que podemos e devemos fazer um mix entre as diversas publicações, utilizando sempre aquele processo/ferramenta/ideia que melhor resultado trouxer.
E vocês, o que acham?! Vamos amadurecer esta ideia!? Comentários são bem vindos!