Durante a minha jornada como solution architect em encontrei várias user stories memoráveis. Umas por bons motivos e outras por motivos…. menos bons. Hoje eu vou partilhar com vocês as estórias dessas user stories.

Mas antes, que tal relembrar o que são user stories?

Uma user story (US), do ponto de vista do produto, é a menor parcela de trabalho a ser executada com a perspetiva de atender uma necessidade do cliente(utilizador). Uma boa user story deveria respeitar um conjunto de critérios que vão facilitar tanto a identificação da sua prioridade quanto o seu desenvolvimento. O mercado, para facilitar a identificação dos critérios mais importantes, criou o acrónimo INVEST. O seu significado é:

I – Independente: as US não devem depender entre si;

N – Negociáveis: as US são a base para a discussão que leva ao seu refinamento;

V – Valorada: a US descreve as vantagens que ela traz para a solução;

E – Estimável: a US contém informação para o cálculo do esforço da implementação;

S – Sintética: a US trata apenas de uma funcionalidade focando no essencial;

T – Testável: a US contém informação suficiente para que sejam criados testes.

Dica para o meu leitor Scrum Master: da próxima vez que for ajudar na criação de uma Definition Of Ready, leve em conta os critérios acima. Os critérios servem como ponto de partida e é mais fácil elaborar a partir de uma base já existente.

Então vamos lá as nossas estórias:

A armadilha técnica

O requisito inicial desta US era mais ou menos: “O sistema A deve partilhar mais informações sobre vendas com o sistema B. A partilha deverá ser feita através de tabelas de transferência numa base de dados partilhada entre os dois sistemas…”.

Essa US não passou dos primeiros dez minutos da sessão de refinamento. Todas as comunicações entre os sistemas eram feitas através de web services, nunca através de bases de dados partilhadas.

Esse caso é um flagrante desrespeito ao critério “S” descrito acima. A pessoa que escreveu a US, no caso um PO com forte background técnico e novo no projeto, optou por tentar impor uma forma de resolver o problema. Esse é um erro muito comum com autores com o mesmo perfil.

Quando escrevemos US deve ter em mente que o objetivo é descrever o melhor possível a funcionalidade requerida. A forma como ela será implementada esta fora do âmbito da própria US.

Diga como testar e eu te mostro como driblar o teste

O objetivo desta US era introduzir pequenas alterações a um formulário e melhorar a performance durante a exibição inicial. O critério de aceitação focava apenas na animação que era exibida durante o carregamento do formulário.

Durante a sessão de refinamento a solução que emergiu da equipe foi a troca do GIF da animação, por um com o movimento mais rápido, e a sua exibição por menos tempo. Esta ideia “espertinha” passava pelos testes de aceitação, porém, não resolvia o problema real, que era a demora no carregamento do formulário. Após a bem-vinda intervenção do Scrum Master a situação foi esclarecida e o critério de aceitação foi melhorado para refletir o objetivo de melhoria de performance do formulário.

Desta vez a vítima foi o critério “T”, onde devemos garantir que é possível testar a user story. Mais uma vez, quando escrevemos user stories, o foco deve ser na funcionalidade que estamos tratando e por isso o teste deve incidir exatamente sobre ela.

Ah! Outro problema que eu vejo repetidamente nos critérios de aceitação é a repetição do requisito com palavras similares. Isso tende a acontecer com as user stories mais simples. Um exemplo:

Requisito: Enquanto utilizador do blog, quando tentar sair da página um diálogo perguntando se eu quero poder registar o meu e-mail para assinar a mailing-list deverá ser exibido.

Critério de aceitação: Dado que um visitante do blog vai sair da página, apresentar um diálogo perguntando o e-mail para subscrição da mailing-list.

Do ponto de vista do negócio, vocês conseguem perceber que o ponto mais importante da funcionalidade não é testado pelo critério de aceitação? O dado coletado é mesmo um e-mail e foi devidamente guardado para utilização futura?

Gémeas siamesas

Quando estamos no início de um projeto ou quando existe pressão para que o trabalho apareça logo este tipo de US é mais comum de ser encontrado. Um exemplo que eu encontrei foi:

“Como um gerente de contas, eu quero continuar a preencher os formulários de visita enquanto estiver offline no mesmo ponto em que eu estava antes e sem a necessidade de fazer login.”

Esta US, na verdade contém duas funcionalidades: continuar a edição do formulário onde parou e aceder os dados sem a necessidade de login. Daí eu as chamar de gémeas. Além disso, da forma que foram escritas, as funcionalidades parecem ter uma ligação e dependência entre si. Daí siamesas.

Desta vez os critérios não cumpridos foram o “I”, “E” e “S”. Como a US ficou muito complexa ela dificulta a criação de uma estimativa acertada, não consegue se focar no essencial pois existe mais de uma funcionalidade sendo descrita e isso pode causar dependências de outras user stories.

Depois de alguma conversa, já dentro da reunião de planeamento, a equipa optou por separar a US original em duas:

“Como um gerente de contas, eu quero ter acesso ao sistema em modo offline sem necessidade de login.”

“Como um gerente de contas, eu quero poder voltar a preencher o formulário de visita de onde eu parei”

Mais simples, mais genéricas e independentes.

A que nasceu pronta

Às vezes, mesmo pessoas com experiência na escrita de US, podem ignorar certas funcionalidades já existentes ou presentes por omissão no ambiente onde a solução é executada.

O exemplo que eu tenho é a uma US que continha o seguinte requisito no âmbito da implementação de uma aplicação baseada em Windows forms:

“Deverá existir um atalho no teclado que faz logout do utilizador e fecha a aplicação”

A princípio vamos ignorar o facto desta US também poder ser classificada como Gémea Siamesa (fechar a aplicação e o logout podem ser encarados como funcionalidades diferentes).

A questão aqui é que como a aplicação só poderia ser executada em windows, lembre-se ela era baseada em windows forms, e o windows já tem o ALT+F4 como atalho para fechar a aplicação atual!

Além disso, era um requisito numa outra user story, escrita pelo mesmo autor, requeria que todas as vezes que a aplicação fosse encerrada toda informação referente ao utilizador deveria ser limpa. Assim nada precisou ser implementado. Porém, tempo precisou ser gasto por mais de uma pessoa para que a US fosse criada, priorizada e, finalmente, esta conclusão atingida.

Definitivamente não foi o melhor ROI.

US bem escritas são o caminho para um projeto mais tranquilo. A alternativa de voltar a ter cadernos de requisitos e toda a burocracia envolvida, na grande maioria das vezes, é pior. Caso as US no modelo tradicional não sejam as mais adequadas para o ambiente do projeto, existem outros modelos ágeis que podem ajudar. Dê uma olhada em: Job Stories, Improvement Stories ou FDD (um primo do BDD).

Uma última sugestão para o meu leitor escritor de US: A prática sempre leva à perfeição (exceto na roleta russa onde a prática leva ao desastre). Quanto mais US você escrever melhores elas ficarão. Conheça as equipas que vão ler o seu trabalho. Direcione a sua escrita para eles. Conheça o melhor possível o projeto onde está envolvido.

Boa diversão!