L’histoire utilisateur est-elle compatible avec le cas d’utilisation ?

En faisant des recherches sur le web, les sages de l’agilité considèrent que les cas d’utilisation et les histoires utilisateur sont deux choses différentes :

• Mike Cohn :Les histoires utilisateur ne sont pas des cas d’utilisation
• Alistair Cockburn :Une histoire utilisateur est à un cas d’utilisation ce qu’une gazelle est à un kiosque
• Extreme Programming.org :Les histoires utilisateur servent au même objectif que les cas d’utilisation, mais elles ne sont pas identiques.

L’approche centrée sur les cas d’utilisation était l’une des techniques les plus populaires pour la capture des exigences, et certaines personnes considèrent aujourd’hui qu’il s’agit d’une technique obsolète, ancienne, associée à de nombreux problèmes qui empêchent votre équipe d’être « agile » en raison des défauts des cas d’utilisation :

• Exigences préalables – essayer de définir en détail tous les aspects des exigences préalables entraîne de nombreux efforts et temps perdus, 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 cas d’utilisation concrets et abstraits, liés par des associations d’extension et d’inclusion.

Si vous faites une recherche sur le web avec les mots-clés « cas d’utilisation vs histoire utilisateur », vous trouverez une longue liste d’articles qui évoquent les inconvénients, problèmes ou pièges de l’approche des cas d’utilisation, tandis qu’il existe une liste encore plus longue des avantages liés aux histoires utilisateur. Intéressant, les choses évoluent très vite dans l’industrie informatique, et encore plus vite pour les personnes passant des choses autrefois « tendances » aux nouvelles « tendances » d’aujourd’hui.

Curieusement, certaines personnes aiment percevoir les choses selon un schéma binaire et poursuivre les choses tendances en s’y associant symboliquement plutôt que de les pratiquer réellement. Certaines personnes n’ont même pas envie que les autres sachent qu’elles utilisent encore les cas d’utilisation, de peur d’être considérées comme obsolètes ou dépassées.

Maintenant, certaines personnes établissent un signe d’égalité entre l’histoire utilisateur et le cas d’utilisation :

• Agile = histoire utilisateur ou Agile = histoire utilisateur + Scrum
• Histoire utilisateur = juste-assez & juste-à-temps
• Histoire utilisateur = répondre aux attentes de l’utilisateur & satisfaisant
• Cas d’utilisation = capture détaillée des exigences préalables
• Cas d’utilisation = <<inclure>> + <<étendre>> = décomposition fonctionnelle
• Le cas d’utilisation est un style « entrée utilisateur » → « réponse système » uniquement
• Cas d’utilisation = style ancien & obsolète

En tant que fournisseur d’outils, nous restons assez neutres en matière de méthodes, outils et techniques. Personnellement, je tiens à souligner clairement que je suis un grand partisan du développement agile, des histoires utilisateur et du processus Scrum. En particulier, les principes fondamentaux et les meilleures pratiques liés à des concepts tels que :

• Découverte des exigences plutôt que livraison des exigences
• Dans le cadre du principe ci-dessus, deux propriétés importantes émergent dans le processus de développement agile
  • Juste-à-temps
  • Juste-assez

(Je rédigerai d’autres articles sur les principes ci-dessus avec mes propres opinions, qui sont étroitement liés à mon domaine de recherche de thèse entre 1992 et 1995 – métamodèles et transformations de schémas)

Maintenant, revenons au sujet « cas d’utilisation vs histoire utilisateur ». Les grands sages de l’agilité ont déjà rendu leur verdict, suis-je si entêté que je cherche à contredire leur « vote » en affirmant qu’ils sont similaires, voire identiques ?

Laissez-moi vous montrer un exemple pour illustrer si l’histoire utilisateur est vraiment « si différente » du cas d’utilisation :

Exemple

Les bons récits utilisateur sont bien plus que de simples énoncés. Un récit utilisateur standard se compose de trois parties, couramment appelées les trois C.

La première « C » de chaque récit utilisateur doit suivre le format standardisé de :

En tant que [rôle], je veux [faire quelque chose], afin que [avantages]

ce qui constitue le contenu minimal d’un récit utilisateur à insérer sur la carte.

