Les «user stories techniques» sont-elles autorisées dans Scrum?

Les user stories techniques sont-elles autorisées dans Scrum? Si oui, quel est le modèle standard pour écrire des user stories techniques dans Scrum? Est-ce la même chose As a <user> I want to do <task> so that I can <goal>??

J'ai lu dans certains blogs qu'en tant que développeur, ce n'est pas une histoire d'utilisateur , mais j'ai également lu que Scrum ne les rend pas obligatoires. Il y a peu de blogs où ils ont partagé des histoires d'utilisateurs avec le système en tant qu'utilisateur , c'est comme ça as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Alors, lequel est la norme?

Par exemple, il existe des user stories comme:

En tant que critique, je veux télécharger des photos de n'importe quel hôtel / nourriture afin que les autres utilisateurs puissent les voir et les aimer

En tant qu'utilisateur, je souhaite ajouter des commentaires photo afin de mieux expliquer mon point de vue

Maintenant, pour ces deux histoires d'utilisateurs, il y a un gros élément technique - Enregistrer et récupérer l'image

Puis-je ajouter une histoire technique intitulée "Mécanisme de stockage et de récupération d'images", avec la description suivante?

En tant que développeur, je souhaite développer un mécanisme pour stocker et récupérer des images afin que les utilisateurs puissent ajouter / visualiser des images partout où cela est nécessaire

Les histoires techniques sont autorisées, mais je vous conseille d'essayer de les éviter autant que possible.

Par exemple, votre histoire pour sauvegarder et récupérer des images peut facilement être écrite en deux histoires utilisateur régulières

