Page 1

SCRUM E PMBOK JUNTOS. É POSSÍVEL? Diego Roberto Rodrigues Borges (ALFA) diegorrborges@gmail.com

Resumo: A utilização de práticas de processos Ágeis com práticas Tradicionais de gerenciamento de projetos é um desafio, porém não é impossível. Há muitos profissionais que são radicais quanto ao uso de uma ou outra abordagem, e que acham impossível que o processo Ágil e tradicional possam ser aplicados conjuntamente. Mas o histórico da indústria de software está mostrando que é sim viável e positivo. O segredo está em saber adaptar o processo, pois não há solução perfeita. Este artigo tem como objetivo descrever um pouco sobre o Scrum e também o PMBOK e mostrar fatos e casos de sucesso sobre a integração entre o Scrum (método ágio) e o Pmbok (método tradicional). . Palavras-chave: Gerenciamento de Projetos; Métodos Ágeis; PMBOK; Scrum.

1. INTRODUÇÃO

Com a crescente competição entre empresas de todo o mundo, buscando um diferencial num mercado, partiram para a adoção de programas de qualidade total e melhoria contínua. E a busca dessa melhoria continua é influenciado pela qualidade no processo de produção. Para isso estas empresas utlizam o Gerenciamento de Projetos (GP) que é a aplicação de conhecimentos, habilidades e técnicas na elaboração de atividades relacionadas para atingir um conjunto de objetivos pré-definidos. Dentre a utilização destes modelos e melhores práticas é importante destacar o Project Management Body Of Knowledge (PMBOK) que é uma metodologia considerada como tradicional e tem como objetivo identificar o subconjunto de conhecimentos sobre a profissão, através de práticas tradicionais e inovadoras, aplicáveis para a maior parte dos projetos, na maior parte do tempo. Outro modelo é o Scrum que é uma nova metodologia para desenvolvimento de software tem despertado grande interesse entre as organizações de todo o mundo, devido à necessidade de um desenvolvimento ágil de aplicações, por ocasião do ritmo acelerado de mudanças na tecnologia da informação e do grande dinamismo no ambiente de negócios. Este artigo retrata estas metodologias e demonstra que existe uma sinergia muito grande entre as duas metodologias, ou seja, que uma pode complementar a outra no desenvolvimento de projetos.


2  

2. MÉTODOS ÁGEIS DE PROCESSOS As Metodologias Ágeis de desenvolvimento de software se propõe a construir softwares com maior produtividade e, sobretudo, com qualidade garantida. Para isso elas encaram os projetos sobre um novo paradigma e defendem a adoção de uma série de princípios e práticas. Entre as quebras de paradigma está a forma de encarar a mudança. Ela é encarada como algo inevitável no projeto de software. Enquanto que as metodologias tradicionais abordam o escopo como fixo devendo ser controlado o máximo possível para não haver mudanças; as Metodologias Ágeis abordam o escopo como manipulável e oferecem flexibilidade para sua mudança. Um dos princípios do Manifesto Ágil (AGILE MANIFESTO, 2001) diz que “Mudança de requisitos são bem vindas, mesmo em estágios tardios do desenvolvimento. Processos Ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente”. O termo Metodologias Ágeis surgiu a partir de um manifesto criado por dezessete profissionais veteranos na área de software, representantes de diversas metodologias, que reuniram-se no ano de 2001 no EUA para discutir o que havia em comum entre estas metodologias. Esse manifesto foi chamado de Manifesto for Agile Software Development, ou simplesmente Agile Manifesto (AGILE MANIFESTO, 2001). Neste manifesto foram descritos princípios que as metodologias de desenvolvimento ágil deveriam seguir: “Estamos evidenciando maneiras melhores de desenvolver software fazendoo nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:  Pessoas e interação MAIS QUE processos e ferramentas;  Software em funcionamento MAIS QUE documentação abrangente;  Colaboração com o cliente MAIS QUE negociação de contratos;  Responder a mudanças MAIS QUE seguir um plano. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.” (AGILE MANIFESTO, 2001).

