Revisões ágeis de sprint

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

Dan Radigan Dan Radigan

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.

Let’s first review why the team’s definition of ‘done’ is so important to this agile ceremony.

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 para fazer como uma equipe. Concluído e concluído!

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 têm processos claros e uma cultura de desenvolvimento para todos os itens de trabalho. Use essas perguntas para avaliar seu processo, e certifique-se de que tudo está funcionando adequadamente para sua equipe:

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

  • Há requisitos e definições claros sobre a revisão de código, teste automatizado e integração contínua para encorajar um desenvolvimento ágil sustentável?

  • Após uma equipe concluir uma história, há muitos erros para corrigir? Ou seja, "concluído" realmente significa "concluído"?

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

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

Uma definição clara de "concluído" ajuda as equipes a focarem na meta final de cada item de trabalho. Quando o proprietário do produto adiciona trabalho à lista de pendências da equipe, definir os critérios de aceitação é parte fundamental do processo. O que significa uma história de usuário estar concluída? Na Atlassian, a equipe Jira monitora os critérios de aceitação e as notas de teste de acordo com o restante da história de usuário dentro do Jira. Desse modo, toda a equipe tem uma visão clara do êxito em todos os problemas. Quais são os critérios de aceitação e as notas de teste?

  • Critérios de aceitação: métricas que o proprietário do produto usa para confirmar se a história foi implementada de acordo com o que esperava.
  • Notas de teste: orientação breve e focada da equipe de assistência de qualidade que possibilita que o engenheiro de desenvolvimento escreva testes automatizados e códigos de recursos melhores.

Ter problemas 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 problema.

Etapa 2: celebrar a equipe

Na Atlassian, um de nossos principais valores é "trabalhar 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. Elas são normalmente feitas nas tardes das sextas-feiras, quando todos estão aguardando o fim de semana. As revisões de sprint não são como as retrospectivas, então se certifique de fazer a revisão de sprint depois de uma iteração, mas antes de sua 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 seu trabalho, fazem perguntas e recebem feedbacks.

Se uma revisão de sprint não se tornar uma atividade positiva na equipe, isso pode ser um indicativo de:

  • A equipe está assumindo muito trabalho e não está conseguindo concluir durante uma iteração
  • A equipe lidando com o débito técnico existente

  • Os recursos não estão sendo desenvolvidos sustentavelmente para garantir que novos erros não sejam inseridos na base de código

  • As práticas de desenvolvimento da equipe não estão tão atualizadas quanto deveriam estar

  • O proprietário do produto está alterando as prioridades em uma iteração, e a equipe de desenvolvimento está marginalizada pelo deslizamento de escopo

Observação: às vezes, toda equipe tem uma iteração difícil. Reserve um tempo para entender o motivo pelo qual uma iteração muda na retrospectiva da equipe e crie um plano para abordar os problemas 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 nossa 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 fuso horário. Ver uma demonstração de recurso feita por um desenvolvedor ajuda a equipe de dois modos:

  • Entendimento do produto: toda a equipe é informada sobre a intenção, a lógica e a implementação do recurso. Isso amplia todo o conhecimento sobre o produto que a equipe tem.

  • Relacionamento da equipe: vídeos proporcionam conexões mais pessoais em toda a equipe. Todos podemos ver quem está por trás de cada aspecto de um produto. A ponte criada por essa prática nos torna um grupo mais unido e coeso apesar da distância.

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 seu 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 nós na equipe Jira  que incorporamos um "vá, celebre" em nossa declaração de visão por esse motivo.

Up Next
Standups