1. En tant que critique, je souhaite que mes photos téléchargées soient stockées de manière permanente, afin que les autres utilisateurs puissent les consulter à tout moment.
   (Notez que cela suppose que dans votre histoire de téléchargement d'origine, l'image ne sera pas stockée de manière persistante après le téléchargement. Bien que cela puisse sembler étrange, c'est un moyen valide de diviser les histoires pour les rendre gérables.)
2. En tant qu'utilisateur, je souhaite afficher les images téléchargées à un moment qui me convient.
   (Cela implique que les images stockées peuvent être récupérées ultérieurement.)

Les histoires techniques doivent être réservées aux travaux importants pour l'organisation, mais non directement visibles en tant que caractéristique / fonctionnalité pour les utilisateurs. Par exemple, l'ajout de l'équilibrage de charge pour gérer un plus grand nombre de demandes.

La question, compte tenu de votre exemple particulier, serait la suivante: pourquoi un développeur souhaite-t-il développer un mécanisme pour stocker et récupérer des images afin que les utilisateurs puissent ajouter / afficher des images à tout moment, à moins qu’un utilisateur ne veuille ajouter ou afficher des images?

Autrement dit, bien que votre question soit bonne, l'exemple ne l'est pas. Il s'agit d'une fonctionnalité utilisateur et doit avoir une histoire utilisateur. Et si l'utilisateur n'a pas vraiment besoin de cette fonctionnalité, le développeur ne devrait pas vouloir le faire.

Une histoire technique, c'est plus "En tant que développeur, je veux réduire la duplication dans les modules d'archivage de données, afin de ne pas avoir à faire chaque changement en 6 endroits."

La question de savoir si ceux-ci doivent être inclus dans le sprint est difficile, et cela dépend quelque peu de qui vous considérez comme votre client. Est-ce l'utilisateur final, ou l'entreprise qui vous emploie, ou l'entreprise qui emploie l'entreprise qui vous emploie?

Beaucoup de conseils d'opinion de l'industrie sont effectués par des personnes qui travaillent pour des sociétés de conseil. De ce point de vue, je peux voir l'argument selon lequel les histoires de développeurs sont mauvaises. Ils devraient simplement faire partie de ce que vous faites, au quotidien, invisibles pour l'entreprise qui les paie. Ces sociétés savent instinctivement que l'exécution des factures trop élevées garantit que votre travail se tarit, donc chaque développeur travaille sur le principe de ne faire que du développement technique qui améliore votre temps de développement ou améliore votre capacité à publier des logiciels sans bogues.

Mon expérience consiste davantage à travailler sur des équipes internes, à fournir des logiciels directement à l'entreprise qui paie mon salaire. Dans beaucoup de ces entreprises, il existe une barrière de confiance entre l'entreprise et l'aile technique de l'entreprise. Dans chacun d'eux, il y a une mentalité différente, où la baisse des coûts est tout autant que l'augmentation des revenus.

Dans ces environnements, il peut être utile de définir des histoires de développeurs importantes. Il augmente la visibilité, engendre la confiance et encourage les développeurs et la direction à réfléchir à la valeur de ces tâches pour l'entreprise et à établir des priorités en conséquence.

En fin de compte, je vous suggère de l'essayer. Et, s'il n'offre pas de valeur, arrêtez de le faire.

Mais mon instinct dit que si vous considériez la valeur de ce développement pour l'entreprise, vous n'auriez même pas essayé d'en faire une histoire de développeur. C'est bon pour l'utilisateur final ou non. Si ce n'est pas le cas, l'entreprise n'a aucune valeur.

C'est une bonne question. Je n'ai pas de réponse officielle mais là où je travaille, nous ajoutons des histoires d'utilisateurs techniques et les appelons dette technique. S'ils n'étaient pas autorisés, je trouverais un autre moyen de les ajouter dans le seul but de faire enregistrer et communiquer mon travail à l'entreprise. De même, avoir cette documentation nous rappelle ce qui est nécessaire pour les futurs projets.

Par exemple, la déconnexion dans une nouvelle application, si nous ne sommes pas autorisés à ajouter des histoires techniques, est que je vais fredonner pendant une semaine après le début d'un sprint créant des modèles de base de données et attendant que mon modélisateur de données approuve eux, itérer avec le modeleur et une fois terminé envoyer les scripts à la dba et attendre qu'ils créent les objets db. En attendant, je vais créer un nouveau projet de code, des fonctionnalités ORM de base et ma disposition de contrôle de source et quand tout sera dit et fait, j'aurai le temps de créer une page de destination vierge et de déployer.

Au jour le jour, si cela ne se passe pas, si je n'enregistre pas les informations, l'entreprise grimpe que notre équipe ne travaille pas sur le projet alors qu'en fait nous le sommes. Le fait d'avoir ces éléments dans les histoires signifie que nous pouvons vérifier notre travail, avoir un travail documenté et communiquer à l'entreprise que nous progressons.

S'il y a une meilleure meilleure pratique pour ce faire, je suis à l'écoute.

Mon sentiment personnel est que les équipes ne devraient pas être trop accrochées à ce que la mêlée permet et être plus inquiètes de ce qui fonctionne pour l'équipe. Une partie de la raison pour laquelle Scrum a acquis une mauvaise réputation est que les praticiens peuvent se concentrer sur les processus, ce qui est contraire aux idées derrière la gestion de projet agile.

Je vais sortir de ma boîte à savon maintenant, mais si vous vous demandez si ce qui suit est vraiment «scrum», veuillez (relire) ce qui précède.

Il est important de séparer les «fonctionnalités» définies par les user stories et les «livrables» que l'équipe technique doit fournir pour prendre en charge ces fonctionnalités. Dans ce cas, le besoin d'enregistrer et de récupérer des images est un livrable technique que vous (en tant qu'équipe technique) devez mettre en œuvre. Presque chaque histoire aura besoin de livrables techniques.

La raison pour laquelle cela est important est qu'un livrable technique (en soi) n'est pas quelque chose qui produit de la valeur du point de vue de l'utilisateur. Si vous commencez à suivre les livrables techniques en tant qu'histoires d'utilisateurs, vous pouvez facilement tomber dans le piège de traiter la production technique comme produisant de la valeur commerciale. Brouiller les eaux de cette façon confondra le travail qui soutient les objectifs commerciaux (c'est-à-dire les choses qui coûtent de l'argent) avec les objectifs commerciaux réels (c'est-à-dire les choses qui font de l'argent).

Toutes les réponses ci-dessus ne font pas référence au document source faisant autorité pour le cadre Scrum: le guide Scrum .

Le Product Backlog répertorie toutes les fonctionnalités, fonctions, exigences, améliorations et correctifs qui constituent les modifications à apporter au produit dans les versions futures.

L'accent devrait être mis sur la production de valeur. Parfois, cette valeur provient du travail technique, comme la mise à niveau des infrastructures. N'excluez pas ces articles!

Le terme user story n'apparaît jamais dans le Scrum Guide, car

c'est un cadre dans lequel vous pouvez utiliser divers processus et techniques.

L'utilisation d'une user story n'est qu'une technique possible pour enregistrer les PBI. Bien qu'il soit courant de voir le format «En tant que, je veux, donc ça», il peut être contraire à son intention initiale . Ce format problématique a également été abordé lors d' Agile 2017 .

La compréhension et l'utilisation du découpage vertical seront utiles pour réduire la taille des éléments de backlog de produit (PBI). Pensez à trancher que seul sauvegarder et de récupérer un objet en sauvegarde et récupérer élément s .