Entre as Metodologias Ágeis, com representação no manifesto está o Scrum, uma Metodologia Ágil para gerenciamento de projetos de software, cuja principal referência são Ken Schwaber, Jeff Sutherland e Mike Beedle.


3  

2.1 SCRUM Scrum é um processo iterativo e incremental para desenvolvimento de qualquer tipo de produto ou gerenciamento de qualquer tipo de trabalho (CONTROL CHAOS, 2008). O Scrum é uma metodologia ágil para Gerenciamento de Projetos. No Scrum, os projetos são dividos em ciclos (tipicamente de 2 a 4 semanas) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum. A cada sprint o esforço é para se entregar itens com o maior valor de negócio (e prioridade) ao cliente, dando a ele algo real e de valor para o negócio. A figura 1 mostra o ciclo de vida do Scrum.

Figura 1 - Ciclo de vida do Scrum. (WIKIPÉDIA, 2010).

2.1.2. Product Backlog É a lista de tudo que se deseja para o software, de uma maneira enxuta, sem detalhamento. O grande diferencial é que esta lista não precisa estar completa logo no inicío,


4  

não precisa ter 100% do itens possíveis e imagináveis. O Product Owner (PO) define essa lista, que pode ir ganhando outros itens ao decorrer do desenvolvimento das Sprints, ele também detalha os itens em cada planejamento de Sprint, e prioriza os itens, a equipe define quais itens cabem ou não dentro da Sprint, essa lista gerada tem o nome de Sprint Backlog. O processo se repete a cada ciclo de desenvolvimento.

2.1.2. Reunião Diária (Scrum Daily Meeting) A reunião diária serve para a equipe se alinhar em relação ao desenvolvimento dos itens do Sprint Backlog. Esta reunião deve durar no máximo 15 minutos, seu conteúdo é exposto pela equipe basicamente respondendo 3 perguntas: 

O que eu fiz ontem?

O que farei hoje?

Quais impedimentos eu tive?

2.1.3. Revisão (Sprint Review) Está é uma reunião muito importante do ponto de vista do cliente, nela, tudo o que foi desenvolvido durante o Sprint será apresentada para os responsáveis pelo projeto, o cliente em si, ou as pessoas que o represente. Cada história (user stories) é apresentada de acordo com a ordem de prioridade definida no Sprint Backlog, e o cliente dá o aceite final a história e indica se a Sprint atingiu a meta proposta.

2.1.4. Retrospectiva (Sprint Retrospective) Ao término de cada Sprint, a equipe se reúne para analisar a Sprint que encerrou, com o propósito de um constante aperfeiçoamento. Nessa reunião serão debatidos o que funcionou bem na Sprint, o que precisa ser melhorado e quais ações serão tomadas para colocar essas melhorias em prática.

2.1.5. Product Owner Este é o integrante que representa o cliente, que conhece o negócio e as regras do funcionamento dele. O Product Owner é responsável por criar o Product Backlog e priorizálo. Como ele é quem sabe o que é mais importante pro negócio, ele também fará as alterações dos itens, seja prioridade ou remoção e adição de novos.Em algumas empresas esse papel é conhecido como Gerente de Produto, e também outros nomes semelhantes.


5  

2.1.6. Scrum Master O Scrum Master é o papel responsável por fazer o ambiente Scrum funcionar, verificando se o time está respeitando e cumprindo os valores e práticas do Scrum. Ele também orienta o time no Daily Meeting corretamente e é o responsável por remover todos os impedimentos apontados. Ele protege a equipe de interferências externas, assegura que os Sprints não contenham itens além do que pode ser realmente entregue. O Scrum Master é um facilitador, alguém que tem a missão de fazer o time funcionar e aplicar corretamente o Scrum.

