SCRUM::Criando histórias de Usuário (User Story) de qualidade

SCRUM::Criando histórias de Usuário (User Story) de qualidade

– O que são histórias de usuários? De forma bem objetiva, são os itens de uma Product Backlog (A listagem destes itens) que se tornarão parte do produto desenvolvido. Para cada História, devemos informar de forma simples mas, ao mesmo tempo com detalhes suficientes, o que se espera implementar como uma parte do produto, como uma feature.

Como muitos devem saber, User Story não é necessariamente uma parte ou requisito do Scrum, nem obrigatório em qualquer metodologia ágil. Mas embora opcional, seu uso conforme elaborado por um Gestor de produto, conhecido como Product Owner, têm sido muito eficaz no desenvolvimento ágil. Na realidade, têm sido tão eficaz que se tornou quase que obrigatório. Pelo menos a grande maioria que trabalha com metodologias ágeis utilizam User Story.

Visto que estamos falando de “histórias de usuário”, faz se necessário lembrar que é a necessidade do usuário que vale. Além disso, essas histórias são informais e poderão até mudar algumas vezes conforme a necessidade durante a evolução do produto. As metodologias ágeis são diferentes neste aspecto, em relação a metodologia Waterfall (Onde se obtém todos os detalhes/requisitos do projeto antes de ser implementado). Essa ideia vem desde a metodologia XP (Extreme Programming), onde surgiu a ideia de se utilizar essas anotações como histórias de usuários.

Criar histórias de Usuário não é tão simples quanto parece, mas ao mesmo tempo não exige muito conhecimento técnico do Gestor do Produto. Acontece que, elas não devem ser tão curtas a ponto de se parecem apenas um recado. Mas também, não devem ser tão compridas e detalhadas a ponto de se parecem especificações técnicas. Muito menos, deverão conter qualquer tipo de diagrama UML!

