Aliando o Scrum às melhores práticas do PMBOK! Isso é possível?

Há quem pense que o Scrum se perpetua como a prática de um framework no âmbito Agile e que se este não for aplicado as pessoas envolvidas estão presas ao “passado”, e que Agile é um caminho sem volta.

Por outro lado, as pessoas / organizações que se utilizam de um modelo cascata e baseiam-se no PMBOK como principal guia de boas práticas em sua gestão de projetos dirão que não há projeto que funcione sem o planejamento abordando o “ponta a ponta”, com todas as informações e requisitos já levantados antes de se iniciar o desenvolvimento, e que o Scrum é uma perda de tempo e utopia.

E você, o que diz? Analisando friamente, podemos afirmar que os dois lados estão parcialmente certos! Não há opção boa ou ruim, melhor ou pior. Ambas as opções são válidas, e a dica aqui é aplicar os processos, frameworks e metodologias apropriados a cada situação e momento. No fim das contas o objetivo é um só: Entregar valor, no prazo, custo e qualidade planejados.

Em um mundo ideal, sob a ótica do PMBOK se tem muito claro qual é o objetivo final, porque todo o processo é descrito em detalhes, enquanto no Scrum você tem a idéia do objetivo e o desenvolvimento daquele “pedacinho” do produto acontece na hora.

Em um desenvolvimento baseado no modelo tradicional, geralmente se tem uma estimativa de data final de desenvolvimento realista do ponto de vista análogo e/ou paramétrico, porque o projeto é totalmente planejado em todas suas áreas de conhecimento (escopo, prazo, custos, riscos, qualidade, aquisições, integração, recursos humanos e materiais, etc), sempre tendo em mente que qualquer desvio nas tarefas atrasará as saídas esperadas e comprometerá a entrega do produto final visado.

No Scrum nos aproximamos pouco a pouco e incrementalmente dessa idéia final, mas sempre terminando o ciclo da iteração com um produto final. Ou seja, uma vez que uma suposta data final chega, você pode não ter o projeto concluído, mas pode fazer uma entrega totalmente funcional de uma porcentagem avançada dele.

Com base nessa comparação, alguns podem afirmar que o Scrum é melhor, visto que se pode entregar 80-90% do projeto na data de entrega. Opa! Espera! Quem já encontrou um projeto onde se permita entregar ao final um pedaço e não o produto completo? Embora certos aspéctos ou detalhes possam ser eliminados, na maioria das vezes se pede por tudo ou nada! Isso é mundo real! Eu não quero o meu carro com três rodas ou sem uma das portas!

Acredito que a principal diferença entre o Scrum e o PMBOK é que o segundo requer requisitos de pré-planejamento, uma análise funcional e técnica e, uma vez que tudo é assinado e planejado nos mínimos detalhes, o ciclo de desenvolvimento é iniciado. O Scrum, por sua vez, “brinca com o Caos”, ou seja, não tem que ser um papel funcional, mas apenas ter uma idéia clara de desenvolvimento que será responsável por orientar a equipe para o seu alvo, priorizar tarefas e fornecer feedback contínuo. Cada iteração constitui-se em uma tomada de requisitos, análise, planejamento, ciclo de desenvolvimento e entrega do produto.

E com base nessa diferença que se determina o porquê do Scrum ser mais aberto à mudança. Em ciclos curtos pode-se desenvolver uma idéia, ser maleável, enquanto para métodos tradicionais qualquer mudança de requisito no projeto demanda reavaliação funcional e replanejamento do todo (lembra da tríplice restrição do PMBOK?).

A equipe

Uma equipe em Waterfall segue algumas indicações, enquanto no Scrum a equipe se auto-organiza com base nas prioridades e metas do Sprint. Quando se diz que o Scrum é fácil de entender, mas difícil de aplicar, isso é fato! Antes de qualquer outro aspecto, precisa-se de uma equipe madura, com o mindset ágil na veia. Assumirão tarefas e responsabilidades, e se comprometerão a cumprí-las dentro do prazo estimado e acordado entre eles. De certa forma, no PMBOK a equipe não exerce esse conjunto de responsabilidades e habilidades gerenciais, embora acabe funcionando da mesma forma.

Adquirir tal responsabilidade não é algo que todo membro de equipe deseja ou tem disposição. Há pessoas que precisam detalhar as informações e que preferem não tomar a iniciativa ou decisão quando se trata de resolver problemas que surgem durante o desenvolvimento, e precisam de orientação e supervisão o tempo todo. Em suma: Você deve ter certeza de que sua equipe está preparada antes de aplicar o Scrum! A equipe é fundamental para o sucesso no Scrum.

Reuniões e follow-up

Em projetos que sem um modelo tradicional, são realizadas reuniões para iniciar o projeto, reuniões de acompanhamento do projeto e reuniões de final de projeto para analisar os erros e aprender sobre eles. É claro que as reuniões já estão definidas antes do início do ciclo de desenvolvimento e, de acordo com o progresso da mesma, mais reuniões de acompanhamento podem ser estabelecidas, se necessário. Além disso, o gerente de projetos precisa dominar com maestria habilidades de comunicação e gestão do conhecimento, para registro e aplicação de lições aprendidas.

No caso do Scrum, é um conceito bastante semelhante, mas aplicado à iteração curta e com mais acompanhamento devido à falta de detalhes do projeto. Temos reuniões diárias para analisar em equipe o comprometimento de cada um, as reuniões de planejamento, a revisão do produto com o feedback do Product Owner, e finalmente a retrospectiva, também para analisar problemas e erros, e aprender com eles para a próxima iteração.