2.1.7. O Time (team) O Time é responsável por transformar itens do Product Backlog em itens do Sprint Backlog e transformar esses itens em software pronto para ser entregue. As equipes de Scrum contém geralmente entre 5 e 9 pessoas, não mais do que 10, isso é essencial para a boa prática do Scrum. Os membros são multifuncionais, podendo conter desenvolvedores, designers, arquitetos da informação, entre outros. Outra característica importante é que os times são auto-gerenciáveis, sendo eles responsáveis por controlar as tarefas do desenvolvimento da Sprint.

3. PMBOK O PMBOK Guide é o principal documento de referência do Project Management Institute (PMI), embora não seja o único. Como o próprio nome em português diz, ele é “Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos”. Está atualmente na terceira edição, lançada em 2004. Como ele mesmo descreve o seu objetivo é: “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, 2004, p. 3).


6  

No PMBOK Guide encontram-se muitas definições e práticas que guiam na gerência de projetos em geral. Entre algumas dessas definições está o projeto é descrito pelo PMBOK Guide (PMBOK, 2004) como “um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. Quando diz temporário, significa que o projeto deve ter um início e fim definidos. A metodologia de gerenciamento do PMI também organiza os 44 processos (3ª edição – PMBOK 2004) e 42 processos (4ª edição – PMBOK 2008) em nove áreas de conhecimento. A figura 2 demonstra as definições de cada área de conhecimento..

Figura 2 - Visão geral das áreas de conhecimento em gerenciamento de projetos (MÁRCIO, 2007).

4. SCRUM versus PMBOK ? 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 para o sucesso de um projeto. 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, 2004, p. 3).


7  

Entre estas práticas inovadas estãos as metodologias ágeis existentes como o Scrum. Segundo MICHELE SLIGER (2006) em uma série de artigos entitulado “Relating PMBOK Pratices to Agile Pratices” (SLIGER, 2006), a autora discute uma abordagem consistente de como trabalhar com PMBOK e Metodologias Ágeis. Cita ainda que apesar das diferenças de filosofias entre PMI e Agile, muitas das práticas do PMBOK são compatíveis com as práticas ágeis. Nesta séria de artigos Michele Sliger destaca que para cada uma das áreas do PMBOK, suas práticas têm práticas relativas nas Metodologias Ágeis, porém a forma de executar é diferente. Dentre estas aréas de conhecimento do PMBOK (integração, escopo, tempo, risco e qualidade) que possuem semelhanças é demonstrado na figura 3 o grupo de processos mapeado do PMBOK e de metodologias ágeis.

Figura 3 - Grupos de processos mapeados para Agile Jim Highsmith quadro de Gerenciamento de Projetos. (MICHELE SLIGER, 2006).

No gerenciamento de integração o principal processo é o desenvolvimento do plano do projeto, definindo como o projeto será executado e controlado, onde contém os planos para cada uma das áreas. Já nas Metodologias Ágeis o plano é feito e revisitado continuamente, com um nível de detalhe o suficiente para a realidade de tempo, conforme os releases e iterações. Da mesma forma o controle integrado de mudança é natural no dia-a-dia da equipe, e ocorre através das priorizações feitas pelo cliente no backlog, e durante as reuniões de planejamento e revisão de iteração e releases. O gerenciamento de escopo é a área mais importante do PMBOK e por isso recebe grande atenção. Nos Métodos Ágeis também é de extrema importância, porém a filosofia é totalmente diferente. Enquanto o PMBOK procura blindar o escopo contra mudanças, a


8  

