Revisões ágeis de sprint

Três etapas para melhores revisões de sprint com sua 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 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.

a seguir
Standups