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