3.4 Histórias de Usuário

Em eXtreme Programming [Beck, 2000] os requisitos eram capturados em “Histórias de Usuário”. As Histórias de Usuário eram escritas em cartões de índice e descreviam expectativas funcionais da perspectiva de um usuário. Bill Wake, um praticante precoce de eXtreme Programming, sugeriu o

“INVEST”[5] acrônimo como uma maneira simples de lembrar e avaliar se ou não uma História de Usuário está bem formada: Independente, Negociável, Valiosa, Estimável, de Tamanho adequado, Testável.

Histórias de Usuário geralmente descrevem uma funcionalidade como uma “História” a partir da perspectiva do “Usuário”. A vantagem de tomar a perspectiva do usuário para descrever o requisito de sistema ou aplicativo é o foco no valor do trabalho para esse usuário.

Os cartões são fáceis de mover, ou serem removidos de um quadro de planeamento, como um radiador da informação. Outra vantagem de usar cartões físicos para as histórias é o espaço limitado para descrições textuais e detalhes. Assegura-se que ele está incompleto por design e desta maneira certifica-se de que uma conversa ocorra. Quando uma história de usuário chega mais próxima de ser feita e a chance de ela ser implementada cresce, isso necessariamente requer uma conversa para descobrir detalhes adicionais. Mais informações podem ser adicionadas ao cartão e algumas destas podem ser expressas como critérios de aceitação para a história de usuário, a confirmação de que a história está bem implementada. Esses critérios de aceitação são tipicamente escritos na parte de trás do cartão.

O Product Backlog no Scrum serve para dar transparência de todo trabalho que um time precisa fazer. Isto compreende mais do que apenas requisitos funcionais. Embora o formato de história de usuário possa ser usado para outros tipos de requisitos além do funcional, não há um encaixe natural. Ele tende a colocar o foco na sintaxe em vez da informação a ser transmitida.

No Scrum, não há nenhuma obrigação em usar o formato de história de usuário para itens do Product Backlog. Isso até cria o risco de negligenciar outros trabalhos importantes que precisam ser executados, ou podem forçar os times a gastar mais tempo e energia usando o formato “certo”, criando assim desperdício. No entanto, para itens funcionais do Product Backlog, as histórias de usuário podem ser muito boas, uma ótima tática.

OceanofPDF.com