GERENCIAMENTO DE PROJETOS E SCRUM

INTRODUÇÃO

Este artigo foca na utilização do framework Scrum juntamente com o guia PMBOK, descrevendo o que o Scrum pode ajudar na gestão de projetos. Os processos descritos no guia PMBOK não serão detalhados.

O SCRUM

O Scrum (pron. [skrʌm]) é um processo de desenvolvimento iterativo e incremental para o gerenciamento de projetos e desenvolvimento de software ágil.

Sprint

O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.

Por time-boxed entende-se que a Sprint tem o tempo e o assunto definido. Se necessário alguma mudança deve-se avaliar a possibilidade de cancelar a Sprint.

Papéis

Product Owner (dono do produto)

O Product Owner (PO) é o representante do cliente dentro do Scrum. Ele é o responsável por realizar os detalhamentos dos requisitos do projeto junto ao cliente e passar estas informações para a equipe.

Time Scrum (Team Scrum)

São os responsáveis por produzir os artefatos do projeto, transformando os requisitos do cliente, detalhados pelo PO no produto final, agregando valor para o cliente.

Scrummaster

É o facilitador da equipe, removendo impedimentos e garantidor de que a equipe seguirá o framework Scrum.

Eventos Scrum

São as reuniões do Scrum:

  • Daily Scrum Meeting
  • Sprint Planning Meeting
  • Sprint Review Meeting
  • Sprint Retrospective Meeting

Artefatos

Product Backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um produto. O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste.

Sprint Backlog
O Sprint Backlog é uma lista de itens selecionados do Product backlog que serão produzidos na próxima Sprint.

Burndown Chart
O gráfico de Burndown mostra visualmente o planejado versus o realizado da Sprint ou do produto, mostrando diariamente se está em atraso ou não.

 

O GERENCIAMENTO TRADICIONAL E O SCRUM

O ciclo de vida do Scrum se adapta ao ciclo de vida tradicional, descrito pelo Guia PMBOK, principalmente em alguns processos de planejamento, execução e monitoramento e controle.

Planejamento

O Guia PMBOK já trazia o conceito de planejamento em ondas sucessivas passando a ser chamado na 5ª edição de ciclos de vida iterativos e incrementais. Nesta última edição o Guia PMBOK também trouxe o ciclo de vida adaptativo, que sugere que o tamanho dos ciclos seja de 2 a 4 semanas.

O Scrum inicia o planejamento e detalhamento pelos itens de maior valor/risco. O planejamento pode ser mais detalhado durante as reuniões do Scrum. Para iniciar uma Sprint o planejamento e detalhamento da mesma já deverá ter sido feita. Do contrário, o Time pode estimar errado.

Definição do escopo

É necessário que o PO, suportado pelo GP, faça o detalhamento dos itens do backlog (requisitos) junto ao cliente. É preferido que este alinhamento prévio tivesse acontecido. O PO deve conseguir detalhar ao máximo o requisito junto ao cliente, extraindo de seu conhecimento tácito (conhecimento implícito adquirido pela experiência). Pode-se utilizar as técnicas de gerenciamento de escopo do guia PMBOK.

Posteriormente, o GP junto com o PO definem os requisitos que entrarão na Sprint.

Seguindo os fundamentos ágeis do SCRUM, não é necessário que todos os itens do backlog do produto estejam detalhados, mas sim que o backlog da próxima entrega esteja.

O escopo delimita o que deve ser feito no projeto e é um dos itens mais importantes para o sucesso do projeto, independente se trata-se de projeto gerenciado pelas metodologias tradicionais ou ágeis.

Definir as Histórias

História é uma descrição resumida que detalha algum dos itens do backlog do produto. Além da descrição, devem ser incluídos os critérios de aceite da história. É indicado usar a linguagem que o usuário/cliente entenda.

Uma história se assemelha a: “Como um <usuário>, eu quero <objetivo> para <atender a uma necessidade>.

Ex: Como um cliente, eu quero poder consultar filmes para que eu possa escolher qual alugar.

Diferentemente do que muitos entendem o manifesto ágil não diz que as documentações não devem existir, mas sim que devem ter o detalhe suficiente para o entendimento do produto.

Sugere-se que unindo o gerenciamento de projetos tradicional com o Scrum, utilizar o backlog do produto com as histórias do Scrum.

Priorizar as Histórias

É de suma importância definir os itens do backlog que serão construídos pelo Time. Entenda com o cliente/stakeholders o que é mais importante na visão deles e não na do GP/Time do projeto. O item deve agregar valor ao cliente.

