2010-10-13 15 views
0

Je me demandais ce que l'on pense de l'utilisation des User Stories pour décrire les fonctionnalités automatisées, programmées ou réactives. Par exemple, que faites-vous quand vous avez quelque chose comme un processus d'exécution de commande qui consiste à tirer une commande d'une file d'attente, préparer un formulaire de commande, envoyer le formulaire à un centre de traitement des commandes, puis attendre une confirmation? le centre de traitement, tel que «commande remplie», ou «erreur d'exécution de commande: raisons ...», etc. Gardez à l'esprit que la seule intervention de l'utilisateur pendant tout ce processus serait au moment de la saisie de la commande. On pourrait toujours prétendre que le processus d'exécution est quelque chose qui peut être implicite à partir d'un récit d'entrée de commande, ou qu'il s'agit d'un détail d'implémentation, mais il me semble que le processus d'exécution est trop important. user story ou en détail de mise en œuvre. On dirait qu'il devrait y avoir une description de l'accomplissement lui-même en tant qu'histoire.Utilisation des user stories pour des fonctionnalités automatisées, programmées ou réactives

En particulier, les aspects qui m'intéressent à propos de l'écriture d'un user story pour une fonctionnalité automatisée, programmée ou réactive sont du point de vue de qui devrait-il être décrit? Étant donné que nous utilisons un format d'histoire comme "En tant que [rôle], je veux [fonctionnalité] pour que [but]", quel est le rôle dans la partie "En tant que [rôle]" de l'histoire, et quelle est la but dans la partie "de sorte que [but]" de l'histoire? La fonctionnalité est généralement assez claire mais le rôle et le but semblent un peu relatifs. Par exemple, je pourrais utiliser le système comme point de référence et écrire quelque chose comme "En tant que système/agent de traitement des commandes, je veux être en mesure de retirer une commande de la file d'attente, de préparer un bon de commande le centre de traitement des commandes afin que la commande puisse être exécutée ". Ou encore, je pourrais regarder les choses du point de vue de l'entreprise et écrire quelque chose comme "En tant que preneur de commandes, je veux être en mesure de traiter les commandes qui sont saisies par les clients afin que je puisse assumer mes responsabilités envers mes clients. eux 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 que ma commande soit traitée/satisfaite pour que je puisse recevoir les choses que je veux".

Je me rends compte qu'il ne peut pas y avoir une réponse ultime quant à la perspective qui est la plus valable. Je suis sûr que j'obtiendrai beaucoup de réponses «ça dépend». Néanmoins, je serais très intéressé d'entendre ce que les autres ont fait dans des situations comme celles-ci, ou si quelqu'un connaît des recommandations, des directives ou des pratiques spécifiques à ce genre de scénarios.

Répondre

1

Il pourrait aider à se éloigner du modèle traditionnel de l'histoire de l'utilisateur et vers le format axée sur les intervenants-de Injection Feature (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 déterminer qui la partie prenante est par penser à qui serait prêt à payer pour que l'histoire soit livrée. Par exemple, les boîtes CAPTCHA - ces choses ennuyeuses que les utilisateurs doivent remplir - sont faites pour le bénéfice d'un modérateur, ou pour rendre le site plus attrayant pour gagner de l'argent, et non pour le bénéfice de l'utilisateur! En fait, lorsque vous pensez à la plupart des sites, applications, etc., ils ne sont presque jamais réalisés pour un utilisateur. La plupart des sites Web traitent des revenus publicitaires. La plupart des applications d'entreprise impliquent qu'un département entre des données afin qu'un autre département puisse les utiliser, ou que l'argent puisse être retiré des clients. Lorsque vous faites cela, il devient plus évident qu'il peut y avoir plus d'un utilisateur impliqué, et un utilisateur peut être un autre système. Dans votre cas, j'imagine qu'une sorte de responsable des ventes est le principal acteur 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 briser:

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

Maintenant, chaque histoire peut être retracée à la vision du projet, et vous pouvez voir tous les systèmes en jeu. Ainsi, vos scénarios automatisés peuvent être:

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. En passant, si vous envisagez de passer à ce format maintenant, sachez que la transparence qu'il crée peut causer des ravages absolus avec des gens qui, disons, se développent parce qu'ils ont le budget, et non un bonne vision du projet. Je pense que c'est une bonne chose. D'autres trouvent la politique moins confortable! Bonne chance, quoi que vous décidiez.

+0

Cela semble intéressant et merci pour la réponse bien pensée avec des exemples. Je n'avais jamais entendu parler de Feature Injection auparavant, mais je vais certainement m'y pencher. Pourriez-vous recommander du matériel que je pourrais consulter pour référence? – lambdakris

+0

Bien sûr. Voici mon article sur ce blog: http://lizkeogh.com/2010/02/02/theyre-not-user-stories/ et un article que j'ai écrit: http://www.infoq.com/articles/pulling-power . Chris Matts l'a créé, alors voici sa bande dessinée: http://www.lulu.com/product/file-download/real-options-at-agile-2009/5949486 - Real Options est également assez hallucinant et Feature Injection est basé sur ses principes. – Lunivore