Correção de bug em review meeting

Olá Eliane,

O interessante no momento da Reunião de Review é que possamos pegar feedback e validar a solução com o cliente e fazer anotações caso necessário.

Lembrando também, que assim, permitimos que o PO possa identificar melhor a prioridade desse bug com as estórias para o próximo sprint.

Caso queiramos resolver o bug na hora, pode dar impressão de preocupação e dedicação em atender o cliente de forma rápida. Mas essa atitude pode ter interpretações negativas também, como desorganização.

Além de que nem sempre podemos resolver um bug de primeira e temos que priorizar os objetivos e o tempo desse timebox.

Olá Eliane,

Pensa que você caiu num cenário próximo do que você comentou. Eu estou numa review e apresento uma tela para meu cliente que é a tabela de usuários cadastrados. Ai seu cliente percebe que na tabela não tem a coluna com a idade da pessoa e ele sente que esta é uma informação relevante. O programador sabendo que por estar na tela que lista justamente os usuários, mostrar a idade é algo que leva 5 minutos no máximo para ser feita dado que é uma informação que está no modelo do usuário, só acrescentar uma chamada a mais para o modelo na sua view. Em poucos minutos alguem faz essa mudança "magicamente" na frente do cliente e tudo funciona. Só que na visão do seu cliente, se ele não tem maturidade/conhecimento de tecnologia, ele começa a entender que acrescentar uma coluna a mais numa tabela é algo muito rápido que leva 5 minutos. Percebendo isso, ele vai validar outra tabela que é uma lista de filmes e pede para você acrescentar uma coluna com a quantidade de usuários que já assistiram o filme dado que para ele acrescentar uma coluna a mais é algo rápido. Tenta explicar para o cliente que essa mudança não leva 5 minutos. Não é algo tão trivial para quem não tem contato com programação.

Por isso que a gente tenta evitar realmente a todo custo programar durante a review, principalmente quando o cliente e o usuário não possuem maturidade trabalhando com equipes de desenvolvimento. As vezes o contexto da mudança a torna simples, mas nem sempre uma alteração similar será tão trivial . E isso gera mal entendidos com o cliente quando ele não tem conhecimento técnico.

Outro motivo muito forte também do porque não fazemos alterações em reviews é que as pessoas perdem o foco e o tempo delas na reunião. Enquanto você está fazendo a mudança e seu cliente acompanhando, mesmo que seja algo que leva 5 minutos, todas as outras pessoas ficarão sem ter o que fazer enquanto isso. Elas começarão a mexer no celular, bater papo sobre coisas alheias, entre outras coisas. Pronto, as pessoas já não estão focadas no objetivo que queremos alcançar na review que é aprovar tudo que ficou pronto na sprint com o cliente e usuário. E se isso ocorre com frequência (o que geralmente acontece porque com certeza se você corrige 1 coisa seu cliente vai pedir várias outras mudanças ao longo da review), as outras pessoas se sentirão desmotivadas e que a reunião não foi proveitosa dado que elas ficaram sem ter o que fazer várias vezes.

Por experiência própria: quando for planejar o sprint, negocia com o cliente uma parte dos pontos para correção de bugs "intempestivos" que serão achados no decorrer. Deixa claro que, se for chegando ao final do sprint e estes pontos ainda não foram utilizados, puxa o item de maior prioridade do backlog.

Até o presente momento, todos os clientes e membros da equipe estão satisfeitos desta forma.