HISTÓRIAS DE USUÁRIOS – APROFUNDANDO O CONHECIMENTO

A história de usuário é apenas uma “promessa de conversa”, um lembrete de que mais detalhes serão necessários, e não deve ser considerada suficiente para a realização do trabalho. É o começo, mas somente será útil para o desenvolvimento do produto se for seguida por uma série de conversas entre as pessoas de negócios (em geral, o product owner ou P.O.) e os membros do time de desenvolvimento. No projeto SGT estes são representados pela equipe de levantamento de requisitos, uma vez que o desenvolvimento está sendo realizado por um time de especialistas na solução fisicamente alocados em diversos lugares do planeta: Estados Unidos e Angola, por exemplo.

Figura 1 – Modelo de história de usuário.

                 Fonte: http://labs.bluesoft.com.br/organizando-historias-do-usuario/

De posse destas informações as histórias de usuário concluídas são traduzidas para o inglês, alocadas no backlog (repositório de user stories) de desenvolvimento, priorizadas, incluídas em uma sprint e enfim desenvolvidas, testadas e apresentadas. Não lembra o que é o backlog, product owner ou uma sprint? Releia a matéria “O SGT e a metodologia ágil”.

Ainda dentro das histórias de usuários temos os critérios de aceitação, os quais são representados por uma lista de itens de negócio que expressam formas de usar a funcionalidades implementadas pela história. O objetivo desta lista é validar se a história foi implementada de acordo com o que o P.O. esperava. São descritos como comportamentos do sistema em desenvolvimento para atender às regras de negócio e fazem parte do aspecto de confirmação, sendo a origem dos casos de teste do sistema.

Buscamos escrever as histórias identificando o ator, a ação e a funcionalidade desejada:

Como [ator, um tipo de usuário] eu quero/preciso de/devo/gostaria de [ação, capacidade] de modo que [funcionalidade, valor do negócio, benefício].

Ou, usando uma história já contada do projeto SGT, relativa a ajustes na declaração do ITCMD:

Como auditor eu quero gerar ajustes manuais para um contribuinte específico de modo que o contribuinte possa ver o valor da dívida ajustado para maior de forma manual por um auditor, como resultado de: processos judiciais, impugnação do contribuinte, projeto de fiscalização DRR, projeto de fiscalização CRE, pedido de retificação, outros.

Para esta história, o critério de aceitação é o seguinte:

O auditor consegue ajustar o débito do contribuinte manualmente.

Neste momento estamos trabalhando com histórias de usuários relativas ao IPVA e ao ITCMD. Dividimos os macroprocessos dos tributos em cadastro, lançamento do crédito tributário, controle de arrecadação, conta corrente, parcelamento e cobrança. Foram identificadas 253 histórias de usuários, sendo que 46 já foram aprovadas.

Lembramos que o número de histórias pode mudar a qualquer tempo durante a execução do projeto, seja por aglutinação ou desmembramento de histórias, de acordo com a necessidade dos usuários para que o sistema possa atender nossas necessidades.

Fontes:

blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/, consultado em 21/06/2018.

www.knowledge21.com.br/sobreagilidade/user-stories/o-que-e-user-story/, consultado em 26/06/2018.

sitecampus.com.br/scrum-o-que-sao-user-stories/, acessado em 28/06/2018.

www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/user-stories?lang=en, acessado em 28/06/2018.

medium.com/@tboschese/documentação-ágil-user-stories-7c18f41a35e0, acessado em 28/06/2018.

www.profissionaisti.com.br/2011/06/levantamento-de-requisitos-voce-sabe-o-que-e/, acessado em 28/06/2018.