10 minutos de leitura

No último artigo, apresentamos o que é o framework de trabalho Scrum, a forma mais conhecida de materialização dos princípios ágeis nas organizações.

Vimos seus processos e benefícios de sua adoção frente metodologias Waterfall.

Discutimos também como o Scrum tem a sua origem para projetos de desenvolvimento de software, mas que é utilizado nas maiores empresas do mundo – fora mesmo do mundo da tecnologia – por ser facilmente adequável para qualquer objetivo de trabalho em que há uma entrega final concreta que pode ser dividida em pequenas partes.

LEIA TAMBÉM: Metodologias ágeis: o que são e como implementá-las no seu negócio?

Agora, vamos apresentar um passo-a-passo e listar algumas ferramentas para implementar o Scrum no seu ambiente de trabalho.

Refrescando a memória

Consiga um lugar para organizar os pensamentos ou o seu Backlog, se já estiver pronto. Isso pode ser feito tanto em um software como o Trello ou Pipefy, ou mesmo apenas em um quadro branco.

O Scrum começa com o Product Owner, o representante do usuário final, tendo autoridade para dizer o que vai ou não ter no projeto. Cabe ao Product Owner a listagem e priorização de uma lista de tarefas e requisitos necessários para o produto final – o Backlog. O Time Scrum – responsável pela produção e desenvolvimento do projeto em questão – é formado e um Scrum Master (o “resolvedor”) é alocado.

Em seguida, a base do Scrum: a Sprint. A Sprint é um prazo predeterminado em que o time responsável pelo desenvolvimento do projeto deve cumprir com um conjunto de tarefas listados no Backlog. O normal é durar cerca de 2 semanas – podendo variar entre 1 e 4 semanas. Faz-se o Sprint Planning, escolhendo quais partes do projeto serão contempladas na Sprint a se iniciar e aí mãos a obra: o Time tem a duração da Sprint para cumprir com o trabalho proposto.

Ao término, faz-se o Sprint Review, no qual se discute o que pode ser melhorado nos processos do Scrum e discute-se a produtividade em termos de entregáveis por período de tempo.

Pré-Requisitos

1 Scrum Master (SM): seja o SM da metodologia que você está tentando implementar. Seu papel será, justamente, garantir o cumprimento dos processos.

1 Product Owner (PO): consiga um PO adequado, que vá conseguir tanto transmitir as ideias do cliente/usuários do projeto que está sendo desenvolvido quanto esteja muito disposto a fazer tudo a seu alcance para o sucesso do projeto.

Time Scrum: monte o time com a quantidade de membros que você julgar conveniente ou tiver disponível.

Para saber mais sobre os pré-requisitos, clique aqui.

Passo-a-Passo

1. Arrume o seu Backlog

O Product Backlog é uma lista de features que as pessoas querem que seja incluída no produto, em ordem de prioridade. Qualquer um pode adicionar qualquer coisa ao Backlog. Mas apenas o Product Owner – o dono do Backlog – tem o poder de realizar a priorização dos itens listados. O Backlog pode conter qualquer coisa relacionada ao produto: desde novos entregáveis e melhorias até problemas, riscos e bugs que possam surgir.

A priorização dos itens do Backlog – quais devem vir primeiro e quais mais tarde – deve ser feita olhando os itens (em sua maioria features do produto) como unidades de uma fila. O Product Backlog é uma fila de entregáveis a serem realizados e a ordem desejada deve considerar a complexidade do trabalho envolvido ao mesmo tempo que maximiza valor criado para usuário com a entrega feita.

2. Estimando o Backlog

Estime seu Backlog – para ter uma noção do tamanho dos itens – em função de pontos, não em função de tempo. Times de desenvolvimento são infinitamente mais capazes de dar palpites sobre estimativas em função de “tamanho” do trabalho do que em termos de “duração” do trabalho.

A pergunta correta não é “quanto tempo vai demorar?”, mas “quão grande é?”

Escolha um sistema de pontos para pontuar cada item do Backlog. Minha dica? A sequência de Fibonacci: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, … (não é a intenção do artigo explorar a relevância dos números de Fibonacci e suas diversas utilizações). Como no Scrum a regra de ouro é simplicidade, sugiro manter o range de possíveis valores entre 1-21.

Por mais claro que seja que “21” se trata do maior item e “1” do menor, pode haver uma falta de referencial no momento da alocação dos pontos entre os itens do Backlog. Para resolver isso, escolha: (i) o maior item e atribua a ele a maior pontuação (no caso, 21) e (ii) o menor item e atribua a ele a menor pontuação (no caso, 1).

