Nossas Retrospectivas

Todo mês fazemos as famosas Retrospectivas na Jera. Quando falamos de SCRUM, as retrospectivas acontecem ao término de cada Sprint, fazemos essa também, mas limitada ao time que está trabalhando no projeto. Esse post se trata das retrospectivas envolvendo toda a equipe.

Sempre que penso nesse assunto, me lembro de um artigo do Manuel Pimentel que trata de forma bem prática, se você não está familiarizado com o termo, recomendo a leitura antes de prosseguir.

Mas, na verdade, o conceito de retrospectiva só nos remete a um assunto que é velho conhecido do pessoal de administração, que é o famoso PDCA. O objetivo de ambos é promover melhoria contínua!

Legal, apesar de ser um assunto aparentemente simples, melhoria contínua trata-se de um dos maiores desafios para qualquer empresa ou pessoa. Para melhorar é preciso saber o que não está bom, e para isso é preciso de humildade para entender e aceitar nossos erros.

As retrospectivas da equipe aqui na Jera sempre causam espanto aos que acabaram de começar conosco. A gente sempre segue o princípio da honestidade, sendo que o todos são encorajados a dizer o que estão sentindo, o que está incomodando e claro, o que deu certo.

Só consideramos que isso seja possível graças a ausência de hierarquias e cobranças “comuns” como pontualidade ou qualquer tipo de formalidade no tratamento. Sentir-se à vontade no trabalho para nós é obrigatório e se algo está te impedindo de conseguir isso, a retrospectiva é o momento certo para discutir o ponto.

Foto: Pizza por Haseo

Como sei se está PRONTO?

Há bastante tempo eu brigo com algumas pessoas que dizem “Está PRONTO” e quando você vai ver percebe um monte de furos. Normalmente o conceito de pronto é relativo, isto é, cada um tem sua própria percepção.

No projeto que estou trabalhando pude perceber isso de uma forma bastante desagradável. A documentação fornecida pelo cliente não é clara o bastante para resolver todas as dúvidas e com isso, precisamos conversar com os usuários e tirar as dúvidas. Até aí nada demais. Para consolidar a discussão fazemos mockups, escrevemos as principais regras de negócio e passamos para o cliente dar o OK. Para os desenvolvedores, usamos um wiki para descrever os campos, regras e eventos de cada tela.

Acreditamos durante algumas semanas que isso fosse o bastante, mas logo percebemos que mesmo com isso várias regras de negócio foram esquecidas ou implementadas de forma incorreta. Foi quando lançamos mão de uma técnica chamada “Como demonstrar”. Acrescentamos a cada história uma sessão “Como demonstrar” listando todos os cenários possíveis de testes.

OK, isso é basico, você me diz. Realmente, eu respondo, me lembro que no início do projeto, há uns 2 meses, as primeiras histórias que escrevemos tinha uma sessão “Como demonstrar” no verso do cartão. Porém, além de inútil, ficou incompleto. Chegamos a duas possíveis conclusões:

  1. Nossas histórias estavam grandes demais, e por isso os cenários de testes eram muitos para o tamanho do cartão.
  2. Haviam poucos cenários no cartão, não cobrindo todos os requisitos da história.

Com isso, naturalmente paramos de escrever os cenários de testes, iludidos que os testes unitários nos dariam um direção sobre como testar as coisas. Porém, estamos trabalhando em um projeto que tem muitas regras, costumamos até dizer que para cada 10 exceções existe uma regra. Nesta hora, percebemos que a nossa definição de pronto deveria obrigatoriamente incluir cenários de testes de aceitação.

Mas, para começo de conversa, fazer esses cenários não é algo trivial. São necessários vários dados de testes para gerar bons cenários de formulários com muitas regras e consultas/relatórios com muitos dados e filtros. Mas, sem isso, o desenvolvedor estava com muita dificuldade de simular e até demonstrar para o cliente todos os cenários.

Até agora foi só conversa, então vou mostrar um pouco da forma que estamos escrevendo a sessão “Como demonstrar”. No wiki, criamos uma tabela com os campos abaixo e para cada cenário (regra ou exceção) relacionamos as entradas e resultado esperado. Para uma tela de login, ficaria algo assim:

# Cenário Entradas Resultado Esperado Status
1 Login com sucesso usuário: sauloarruda, senha: secret Login com sucesso OK
2 Usuário inválido usuário: inválido, senha: secret Mensagem de login ou senha inválidos OK
3 Senha inválida usuário: sauloarruda, senha: inválida Mensagem de login ou senha inválidos OK
4 Usuário e senha inválidos usuário: inválido, senha: inválido Mensagem de login ou senha inválidos OK
5 Usuário ou senha em branco usuário: , senha: Mensagem de validação solicitando preenchimento dos campos ERRO

Lembrando que tem que haver um banco de dados com o usuário sauloarruda/secret para os testes passarem. Após passar em todos os testes, fazemos mais alguns testes exploratórios procurando novos cenários e problemas. Se encontrarmos algo, criamos uma nova linha na tabela e colocamos o status como Pendente. Simples assim.

Esses cenários também são bons candidatos para automatização de testes usando alguma ferramenta como Webdriver ou Selenium, além de ser uma boa orientação para criação dos testes unitários. Com isso, alteramos nossa forma de trabalho para o desenvolvedor escrever os cenários de testes antes de iniciar o desenvolvimento.

Enfim, é isso. Deixem suas sugestões!