Pode-se utilizar uma contagem para definir a importância, sendo que o menor valor tem menos importância e o maior valor, maior importância. Exemplo, o maior valor pode ser 100 e será atribuído para a história com maior complexidade.

As histórias vão sendo lidas e tendo os valores atribuídos a elas. É importante não utilizar valores muito próximos para facilitar encaixar outras histórias.

Pode-se usar a técnica MoSCoW na identificação da priorização.

EAP/WBS x Histórias

Uma das ferramentas trazidas pelo Guia PMBOK é a Estrutura Analítica do Projeto (EAP) ou do inglês Work Breakdown Structure (WBS) e é uma das melhores ferramentas para controlar o escopo. Na abordagem com o Scrum, os pacotes de trabalho, que é o nível mais baixo na EAP podem ser representados pelas Histórias.

Histórias muito complexas podem ser subdivididas, passando a ser chamadas de épicos. As subdivisões serão as histórias deste épico.

Definindo o Time Scrum

Com base nas histórias e marcos é possível definir o Time Scrum. Alguns recursos já estariam pré-designados no termo de abertura do projeto. Outros serão negociados com outros gestores, contratados e até mesmo utilizados recursos de forma virtual.

Além disto, é necessário identificar os recursos não humanos. O Scrum não trata disto, sendo papel fundamental do GP.

Posteriormente o Time será mobilizado para dentro do projeto e terão os itens do backlog da próxima exibidos pelo Project Owner. Nesta reunião é sugerido que o Time estime o tamanho das histórias para se chegar ao tamanho da entrega ou do projeto inteiro.

Definindo o tamanho das histórias

Uma técnica para auxiliar nas estimativas utilizada no Scrum é o Planning Poker Card. É uma técnica que utiliza cartas com pontos e serão utilizadas pelos recursos para pontuar uma história apresentada, devendo-se chegar ao consenso.

A ideia é ter as histórias estimadas ou postergadas para análise futura caso o time não consiga faze-lo agora. Cada história irá ganhar uma pontuação, que neste momento não tem relação com duração. É sugerido que o time escolha a história mais simples e atribua a carta de menor valor. As demais histórias tem a estimativa baseada nesta história.

Tendo atribuído pontos para cada história, é hora de definir a equivalência entre os pontos e as horas. É importante manter uma lógica constante na definição das horas, para se ter um total aproximado de horas de esforço. Gerar esta equivalência é importante para que o GP tenha a informação em horas sem que tenha que ficar parando a equipe para novas estimativas.

Exemplo: Pode-se definir que os 2 pontos atribuídos à história mais simples equivalem a 4 horas. Os demais seguem este padrão.

É importante também que atividades de garantia da qualidade estejam consideradas nas estimativas. Esse esforço faz parte da definição de “pronto” que a equipe precisa fazer. Resumindo: “Pronto é pronto, não é quase pronto ou está pronto, mas …”. É sugerido que as horas da atividade principal (construção/testes unitários) sejam separadas destas atividades, já que muitas vezes são executadas por equipes diferentes.

Após chegar ao esforço total para a entrega ou projeto, com base na velocidade do Time pode-se definir a duração do projeto. A velocidade quer dizer quantos pontos por história o Time consegue trabalhar numa Sprint. Se for uma equipe nova, deve-se executar uma Sprint e ver no final dela qual foi o resultado. A cada Sprint a velocidade é revalidada.

Durante esta fase de esclarecimentos e estimativa das histórias o Time do projeto pode sugerir terceirizar o trabalho e identificar os riscos e registra-los no registro de riscos, juntamente com as possíveis respostas. No caso de terceirização o GP deve avaliar se o orçamento do projeto tem espaço para este gasto. Se a decisão de terceirizar for mantida, o Time Scrum será responsável por fazer a DT (declaração de trabalho) que será submetida aos fornecedores potenciais.

As cerimonias do Scrum podem e devem ser usadas para identificação de riscos. O GP deve participar desta reunião como ouvinte para ter informações para seu planejamento, bem como também identificar alguns riscos.

Gerenciamento dos custos

O Scrum não menciona o gerenciamento dos custos, mas não é possível conduzir um projeto sem pensar nos custos.

Mesmo sem muita precisão inicialmente, o GP tem condições de estimar os custos das histórias estimadas, recursos humanos e materiais. Durante o andamento do projeto a precisão aumenta.

