Uma história de usuário pode ser definida em uma frase como:
As a <type of user> I want <some goal> so that <some reason>
Apenas o Google para 'fórmula da história do usuário' e os primeiros links propõem essa fórmula.
Minha pergunta é: qual é o propósito dessa cláusula? Existe para os gerentes? Existe para que os gerentes de projeto e as partes interessadas possam entender melhor a prioridade do item? Por que está aí?
Nota: Eu trabalhei com as a <type of user> I want <some goal>fórmula e funciona muito bem. Não notei nenhum problema no meu trabalho ao implementar esse formato, que é mais breve.
user-story
Saeed Neamati
fonte
fonte
Respostas:
O objetivo é evitar trabalho desnecessário, forçando o usuário / cliente a fornecer um benefício comercial sólido e tangível como uma razão para a existência desse recurso.
Não é incomum que esses recursos sejam adicionados apenas porque alguém achou que parecia legal ou porque outro software o possui, então o nosso também deve tê-lo. Na maioria das vezes, essas são pelo menos completamente desnecessárias, se não ativamente prejudiciais.
No entanto, geralmente é fácil identificar esses recursos, porque as pessoas que os propõem geralmente têm problemas em fornecer uma razão comercial convincente para eles.
Existe uma técnica chamada Popping The Why Stack , onde você pega a parte "so that" e pergunta "Why?", Depois pega a resposta e pergunta "Why?" novamente, recursivamente. Se, depois (digamos) de três a cinco "Por que", você não chegou a "porque nos dará dinheiro" ou "porque nos poupará dinheiro" (de preferência com uma descrição precisa de como exatamente isso vai acontecer), então não vale a pena implementar o recurso.
Algumas pessoas acreditam que isso é tão importante que, na verdade, colocam em primeiro lugar no modelo da história:
Há um ótimo exemplo de uma palestra de algumas pessoas da Thoughtworks: um de seus clientes queria que os relatórios impressos fossem formatados de uma maneira muito peculiar. Quando o consultor perguntou "Por que", eles disseram que dessa maneira eram mais fáceis de digitar novamente. Portanto, em vez de implementar o recurso de formatação de relatório, eles apenas transferiram os relatórios pela rede. Sem a cláusula "para que", eles ainda estariam imprimindo os papéis em um departamento, enviando-os por correio para o outro departamento e digitando-os novamente.
fonte
O "para que" fornece uma razão para a meta.
Por exemplo, o objetivo pode ser exibir os números de vendas do mês passado. Você poderia trabalhar com isso, mas um motivo é necessário saber por que você deseja exibi-los para que você possa obter os requisitos mais profundos. O que eles querem fazer com os números de vendas ou clientes potenciais? Conhecer essas informações fornecerá mais informações sobre o aplicativo e mais chances de projetar uma interface do usuário que permita ao cliente fazer o que deseja.
Outro uso pelo motivo é priorizar histórias. Se você tem duas histórias:
mas só tem os recursos para fazer um - qual deles você faz? Sem o motivo, você estaria apenas adivinhando e talvez não entregasse o caminho certo a tempo. Embora isso seja menos importante, o cliente deve dizer o que fazer primeiro, mas ocasionalmente não é esse o caso.
fonte
Além do que foi dito, fornecer uma razão para os requisitos permite que você julgue a validade do requisito. O usuário pode querer coisas pelo motivo errado. Tendo o "para que" esclareça o motivo, permite ao analista validar que a solicitação é melhor atendida dessa maneira.
Exemplo:
A AI deseja poder selecionar funcionários de uma lista de todos os funcionários da empresa
O BI deseja poder selecionar funcionários de uma lista de todos os funcionários da empresa, para que eu possa excluir os que deixaram a empresa há 5 anos.
(B) não faz sentido, mesmo em uma organização média, mas você pode validar o requisito do usuário e propor outra maneira de o cliente atender ao requisito.
fonte