A história das histórias do usuário

Fiz há alguns dias um post com uma narrativa temporal, desde os objetivos estratégicos até a entrega de cada pedaço de software mais valioso ao cliente. Dois amigos curtiram e me pediram algo introdutório, simples, sobre a história das histórias do usuário. Aqui vai!

Pressupondo que temos clareza e valor do porque uma história deve ser escrita ou detalhada, aderente a visão de negócio, produto ou serviço. Se utilizando para isso de abordagens e técnicas para estratégia, portfólio, roadmap, planejamento e tal … que nos proporcionou um product backlog priorizado.

História das histórias do Usuário

Aparentemente nos anos 90, Kent Beck ao compartilhar conceitos sobre Extreme Programming, falava de formas alternativas para descrever funcionalidades que não através de requisitos funcionais, não funcionais e regras de negócios. Chamadas de histórias do usuário, eram alusivas a narrativa de um usuário sobre suas necessidades, nascia ali o “Como <persona>, eu quero <interação, necessidade> para obter <valor>”.

Segundo Kent Back, assim como é possível durante um storytelling identificar e representar quem é o ator, sua ação e o resultado dela, gerando empatia e foco na narrativa e sua contextualização imaginária. Se isso é um fato, mais ainda para descrever as ações ou funcionalidades pertinentes a um software, transformando o aspecto formal e tecnicista dos requisitos tradicionais em uma conversação em linguagem natural.

Outro grande nome naqueles momentos antológicos dos anos 90 é Jeff Patton, muito citado neste blog, por ser uma linguagem natural e focada na visão e narrativa do usuário, sua narrativa está focada na necessidade e valor que gera e não na notação escolhida para sua escrita … por isso “histórias dos usuários”. A partir da conceituação, venho em decorrência uma notação que garantisse suas premissas:

Narrativa (Quem – O que – Porquê)

A ideia era perguntar ao usuário as suas necessidades e ir registrando-as em pequenos cartões que poderiam ser então ordenados, priorizados, finalmente a seu tempo, ter seu entendimento refinado. Ao natural surgiram conceitos como 3C (Ron Jeffries), INVEST e MoSCoW, também os critérios de aceitação, uma forma natural para descrever as regras essenciais envolvidas na validação daquela história por aquele usuário.

Com o tempo consolidou-se a imagem de histórias do usuário como cartões com a sua narrativa de um lado e os seus critérios de aceitação do outro, ao mesmo tempo mínimos e suficientes para a compreensão do que e porque o usuário desejava ou necessitava tal funcionalidade. Um nome que também precisa ser citado nesta retrospectiva das histórias é o de Mike Cohn, responsável pelo antológico site da Mountain Goat SW,

3 C’s

Ron Jeffries propôs critérios para compôr uma história do usuário baseado em três C’s – Cartão, referência a um cartão ou mesmo um postit que dá forma tangível à abstração que a história representa. Conversa simboliza que a história é fruto do debate e co-criação entre as pessoas envolvidas e interessadas. Confirmação representa se está claro os termos para que os objetivos da história terão sido alcançados.

INVEST

Disseminado por Mike Cohn em User Stories Found de 2004, INVEST representa os critérios essenciais de uma história do usuário – Independente, Negociável, Valoroso, Estimável, Pequeno (Small) e Testável. Derivados do acrônimo SMART (Específico, Mensurável, Atingível, Relevante, Time-boxed), não devem ser dogmas, mas representam boas práticas recomendadas em requisitos ágeis.

MoSCoW

Após escritas, histórias do usuário são debatidas em jogos de planejamento, priorizando-as com o método MoSCoW. Muitas equipes usavam esta escala de valor nos primórdios dos métodos e práticas ágeis, um acrônimo para Must Have, Should Have, Could be nice e Won’t Have (Deve, Deveria, Poderia ou Não deve). Já vi muitas equipes usarem uma simplificação Meta (necessário), Não Meta (desejável) e Não escopo.

Critérios e a notação Gherkin

Os critérios de aceitação garantem o entendimento daquilo que são regras a serem validadas para saber se a história atingiu seu objetivo e valor propostos. Inicialmente e para muitos times, critérios de aceitação são relatos textuais contendo cada uma das regras que envolvem determinada história.

A notação Gherkin (Dado que – Quando – Então) descreve comportamentos para testes do Behavior Driven Development (BDD). O objetivo é criar automação de testes a partir da descrição baseada em exemplos (comportamentos) de quando o usuários interage com o sistema, um a um, exemplos reais.

Na história com narrativa: Como usuário, Preciso fazer login, Para ver minhas campanhas de marketing. Poderíamos ter como critérios Dado que estou na página de login, Quando insiro meu nome de usuário e senha corretamente E clico em ‘Entrar’, Então sou levado ao painel.

Na narrativa de Como cliente que comprou um produto, devo poder devolvê-lo, caso esteja com defeito. Um critério de aceitação textual é que ao devolvê-lo com sucesso deve receber o valor integral de volta. Com Gherkin temos um exemplo prático, como: Dado que Jorge comprou um computador por R$10000, Quando ele devolve o computador com sucesso, Então Jorge deve ser reembolsado em R$10000.

Além da História do Usuário

Em posts anteriores já defendi a tese comum de que histórias são a granularidade final, pois podemos iniciar com temas de negócio, épicos, features, histórias, até chegar na especificação completa, conjunto que alguns autores da comunidade Scrum chamam de DoR (Definition of Ready), acordados de forma singular a cada time.

Raramente a especificação ou o DoR é apenas uma User Story, a história começa com seu cartão, mas a medida que entra em especificação tem agregado outros potenciais artefatos, como o resultado de um trabalho de UX, um planejamento de testes mais refinado e uma documentação complementar detalhando questões relevantes de negócio, integrações e informações adicionais essenciais para implementação ou registro.

Minha defesa de tese é que a quantidade de documentação necessária é inversamente proporcional às boas práticas em desenvolvimento de software. Um time com profissionais que adotam conceitos oriundos de abordagens como Domain Driven Development (DDD), BDD (Behavior Driven Development), orientação a serviços (API first), clean code, code review, integração contínua, …

Tenho treinamentos de US, conceito e técnicas amplamente difundida, mas a história das histórias sempre tem uma pitada de curiosidade e trocas que perpassam um tanto das icônicas origens dos Métodos Light Weight (Agile) e os tantos métodos representados em Fevereiro de 2001, além do Scrum 🙂

Outros posts que podem ajudar

• https://jorgeaudy.com/2021/06/30/historia-do-usuario-quando-nascem-como-onde-o-que-comem/
• https://jorgeaudy.com/2018/09/25/impact-mapping-example-mapping/
• https://jorgeaudy.com/2017/12/11/fibonacci-user-story-points-e-frutas/
• https://jorgeaudy.com/2018/04/07/registros-de-uma-montanha-nevada/