En fouillant sur le Web, les Agile Sages considèrent que les cas d’utilisation et les user stories sont deux choses différentes :

• Mike Cohn :  les user stories ne sont pas des cas d’utilisation
• Alistair Cockburn :  Une user story est à un cas d’utilisation ce qu’une gazelle est à un belvédère
• Extreme Programming.org :  les user stories ont le même objectif que les cas d’utilisation, mais ne sont pas identiques.

L’approche basée sur les cas d’utilisation était l’une des techniques les plus populaires pour la capture des exigences et certaines personnes considèrent maintenant qu’il s’agit d’une sorte de technique obsolète et à l’ancienne associée à de nombreux problèmes qui rendent votre équipe NON “Agile” en raison des problèmes de cas d’utilisation. :

• Exigence initiale – essayer de définir les détails de tous les aspects de l’upfront entraînera une perte de temps et d’efforts, car une grande partie du travail devra être refaite.
• Décomposition fonctionnelle : la nature fonctionnelle des cas d’utilisation conduit naturellement à la décomposition fonctionnelle d’un système en termes de cas d’utilisation concrets et abstraits qui sont liés par des extensions et incluent des associations de cas d’utilisation.

Si vous effectuez une recherche sur le Web avec les mots-clés “cas d’utilisation vs histoire d’utilisateur”, vous trouverez une longue liste d’articles suggérant les inconvénients, les problèmes ou les pièges de l’approche des cas d’utilisation, alors qu’il existe une liste encore plus longue des avantages liés à l’histoire d’utilisateur. . Intéressant, les choses changent si rapidement dans l’industrie informatique, et encore plus rapidement pour les personnes qui passent des choses « à la mode » du passé aux « nouvelles choses à la mode » d’aujourd’hui.

Fait intéressant, certaines personnes aiment percevoir les choses dans un schéma binaire et rechercher des choses à la mode en s’y associant symboliquement plutôt qu’en les pratiquant véritablement. Certaines personnes ne veulent même pas faire savoir aux autres qu’elles utilisent encore des cas d’utilisation, ou elles peuvent être considérées comme obsolètes et de style ancien.

Maintenant, certaines personnes mettent un signe égal lié à la user story et au cas utilisateur :

• Agile = user story ou Agile = user story + Scrum
• User story = juste assez et juste à temps
• User story = répondant aux attentes des utilisateurs & satisfaisant
• Cas d’utilisation = Capture d’exigence détaillée en amont
• Cas d’utilisation = <<include>> + <<extends>> = décomposition fonctionnelle
• Le cas d’utilisation est le style “entrée utilisateur” -> “réponse système” uniquement
• Cas d’utilisation = style ancien et obsolète

En tant que fournisseur d’outils, nous sommes assez neutres dans les méthodes, les outils et les techniques. Personnellement, je tiens à souligner clairement que je suis un grand fan du développement Agile, de la user story et du processus Scrum. En particulier, les principes sous-jacents et les meilleures pratiques liés à des concepts tels que :

• Découverte des exigences plutôt que livraison des exigences
• Selon le principe ci-dessus, cela donne deux propriétés importantes dans le processus de développement Agile
  • Juste à temps
  • Juste assez

(J’écrirai plus d’articles liés aux principes ci-dessus avec mes propres opinions, qui sont étroitement liées à mon domaine de recherche de doctorat en 1992-1995 – métamodèle et transformations de schéma)

Revenons maintenant aux sujets “cas d’utilisation vs user story”. Eh bien, les poids lourds Agile Sages ont déjà voté pour cela, suis-je si têtu à essayer de renverser leurs “votes en arguant qu’ils sont similaires ou même identiques ?

Laissez-moi vous montrer un exemple pour illustrer si la user story est « si différente » du cas utilisateur :

Exemple

Les bonnes user stories sont bien plus que de simples déclarations. Une user story standard se compose de trois parties, communément appelées les trois C.

Le premier “C” de chaque user story doit suivre le format standardisé de :

En tant que [rôle], je veux [faire quelque chose], de sorte que [bénéfices]

qui est le contenu minimal d’une user story à mettre dans la carte.

Les conversations sont le contenu du deuxième “C” d’une user story qui représente la discussion entre les utilisateurs finaux, le propriétaire du projet et l’équipe de développement. Dans ces conversions, il enregistre la discussion verbale, ou de nombreuses autres informations utiles telles que les e-mails, les wireframes ou tout autre contenu lié au projet.

