Il y a plus dans la connexion à la user story que vous ne le pensez. Derrière une entrée à deux champs peut se cacher un traitement et une complexité importants, il est donc très important de passer du temps à trouver les bons mots. Pour commencer, la formulation doit être claire, sans ambiguïté, cohérente, concise mais aussi complète.
Il n’existe pas de user story parfaite. Il existe toute une gamme de qualités, du mauvais au bon. Et la qualité de la user story peut être évaluée par rapport à au moins 10 critères. J'étudie ici une seule user story relative à un scénario courant – le processus de connexion – et vois comment nous pouvons progresser le long de la ligne de qualité.
L'authentification avec une application logicielle, ou la connexion, se trouve dans presque toutes les applications logicielles. C'est une fonctionnalité tellement courante que la plupart des développeurs essaieront de réutiliser le code pour implémenter cette fonctionnalité. Pourtant, à quelle fréquence pensons-nous à réutiliser cette exigence ? Et quelle est l’ampleur et la complexité de cette fonctionnalité ? Et qu’est-ce que cela signifie réellement lorsque nous nous connectons ? Dans cet article, nous explorerons ces questions et aboutirons à un ensemble de user stories (de bonne qualité) réutilisables.
Être précis
Nous avons analysé plus de 100 000 user stories chez ScopeMaster et estimons, en moyenne chaque mot d'une user story décrit 25 lignes de code, donc une erreur dans un mot d’une user story peut avoir un impact profond sur les efforts et le temps de développement.
Une user story bien formée évitera les discussions inutiles, réduira les retouches et réduira considérablement le temps de développement. passer du temps trouver les bons mots.
Rappelons qu'une user story est écrite pour un certain nombre de lecteurs et dans plusieurs buts. Les deux principaux messages qu’une user story doit véhiculer sont :
- Qui est l’utilisateur et de quelles fonctionnalités a-t-il besoin. (OMS et quoi)
- Pourquoi est-ce important (pourquoi)
Pour la user story de connexion, vous pouvez commencer par ceci :
En tant qu'utilisateur, je souhaite me connecter.
Mais c’est une mauvaise user story et nous allons vous expliquer pourquoi. Cela laisse un certain nombre de questions sans réponse, à savoir que signifie réellement « connexion ». Que signifie réellement « utilisateur » ? Nous pourrions tous penser que nous savons ce que ces termes signifient, mais il vaut la peine d'y regarder de plus près. En fait, beaucoup de choses peuvent devoir se dérouler en coulisses, lors de l'authentification auprès d'une application. Regardons ce qui peut réellement se produire lorsque nous nous connectons à une application Web.
Un scénario de connexion
Voici un scénario typique de connexion Web réussie :
- Entrez un nom d'utilisateur et un mot de passe. Le nom d'utilisateur est le plus souvent l'adresse email de l'utilisateur.
- Cliquez sur Soumettre, le nom d'utilisateur/e-mail est recherché. Si trouvé,
- une version chiffrée du mot de passe est ensuite comparée à la version chiffrée stockée.
- Le profil est mis à jour avec la dernière date et heure de connexion.
- Le système effectue une recherche de groupes (ou de rôles) et d'appartenances à des groupes,
- Enfin, l'utilisateur voit un écran qu'il est autorisé à voir en fonction du résultat des étapes précédentes.
Il s'agit maintenant d'un scénario assez basique, le processus de connexion peut devenir beaucoup plus compliqué, par exemple il peut impliquer des services d'authentification fédérés, la journalisation des événements et bien plus encore, mais restons-en au simple pour l'instant.
La langue anglaise compte plus de 150 000 mots que nous pouvons utiliser, et pratiquement dans n'importe quel ordre, les alternatives sont donc pratiquement infinies. Le but de l'histoire est de communiquer, et il n’y a pas besoin d’être complexe si on peut l’exprimer simplement. Ceci n’est qu’une version de ce à quoi pourrait ressembler la user story :
En tant qu'utilisateur enregistré, je peux m'authentifier grâce à mon profil. Le système devrait également rechercher mon group_membership. Il doit également récupérer le groupe [informations permettant de déterminer les fonctionnalités auxquelles je suis autorisé à accéder].
Voici l’analyse détaillée réalisée par ScopeMaster :
L'utilisation de crochets indique à ScopeMaster d'ignorer certains textes lors de la détermination de la signification fonctionnelle.
Comme vous pouvez le voir, les étapes fonctionnelles sont déterminées et celles-ci sont ensuite mappées aux mouvements de données (l'unité du point de fonction COSMIC).
Cette version de l’histoire est donc bien meilleure car elle est :
- Orienté utilisateur (registered_user suppose que cette personne devrait déjà exister).
- Précieux
- Concis (non détaillé, faisant uniquement référence aux types d'objets, pas à leurs propriétés individuelles)
- Complet (décrit toutes les étapes fonctionnelles clés de cette user story)
- Important, à 9 points de fonction cosmique.
- Non ambigu (mappé avec succès aux étapes fonctionnelles)
- Non conception (il ne précise pas à quoi il doit ressembler ni comment il doit être codé).
Autres considérations. Voies alternatives (tests négatifs)
Les autres voies doivent également être considérées dans le contexte de cette histoire, et devraient probablement être ajoutés séparément comme critères de réussite :
- Mon identifiant est incorrect – afficher un message d'erreur
- mon mot de passe ne correspond pas – afficher un message d'erreur
- mon mot de passe a expiré – afficher un message d'erreur
- mon compte a été désactivé – afficher un message d'erreur
- Je peux me connecter mais je ne suis membre d'un rôle avec aucune autorisation – afficher un message d'erreur
Témoignages d'utilisateurs associés
Maintenant que nous avons couvert l'histoire utilisateur de base de connexion, nous pourrions créer des histoires pour les éléments suivants.
- Mot de passe oublié
- Changer mon mot de passe.
- Stocker un cookie pour mémoriser mon identité
- L'administrateur peut déclencher une réinitialisation de mon mot de passe.
- S'inscrire en tant qu'utilisateur
- L'administrateur peut m'inscrire en mon nom
- Synchroniser ou partager mon identifiant avec un autre système d'authentification (par exemple Facebook)
Ceux-ci feront l’objet de prochains articles, alors restez connectés.
J'espère que vous avez trouvé cet article utile. Maintenant, je vous suggère de jeter un œil à 10 tests pour rédiger de superbes histoires d'utilisateurs
Colin.
Tenez compte de votre public
Considérez le public de votre user story :
Les différents lecteurs d'une user story
Tous ces lecteurs devraient être capables de lire la user story et d'obtenir le même compréhension à partir de cela. Les lecteurs peuvent avoir des objectifs et des perspectives différents, mais l'histoire doit signifier la même chose pour tous les lecteurs. Si différents lecteurs peuvent interpréter l’histoire différemment, envisagez de la reformuler. Dans le développement logiciel Agile, les user stories sont écrites comme un espace réservé à une conversation, mais il est courant que les user stories sont souvent la seule articulation des exigences. Il est donc essentiel qu’ils soient rédigés avec soin.
Laissez l'IA vous aider à perfectionner la user story de connexion
Testez vos user stories au fur et à mesure que vous les rédigez
.
Générer automatiquement des scripts de tests
.
Suivant:
Pour en savoir plus, apprenez-en davantage sur l’amélioration des user stories en général. Dans notre prochain article sur la qualité des user stories.
Découvrez 10 étapes pour améliorer vos user stories, que vous pouvez appliquer sur vos projets logiciels en cours.