Nesse estágio – de estimativas – pode-se jogar o Planning Poker. Cada membro do time recebe uma carta com cada uma das possíveis pontuações e vota uma pontuação para cada funcionalidade. Cada rodada é uma funcionalidade e todos devem virar as cartas da rodada ao mesmo tempo – para não haverem vieses de opinião.

Caso não tenha entendido o Planning Poker (afinal, é complicado mesmo) muito bem, clique aqui.

Com essas estimativas em mãos, o Product Owner tem agora uma ótima base para fazer a priorização oficial do Backlog.

3. Sprint Planning: Requisitos

A próxima coisa que deve ser feita é determinar a duração da Sprint. Na metodologia, costuma variar entre 1 semana e 1 mês – sendo 2 semanas a mais frequente. Reflita bastante antes de tomar a decisão sobre a duração da Sprint, pois, ao longo do projeto, é recomendado – na verdade, é quase mandatório – que a duração não mude.

Monte o Sprint Backlog: o conjunto de itens do Backlog que é desejado estarem entregues ao término da Sprint. Inclua um pouco mais do que você acredita que o time é capaz de realizar – evitando ociosidade na hipótese de o time finalizar o trabalho antes da data.

Antes do início da Sprint, o Product Owner apresenta ao time cada item do Backlog e explica como ele/ela o vê em uma perspectiva funcional. O time discute cada um dos itens, fechando o escopo para cada um. Se possível, decompondo cada um em User Stories: framework que segue o formato “Como um ____ (tipo de usuário), eu quero ____ (funcionalidade) para que eu possa ____ (objetivo)”. A especificação em termos de User Stories é muito boa, pois permite a você dar um contexto, um sentido a cada funcionalidade – atribuindo quem vai precisar da funcionalidade e o propósito da interação do usuário com ela.

4. Sprint Planning: Tarefas

Quebre os requisitos atribuídos para a Sprint em tarefas. Exemplo? A “Home” de um Website: Documentação, Design, Desenvolvimento, Testes Unitários, Testes Gerais e Aprovação. Inclua todas as tarefas necessárias para se ter um Sprint Backlog 100% completo. Por último, traduza as tarefas em entregáveis – entregáveis são mais metrificáveis do que tarefas.

Priorize o Sprint Backlog, incluindo os sub-entregáveis definidos para cada requisito.

Agora, cabe ao time se comprometer a entregar todo o Sprint Backlog. Ao término da Sprint, esse Backlog deve constituir um produto que pode ser avaliado e manuseado por usuários.

5. Crie um espaço de trabalho colaborativo

Deixe a sala repleta de quadros brancos. Qualquer coisa que precisar ser repassada para o restante do time ou que se deseja anotar com relação ao projeto, cole na parede! Mencionamos alguns softwares que podem ajudar nessa tarefa – de exercer o papel de um Quadro Kanban – mas poucas coisas traduzem ao senso de colaboração melhor do que escrever em algo físico, dentro do ambiente de trabalho.

Crie o quadro do projeto com 5 colunas: “Product Backlog” (todos os requisitos), “A Fazer” (entregáveis a realizar na Sprint), “Fazendo” (trabalho que está sendo realizado), “Aguardando Aprovação” (aguardando aval do Product Owner) e “Feito”. Trabalhe com post-its e deixe o time livremente mover os cartões conforme o trabalho evolui.

6. Sprint!

Regras:

– Os Times tomam as próprias decisões durante a Sprint. O Scrum Master não dá instruções sobre o trabalho, mas suporte e assistência. É importante que o Time tome as decisões para se sentirem donos do que está sendo feito e assumam as responsabilidades do projeto, aumentando o engajamento.

– A duração da Sprint é fixa. Não muda. Se houve trabalho em excesso, uma pena; ele será transferido para a próxima Sprint. Se faltou trabalho, puxa pedaços do Backlog que pertenceriam a próxima Sprint. A Sprint sempre vai durar o que foi planejado para ela durar.

– Você só pode seguir para o próximo entregável uma vez que o anterior tenha sido aprovado. Feito significa “Feito.”. Para conseguir trabalhar com uma escala de tempo fixa, é imperativo que não haja retrabalho.

7. Reuniões

Diariamente – mesmo – deve ser sediado o Daily Scrum.