E quanto aos processos? Adaptação é a chave!

Há certa dificuldade em avaliar qual usar em um projeto, um guia que contém diversos processos e boas práticas (PMBOK), ou um framework em que variados componentes e papéis já estão definidos. Mas será que realmente precisamos optar por um ou outro? Afinal de contas, como comparar um guia a uma estrutura? Vamos brincar um pouco! Abordaremos as 10 áreas de conhecimento do PMBOK fazendo uma co-relação ao Scrum, topas? Bora!

Gerenciamento de Escopo: com certeza o processo mais importante e necessário dentro do gerenciamento de projetos, pois conforme prega a abordagem tradicional, o correto é deixá-lo distante de eventuais mudanças. No Scrum, o Product Owner prioriza o backlog para gerenciamento do escopo e entregas a serem feitas, em vez de adotar uma abordagem fundamentada em um plano que pode as vezes ocasionar em ferramentas que nunca serão utilizadas.

Gerenciamento de Tempo: conforme a abordagem tradicional, é determinado por meio do planejamento das atividades no Plano de Projeto, com base na EAP gerada em dos processos de gerenciamento de escopo. Já no Scrum as atividades são fundamentadas em valor, mas, no entanto, há a necessidade de avaliação de esforço feito em alto nível por meio de Releases, e em baixo nível na determinação das Sprints.

Gerenciamento de Custos: para ambos os conceitos, o escopo de desenvolvimento precisa estar nos limites de custo definidos. O que difere um do outro é que no modelo tradicional já temos um plano de orçamento que contemplará todo o projeto e que pode sofrer mudanças, caso seja identificada tal necessidade e aprovado por um comitê, e no Scrum, tal avaliação é feita em diferentes pontos do projeto, ou seja, depois de alguma Sprint, no começo ou no término de uma Release.

Gerenciamento da Qualidade: no Scrum é realizado por meio de avaliações funcionais ao fim de cada iteração, testes exploratórios e de aceite ao fim das Releases, sendo parte essencial no desenvolvimento do software. No PMBOK, é um processo determinante, inclusive considerado uma “quarta restrição” para a tríplice restrição, onde a auditoria e inspeção contínuos são essenciais para garantir uma boa entrega, sem necessidade de solicitações de mudanças.

Gerenciamento de Recursos Humanos: Para o guia PMBOK é uma boa prática incluir todas as partes interessadas e pessoas envolvidas no projeto no plano do projeto, definindo os papéis, responsabilidades e nível autoridade de cada membro dentro do projeto desde o início e manter isso inalterado, mas em caso de mudanças, manter o plano atualizado constantemente, além de refletir os impactos de tal mudança nos demais planos. Já o Scrum, aborda as equipes multifuncionais, sendo que estas realizam reuniões diárias e durante Sprints.

Gerenciamento de Comunicações: aqui a diferença determinante é o tipo de comunicação. No Scrum se defende o fundamento do diálogo direto (comunicação ativa, face a face). O PMBOK defende a documentação formal, embora enfatiza a importância de se utilizar antes a comunicação ativa, mas gerar um documento que registra tal informação.

Gerenciamento de Riscos: Aqui o PMBOK® disparadamente é mais específico, pois a todo momento os riscos são mapeados, gerenciados e alterados, mantendo-se um plano de gerenciamento de riscos coeso e preciso, prevendo, assumindo ou mitigando quaisquer ocorrências inesperadas. No Scrum tal tipo de abordagem é feita informalmente por toda a equipe de desenvolvimento, no decorrer do projeto por meio de descoberta e avaliação dos riscos, sendo estes levantados e explorados nas reuniões feitas diariamente e dailys.

Gerenciamento de Integração: em ambas as abordagens se inclui os processos necessários para a geração de um plano de entrega dos requisitos ao cliente final. O que difere é o papel do gerente de projeto segue os planos criado por ele e pela equipe para guiar as fases do projeto. No caso do papel de Scrum Master, esse atua como facilitador / líder-servidor, removendo impedimentos para que o time consiga andar por si próprio.

Gerenciamento de Aquisição: o Scrum não exerce tal processo para que possamos usar de alusão ou comparativo com o PMBOK.

Gerenciamento das Partes Interessadas: O PMBOK dispõe de processos que facilitam o registro e gerenciamento das partes interessadas do projeto, de modo a determinar o seu grau de influência e engajamento no decorrer de todo o ciclo de vida do projeto.

Dá para associar as duas abordagens e tirar o melhor proveito do que ambas têm a oferecer! Scrum, enfatiza em especial duas áreas de conhecimento do PMBOK: Gerenciamento de Escopo, com foco na gestão e priorização de requisitos (backlog), e no Gerenciamento de Recursos Humanos, dada a importância que este framework dá ao desenvolvimento da equipe. No que se refere ao Gerenciamento de Qualidade, não está definido formalmente, mas é realizado através do uso de regras e revisões constantes. Contudo, o Scrum demanda de apoio externo para processos em que dá pouca ou nenhuma ênfase, como por exemplo as áreas de conhecimento de Gerenciamento de Custos e Aquisições.

Tendo-se um uma política de governança com alto grau de maturidade adotando-se um mindset ágil, é sim possível rodar o Scrum, com o apoio e suporte dos processos do PMBOK. É uma aliança poderosa, acredite!