• Accueil / Salesforce / Comment rédiger des…
, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Comment rédiger des histoires d’utilisateurs pour Salesforce: ce que nous avons appris en écrivant 100012 minutes de lecture


Une user story est une déclaration structurée « comme un [role], Je veux [action], afin que je puisse [outcome] », décrivant le travail que vous devez effectuer pour répondre à l’exigence globale de l’entreprise. La user story est la pierre angulaire du développement d’applications.

Nous avons écrit plus de 1000 user stories, mises en production 77 fois au cours des 12 derniers mois, et déployé 439 user stories en conséquence (une moyenne de 6,4 versions par mois, 5,7 histoires par version!)

, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

En tant qu’administrateur Salesforce d’un éditeur de logiciels indépendant en croissance rapide, je reçois un assaut constant de demandes de modifications. Beaucoup de ces demandes proviennent de personnes qui comprennent Salesforce, et la demande est souvent accompagnée d’idées très spécifiques sur la façon dont elle doit être mise en œuvre (une histoire familière?)

Heureusement, dans notre organisation, nous avons un processus d’analyse très clair avant d’apporter des changements. Cela garantit que nous livrons ce que l’utilisateur Besoins, pas ce qu’ils pensaient recherché. Bien que cela semble ralentir la livraison, en réalité, cela s’est avéré plus rapide. Nous construisons la bonne chose, du premier coup.

Qu’est-ce qu’une user story?

Une user story est essentiellement une tâche, un travail que vous devez effectuer pour aider à répondre à l’exigence globale de l’entreprise.

Une user story a une structure simple basée sur le format agile standard de «as a [role], Je veux [action], afin que je puisse [outcome]».

Une user story a souvent critères d’acceptation pour guider la phase de test, utilisé pour évaluer si l’exigence a vraiment été satisfaite. Pour prouver que le travail livré répond aux critères d’acceptation, il est courant de créer un lien vers le contenu de support, tel que le diagramme de processus, les notes et les discussions.

Tout cela va de pair pour ensuite évaluer le risque que la user story aura à travers trois dimensions; technique, opérationnel et réglementaire. Par la suite, la user story est affectée à une version (nous en parlerons plus tard).

User story vs exigence – quelles sont les différences?

Une exigence est rédigée du point de vue de l’entreprise détaillant ce que l’entreprise est réellement Besoins – en d’autres termes, le résultat commercial souhaité.

Les exigences sont souvent rédigées à des niveaux de détail très différents. Ils pourraient être stratégique, « Nous devons mettre en œuvre CPQ », ou tactique «Nous devons prendre en charge un nouveau type de client» ou «Je veux cette liste de sélection à sélection multiple».

La condition est de savoir où (avec votre chapeau d’analyste d’affaires), vous voulez aller au problème racine. Au fil du temps, ce que j’ai constaté, c’est que les utilisateurs sont très doués pour communiquer avec leur administrateur avec un «besoin», cependant, la condition est de commencer à obtenir ce dont l’utilisateur a réellement besoin.

Les user stories seront rédigées du point de vue d’un groupe d’utilisateurs pour valider comment l’exigence sera pertinente / adaptée à un groupe d’utilisateurs. En fin de compte, une ou plusieurs user stories répondent aux besoins de l’entreprise.

Pour résumer, à ce stade:

  • L’exigence est le titre du résultat commercial souhaité, ce dont l’entreprise a réellement besoin, plutôt que ce qu’elle veut.
  • Les user stories aident à répondre aux besoins métier globaux.
  • Les user stories sont les tâches requises pour apporter les changements aux systèmes.

Remarque: une user story n’a pas à être liée à un changement de système. Une user story peut détailler une modification apportée à un processus opérationnel ou à un contenu de formation sans impact sur les systèmes.

Rédigez de meilleures user stories – la technique des «5 pourquoi»

Les «5 pourquoi» est une technique que j’ai adoptée lors de la rédaction des exigences et des user stories. C’est aussi simple que de demander «Pourquoi?» Jusqu’à ce que vous arriviez au vrai problème à la racine.

À première vue, cette technique donne l’impression que vous êtes cet enfant ennuyeux à l’arrière de la voiture qui vous demande «sommes-nous encore là?» Encore et encore.

