Criado em 1995 por Ken Schwaber e Jeff Sutherland, o scrum é o framework (diferente de metodologia) de gerenciamento de projetos ágeis mais utilizado no mundo e utiliza conceitos modernos de trabalho. Não vamos detalhar aqui a história do Scrum (clique aqui para saber mais), mas em seus conceitos práticos.
Basicamente o Scrum transforma o método de gerenciamento de projetos em cascata (aqueles bem desenhados em MS Project com gráficos de Gantt) e o quebra em partes (várias partes) que são espécies de "mini projetos", também conhecidos como "sprints". O que mais chama a atenção no Scrum é o fato de se possibilitar pequenas entregas funcionais ao cliente.
Afinal, pra que usar Scrum?
Se você tem a responsabilidade de gerenciar um projeto, qualquer que seja, podendo este projeto ser delimitado com datas de término ou não, você precisará ter um modelo de trabalho. Existem vários modelos (existem também pessoas que não usam modelo nenhum), mas há dois específicos que são os mais utilizados:
Modelos em cascata
Os modelos em cascata são aqueles projetos em que se planeja todas as fases e atividades em datas, uma amarrada a outra. Este modelo cria um cronograma bem delimitado com prazos e data estimados. A PMI é a organização que define as diretrizes para um gerente de projetos. Há muitas regrinhas a serem seguidas e em algumas empresas, exige-se uma certificação PMI para ser considerado um gerente de projetos (PM) ou trabalhar em um escritório de projetos (PMO).
Modelos ágeis
Os modelos ágeis são aqueles em que não há uma preocupação em delimitar as datas para cada fase e tarefa. Isso não significa que as obrigações não tem prazo! O fato é que não há tanta preocupação em estimar a data de tudo no início do projeto, pois a estimativa se fará ao longo das entregas chamadas de "Sprints".
Serve apenas para desenvolver Software?
Apesar de ter ser concebido no mundo do desenvolvimento de software, o Scrum se aplica a qualquer tipo de projeto. Abaixo iremos detalhar de maneira genérica como isso irá acontecer.
Como ele funciona?
Existem muitas ilustrações sobre o Scrum, mas esta ilustração abaixo representa TODOS os elementos do processo Scrum.
O backlog
O Product Backlog é uma lista com todas as funcionalidades que serão desenvolvidas no projeto.
Concebendo o backlog com Epics e Features
O Product Backlog é composto por itens denominados Epics, que são grandes etapas com descritivo na linguagem do cliente, sem muito detalhamento técnico. Os Epics podem ser os itens de um contrato, por exemplo. As Features são etapas que caracterizam os Epics e são descritivos mais técnicos, uma ideia da concepção dos Epics. Em projetos menores, os Epics não são utilizados e são substituídos pelas Features.
Backlog Grooming
O Backlog Grooming é uma série de ações que visam a incrementação e priorização do Backlog, afinal, requisitos podem mudar e o Product Backlog precisa refletir esta mudança.
Priorizando o Product Backlog
Imagine uma lista de 1000 itens do projeto, qual deve ser feito primeiro? O Scrum é flexível e como é um modelo ágil, permite que o Product Backlog seja priorizado pelo cliente a qualquer momento e incrementado, pois novos itens e novos requisitos podem surgir a qualquer momento, assim como mudanças!
Portanto, o Product Owner deve estar constantemente atualizado o Product Backlog e o mantendo priorizado de acordo com as necessidades do cliente e especificidades do contrato.
Criando as Tasks
Os itens mais prioritários do Product Backlog precisam ser analisados pela equipe técnica e detalhados, afinal, os itens do Product Backlog são genéricos, escritos de maneira superficial. Uma vez que os mais prioritários são os que serão desenvolvidos primeiro, precisam ter um detalhamento mais aprofundado tecnicamente. A partir das Features, o técnico deve criar o último nível, as Tasks (se for um projeto de desenvolvimento de software, são as User Stories).
Resumindo, a hierarquia dos itens que compõe o backlog é esta:
Os sprints
Assim como o Product Backlog, o Sprint Backlog é uma lista de funcionalidades, porém, é uma lista menor e com itens prontos para o trabalho. Para conceber o sprint, é preciso realizar uma reunião chamada de Sprint Planning, mas, antes os itens precisam ser estimados com a equipe.
Estimando o Product Backlog com Planning Pocker
Não é possível criar um Sprint Backlog, sem que os itens do Product Backlog estejam estimados. Existem várias técnicas para se estimar o serviço, mas a mais comum (e interessante) é o Planning Pocker. No Planning Pocker, o Product Owner pega as Tasks dos itens mais prioritários do Product Backlog e apresenta para o time. Para cada item apresentado, o time apresenta suas estimativas da seguinte maneira:
- Com cartões na sequência fibonacci, após apresentação do item, o time escolhe sua estimativa e ao mesmo tempo, jogam na mesa
- Se todos apresentarem a mesma estimativa, esta é atribuída ao item
- Se a equipe apresentar estimativas diferentes, deve ser questionado o motivo para quem lançou a menor e a maior estimativa
- Após o entendimento a discussão, os cartões são lançados novamente até que se haja estimativas homogeneas
Com todos as Tasks dos itens mais prioritários do Product Backlog estimados, é hora de se definir o Sprint Timebox.
Sprint Timebox
Com o período de sprint definido (2, 3 ou 4 semanas), sabemos quantos dias úteis serão trabalhados no sprint. Ao definirmos as horas por dia dedicadas pelas pessoas que farão o sprint, podemos saber o Sprint Timebox.
Sprint Planning
A reunião de Sprint Planning irá definir o Sprint Backlog, que é uma lista de itens que serão realizados no período do sprint. É para esta fila que a equipe que executa as tarefas irá olhar e acompanhar as demandas.
Kanban para gerenciamento da rotina
O sprint começou e a melhor maneira de organizar a rotina de trabalho é utilizando o Kanban. O Kanban é um quadro composto por colunas com os status da Task. Conforme a equipe executa as Tasks, atualiza o status do Burndown Chart.
Burndown Chart para acompanhar a evolução do sprint
O Burndown Chart é um gráfico que apresenta duas linhas. Uma linha com a tendência ideal e outra linha que apresenta o andamento real dos trabalhos. Se a linha real estiver abaixo da linha de tendência ideal, significa que o sprint foi estimado errado e a equipe poderia ter produzido mais itens no período. Se a linha real ficar acima da linha ideal, significa que os itens não foram feitos dentro do tempo estimado. Quando isso acontece, o ideal é encerrar o sprint e colocar os itens restantes no próximo.
Daily Scrum
A Daily Scrum é uma reunião diária feita entre a equipe. Deve ocorrer de maneira rápida e em no máximo 15 minutos. Geralmente a equipe faz esta reunião em pé, para que seja ágil. Na reunião a equipe responde as seguintes questões:
- O que estou fazendo?
- O que vou fazer?
- Há algum impedimento para o que vou fazer?
O Product Owner deve colaborar para a solução dos impedimentos.
Sprint Review
O Sprint Review é uma reunião para apresentação e entrega da funcionalidade (ou parte dela) que foi desenvolvida durante o Sprint. Nesta reunião o Product Owner, junto da equipe, apresenta o que foi feito ao Cliente. Nesta reunião participam todos os interessados pela entrega.
Sprint Retrospective
A reunião Sprint Retrospective é realizada apenas pelo Time e pelo Product Owner. Nela a equipe irá discutir o que foi produzido no Sprint, as técnicas utilizadas e farão um Brainstorm para identificar melhores maneiras de se fazer o trabalho e otimizar o próximo Sprint. Nesta reunião também se reavalia a necessidade de novos itens que serão adicionados ao Backlog e provavelmente irão para o próximo Sprint.
A entrega
O objetivo do Sprint é entregar algo funcional ao cliente. A entrega pode exigir alguma cerimônia com o cliente, tudo vai depender do projeto. Além disso, a entrega marca um item do Backlog como concluído, mas o que não se pode esquecer é o fato de que esta entrega deve "agregar valor" ao cliente e resolver o problema (ou parte do problema) ao cliente. Afinal de contas, a agilidade não pode deixar de considerar a qualidade.
Foto de Startup Stock Photos no Pexels
Voltar
