Olá! Hoje continuaremos com a série FAQ Scrum, falando da Reunião de Revisão. O próprio nome já parece ser auto-explicativo, mas como acontece essa reunião? Quem deve estar presente? De quem é a responsabilidade de mostrar os artefatos construídos e o que acontece quando algo é reprovado? No post de hoje tentaremos esclarecer todas essas dúvidas e sugerir práticas para que tudo corra bem nessa reunião.
Seguindo o fluxo do Scrum, a Reunião de Revisão ocorre logo após o período de desenvolvimento da Sprint. O objetivo desta reunião é apresentar ao Product Owner (PO) todos os entregáveis que foram produzidos pelo time Scrum e ela conta com a participação do time, do Scrum Master (SM), do PO e de qualquer outro interessado no projeto. Durante essa reunião, o time tem a responsabilidade de mostrar ao PO o trabalho que foi feito, o SM tem a responsabilidade de evitar que a reunião saia do seu propósito inicial e o PO tem a responsabilidade de aprovar, ou não, as novas funcionalidades mostradas.
E por que é o time quem apresenta o que foi produzido? Na verdade, essa responsabilidade é uma das mais importantes do time e deve sempre ser respeitada. Durante as reuniões de planejamento, o time se compromete com o PO a fazer determinados itens do Product Backlog e, ao fim do ciclo de trabalho, é ele quem deve mostrar ao PO e assumir a responsabilidade pelo que foi produzido. Além disso, o time também deve discutir com o PO as soluções encontradas e ouvir sugestões e impressões sobre o que foi apresentado.
O papel do PO nesta reunião é avaliar se o que foi produzido está de acordo com o que era esperado e validar a Sprint. Para a Sprint ser validada, é preciso que as funcionalidades entregues pelo time cumpram a meta da Sprint, acordada na Reunião de Planejamento. O fato de algum item do Sprint Backlog ser reprovado pelo PO não indica, necessariamente, que a Sprint não teve sucesso. Se o item reprovado não estiver relacionado à meta da Sprint, ela pode ser validada ainda assim. Só temos que ter em mente o seguinte: se um item é reprovado pelo PO, mesmo que parte dele possa ser entregue, todo ele voltará para o Product Backlog e nenhum ponto será considerado na velocidade do time. Em uma próxima Sprint, de acordo com a necessidade do PO, esse item volta para o Sprint Backlog, com a mesma estimativa, e aí, então, o trabalho que falta para finalizá-lo será realizado.
O que foi dito no post “Por que liberar versão em produção é como correr no asfalto” também vale para esse momento de validação do trabalho realizado. Por isso, na GPE, procuramos seguir as seguintes práticas: montar um roteiro da apresentação e testar o projeto em um servidor local. Ao montar um roteiro da apresentação, é possível pensar em todos os passos que devem ser realizados para a apresentação das funcionalidades produzidas, o que permite que o time reveja todo o fluxo e verifique se algo passou despercebido e precisa ser revisto. Ao realizar o teste em um servidor local, o time pode simular o ambiente que será utilizado na apresentação e tentar identificar e corrigir possíveis problemas de configuração de ambiente. Essas práticas permitem que o time tenha mais tranquilidade durante a reunião e evita problemas em que a resposta é a já famosa “na minha máquina estava funcionando”, mesmo que realmente estivesse.
Uma última prática deve ser sempre utilizada: não deixem para contactar o PO apenas na Reunião de Revisão. Quanto mais opiniões e impressões forem coletadas durante o processo de desenvolvimento, maior será a chance de o item do Sprint Backlog ser aprovado.
E então? Ficou alguma dúvida? Não deixem de mandar seus comentários e assista à vídeo-aula sobre Reunião de Revisão na Universidade Scrum!
