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.
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
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