Le « C » final d’une user story est la confirmation, qui est le critère d’acceptation utilisé pour confirmer que la user story est mise en œuvre, corrigée et livrée avec succès.

Permettez-moi d’élaborer un peu plus sur la manière de développer la partie confirmation d’une user story. Ici, nous utilisons le modèle le plus connu appelé Gherkin qui adopte la formule Given-When-Then pour guider l’écriture des tests d’acceptation pour une User Story :

• (Étant donné .. et) un certain contexte
• (Quand.. et) une action est effectuée
• (Puis.. et) Effectuez quelques actions

Des outils tels que les cadres de test Cucumber et Jbehave encouragent l’utilisation du modèle Given/When/Then pour effectuer des tests automatisés, bien qu’il puisse également être utilisé uniquement comme heuristique, qu’il s’agisse d’un outil à utiliser ou non.

Rassemblons toutes les informations pour la user story « s’inscrire au cours » et mettons-la au format 3C :

J’ai adopté le format couramment utilisé des 3 C pour représenter la user story « enregistrer le cours ». De même, j’ai également adopté le format le plus largement utilisé pour décrire pour le même cas d’utilisation « cours de registre » élaboré par une description de cas d’utilisation. J’ai numéroté les étapes de la section de confirmation (le dernier C) de la user story qui est associée au numéro d’étape que j’ai mis dans la description du cas d’utilisation. Ce sont les mêmes “neuf étapes” du scénario à mettre dans chacune des approches avec un ordre différent. Je crois que les deux modèles de représentation sont acceptables pour leurs sages et adeptes correspondants. Ensuite, la question à nouveau, est-ce que la user story est très similaire au cas d’utilisateur et pourtant elles sont différentes ou l’ordre des étapes provoque toutes sortes de critiques pour l’approche des cas d’utilisation ?

Sémantiquement équivalent avec un sens différent ?

Examinons s’il existe un cas similaire dans le domaine de la modélisation, afin de comparer avec la situation ici, ou cela pourrait nous aider à émettre notre propre vote sur “l’histoire de l’utilisateur par rapport aux cas d’utilisation”, mais pas non plus suivre aveuglément la foule ou répéter ce que le les sages ont dit comme un discours de perroquet.

Exemple : sémantiquement équivalent

En UML, nous pouvons décrire un scénario de cas d’utilisation avec un diagramme de séquence, mais nous n’utilisons généralement pas de diagramme de collaboration dans le même but ; même à travers les deux diagrammes sont sémantiquement équivalents. En d’autres termes, le diagramme de séquence et le diagramme de collaboration ont le même nombre d’objets participant à un scénario avec le même nombre de messages passant autour du même ensemble d’objets pour effectuer une tâche d’un scénario. Cependant, le premier est focalisé sur le temps et le second est focalisé sur l’espace. Le diagramme de séquence est plus intuitif lorsqu’il est utilisé avec la modélisation de scénarios, tandis que le diagramme de collaboration est approprié pour modéliser les relations structurelles entre les objets. c’est-à-dire que vous souhaitez représenter structurellement le scénario de l’objet participé dans le cadre MVC (couches modèle/vue et contrôle).

Personnellement, je ne pense pas que l’utilisation de la user story rendra mon équipe agile, et les cas d’utilisation amèneront mon équipe à être “upfront”. Le plus important est de savoir comment nous appliquons et utilisons ces outils avec quel type d’état d’esprit et les meilleures pratiques derrière. Je ne m’inquiète pas trop du fait que les gens me considèrent comme “à l’ancienne” ou dépassé alors que j’agis réellement avec agilité.

Je me souviens encore à l’époque de l’analyse structurée et de la conception, peut-être pouvons-nous utiliser Abstract Data Type dans ADA pour appliquer les principes d’analyse et de conception orientés objet sans avoir le support de la POO en 198x, n’est-ce pas? Malheureusement, vous ne rencontrerez peut-être même pas du tout les concepts du type de données abstrait ! Oh! Mon Dieu, je divulgue accidentellement – je suis vieux? Ou, je devrais penser positif – expérimenté ?

Qu’est-ce que tu penses? Quel est votre vote là-dessus ? Faites-moi savoir ou corrigez-moi si je me trompe.