Review, Demo, Apresentação da Sprint – pontos importantes

Independente da metodologia de desenvolvimento de software, existe valor em apresentar o trabalho em andamento e o que foi entregue.

“..a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.”

Fonte: Scrum guide em português

Abaixo, compartilho alguns elementos que considero importantes para reuniões de apresentação do trabalho:

Preparação

Um bom indicativo de um bom formato de review, é aquele que exige pouco tempo de preparação. A ideia é que não leve mais  do que uma ou duas horas para preparar uma review. O que deve se apresentar é o trabalho que foi feito. Vale a pena ter em mente que a reunião deveria ser descontraída. Muitas vezes, não há um conjunto de slides e/ou powerpoint como “entregáveis” da preparação nem da “entrega” de uma review (Foco em ter o software funcionando!!!).

Código funcionando adequadamente

Foco em ter o software funcionando. Nestas reuniões, é preferível que ocorram demonstrações do produto e suas funcionalidades. Dependendo do contexto, o ambiente que será utilizado será diferente. Ambiente de desenvolvimento (local ou remoto), teste, homologação, o que fizer mais sentido e for mais próximo possível do ambiente de produção. Código parcialmente entregue não deve ser apresentado  (só falta testar, só falta deployar, só falta validar..).

Coleta de feedback

A review é uma reunião para colher feedback dos stakeholders, patrocinadores e negócio e apresentar o que foi feito de mais relevante em termos de valor e conversar a respeito. O objetivo é INSPECIONAR o que foi feito e ADAPTAR o que foi feito.  O mais importante e o foco é colher feedback de forma estratégica. Para os times que trabalhem com Scrum, o Product Owner (PO) pode ajudar na priorização e escolha sobre “o que” demonstrar.

Apresentação e Condução

Existem duas abordagens mais comuns para condução de uma Review: ou alguém é escolhido pela equipe para conduzir e apresentar a review como um todo e os demais membros do time complementam OU os membros da equipe apresentam o que entregaram. Dependendo do tamanho da equipe, em uma reunião de 1 hora, não necessariamente todos da equipe vão ter tempo para apresentar o que fizeram individualmente. É importante proporcionar oportunidades para todos e/ou maioria dos profissionais da equipe apresentem em  alguma reunião de demonstração, ou seja, rotacionando esta responsabilidade. Em alguns contextos, a troca de interlocutor acaba dificultando o recebimento do feedback e entendimento dos stakeholders sobre o que está sendo entregue. A comunicação não deve ser em uma única direção, da equipe para os presentes na review, os participantes também devem ser ouvidos.

Engajamento e inclusão dos participantes

Uma boa estratégia para a review é deixar que os próprios participantes (com foco nos que não fazem parte da equipe), utilizem o incremento de produto. Pode ser útil para coletar informações relacionadas a experiência do usuário (UX), requisitos não funcionais, identificar cenários não antecipados em tempo de análise/desenvolvimento/teste, e outros.

Participantes

Relacionado ao item acima, é de suma importância a correta escolha de quem são os participantes. Os participantes mais comuns tendem a ser: membros do time (Se for um time Scrum: Scrum Master, Product Owner, time Scrum), patrocinadores, clientes, usuários, desenvolvedores de outras equipes (que podem ser dependências ou ter dependência impactando diretamente no trabalho de uma outra equipe) entre outros. Notem que os papéis citados acima não são uma checklist de participantes. Cada produto, serviço e aplicação deve considerar o seu contexto para selecionar os seus participantes.

Ambiente para demonstração

Se não for possível demonstrar a aplicação em virtude de dependência de dados, setup ou algo do gênero, uma boa opção é mostrar um vídeo exercendo manualmente as funcionalidades e regras de negócio ou a execução de testes automatizados que demonstrem a funcionalidade.

Planejado x Realizado

É importante apresentar e deixar claro o que foi planejado e o que foi realizado pela equipe. Também é válido lembrar constantemente que o planejado é um comprometimento com base na experiência da equipe ou estimativas ou em entregas passadas. Um dos fatores que demonstra a maturidade ou imaturidade (falta de maturidade) de equipes de desenvolvimento de software é a quantidade de tarefas não planejadas realizadas. Eventuais itens planejados e não realizados, devem voltar ao backlog de produto ou já serem pré-selecionados para a próxima iteração.

Comunicados importantes

É relevante comunicar certos acontecimentos aos stakeholders internos e externos e seus respectivos impactos. Se o time trabalha mapeando e acompanhando riscos, talvez seja relevante dar exemplos de riscos que foram mitigados ou que foram percebidos e qual impacto eles geraram no trabalho da equipe. Alguns outros exemeplos relevantes: alterações de membros da equipe, algum novo membro? Alguém deixou a equipe? Ausências (planejadas e não planejadas): treinamentos? eventos? folgas? doença? ausente? férias? Houve alguma definição de arquitetura? Ocorreu alguma mudança de mercado ou de legislação que afetou o planejamento? Alguma dívida técnica foi paga?

Visão, Missão, Objetivo..

O propósito daquele timebox (intervalo de tempo pré determinado para realizar o trabalho) deve estar muito claro e comunicado para a equipe e para a organização. É indiferente, se a organização e/ou a equipe utilizam BSC (balanced score card), OKR (objectives and key results), Impact Mapping (Mapas de Impacto), Mapa Mental para organizar os objetivos da equipe (e alinhar com o planejamento estratégico da organização). O Product Owner (PO) tem de deixar claro porque a definida meta foi essa e não outra. É importante explicar de onde veio a priorização e como o trabalho desta equipe conecta no “plano mestre” da organização (trabalho do indivíduo que faz parte do time conectando com outros projetos, iniciativas, planejamento estratégico da organização..).

O que você utiliza em suas reuniões de revisão de sprint, projeto, que considera importante e não está mapeado acima?

Publicidade