Tenho visto em muitos artigos, a recomendação que desejo reforçar aqui: o uso de 6 características para a criação de uma User Story de qualidade de qualidade, representadas pelo acrônimo INVEST (https://en.wikipedia.org/wiki/INVEST_(mnemonic)).

Somando isso com a técnica de Example Mapping, será realmente possível criar histórias de qualidade.

Para criar uma história de usuário, você pode adotar uma forma muito conveniente e utilizada:

  • Como a/o/um | Sendo a/o <pessoa simulada>

  • Quero | Devo | Preciso | Gostaria de <ação, o que se faz, a necessidade na história>

  • Porque | Para <Motivação dessa necessidade – Porque você precisa, quer ou deve?>

Tome como exemplo essas histórias de usuário para um blog:

“Como um usuário do blog devo me autenticar de forma padrão para conseguir comentar uma postagem

“Como um usuário que faz postagem devo me autenticar como editor para conseguir postar um novo artigo

Outros exemplos, no caso de um site para anunciar vendas de veículos. Seriam:

“Como um usuário interessado devo me cadastrar no site para criar um anúncio de venda de veículo

“Como um usuário cadastrado preciso me autenticar no site para editar os dados do anúncio

“Como um usuário autenticado gostaria de anexar uma ou mais fotos de um veículo para serem exibidas como parte do anúncio

“Sendo o usuário proprietário de um anúncio gostaria de selecionar uma foto do veículo para exibir como destaque no anúncio

“Sendo o usuário proprietário de um anúncio quero uma maneira para destacar o anúncio porque espero ter maiores chances de vender o veículo

O INVEST representa as iniciais: Independente, Negociável, Valioso, Estimável, “Small” – Pequeno, Testável. E como é que temos tudo isso alí naqueles exemplos?

Veja que se sabemos o que se deseja e o seu “porquê” (sua motivação), então temo um indicativo de valor para o negócio. Sendo assim, também será possível testar cada necessidade e o cliente saberá como fazer isso. Se o cliente não sabe como testar é porque a história não está clara o suficiente e talvez o “porquê” (a motivação), esteja causando confusão. Dessa forma, não estaria de fato, agregando valor! e se de fato, não agrega valor, logo não faz sentido existir. É importante lembrar que, para agregar valor é necessário captar a “ideia”, a “essência” da coisa, e não um monte de detalhes para uma feature.

Então, embora talvez seja desnecessário esse comentário aqui para muitos, mas é válido dizer que já me deparei com situações que precisam do alerta: se você também for programador e estiver participando de uma reunião para desenvolvimento ou desmembramento de um história de usuário, lembre-se que ninguém quer saber naquele momento: qual é o ícone apropriado para o botão da “toolbar” que … Nem muito muito menos, que o componente melhor para a tela tal poderá ser um datagrid tal porque …, ou o servidor Linux é bom para … esquece!

Estando no papel de criar histórias, deve-se coletar a essência da coisa, e não viajar em uma utopia de como o software será implementado. Afinal, ali naquele momento ninguém estará definindo uma documentação de requisitos para selar um contrato para implementar features.

Note também que, nos exemplos anteriores foi possível especificar necessidades independentes, sem ligações “íntimas” entre si e essa é uma das características mais difíceis! Neste caso, sendo uma história independente, será possível implementar uma feature partindo dela, em qualquer momento ou qualquer ordem. Porque não existe nada amarrando-a e criando uma corrente entre histórias, ou até mesmo a ideia da cascata (Esse primeiro, depois esse, …). Perceba que dessa maneira, não travará o processo em nada, porque não será necessário terminar primeiro uma para depois se implementar uma outra, gerando um gargalo enorme, prejudicando a entrega no final da Sprint. Perceba que, se isso ocorrer, talvez seja o caso em que duas ou mais histórias sejam redundantes.

Outro detalhe, as histórias ficaram bem objetivas sendo pequenas, porém contendo detalhes suficientes para se entender (de novo) a “essência”, o que se espera na implementação das features. Por fim, perceba que expressamos desejos do usuário, e assim, acabam sendo negociáveis. Embora sendo curtas ou pequenas, teremos bases para estimá-las, sabendo quanto esforço da equipe será necessário. Também aqui é importante entender que histórias sendo curtas, serão estimadas com maior precisão, porque o time não vai ficar supondo o tempo de implementação lá em cima, simplesmente porque não entendeu exatamente o que se espera. Precisamos ser “capaz” de estimá-las e não “chutar aí um tempão” … rs

Agora que já temos as histórias, próxima etapa será desmembrá-las! Fazendo isso, teremos o cenário de teste e a visão real do usuário sobre a necessidade.

Podemos usar uma técnica conhecida como Example Mapping em uma reunião com tempo fixo e tema único, apenas uma história. Seguindo a recomendação, será necessário convidar 3 a 5 pessoas que representem o negócio. O tempo sugerido é de 25 a 30 minutos no máximo. Neste tempo será desmembrado apenas uma das história de usuário, e caso surjam novas histórias, o que é facilmente identificável, deve ser anotada e tratada em outra reunião, exatamente para não ofuscar a ideia primária.

Nesta reunião, se obtém as regras com os critérios de aceitação para a necessidade. Isto será válido para a feature que será implementada conforme a história de usuário. Vamos lembrar aqui novamente, como já dito, que o usuário cliente que expressou a necessidade, sabe como testar a ideia, por isso é plenamente capaz de indicar tais regras. Se ele não souber, é porque a história está confusa, não é exatamente o que ele pensou e se continuar assim, será tempo perdido.

Como temos regras, é possível “aplicar exemplos” de testes para cada regra definida. O exemplo precisa contar com um cenário ou contexto, a ação do usuário neste contexto, bem como o resultado esperado para essa ação dentro desse cenário. Dessa forma, nossa história começa ser testável. Essa etapa pode ser base para construção de testes automatizados, mas estes não são necessariamente a definição dos testes automatizados. Até porque, se adicionarmos detalhes técnicos de implementação nesta etapa, detalhes desnecessários serão discutidos, envolvendo até mesmo pessoas que não estarão tecnicamente preparadas para tal, sendo que detalhes valiosos que verdadeiramente descreveriam o negócio, serão inevitavelmente ofuscados. Portanto, evite entrar em detalhes meramente técnicos aqui.

A técnica de example mapping também sugere o uso de cartões ou post-its coloridos, cada um com seu objetivo e que de preferência, as cores sejam padronizadas para equipe. Isso evitará confusões, principalmente porque chegará um momento em que a cor estará ligada a ideia ali aplicada.

Escolha uma das cores para conter a User Story, e logo em seguida outra cor que representará uma regra de aceitação. Descreva apenas uma regra de aceitação por cartão ou post-it! E daqui a pouco virão exemplos, não se preocupe! 🙂

Quando tivermos uma regra de aceitação, teremos então definido obviamente um critério de aceitação. Isso é redundante mas esclarece o ponto! E se você têm um critério de aceitação, pode aplicar cenários de testes para identificar resultados de sucesso e insucesso. Logo, poderemos eleger outra cor de cartão ou post-it para definirmos cada exemplo.

Durante a reunião, poderão surgir questionamentos válidos sobre a história, a regra ou o exemplo. Mais uma vez, poderemos eleger uma nova e quarta cor para indicar os questionamentos que ficarão documentados.

Um padrão de cores sugerido: amarelo para User Story, azul para Regras, verde para Exemplos e Vermelho/Rosa para Questionamentos. Esse padrão de cores foi proposto pelo Cucumber. (https://cucumber.io/blog/example-mapping-introduction/)

Então para iniciar o entendimento da ideia, vamos tomar uma história como exemplo:

“Como um usuário interessado devo me cadastrar no site para criar um anúncio de venda de veículo

Exemplos de regras aqui seriam:

Dados obrigatórios devem ser informados tais como nome, e-mail

Uma senha complexa deve ser provida com letras, números e ao menos 8 caracteres

Estas regras poderiam estar, cada uma, descrita em um cartão azul. Tendo estas regras provido critérios de aceitação, podemos prover exemplos correspondentes.

Antes de começar a escrever, talvez seja importante pensar em acontecimentos aproximados. Para isso, também há uma convenção amigável sugerida, partindo da ideia: “The one where …”, ou seja , “Aquele onde/em que …”. Note abaixo:

  • Aquele em que o usuário cadastrado esquece de informar seu nome de usuário.

  • Aquele onde o usuário cadastrado informa uma senha com apenas números.

Veja que raciocínio interessante em uma reunião! Daí, para descrever um exemplo, considere prover: contexto, ação e resultado esperado.

Você vai perceber uma sintaxe muito parecida com: Give … when … then… Mas não se prenda rigorosamente a essa estrutura. Apenas note os exemplos:

Para um “caminho feliz”:

  • Para dados obrigatórios

  • usuário informa dados válidos e quando e submete formulário

  • Resulta: Ok! Cadastro efetivado com sucesso

Para um “caminho triste”:

  • Para dados obrigatórios

  • usuário esquece de informar um dos dados e quando submete formulário

  • resulta: Falha! Dados incorretos

Ou:

Para um “caminho feliz”:

  • Para senha complexa

  • usuário informa uma senha 1234abcd e quando submete formulário

  • Resulta: Ok! Cadastro efetivado com sucesso

Para um “caminho triste”:

  • Para senha complexa

  • usuário informa uma senha 12345678 e quando submete formulário

  • Resulta: Falha! Senha não atende os requisitos de complexidade

Vale dizer que, o Cucumber (https://cucumber.io/) provê ferramentas para a documentação de example mapping e sem dúvida será interessante para documentar o que ocorreu na reunião, talvez utilizando até uma sintaxe Gherkin. Mas não se apegue a nada disso durante a reunião pois, poderá intimidar os usuários ou gastar muito tempo valioso apenas no entendimento de algo desnecessário para o momento.

Mas e se por algum motivo aparecerem dúvidas? Como já mencionado, um cartão vermelho/rosa pode ser usado para isso. Talvez, nessa mesma linha de raciocínio sobre o cadastro, um questionamento seria:

“O e-mail cadastrado para o usuário deverá ser único?”

Dependendo da resposta do cliente, poderá surgir aqui uma nova regra de aceitação. Mas outro questionamento seria:

“Será preciso confirmar o e-mail do usuário?”

Note que neste caso, poderemos ter uma nova história de usuário.

Os exemplos aqui foram simples, e claro que não representaram nenhuma regra de negócio mais complexa. Mas tenha certeza de que estes principios e métodos serão válidos para todos os cenários, desde o mais simples, até os mais complexos!

[]’s

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.