Scrum na prática: Entendenda o fluxo

Para dar continuidade em nossa trilha de como utilizar scrum na prática, neste segundo artigo vou falar sobre o fluxo do scrum.

Caso você ainda não tenha ouvido falar de scrum, ou não esteja familiarizado com os termos deste framework. Sugiro que leia o primeiro artigo da nossa trilha, Scrum na prática: Introdução.

Bom, agora que já temos a introdução aos termos e conceitos, é hora de começar a entender o fluxo do scrum. Vamos lá?

Visão do produto

O primeiro passo para um time que vai utilizar o scrum na prática, começa um pouco antes dos tradicionais eventos que sempre ouvimos falar.

Antes de por o scrum pra rodar, é importante que o P.O., passe para o time uma visão clara do produto. Esse visão pode ser dada de uma forma macro, para que a equipe possa visualizar os seguintes pontos:

• Qual o objetivo do produto que estamos construindo
• O que queremos alcançar com este produto
• Quais os objetivos de negócio envolvidos no nosso projeto
• Quais são as expectativas do cliente com esse produto

Enfim, tudo que está relacionado a direção do produto em si. Desta forma, teremos uma equipe alinhada com os objetivos daquele projeto e fazendo parte da concepção do mesmo.

Montando a lista de funcionalidades

Depois de alinhar com o time os pontos citados acima, é hora do P.O. definir uma lista de funcionalidades para atingi-los. Ou seja, ele precisa definir quais as funcionalidades e recursos necessários que precisarão ser desenvolvidos para criar um produto alinhado com os objetivos do cliente.

Por ser uma missão um pouco complexa, o P.O. pode pedir auxílio para o S.M. e até mesmo para membros mais experientes do time de desenvolvimento no momento de definir essa lista.

Priorizando as funcionalidades

Após ter a lista completa de funcionalidades, o P.O. deve fazer a priorização delas. Ou seja, ele precisa definir a ordem em que todas as atividades serão desenvolvidas.

Além disso, é muito importante que o P.O. sempre leve em conta o valor agregado que cada recurso irá trazer para o produto. Dessa forma ele conseguirá juntamente com o time de desenvolvimento, desenvolver um projeto que entrega valor para o cliente frequentemente.

E com essa lista de funcionalidades definida e priorizada, temos o nosso primeiro artefato do scrum. O Product Backlog, será o pontapé inicial para a equipe começar a usar o scrum na prática.

Planejamento do Scrum

Com o product backlog pronto, vamos começar nosso fluxo. Mas para falarmos deste fluxo, precisamos entender primeiro sobre o principal ciclo de trabalho do scrum, a sprint.

A sprint nada mais é do que o ciclo de trabalho onde o time desenvolve uma lista de funcionalidades pré-selecionadas. Normalmente com duração de duas a quatro semanas. É importante enfatizar também, que as sprints do projeto devem ter tamanho fixo, ou seja, se a sua primeira sprint durou duas semanas, esse ciclo de duas semanas deverá se repetir até a conclusão do projeto.

Com isso entendido, vamos continuar falando do fluxo. E aqui vamos entender o primeiro evento do scrum, o Sprint Planning.

No evento de sprint planning, o time se reuni e seleciona quais atividades do product backlog, irão formar o sprint backlog. Sempre respeitando a ordem de priorização da primeira lista, não se pode por exemplo, pegar o primeiro e terceiro item do product backlog, deixando o segundo pra trás.

A ideia é planejar os itens que iremos conseguir entregar ao final da sprint. Claro, que é difícil tem essa previsão. Mas para isso podemos utilizar o Planning Poker. E com o tempo, a equipe vai entendendo melhor os pontos, e o que consegue fazer em cada sprint.

Além disso, o sprint planning não deve ser utilizado apenas para definir “o que será entregue”, mas também “o como isso será desenvolvido”. Então é importante que o time discuta tecnicamente sobre os itens, e sane com o P.O. as dúvidas relacionadas as regras de negócio. Por isso, o timebox recomendado para este evento, varia de 4 até 8 horas, dependendo do tamanho da equipe e duração da sprint a ser planejada.

O Fluxo de trabalho do Scrum

Após definirmos o nosso sprint backlog, é hora de começar a rodar nossa sprint. Então o time inicia o desenvolvimento das atividades efetivamente, de acordo com o que foi definido no sprint planning.

Durante esse ciclo, a equipe deve realizar diariamente a daily scrum, no horário combinado. Para que seja alinhado como está o andamento do projeto, devemos lembrar que inspeção e transparência são pilares do scrum.

Garantir que o evento da daily seja realizado todo dia, que a equipe participe ativamente e respeite o timebox máximo de 15 minutos, é papel do S.M. Isso é tão importante quanto remover os impendimentos que possam surgir no caminho, e está contemplado na atuação dele dentro do projeto.

O fechamento do fluxo de trabalho do Scrum

Ao terminarmos a sprint, entramos na fase final do fluxo de trabalho. A etapa onde iremos revisar e avaliar tudo que foi desenvolvido e praticado durante a sprint.

A primeira reunião de fechamento é a sprint review, que como já mencionei no artigo anterior serve para avaliarmos se os itens desenvolvidos na sprint, estão de acordo com o esperado. Nela o P.O.  também pode dar manutenção no product backlog.

Depois da review, acontece a retrospectiva. Esta é a reunião aonde avaliamos como está nossa execução do processo, e como anda nossa prática do scrum. Como também já falei anteriormente, nesse espaço a equipe pode discutir sobre o que precisa parar de fazer, ou melhorar na próxima sprint.

Além disso, no final deve acontecer o incremento do produto. Devemos lembrar, que no scrum o time é sempre responsável por manter uma versão estável e utilizável do produto. Por isso a entrega deve agregar novos recursos funcionais, mas sem prejudicar o que já existe.

Concluindo o ciclo do scrum

Bom pessoal, esse é um resumo de como o fluxo do scrum funciona. E apesar de parecer muita coisa, o importante é entender os conceitos e começar a aplicá-los no dia a dia.

O próximo e último artigo dessa trilha fala sobre Scrum no dia a dia, e nele dou algumas dicas de como aplicá-lo. E também falo de ferramentas complementares, que podem auxiliar na utilização deste framework.