abordagem ágil abraça a mudança. Uma abordagem interessante colocada pela Sliger é a forma de criar a Estrutura Analítica do Projeto (EAP). Ao invés de conter todo o trabalho para o projeto como normalmente é feito no PMBOK, no modelo ágil a EAP pode ser feita no início de cada release. O gerenciamento de tempo no PMBOK inclui os processos necessários para realizar o término do projeto no prazo entre eles definição das atividades, sequenciamento das atividades, desenvolvimento do cronograma, controle do cronograma entre outros. Já em metodologias ágeis as estimativas são baseadas na quantidade de esforço de trabalho necessário para cada uma das tarefas, e é toda a equipe - não apenas o gerente do projeto - que faz a estimativa. Os membros da equipe se inscrevem para as funções em vez de ser simplesmente atribuída a eles. Isto dá à equipe uma oportunidade de se comprometer com a agenda e se apropriar do trabalho. Outro aspecto importante é o gerenciamento do risco que no PMBOK significa identificar possíveis eventos negativos para o projeto e tentar minimizar sua ocorrência e impacto. Na abordagem ágil o risco é tratado naturalmente no ciclo de vida do produto. É natural identificar e responder aos riscos continuamente. Isso é feito nas reuniões diárias, nas reuniões de planejamentos e de revisão e de retrospectiva de releases e iterações. Quanto ao gerenciamento da qualidade, normalmente é uma das últimas fases no modelo tradicional enquanto que na filosofia ágil há uma busca constante da qualidade ao longo das iterações e com envolvimento do cliente, quem dará o aceite final.

4.1.CASO DE SUCESSO ENTRE INTEGRAÇÃO DO PMBOK E SCRUM.

É importante destacar não só a teoria sobre a integração de PMBOK e Scrum mas também a prática de empresas que aplicaram este conjunto de conhecimento de melhores práticas. Entre estas empresas está a Globo.com que em um evento realizado pela CAELUM (2008) entiluado como “Falando em Agile” o palestrante Danilo Bardusco traz um enfoque deste caso de sucesso abraçado pela empresa. Integrando Scrum as suas práticas de processos e principalmente um enfoque em pessoas que esta integração não é só processos mais principalmente a atitude das pessoas envolvidas. A figura 4 demonstra o portal desenvolvido como fruto do trabalho da integração entre Scrum e PMBOK.


9  

Figura 4 - Caso de sucesso. Desenvolvimento de um portal do BBB. (CAELUM, 2009).

Nesta palestra Danilo Bardusco retrata que este projeto surgiu como idéia de um diretor da Globo que precisava que fosse desenvolvido em 40 dias. Porém este tempo era praticamente impossível para ser desenvolvido somente com as práticas aplicadas do PMBOK pela empresa, foi então que foi proposto uma integração com métodos ágeis o Scrum para o desenvolvimento deste projeto e no início houve uma grande restrição, mas, uma das abordagens do Scrum que foi essencial para o sucesso é que time é auto-gerenciáveis, sendo eles responsáveis por controlar as tarefas do desenvolvimento e participar das decisões. Proporcionando assim uma maior participação de todos os integrantes o que contribui significamente para o sucesso do projeto que foi desenvolvido em 35 dias. Após isso em 2009 já existiam 14 times Globo.com que trabalhavam com esta integração. Entre os itens destacados por Danilo Bardusco estão: maior velocidade, respostas mais rápida as mudanças, maior qualidade, distribuição do conhecimento e motivação dos integrantes.

5. CONSIDERAÇÕES FINAIS Em conclusão a este artigo defende-se que as abordagens tradicional e ágil podem conviver bem já que as boas práticas são compatíveis, mas é importante buscar o equilíbrio e considerar o ambiente. O segredo está em saber adaptar o processo para o projeto em questão. Não há solução perfeita, cada situação requer atenção especial.


10  

O PMBOK não retrata nenhuma proibição da utilização de metodologias ágeis, como também, não defende o ciclo em cascata para o desenvolvimento de projetos mas apenas cita como uma possibilidade. Abaixo uma descrição no PMBOK sobre o ciclo de vida: “Não existe uma única melhor maneira para definir um ciclo de vida ideal do projeto. Algumas organizações estabeleceram políticas que padronizam todos os projetos com um único ciclo de vida, enquanto outras permitem que a equipe de gerenciamento de projetos escolha o ciclo de vida mais adequado para seu próprio projeto..” (PMBOK, 2004 p. 20).

É importante destacar alguns itens sobre o Scrum e sua implantação em projetos na empresa. Para isso existe um maturidade necessária para verificar se realmente aquele projeto possui um perfil para a utilização de práticas de metodologias ágeis. Entre estes pontos destaca-se: 

