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 impedimentos 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.