Essa reunião deve ser feita formando um meio circulo envolta do quadro branco da Sprint. Todo o time, Scrum Master e Product Owner devem estar presentes. É feita de forma a não tomar mais do que 15 minutos do tempo dos envolvidos e são respondidas, por cada um dos membros do Time:

1 – “O que fiz?” (Ontem-Hoje)

2 – “O que vou fazer?” (Hoje-Amanhã)

3 – “Houve algum impedimento no meu trabalho?”

O Scrum Master é o responsável por garantir que essa reunião ocorra – e ocorra bem. Além disso, é ele o responsável direto por resolver questões que surjam com as respostas da pergunta 3: os impedimentos. Se surgiram impedimentos que não permitiram um fluxo contínuo de trabalho por parte do time, cabe a ele ir atrás para resolver isso – lidando com stakeholders externos a equipe se necessário – e garantir o bom funcionamento do Scrum.

8. Acompanhe o progresso

Atualize diariamente o “Burndown Chart”: o gráfico que relaciona progresso planejado x realizado (eixo Y) em função do tempo (eixo X).

Um gráfico com o eixo Y contendo quantos pontos – colocados na priorização – você tem que estar conseguindo “abater” através do release de entregáveis, imaginando um esforço constante do Time. E um outro gráfico com o eixo Y marcando os pontos a serem cumpridos de acordo com as datas.

Dessa forma, atualizando diariamente o gráfico, tem-se uma ferramenta extremamente visual para saber se a equipe toda está adiantada, de acordo com ou atrasada quanto ao timing previsto tanto para a Sprint quanto para o projeto todo.

9. Termine quando você disse que faria

Termine toda funcionalidade antes de ir para a próxima e dê um jeito de cumprir com o planejado. Todo o time deve cooperar para atingir o maior propósito do Scrum: entregar o que fora prometido até o término da Sprint. Siga o princípio de que “feito significa feito!” Para evitar retrabalhos e para que você sempre esteja apto a poder – caso necessário – entregar o produto/projeto a qualquer momento.

10. Reveja, Reflita, Repita

Agora que você terminou o seu trabalho durante a Sprint, está na hora das reuniões de Sprint Review (uma revisão) e Sprint Retrospective (uma retrospectiva).

A Sprint Review pode incluir todo tipo de stakeholders relacionado ao projeto externo a equipe de desenvolvimento. Ela ocorre por 3 motivos:

1. Permitir que os membros do time mostrem o que alcançaram e demonstrarem sua contribuição ao produto.

2. Permitir que todos os stakeholders vejam o que está sendo feito e providenciar um feedback pontual e regular, enquanto ainda há espaço para ajustes no produto.

3. Ajuda que todos mantenham o foco no deadline da Sprint – ninguém vai querer aparecer na reunião sem nada de útil para mostrar aos outros.

A Sprint Retrospective, por seu lado, é restrita a equipe responsável e se refere a melhoria dos processos internos e do próprio Scrum:

1. Revisite o seu Burndown Chart (gráfico de progresso) e veja as variações na produtividade do time ao longo da Sprint. Com ele e o quadro Scrum ao lado, pergunte:

2. O que deu certo? (Garanta que isso vai continuar na próxima Sprint)

3. O que poderia ter saído melhor? (Tente entender o porquê e corrigir)

4. O que faremos de diferente na próxima Sprint? (Escolha algumas ações concretas que time pode fazer e irá acarretar em melhorias de produtividade)

Pronto. Você acabou de rodar o Scrum na sua empresa. Agora, repita o processo desde o ponto 3 até esgotar todo o Product Backlog.

Fechamento

A implementação do Scrum não irá acontecer de um dia para o outro e não há uma – por mais que tenha sido dado bons guidelines acima – uma receita correta a ser seguida. Será um trabalho de constante testes, iterações, feedbacks e ajustes.

Cada empresa tem a sua cultura organizacional e, por mais que o Scrum seja um framework de trabalho que traz benefícios imensuráveis para a produtividade e engajamento da sua equipe, você, gestor, precisa avaliar se de fato a sua empresa tem sinergia com essa metodologia.

Faça o processo ser natural, mostre a todos a importância dessa ferramenta e deixe que todos colaborem com uma construção da metodologia mais apropriada a vocês e aproveite todos os benefícios que a metodologia ágil mais famosa do mundo tem a oferecer!

Precisa de ajuda para montar a squad com as melhores metodologias e cerimônias? Clique aqui e converse com nosso time!