DEV Community

loading...
Cover image for Eventos Scrum: um relato de experiência

Eventos Scrum: um relato de experiência

Felipe Tófoli
Software developer
・5 min read

Semanas atrás, algumas pessoas do meu time que não tiveram muito contato com metodologias ágeis pediram que eu contasse um pouco sobre a aplicação do Scrum nos meus projetos anteriores, evidenciando sobre como os eventos scrum eram tocados.

Percebi que contar um pouco sobre minhas experiências positivas em times que aplicavam Scrum é uma tarefa recorrente, então decidi escrever sobre isso! 😃

Atenção!

⚠️ >>
Este texto não irá debater ou apresentar definições. Caso tenha interesse nas definições sobre os eventos citados, recomendo consultar o Scrum Guide.

E se você está começando a estudar sobre agilidade, vale consultar o Manifesto ágil.

Agilidade não se resume a Scrum.

Algumas das práticas apresentadas no texto funcionavam bem em determinados contextos. Os desafios e as escolhas que são feitas dependem muito das pessoas e do contexto.
Não existe uma solução geral (bala de prata) que funcione para todos os casos.
<< ⚠️

Eventos Scrum

Os seguintes eventos são citados no Scrum Guide e apresentados na sequência do texto:

Além dos eventos citados no Scrum Guide, será apresentada também a dinâmica de um Refinamento.

Sprint 🏃

⌛ 2 semanas (geralmente, no meu caso)
É quando o que foi planejado é executado. Para melhorar a agilidade no desenvolvimento de software costumávamos nos valer de testes automatizados (como documentação viva do código, segurança para o time fazer as alterações necessárias no código), CI/CD (facilitando o processo de deployment de software) e técnicas como pair programming.
Quando itens inesperados surgiam, o "objetivo do sprint" era utilizado como critério para decisão da priorização entre itens planejados e não planejados. Quando os itens não planejados eram adicionados ao "Sprint Backlog", algum item planejado era despriorizado, para não onerar o time.

Sprint Planning 🎯

📅 Após a retrospectiva
⌛ 2h-4h
Nas sessões de planejamento do sprint os itens refinados (aptos a serem desenvolvidos no próximo sprint) eram revisados. Os itens eram puxados pelo time de desenvolvimento, conforme a priorização estabelecida no product backlog, de acordo com o quanto o time acreditava que conseguiria produzir e se comprometer.
Para ajudar a entender, e obter certa previsibilidade, sobre o quanto um time costumava produzir durante um sprint, algumas equipes utilizavam sistemas de estimativas e técnicas: story points, tamanhos de camiseta (P, M, G), planning poker.
Ao término da sessão de planejamento do sprint, o time saía com a definição do "objetivo do sprint", que ajudaria o time a se organizar e inspecionar constantemente se as ações tomadas durante o sprint estão contribuindo para o atingimento do objetivo. A definição do objetivo sprint era muito útil para tomadas de decisão sobre a priorização dos itens no decorrer do sprint, conforme itens inesperados surgiam.

Daily Scrum 🔁

📅 Diariamente
⌛ Até 15 minutos
As dailies tinham foco em traçar o plano para as próximas 24h e avaliar se estávamos continuamente avançando em busca do objetivo do sprint. Impedimentos eram declarados e as pessoas se organizavam para superar os bloqueios ou notificar quem fosse necessário.
Quando trabalhando com times distribuídos, geralmente os times faziam a daily olhando para as tasks no board, desta forma trabalhos invisíveis eram identificados (e cadastrados no Jira), o quadro era atualizado diariamente, verificava-se quais os cards estavam parados há muito tempo, era possível notar em uma cadência diária se o time estava se aproximando do objetivo traçado no Sprint Planning, em vez de perceber isso apenas no Review.

Sprint Review 🎁

📅 No término do sprint
⌛ 1h-2h
Neste evento, apresentávamos as entregas do time e o valor que foi gerado, com foco em dar visibilidade do que foi feito e compartilhar o conhecimento entre todos. Além de fazer uma "demo", era importante contar com feedbacks e insights do time que ajudavam a definir melhorias, mudanças e os próximos passos que poderiam ser priorizados (resultando na atualização do Product Backlog).

Sprint Retrospective 📣

📅 Após o sprint review
⌛ 1h-1h30
Constituía na etapa de inspeção contínua do ciclo, uma oportunidade para notar o que estava dando certo e tínhamos interesse em continuar fazendo, e também identificar o que não estava tão legal e queríamos melhorar.
O ponto chave aqui era extrapolar os próprios pontos, e elaborar planos de ação do time que seriam acompanhados e monitorados. Os formatos variavam de conversas casuais à clássica utilização do board (utilizávamos esse board online). Tinha um pessoal que gostava de acessar esse site para aprender novos formatos de retrospectiva.

Refinamento 🔬

📅 Antes do planning
⌛ 1h
Esse evento não está listado no ScrumGuide, mas fazíamos em alguns times (principalmente para os times que precisavam de maior previsibilidade). O objetivo era refinar os itens de backlog.
O refinamento poderia indicar que o item não estava pronto para ser implementado (possivelmente devido a algum pré-requisito não mapeado que faria com que o item ficasse para o próximo sprint), ou que o item era muito grande e poderia ser dividido em mais partes. O refinamento era utilizado também como alinhamento técnico entre os engenheiros que poderiam discutir como o item seria implementado.
Para times que estimavam tarefas, era uma reunião bastante útil, pois as dúvidas eram antecipadas, evitando que as plannings ficassem muito extensas.

E você, como aplica os eventos Scrum?

Neste texto pude apresentar algumas experiências que tive aplicando os eventos Scrum no meu dia-a-dia profissional.

Você aplica de uma forma parecida? De uma forma completamente diferente? Te pareceu interessante ou errado?
Conta pra gente nos comentários! 😉

Referências

Discussion (0)