Scrum precisa estar no lugar certo, na hora certa - Aplicar Scrum exige paciência e maturidade antes de aplicá-lo.

Scrum precisa ser promovido dentro da empresa - Entenda que as práticas de Scrum “atacam” diretamente uma série de vícios existentes nas equipes. Para que esta mudança seja agradável, essas pessoas da equipe precisam primeiro concordar com você sobre os problemas gerados por estes vícios, e querer atacá-los.

Scrum precisa de estratégia para ser bem aplicado: Conheça a empresa/time e então estude como Scrum poderá ser aplicado;

A abordagem ágil (Scrum), assim como a abordagem tradicional (PMBOK), possui características positivas e negativas, sendo que a principal diferença entre as duas está no conjunto de pressupostos de cada uma. É possível afirmar, ainda, que existe uma sinergia muito grande entre as duas metodologias, ou seja, uma pode complementar a outra. É importante destacar também um comentário do RICARDO VARGAS (2009) que fala em seu podcast com o título de “Gerenciamento Ágil de Projetos e Scrum” sobre a utilização de métodos ágeis que hoje é voltado mais para o mercado de desenvolvimento de software. De como esta utlização de metodologias ágeis em megaprojetos como plataformas de petróleo, ilhas artificiais implementassem um metodologia melhorada deste conceito de Sprint, times auto-gerenciáveis que hoje é um grande desafio para a área de Gerencimento de Projetos. Outro item que ele destaca é que as metodologias ágeis se encaixam totalmente nas melhores práticas do PMBOK e o principal objetivo das metodologias é gerar a os resultados. Portanto, metodologias ágeis ou metodologias tradicionais não são processos que devem ser aplicados ao “pé-da-letra” mais são práticas reconhecidas e recomentadas para


11  

utilização nos projetos. E que Scrum e PMBOK são práticas que se complementam e depende do que o projeto exije para que sejam aplicadas as melhores práticas. É bom aprender que como tudo na vida projetos podem falhar, por isso, deve-se estar atento as lições aprendidas, as metodologias aplicadas e buscar aplicar a metodologia correta para o trabalho a ser realizado.

6. REFERÊNCIAS AGILE MANIFESTO. Manifesto for Agile Software Development. Agile Alliance, 2001. Disponível em: <http://www.agilemanifesto.org/>. Consultado em fevereiro de 2010. CAELUM. Falando em Agile 2008 – Scrum na Globo.com: Derrubando Mitos. Disponível em: < http://blog.caelum.com.br/2008/12/03/falando-em-agile-2008-scrum-naglobocom-derrubando-mitos/>. Consultado em fevereiro de 2010. CONTROL CHAOS. About Scrum – Overview. Disponível em: <http://www.controlchaos.com/about/>. Consultado em fevereiro de 2010. DSDM-ORG. DSDM Consortium: Enabling Business Agility. Disponível em: <http://www.dsdm.org/>. Consultado em fevereiro de 2010.

:

MÁRCIO. PMBOK e Gerenciamento de Projetos. Disponível em: < http://www.mhavila.com.br/topicos/gestao/pmbok.html/>. Consultado em fevereiro de

2010. MICHELE SLIGER. Relating PMBOK Practices to Agile Practices. Disponível em: <http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&Object Id=10365&tth=DYN&tt=siteemail&iDyn/>. Consultado em fevereiro de 2010. PMBOK, Guide. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos – Terceira Edição. Versão em Português. Pennsylvania: PMI, 2004. RICARDO VARGAS. Gerenciamento Ágil de Projetos e Scrum 2 de 2. Disponível em: <http://www.ricardo-vargas.com/pt/podcasts/agile2_2>. Consultado em fevereiro de 2010. WIKIPÉDIA. Scrum. Disponível em: < http://pt.wikipedia.org/wiki/Scrum/>. Consultado em fevereiro de 2010.

Scrum e Pmbok juntos  

A utilização de práticas de processos Ágeis com práticas Tradicionais de gerenciamento de projetos é um desafio, porém não é impossível. Há...