Utilisation des histoires d'utilisateurs pour automatisé, programmé ou fonctionnalité réactive

Question

Je me demandais ce que la pensée est en ce qui concerne l'utilisation du récit de l'utilisateur pour décrire des automatisé, programmé ou fonctionnalité réactive. Par exemple, que faites-vous quand vous avez quelque chose comme un processus d'exécution des commandes qui consiste à tirer une commande à partir d'une file d'attente, la préparation d'un « formulaire de commande de remplissage », envoyant le formulaire à un centre de traitement des commandes, puis d'attendre une sorte de confirmation le centre de traitement, telles que « l'ordre accompli », ou « ordre erreur d'exécution: raisons ... », etc .. Gardez à l'esprit que la seule intervention de l'utilisateur pendant tout ce processus serait lorsque l'ordre a été saisi. On pourrait toujours faire valoir que le processus d'exécution est quelque chose qui peut être impliqué d'une histoire d'entrée de commande, ou qu'il est un détail de mise en œuvre, mais il me semble que le processus accomplissement est trop grand pour prendre simplement comme implicite d'une entrée de commande histoire d'utilisateur ou un détail de mise en œuvre. Il se sent comme il devrait y avoir une description de l'accomplissement lui-même comme une histoire aussi bien.

En particulier, les aspects qui me intéressent à écrire une histoire d'utilisateur pour automatisé, programmé ou fonctionnalité réactive est de quel point de vue doit-il être décrit? Étant donné que nous utilisons un format histoire comme « En tant que [rôle], je veux [fonctionnalité] de sorte que [but] », quel est le rôle dans le « En tant que [rôle] » partie de l'histoire, et quelle est la dans le but « de telle sorte que [fin] » partie de l'histoire? La fonctionnalité est généralement assez claire, mais le rôle et le but semble un peu relatif. Par exemple, je pouvais utiliser le système comme point de référence et d'écrire quelque chose comme « Comme l'exécution des commandes système / Agent, je veux être en mesure de tirer un ordre de la file d'attente réalisation, préparer un formulaire de commande de remplissage, et l'envoyer à le centre de traitement des commandes pour que l'ordre peut être accompli ». Ou bien, je pourrais regarder les choses du point de vue commercial et quelque chose écrire comme « En tant que preneur d'ordre, je veux être en mesure de traiter les commandes qui sont entrées par les clients afin que je puisse remplir ma responsabilité de mes clients et donner leur ce qu'ils veulent »(ou quelque chose dans ce sens). Cependant, je pourrais aussi écrire ceci du point de vue du client et dire quelque chose comme « En tant que client, je veux mon entrée de commande à traiter / remplies pour que je puisse recevoir les choses que je veux ».

Je me rends compte qu'il ya peut-être pas une réponse définitive à quel point de vue est celui valide ou un plus utile. Je suis sûr que je vais avoir beaucoup de « ça dépend » des réponses. Quoi qu'il en soit, je serais très intéressé à entendre parler de ce que les autres ont fait dans des situations comme celles-ci, ou si quelqu'un sait de toutes les recommandations, directives ou pratiques spécifiquement pour ces types de scénarios.

Answer 1

Il pourrait aider à se éloigner du modèle traditionnel de l'histoire de l'utilisateur et vers le format axé parties prenantes de l'injection de fonction (BDD dans l'espace d'analyse):

In order to <achieve a goal>
As <the stakeholder>
I want <someone to do something for me>.

Vous pouvez travailler sur la partie prenante qui est en pensant à qui serait prêt à payer pour l'histoire à livrer. Par exemple, des boîtes CAPTCHA - ces choses ennuyeuses les utilisateurs doivent remplir - sont faits pour le bénéfice d'un modérateur, ou pour rendre le site plus attrayant pour gagner des revenus, et non pour le bénéfice de l'utilisateur du tout! En fait, quand vous pensez à la plupart des sites, applications, etc., ils sont presque jamais fait pour un utilisateur. La plupart des sites sont sur les recettes publicitaires. La plupart des applications d'entreprise impliquent un service la saisie des données afin qu'un autre ministère peut l'utiliser, ou que l'argent peut être pris des clients.

Quand vous faites cela, il devient plus évident qu'il pourrait y avoir plus d'un utilisateur impliqué, et un utilisateur peut-être un autre système. Dans votre cas, je suppose que la tête une sorte de vente est la principale partie prenante de cette histoire.

In order to make sales
As the Sales Head
I want customers to be notified of any errors with their order.

In order to make sales
As the Sales Head
I want customers' orders to be fulfilled within 24 hours.

Vous pouvez voir ce que les objectifs deviennent très haut niveau, donc si vous avez un logiciel qui joue dans ces objectifs, vous pouvez les décomposer:

In order to fulfil customer's orders within 24 hours...

Maintenant, chaque histoire remonte à la vision du projet, et vous pouvez voir tous les systèmes en jeu. Ainsi, vos scénarios automatisés pourraient lire:

Given a valid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds successfully
Then the successful fulfillment should be logged
And the customer should be notified by email.

Given an invalid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds with an error
Then the error should be logged
And the customer should be notified of the problem by email.

Par exemple.

Par ailleurs, si vous envisagez de passer à ce format maintenant, sachez que la transparence crée peut causer des ravages absolue avec des gens qui sont, par exemple, le développement parce qu'ils ont le budget, et non pas un bon vision projet. Je pense que cela est une bonne chose. D'autres trouvent la politique moins à l'aise! Bonne chance, tout ce que vous décidez.