Cependant, vous aurez désormais une exigence métier définie, ce qui signifie que vous comprenez le processus métier «À venir»; cela vous aidera à déterminer quelles user stories sont nécessaires pour fournir le nouveau résultat commercial.

Comment une user story mal écrite revient à vous mordre

De mauvaises user stories sont nées du fait de ne pas vraiment comprendre ce qui est nécessaire. Ils ont tendance à être circulaires dans leur logique, par exemple, «En tant que chef de produit, je veux un objet Persona pour pouvoir enregistrer des personas». En d’autres termes, je veux X pour pouvoir faire X.

Une bonne analyse commerciale rigoureuse élimine ces types de récits d’utilisateurs pour éliminer les retouches du système et réduire l’agilité de l’entreprise.

, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Comment identifier une user story mal écrite

« Pouvez-vous juste? »

Les user stories mal rédigées sont souvent motivées par ces trois mots qui donnent des frissons dans la colonne vertébrale de chaque administrateur Salesforce.

Parfois, les demandes, à première vue, sont à faible risque. Ils semblent être de simples changements qui peuvent être effectués rapidement. éventuellement directement dans votre organisation de production. Alors, vous écrivez une user story avec ça biais et sans analyse appropriée.

Voici un exemple concret et rapide:

« Jack, pouvez-vous simplement ajouter une nouvelle étape au champ de l’étape d’opportunité? »

J’ai oublié mes propres règles, j’ai écrit une user story pour le changement! Je n’ai analysé aucune métadonnée. Je pensais que « c’était un simple changement, non? »

TORT.

Il s’avère que le champ d’étape avait 21 dépendances de flux, 7 Process Builders et 71 rapports.

La user story mal écrite et le fait de sauter les 5 minutes d’analyse, ont abouti à 2 heures de nettoyage.

J’aurais dû regarder quelque chose comme un arbre de dépendances (ci-dessous) car il m’aurait alerté sur les éléments de métadonnées dont je devais tenir compte. Cela m’aurait aussi donné les munitions pour repousser le demandeur, et montrer pourquoi ce n’était pas le simple changement qu’ils pensaient.

, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Ci-dessus: un exemple d’arbre de dépendances pour un champ montrant les dépendances / métadonnées associées, et par conséquent, l’impact indirect que toute modification du champ pourrait avoir.

5 leçons que nous avons apprises en écrivant plus de 1000 user stories

Leçon 1: Connectez les user stories aux métadonnées

Nous savons déjà que faire le analyse d’impact, et connexion des métadonnées aux user stories, vous aide à repérer les conflits de changement potentiels au début du cycle.

La transmission de ces informations aux équipes de développement, de test et de publication signifie qu’elles peuvent planifier et exécuter leur travail plus efficacement. Cependant, cela constitue également la constitution de la documentation pour l’élément de métadonnées qui est si précieux pour l’analyse d’impact et le nettoyage de la dette technique.

Pour illustrer ce point, l’image montre à la fois les métadonnées existantes et les métadonnées proposées ajoutées à une user story. L’ajout d’éléments proposés signifie que nous pouvons ajouter de la documentation aux éléments de métadonnées avant qu’ils n’existent dans Salesforce. Nous savons par expérience que si nous laissons la documentation à «plus tard», cela n’arrivera jamais.

, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Ci-dessus: user stories connectées à la prise en charge des métadonnées Salesforce.

Leçon 2: Reliez les user stories aux informations commerciales

Une user story mal rédigée pourrait avoir un impact énorme sur l’organisation Salesforce (le «risque technique» dont j’ai parlé jusqu’à présent), mais la user story pourrait également avoir un impact sur l’entreprise, à savoir:

  • «Risque opérationnel», quels changements y a-t-il dans les processus métier et la formation / l’habilitation,
  • «Risque réglementaire», quels changements mettent l’entreprise en danger, du point de vue de la conformité?

Les risques sont rapides à analyser si la user story est liée à des informations commerciales. Il peut s’agir de diagrammes de processus, de contenu de formation, de captures d’écran ou de déclarations de conformité.

Là encore, ces informations liées à la user story sont de la «documentation».