Após termos levantado todos os custos individuais, sumarizando-os teremos o orçamento da fase ou projeto.

Planejando as Sprints

Nesta fase, o Time Scrum analisa junto com o Product Owner o backlog do produto e de acordo com as prioridades decide quais histórias irão fazer parte da Sprint. É um momento de reavaliar as estimativas.

O time inclui quantas histórias couberem na Sprint, de acordo com a velocidade do time, incluindo ou não segurança de acordo com a criticidade. Posteriormente as histórias são decompostas em tarefas, de preferência cabendo um 1 dia da Sprint.

Durante esta reunião pode-se (ou deve) revisar os riscos, qualifica-los, quantificar os mais críticos e definir as respostas para os mesmos. O GP pode participar para gerar a matriz de probabilidade durante a reunião e passando informações que ele tiver relacionadas ao projeto que possam influenciar o planejamento da Sprint.

Tendo os itens do backlog definidos para a Sprint, o GP pode gerar o cronograma do projeto. Seguindo a ideia de planejamento iterativo/incremental, o GP gera um cronograma para a Sprint em questão. Nesta abordagem ao GP cabe a gestão macro (histórias) e ao Time à gestão micro (tarefas).

Durante esta fase pode-se ser definida a forma de gestão da comunicação, informando quais informações serão divulgadas, quando e a quem serão.

Painel de controle do Scrum

A Taskboard ou quadro de tarefas é um painel que traz minimamente as histórias, tarefas pendentes, em andamento ou concluídas. Com este painel é possível ver facilmente o andamento da Sprint, bem como se todos estão trabalhando.

O gráfico de Burndown mostra visualmente o planejado versus o realizado da Sprint ou do produto, mostrando diariamente se está em atraso ou não.

Em ambos os casos, o GP pode olhar diariamente a Taskboard e o gráfico de Burndown para obter informações do andamento para utilização em seus reports.

Executando a Sprint

A execução da Sprint inicia-se após a reunião de planejamento e antes da reunião de revisão, ou seja, onde efetivamente as tarefas são executadas, inspeções realizadas e o painel do Scrum atualizado. O GP se utiliza das informações dos painéis para gerar seus próprios reports.

Na execução, o Time Scrum é responsável por executar e gerenciar as tarefas. Deverá mover a tarefa entre as abas do painel Scrum, para que este reflita as tarefas pendentes, em andamento e finalizadas.

Dado que uma pessoa não pode fazer duas tarefas ao mesmo tempo, para começar uma outra, deve obrigatoriamente mover ou mudar o status da que estiver trabalhando. No caso da tarefa estar bloqueada pode “ganhar” uma marca ou um post-it de cor diferente com uma breve descrição do impedimento.

O Time Scrum ou o Product Owner também deverão atualizar diariamente o gráfico de Burndown.

O Scrummaster é responsável por garantir que o Time Scrum siga as cerimonias do Scrum e remover obstáculos. Neste último caso podendo precisar de auxílio do GP, dependendo do que envolver, como por exemplo, custos, etc.

O Product Owner é responsável por garantir o entendimento funcional e fazer pré-validações.

O GP apoia o Scrummaster e atua nas atividades de monitoramento e controle.

Monitorar e controlar a Sprint

O Scrum tem como principal ferramenta a reunião diária. Nela cada um diz o que fez, o que fará e quais impedimentos tem para conclusão das tarefas. Para manter o foco e fazer uma reunião rápida, pode-se usar a Stand-up meeting, que nada mais é que fazer a reunião em pé.

O Scrummaster tem um papel muito importante que é garantir que o Time siga o Scrum, realizando a reunião, mantendo o tempo de 15 minutos e também incentivando a equipe a colocar os impedimentos.

O Scrummaster irá apoiar na resolução dos impedimentos e quando necessário envolverá o GP caso envolva custos e o Product Owner quando envolva detalhamento das histórias.

O GP junto com o Scrummaster também pode utilizar a reunião diária para identificar possibilidades de desenvolvimento da equipe.

Também é um bom momento para atualização do painel de controle e identificação e gerenciamento dos riscos do projeto.

Revisando a Sprint

A reunião de revisão da Sprint acontece ao final desta e é o momento onde são apresentados os resultados da Sprint para o Product Owner e/ou cliente. Não serão realizados os testes, mas sim apresentar os itens entregues.

Esta reunião é um bom momento para que sejam avaliados os itens não planejados que entraram na Sprint, bem como nas causas e motivos de correções e ajustes, o que pode evidenciar problemas de qualidade e planejamento.

A reunião de revisão pode ajudar o GP a identificar necessidades de gerenciamento das expectativas dos stakeholders, principalmente em virtude de produto instável ou inacabado.

Retrospectiva da Sprint

É uma das reuniões mais importantes após o planejamento da Sprint. É usada para rever como foi a Sprint com o objetivo de identificar melhorias para a próxima Sprint. Nela todos devem participar.

Se houver tempo, uma das melhorias pode ser implementada ainda dentro da reunião para testar a efetividade.

Após mapearem as melhorias o PO e o GP podem analisar se haverá algum impacto ou retrabalho que possa afetar os acordos com o cliente.

Deve-se entender esta reunião como uma chance de identificar as melhorias, sem buscar culpados.

Nesta reunião, como em todas as cerimônias do Scrum pode-se identificar e revisar riscos.

O guia PMBOK sugere que ao final de cada fase ou projeto se armazenem as lições aprendidas. No Scrum esta reunião pode ser utilizada. Se o Sprint não representar uma fase e fazendo o registro das lições aprendidas ao final de cada Sprint, mais lições aprendidas poderão ser registradas já que o risco de serem esquecidas é menor.

O importante é, deixar de fazer o registro das lições aprendidas na Sprint ou no final da fase implicará na equipe continuar a incorrer nos mesmos erros.

Encerrando a fase / projeto

Após a reunião de retrospectiva uma nova Sprint é iniciada sem intervalo. Se o cliente exige uma homologação formal para dar o aceite, parte da equipe pode fazer este acompanhamento enquanto os demais focam na nova Sprint para não haver a necessidade de parar e aguardar a homologação formal, desde que não seja a última Sprint do projeto. Esta equipe à parte pode ser composta por analistas de testes ou negócios.

O acompanhamento da homologação é feito pelo GP.

O PO é responsável por dirimir dúvidas com relação ao que foi especificado e o que foi entregue.

Durante a homologação formal erros ou solicitações de mudança deverão ser tratados. Pode-se utilizar a mesma equipe de desenvolvimento ou por outros membros exclusivos. O primeiro caso pode gerar atrasos na Sprint em andamento. É de suma importância trabalhar com prevenção na questão da qualidade para evitar ou minimizar este cenário.

É de suma importância formalizar o encerramento para evitar questionamentos e até ações judiciais.

CONCLUSÃO

Primeiramente deve-se remover a ideia de que projetos gerenciados de forma tradicional e ágil não convivem. O Guia PMBOK é base para a gestão de projetos, mas ele é uma referência, não deixando claro como executar as atividades. Cada projeto tem suas particularidades e devem decidir o que usar ou não.

O Scrum é mais voltado para a execução do projeto e pode ser usado para suprir a falta do Guia PMBOK.

Mas o Scrum não tem processos para gerenciar muitas atividades importantes nos projetos, que sem elas, hoje em dia fica muito difícil de gerenciar.

Muitos processos do Guia PMBOK são executados de forma transparente pelo Scrum, sem dar nomes às técnicas.

Unindo as metodologias, podem-se usar as boas práticas do Guia PMBOK com a agilidade do Scrum.

Nesta abordagem, o GP é dono das decisões de custos, cronograma e orçamentos, etc., enquanto o Time Scrum põe a mão na massa para efetivamente gerar o produto ou o incremento do produto, agregando valor a este.

Conforme visto, o GP se beneficia dos controles gerados pelo Scrum e o Time Scrum se beneficia por trabalhar focado na execução, enquanto o GP pelas demais atividades. Com isto, diz-se que a o Time Scrum é blindado pelo GP que evita na medida do possível que eventos externos os impactem.

Apesar de ser uma regra do Scrum de que o Time Scrum deve ser auto gerenciável, isto é difícil de acontecer, mas podem ser auto organizáveis e realizar o micro gerenciamento das próprias tarefas.

 

REFERÊNCIAS

Fábio Cruz (@fabiorcruz): Livro Scrum e PMBOK – Unidos no gerenciamento de projetos
http://pt.wikipedia.org/wiki/Scrum
Scrum Guide: www.scrum.org

 

* Cadastre seu e-mail no formulário existente no lado direito da página para receber informações sobre a publicação de novos artigos. O e-mail não será utilizado para qualquer outro fim.

Paulo Hakme, PMP®

Leave a Comment

Your email address will not be published. Required fields are marked *