Características das Histórias de Usuário:

• Cartão
• Conversa
• Confirmação

Cartão

Por que Cartão?

Histórias de Usuário (do inglês User Stories) são requisitos escritos em cartões – também conhecidos como ficha ou em inglês Index Cards (como na imagem acima).  O propósito do Cartão é de limitar o espaço para as informações que descrevem um determinado requisito.

Por que limitar o espaço?

A razão de limitar o espaço disponível na hora de descrever uma história de usuário atende ao propósito de lembrar aos membros do time do que se trata o requisito e algum meio de identificar a mesma. Normalmente, a história possui um título de fácil associação e um identificador único que serve de fácil indexação para buscas e agrupamento de histórias de usuário por meio de temas, épicos, sprints, trimestres e etc.

Outro motivador é o segundo C, Conversa.

Quais informações o Cartão deve conter?

Inicialmente, este requisito deve deixar claro o seu objetivo de negócio que atende a um determinado ator/cliente/usuário para atingir um determinado benefício.

Ao longo do desenvolvimento, o Cartão deve ser utilizado para entendimento, planejamento e amadurecimento da funcionalidade. Conforme outras informações vão sendo descobertas, este cartão pode ser complementado com: prioridade, estimativa (caso o time trabalhe com estimativas), riscos, dependências, suposições e quaisquer informações que sejam pertinentes para o desenvolvimento.

 

Conversa

Lembrando de um dos 12 princípios do manifesto ágil:

O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

Quem Conversa?

O requisito idealmente deveria ser comunicado de um cliente ou usuário para o time ou para as pessoas que irão desenvolver a mesma. Esta conversa deveria expressar os pensamentos, opiniões e sentimentos. Não deveria ser apenas uma comunicação unidirecional, ou seja, é possível de que neste momento o negócio descubra que existe alguma limitação técnica para implementar uma determinada funcionalidade, inviabilizando a mesma.

Ao pensar nos fluxos de uso, ao criar mockups de interface, ao documentar cenários, novos documentos podem surgir para uma determinada funcionalidade e estes fazem sentido desde que agreguem valor e não sejam criados apenas para estar aderente a um determinado processo de desenvolvimento.

Confirmação

Independente da quantidade de tempo que o time invista em amadurecer e clarificar um requisito ou funcionalidade de um sistema, o que tem se observado é que nós não sabemos como a funcionalidade ficará quando estiver pronta.

Na etapa de Confirmação, diversas atividades podem ocorrer. Ao desenvolvedor ler um determinado requisito e avaliar o sistema, podem surgir dúvidas que devem ser endereçadas por alguém especialista de negócios (em inglês SME – Subject Matter Expert) ou por um Product Owner / Product Manager, dependendo do ambiente e das metodologias utilizadas para desenvolver software.

Os critérios de aceite de cada história de usuário também devem ser meios de confirmar que o comportamento de uma determinada funcionalidade está sendo atendido com as regras de negócio que foram desenvolvidas. Na teoria, são os critérios de aceite que nos dizem quando uma história de usuário está pronta para ir para produção.

É preferível de que estes testes de aceite sejam automatizados pois quando são criados de forma textual em documentos isolados existe uma grande chance de ser tornarem obsoletos, desatualizados ou até mesmo esquecidos. Uma abordagem possível é transformar os critérios de aceite em testes automatizados de aceitação. Esta abordagem é conhecida como BDD – Behaviour Driven Development.

Uma outra Confirmação pode ser feita pelo benefício que aquela determinada funcionalidade proporciona e ou com o feedback das pessoas que de alguma forma solicitaram aquela determinada funcionalidade.

 

Histórico e origem

Este texto foi uma interpretação do modelo original dos 3C’s proposto por Ron Jeffreis em 2001. Não é uma tradução direta dado que experiências pessoais foram incorporadas no texto.

Embora o texto seja antigo, os requisitos que entram nos ciclos de desenvolvimento de software das organizações seguem sendo um grande desafio.

Publicação original do modelo em inglês: https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/