Une partie est créée automatiquement, où les informations existantes peuvent simplement être liées. La documentation que vous ajoutez à la user story et aux métadonnées ne vous aidera pas maintenant, mais elle le sera certainement la prochaine fois que vous toucherez les métadonnées, car cela réduira considérablement le temps d’évaluation de l’impact.

, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Ci-dessus: des user stories connectées à des informations de support telles que des notes, des images et des processus.

Leçon 3: Regroupez les user stories en versions

Chaque changement, aussi petit soit-il, nous le livrons via une version. Rappelez-vous que nous avons dit que nous avions livré 77 sorties l’année dernière? Une version est un regroupement de user stories.

Nous examinons les risques techniques, commerciaux et réglementaires des user stories lorsque nous les regroupons en versions. Ensuite, nous attribuons à la version une valeur de risque globale qui aide les équipes de développement et de test à décider comment et combien de temps la version prendra pour être livrée – et la livrer avec le minimum d’effort. Si nous savons qu’une version présente un faible risque, elle pourrait être accélérée avec moins de tests (détails dans «Développer en production pour accélérer Salesforce DevOps: un plaisir coupable moins tout retour»)

Nous pouvons également identifier les conflits entre les versions. Une user story va-t-elle être modifiée dans plusieurs versions et quel en est l’impact? Cela devient encore plus critique si plusieurs équipes travaillent toutes dans l’organisation où elles peuvent ne pas avoir la visibilité des modifications planifiées de l’autre.

Sans cette visibilité, ils ne peuvent découvrir les conflits que lorsqu’ils sont poussés vers la production, ce qui est beaucoup plus coûteux et stressant à résoudre.

Dans ces 77 versions, nous avons eu 0 (zéro) annulation.

, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Ci-dessus: libérez les conflits pour les métadonnées dans les user stories.

Leçon 4: Partager des user stories avec le développement («Shift Left»)

Les équipes de développement utilisent généralement un système de billetterie pour gérer leur travail (Jira, Rally, Accélérateur Agile de Salesforce, etc.). La définition du travail à réaliser sera la user story (bien que cela puisse être appelé autre chose dans le système de billetterie).

Le travail d’analyse pour créer la user story et toute la documentation à l’appui ne doivent pas être perdus lors de sa conversion en ticket. Vous perdrez un contexte commercial précieux qui facilite le développement et le test du ticket et réduit les erreurs causées par toute ambiguïté.

Une user story doit créer automatiquement un ticket une fois que la user story atteint un statut clé; lorsque le ticket est fermé par le développement, le changement de statut doit être reflété dans la user story.

, Comment rédiger des histoires d&rsquo;utilisateurs pour Salesforce: ce que nous avons appris en écrivant 1000<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Ci-dessus: informations de user story affichées dans le panneau de droite à l’intérieur d’un ticket Jira.

Leçon 5: Construire de la documentation en tant que sous-produit de l’analyse

Le partage, c’est bien. La recomposition est mauvaise. Ne pas savoir est pire.

L’analyse, l’évaluation des risques et la documentation sont précieuses tout au long du cycle de vie de la mise en œuvre.

Personne n’a le temps de documenter correctement, même si les avantages sont évidents. Le problème est que ces avantages ne se font sentir que plus tard.

Donc, cette approche de user story que j’ai décrite construit la documentation comme un sous-produit de l’analyse, rapidement.

L’établissement de liens entre les user stories, les diagrammes de processus métier, les notes et les métadonnées accélérera l’analyse et le développement futurs – l’effet volant. Vous disposez déjà de l’historique complet des modifications apportées aux métadonnées et des raisons pour lesquelles elles ont été apportées, ce qui accélère l’analyse, le développement et le risque.

Prochaines étapes

Cette approche semble incroyable, mais elle doit être difficile à mettre en œuvre? Pas vraiment. Vous n’avez pas besoin de réinventer complètement vos processus de développement. Vous pouvez l’essayer pour le prochain travail que vous livrez en suivant ces étapes:

  1. Centralisez la capture des user stories.
  2. Engagez-vous à analyser chaque user story avant qu’elle ne soit transmise à l’équipe de développement.
  3. Liez les user stories aux métadonnées et à toute autre information complémentaire.
  4. Fournissez l’accès à la user story et aux informations liées à l’équipe de développement.



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer