Dans cet article, nous explorons les résultats de l'utilisation de l'outil d'analyse des user stories, ScopeMaster sur un exemple d'ensemble de user stories (accéder aux originaux ici). Les histoires que nous avons utilisées sont publiées par Mike Cohn sur le site Mountain Goat, elles décrivent les fonctions d'un site Web interactif à construire.
À propos des exemples de témoignages d'utilisateurs
Nous avons choisi ces exemples de user stories car ils sont disponibles gratuitement et sont publiés par un auteur bien connu de livres sur le thème de l'écriture de user stories de logiciels. Ce sont des exemples que tout le monde peut télécharger. (Le PDF contient en fait des exemples de trois projets différents). Pour cet exercice, nous venons de regarder les histoires des Site Web de ScrumAlliance . Téléchargez le CSV avec les exemples de user stories
Le but de l'exercice est d'explorer ce que ScopeMaster peut révéler sur un ensemble typique de user stories.
Préparation
Étape 1. Convertissez le PDF en CSV
Le document PDF contient une liste à puces de user stories. Pour préparer la liste à l'importation, nous avons d'abord copié chaque user story sur une ligne d'une feuille de calcul. La feuille de calcul a ensuite été enregistrée au format CSV, prête à être importée dans ScopeMaster. C’était la partie la plus longue de tout l’exercice ! Heureusement, la plupart des user stories de nos jours sont contenues dans une structure qui peut facilement être formatée sous forme de fichier CSV et cette étape serait donc généralement évitée.
Au total, il y a 98 user stories. Nous en avons profité pour générer un identifiant de référence unique pour chacun avant de les importer. Vous pouvez réutiliser le csv que nous avons créé si vous le souhaitez, ici : Exemples d'histoires d'utilisateurs originales de Mountain Goat – ScrumAlliance CSV
Étape 2. Importer dans ScopeMaster
Nous avons ensuite créé un nouveau projet dans ScopeMaster et sélectionné l'option « importer CSV »
Nous recommandons de séparer la partie fonctionnelle de la user story du texte des avantages, nous avons donc demandé à l'import de ScopeMaster de le faire pour nous.
Étape 3. Analysez tout
Nous avons ensuite lancé l'analyse automatisée. Simplement en appuyant sur le bouton vert.
C'est là que la magie opère. Le moteur d'analyse de ScopeMaster travaille tour à tour sur chaque user story, elle est interprétée, analysée, testée, dimensionnée et croisée.
En seulement moins de 3 minutes, ScopeMaster a analysé chaque mot des 98 user stories et effectué près de 112 000 tests.
ScopeMaster a analysé l'intégralité du backlog de 98 user stories en moins de 3 minutes
Résultats
Voyons maintenant ce que ScopeMaster nous dit à propos de ces user stories.
Chaque User Story : interprétée, testée et dimensionnée (si possible)
- ScopeMaster a examiné chaque mot de chaque user story pour déterminer s'il peut établir une intention fonctionnelle claire. Est-ce clair?
- Si tel est le cas, ScopeMaster a déterminé qui est le utilisateur et quoi ils veulent/doivent réaliser. c'est à dire. Est-il orienté utilisateur et fonctionnel ?
- À partir de l'intention fonctionnelle déterminée ci-dessus, ScopeMaster a estimé la taille fonctionnelle des points de fonction COSMIC des normes ISO. Quelle est la taille?
ScopeMaster détecte les étapes fonctionnelles décrites dans chaque user story
Retours de qualité détaillés sur de nombreux aspects de la user story
ScopeMaster génère automatiquement (pseudo) du code de test pour vérifier chaque user story
Aperçu des exemples de témoignages d'utilisateurs
Le diagramme de modèle de cas d'utilisation a été généré à partir de l'interprétation de l’ensemble des user stories. Ce diagramme révèle instantanément de nombreux aspects de la qualité de l'ensemble des user stories qui ne sont tout simplement pas visibles dans les référentiels d'exigences tels que Trello, Jira, Azure DevOPs. Ce diagramme révèle la relation logique entre les user stories. Ce diagramme vous aide à déterminer si vous avez les bonnes exigences ?
L'interprétation fonctionnelle de l'ensemble des user stories est très perspicace et maintenue de manière dynamique.
Des user stories au modèle de données
À partir des intentions fonctionnelles déterminées par ScopeMaster, un diagramme de classes suggéré de toutes les classes probables et leurs méthodes sont déterminés à partir du texte des user stories. Cela peut aider les développeurs à comprendre quelles données ils doivent prendre en compte et comment elles peuvent être stockées et traitées. Ce n'est pas un diagramme de classes définitif mais un point de départ très utile. Ce diagramme aide à déterminer comment organiser et structurer les données pour répondre aux exigences ?
Classes et méthodes suggérées automatiquement à partir de l'ensemble des user stories
Tests générés directement à partir des user stories
Exemple de pseudo-code pour les scénarios de test, généré à partir du texte de la user story
Déterminer la taille du backlog
Pour toutes les équipes, tous les projets, les user stories varient en taille et en efforts pour les livrer. Cette variabilité peut être très élevée. ScopeMaster a été conçu dès le départ pour automatiser le dimensionnement fonctionnel des exigences logicielles écrites. Cela signifie qu'il a été conçu pour éliminer ou réduire le travail administratif lié aux exigences de lecture afin de déterminer une estimation formelle de la taille fonctionnelle du logiciel qu'elles décrivent. La taille fonctionnelle est un indicateur d’ampleur indépendant de la technologie et orienté vers l’utilisateur. ScopeMaster estime la taille fonctionnelle dans les deux principales normes ISO pour les logiciels de dimensionnement, à savoir Points de fonction cosmique et IFPUG Points de fonction. Nous recommandons le premier car il est plus adapté aux architectures logicielles modernes et gère mieux les exigences incomplètes. ScopeMaster estime le fonctionnel taille de toutes les histoires de l'ensemble de votre backlog en quelques minutes, évitant ainsi à l'équipe de perdre du temps dans des discussions sans valeur sur les story points ou la taille des t-shirts.
ScopeMaster dimensionne automatiquement les user stories en points de fonction COSMIC standardisés
Analyse de la qualité
En un peu moins de 3 minutes, ScopeMaster a identifié des centaines de problèmes avec les user stories.
Rapport de qualité de ScopeMaster sur les exemples d'histoires d'utilisateurs de Mike Cohn du site Web ScrumAlliance
Ambiguïtés
51 des 98 user stories avaient une signification fonctionnelle ambiguë, qui, si elle n'était pas résolue, entraînerait des bugs. 51 défauts identifiés.
Témoignages d'utilisateurs de sécurité de base manquants
Il n'y avait aucune mention de connexion, d'authentification, d'autorisation, d'autorisation ou de déconnexion dans les user stories. Il s’agit évidemment d’une omission importante. Nous nous attendons généralement à ce que cela nécessite au moins plusieurs user stories. (même si l’histoire du « mot de passe oublié » est là). 5 défauts identifiés :
• Se connecter
• Email validé
• Changer le mot de passe
• Se déconnecter
• Et puis, pour chaque user story sensible au rôle, il faudra effectuer une vérification du rôle et/ou des autorisations.
L’ensemble original de user stories ne décrivait pas complètement les fonctionnalités requises.
Termes incohérents pour les utilisateurs/personas
ScopeMaster a identifié 26 types d'utilisateurs potentiels. Il est probable qu’il n’y ait en réalité que 10 personnages distincts. 16 défauts identifiés.
Termes incohérents pour les utilisateurs/personas
De même, ScopeMaster a identifié 41 types d'objets potentiels, alors qu'il n'y en a probablement qu'environ 25 à 30. 16 défauts identifiés.
exhaustivité de la maintenance des données (analyse CRUD)
Pour chaque type d'objet valide, il doit y avoir au moins 1 fonction pour chaque événement CRUD. Après avoir éliminé les types d’objets redondants, cela conduit à environ 80 user stories fonctionnelles manquantes. 80 défauts identifiés.
Capacités aberrantes
Le diagramme du modèle de cas d'utilisation a révélé d'autres exigences manquantes basées sur les rôles/personnes. Nous estimons au moins 1 ou 2 par type d'utilisateur. 10 défauts identifiés
Déclarations de valeur
ScopeMaster a identifié que seulement 58 des 98 ont utilisé l'expression « de sorte que », mais tous sauf 3 incluent le terme « donc ». 3- 40 défauts identifiés
NFRS
De plus, la détection des exigences non fonctionnelles de ScopeMaster a identifié qu'il existe plusieurs catégories pertinentes de NFR qui n'étaient pas mentionnées dans cet ensemble de user stories : accessibilité, auditabilité, observabilité. 3 Défauts identifiés
Résumé des résultats de qualité
En seulement 3 minutes, ScopeMaster a identifié 211 problèmes probables (97 + 114) avec ces user stories. Il a également déduit via l'analyse CRUD que seule la moitié des user stories probables nécessaires sont réellement répertoriées. (Cet exemple d'ensemble de user stories peut avoir été délibérément coupé avant la publication).
De plus, ScopeMaster a généré plus de 140 scénarios de tests essentiels, ce qui contribuera à accélérer l'initiative de tests fonctionnels, une fois la fonctionnalité créée.
Le but de cet exercice n'était pas de critiquer les exemples de user stories mais de souligner l'intérêt de l'utilisation de ScopeMaster sur n'importe quel ensemble de user stories.
Nous apprécions tous les commentaires des gens de Mountain Goat.
Conclusion
À partir de cet exercice, nous pouvons voir que ScopeMaster effectue un travail précieux sur cet exemple d'ensemble de user stories. Il a:
- Révélation de plus de 200 problèmes qui peuvent être facilement résolus avant de devenir par inadvertance la cause d'une refonte.
- Portée manquante révélée
- Révélation d'une conception de données potentielle
- Produit des scénarios de tests de base utilisables pour chaque user story, y compris des tests positifs et négatifs.
- Estimation de la taille fonctionnelle de chaque étage (y compris ceux manquants) selon les normes ISO de taille fonctionnelle.
Tout cela représente une quantité substantielle de travail utile, perspicace et axé sur la gauche, qui contribue à apporter une certitude quant à la portée et à réduire les risques de tout projet logiciel.
Ce serait formidable d'entendre Mike Cohn ou toute personne ayant travaillé sur le site Web ScrumAlliance parler de son expérience de l'utilisation de ces user stories et de ses réflexions sur l'analyse de ScopeMaster. Jusqu'à présent, aucun membre de son équipe n'a été disponible pour commenter.
