O ator de uma história de usuário deve ser um ser humano?

Question

As histórias de usuários são tradicionalmente escritas como a expressão "Como [tipo de usuário], quero [recurso] para que [algum benefício]".Nos livros e recursos online, [Tipo de Usuário] normalmente corresponde a uma função de um ser humano.No entanto, ao descrever recursos internos do sistema, muitas vezes é mais fácil colocar algum serviço autônomo no lugar de um usuário, por exemplo."Como ServiceX, quero que alguns dados sejam atualizados regularmente para que eu possa fazer XYZ usando as informações mais recentes".

Esse formato facilita a escrita de testes de aceitação fáceis de entender para partes relacionadas do sistema.Mas isso é conceitualmente correto?As histórias de usuários não deveriam ser baseadas em recursos que fornecem negócios valor, e como os sistemas e serviços não estão interessados ​​em obter valores de negócios, eles não deveriam ser atores de histórias de usuários?

Answer 1

Os sistemas certamente estão interessados ​​em obter valor comercial.Um ator pode ser um agente automatizado escrito por terceiros e que incorpora a intenção desse terceiro.Na verdade, esta está se tornando uma forma dominante de interação à medida que os serviços web se tornam um recurso mais popular nos principais sites, permitindo assim interações complexas entre sites em nome dos usuários, mas envolvendo apenas máquinas.

Answer 2

Não vejo por que um ator deveria ser humano - seu exemplo é uma razão perfeitamente boa para que não seja.

O problema com uma metodologia como essa é não se preocupar em se ater às minúcias da prática definida.Mesmo que as pessoas que originalmente criaram o conceito de "histórias de usuários" pensassem que elas deveriam se aplicar apenas a humanos, não existe nenhuma lei que o obrigue a seguir rigidamente seus conceitos.

O objetivo das histórias de usuários, do ágil, do scrum e de todas as outras metodologias é ajudar com o processo de desenvolvimento, não ser o processo de desenvolvimento.Uma metodologia só tem valor se melhorar o processo, então é assim que você deve usá-la.Você deve se sentir à vontade para adaptar a metodologia às suas circunstâncias específicas.Não deixe que a metodologia se torne mais importante do que o próprio desenvolvimento do código.

Answer 3

Aqui está o segredo.Não são histórias de usuários, mas cenários de usuários.

O do utilizador é a coisa que interage - a máquina ou uma pessoa.

O parte interessada é a pessoa ou empresa que obtém o benefício da interação (nunca é uma máquina;pelo menos não nesta fase do desenvolvimento da IA).Geralmente existem várias partes interessadas com necessidades concorrentes para qualquer projeto.A principal parte interessada pode ser localizada descobrindo quem está pagando pelo projeto e por quê.

O usuário é raramente o principal interessado.Normalmente, uma parte interessada deseja que um usuário faça algo para que ela, a parte interessada, possa obter o benefício.

Por exemplo, os investidores do Twitter desejam que os usuários aproveitem o Twitter para que possam manter todas as suas opções para ganhar dinheiro no futuro.Os chefes querem que suas secretárias usem processadores de texto para que possam digitar as cartas mais rapidamente e mudar de ideia no último minuto.StackOverflow deseja que ótimas postagens sejam votadas positivamente para que possam obter receita de publicidade.

Aqui está uma postagem do blog que escrevi sobre o assunto, incluindo um modelo que você pode usar para separar as preocupações do usuário e das partes interessadas.Deixo como exercício para você imaginar quem se beneficia quando você, usuário do post, o lê.