Revisões ágeis de sprint

Três etapas para melhores revisões de sprint com a equipe ágil

Dan Radigan Dan Radigan
Buscar tópicos

As revisões de sprint não são retrospectivas. Uma revisão de sprint é sobre a demonstração do trabalho árduo de toda a equipe: designers, desenvolvedores e o proprietário do produto. Na Atlassian, gostamos de fazer reuniões de sprint casuais. Os membros da equipe se reúnem ao redor de uma mesa para demonstrações informais e descrevem o trabalho que fizeram para cada iteração. É um momento de fazer perguntas, testar novos recursos e dar feedback. Compartilhar com êxito é uma parte importante da criação de uma equipe ágil.

Primeiro vamos revisar por que a definição de "concluído" da equipe é tão importante para esta cerimônia ágil.

Etapa 1: definir "concluído"

Como um usuário regular do Jira, não há nada mais gratificante do que mover uma tarefa de "revisão de código" para "concluído". O som de um cartão ágil representa o trabalho concluído que estabelecemos realizar como uma equipe. Feito!

Atualização de um cartão ágil no Jira

Cruzar a linha de chegada e concluir o trabalho exige um bom planejamento, uma definição clara de "concluído" e execução com foco. Grande parte disso acontece durante o planejamento de sprint, mas, para ter um sprint e uma revisão de sprint bem-sucedidos, as equipes precisam fazer um pouco mais do que apenas planejar. As equipes precisam desenvolver uma cultura clara de como entregar o trabalho, bem como o que significa estar "concluído".

Uma cultura de entrega

Equipes eficazes trazem processos claros e cultura de desenvolvimento para todos os itens de trabalho. Use essas perguntas para avaliar o processo e garantir o funcionamento ideal para a equipe:

  • As histórias são bem definidas pelo proprietário do produto, designer e equipe de engenharia antes da implementação?
  • Todos entendem e vivem os valores e cultura da equipe de engenharia?

  • Há revisões e requisitos claros em relação à revisão de código, testes automatizados e integração contínua para encorajar o desenvolvimento ágil e sustentável?

  • Após a equipe concluir uma história, há muitos bugs na superfície? Em outras palavras, "concluído" realmente significa "concluído"?

A cultura da equipe em relação à qualidade e à conclusão deve vir de todas as histórias do usuário, itens de trabalho de engenharia e bugs. Essa cultura reflete como a equipe aborda e entrega software.

Definição de "concluído" em cada item de trabalho

Uma definição clara de "concluído" ajuda as equipes a focar no objetivo final para cada item de trabalho. Quando o proprietário do produto adiciona trabalho ao backlog da equipe, definir os critérios de aceitação é uma parte fundamental do processo. O que significa para uma história do usuário ser concluída? Na Atlassian, a equipe do Jira acompanha critérios de aceitação e observações de teste alinhados com o restante da história do usuário dentro do Jira. Dessa forma, toda a equipe tem uma visão clara do sucesso em cada questão. O que são critérios de aceitação e observações de teste?

  • Critérios de aceitação: métricas que o proprietário do produto usa para confirmar que a implementação da história está satisfatória.
  • Observações de teste: orientações breves e focada da equipe de assistência de qualidade que permitem ao engenheiro de desenvolvimento escrever melhor o código de recursos e testes automatizados.

Ter itens bem definidos durante a implementação permite que todos tenham êxito. Com o Jira, é fácil de adicionar campos em sincronia. Como administrador, clique no botão "admin" no item.

Etapa 2: celebrar a equipe

Na Atlassian, um dos principais valores é "Jogar, sempre em equipe". As revisões de sprint são um ótimo momento para comemorar as conquistas da equipe e de todos durante uma iteração. Normalmente elas são feitas às sextas-feiras à tarde, quando todos estão aguardando o fim de semana. As revisões de sprint não são como as retrospectivas, então garanta que a revisão de sprint seja feita depois de uma iteração, mas antes da retrospectiva. Os participantes externos são sempre bem-vindos, mas a reunião normalmente é feita com o proprietário do produto, toda a equipe de desenvolvimento e o scrum master. Como melhor prática, recomendamos de 30 minutos a uma hora para cada iteração durante a reunião.

Amamos revisões de sprint porque elas protegem a integridade e a disposição da equipe. As revisões de sprint abrangem tudo sobre a criação da equipe. A revisão não é algo negativo, não é um teste, é um evento colaborativo de toda a equipe, no qual as pessoas demonstram o trabalho realizado, fazem perguntas e recebem feedbacks.

Se uma revisão de sprint não se tornar uma atividade positiva na equipe, isso pode indicar que:

  • a equipe está assumindo muito trabalho, que não consegue concluir durante uma iteração
  • a equipe está enfrentando débito técnico

  • os recursos não estão sendo desenvolvidos sustentavelmente para garantir que novos bugs não sejam introduzidos na base de código

  • as práticas de desenvolvimento da equipe não estão tão adaptadas quanto poderiam estar

  • o proprietário do produto está mudando as prioridades dentro de uma iteração, e a equipe de desenvolvimento é vencida pela agregação de escopo

Observação: toda equipe tem iteração difícil às vezes. Reserve um tempo para entender por que uma iteração muda na retrospectiva da equipe e crie um plano para abordar os itens no próximo sprint.

Etapa 3: atingir todas as regiões

As empresas com equipes distribuídas têm desafios especiais em relação ao dimensionamento de cerimônias ágeis em todas as localidades. As revisões de sprint não são exceção. A equipe Jira tem membros em todo o mundo: Sydney, Gdańsk, Saigon e São Francisco. Embora sejamos distribuídos, as revisões de sprint são uma parte importante da cultura da equipe. Os membros da equipe fazem vídeos informais e compartilham em uma página do Confluence para toda a equipe usar.

Esses vídeos informais mantêm todos atualizados sobre o progresso do desenvolvimento, apesar das diferenças de horário. Ver uma demonstração de recurso em primeira mão pelo desenvolvedor fortalece a equipe de duas maneiras:

  • Entendimento do produto: toda a equipe passa a conhecer a intenção, motivação e implementação do recurso. Isso amplia o entendimento de todos sobre o produto.

  • Desenvolvimento da equipe: vídeos criam mais conexões pessoais na equipe. Todos veem quem está por trás de cada aspecto de um produto. As pontes criadas por esta prática tornam a gente um grupo mais unido e coeso, apesar das diferentes localidades.

Um conselho final

Para equipes novas em revisões de sprint, é muito tentador falar sobre revisão de sprint durante a retrospectiva. Uma revisão de sprint é uma cerimônia independente de uma retrospectiva de sprint. Reserve um tempo para aproveitar os frutos do trabalho. Comemore as realizações. As revisões de sprint efetivas proporcionam incentivo e motivação para a equipe. Essa ideia de celebração é tão importante para a gente na equipe Jira que incorporamos um "vá em frente, comemore" na declaração de visão por esse motivo.

a seguir
Standups