Les conversations constituent le contenu de la deuxième « C » d’un récit utilisateur, qui représente la discussion entre les utilisateurs finaux, le propriétaire du projet et l’équipe de développement. Dans ces échanges, on enregistre les discussions orales ou d’autres informations utiles telles que des courriels, des maquettes ou tout autre contenu connexe au projet.

La dernière « C » d’un récit utilisateur est la confirmation, qui correspond aux critères d’acceptation utilisés pour vérifier que le récit utilisateur a été correctement mis en œuvre et livré avec succès.

Permettez-moi d’approfondir un peu plus la manière de développer la partie confirmation d’un récit utilisateur. 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 un récit utilisateur :

• (Étant donné.. et) un contexte
• (Lorsque.. et) une action est effectuée
• (Alors.. et) Effectuer certaines actions

Des outils tels que Cucumber et les frameworks de test 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, indépendamment de l’outil utilisé.

Examinons ensemble toutes les informations relatives au récit utilisateur « s’inscrire à un cours » et plaçons-les dans le format 3C :

J’ai adopté le format 3C couramment utilisé pour représenter le récit utilisateur « s’inscrire à un cours ». De même, j’ai également adopté le format le plus répandu pour décrire le même cas d’utilisation « s’inscrire à un cours », tel qu’élaboré dans une description de cas d’utilisation. J’ai numéroté les étapes de la section de confirmation (la dernière C) du récit utilisateur, en lien avec le numéro d’étape que j’ai indiqué dans la description du cas d’utilisation. Il s’agit des mêmes « neuf étapes » du scénario, à placer dans chaque approche selon un ordre différent. Je pense que les deux représentations de modèle sont acceptables pour leurs auteurs respectifs et leurs adeptes. Ensuite, la question se pose à nouveau : le récit utilisateur est-il très similaire au cas d’utilisation, tout en étant différent, ou est-ce l’ordre des étapes qui suscite toutes sortes de critiques à l’égard de l’approche des cas d’utilisation ?

Équivalent sémantiquement, mais avec un sens différent ?

Examinons s’il existe un cas similaire dans le domaine de la modélisation, afin de comparer cette situation, ou cela pourrait nous aider à formuler notre propre avis sur « récit utilisateur vs cas d’utilisation », sans pour autant suivre aveuglément la foule ou répéter comme un perroquet ce que les sages ont dit.

Exemple : Équivalent sémantiquement

Dans UML, nous pouvons décrire un scénario de cas d’utilisation à l’aide d’un diagramme de séquence, mais nous n’utilisons généralement pas un diagramme de collaboration à la même fin ; même si les deux diagrammes sont sémantiquement équivalents. Autrement dit, à la fois le diagramme de séquence et le diagramme de collaboration impliquent le même nombre d’objets participant à un scénario, avec le même nombre de messages échangés entre le même ensemble d’objets pour accomplir une tâche dans un scénario. Toutefois, le premier est centré sur le temps, tandis que le second est centré 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 convient mieux à la modélisation des relations structurelles entre objets. Par exemple, si vous souhaitez représenter de manière structurée le scénario des objets impliqués dans un cadre MVC (couches modèle/vue et contrôle).

Personnellement, je ne pense pas que l’utilisation de récits utilisateur fasse de mon équipe une équipe agile, ni que l’utilisation de cas d’utilisation la rende « précoce ». Ce qui est le plus important, c’est la manière dont nous appliquons et utilisons ces outils, avec quel état d’esprit et quels meilleures pratiques derrière. Je ne suis pas trop inquiet que les gens me considèrent comme « old style » ou dépassé alors que je suis en réalité agile dans mes actions.

Je me souviens encore des jours de l’analyse et de la conception structurées, peut-être pouvions-nous utiliser le type de données abstrait dans ADA pour appliquer les principes d’analyse et de conception orientés objet sans le soutien du POO dans les années 1980, n’est-ce pas ? Malheureusement, vous pourriez même ne jamais rencontrer les concepts de type de données abstrait ! Oh ! Mon Dieu, j’ai accidentellement révélé – suis-je vieux ? Ou devrais-je penser positivement – expérimenté ?