Les rôles impliqués dans les histoires d'utilisateur

Il n'y a pas que l'utilisateur et l'administrateur…

La découverte des histoires d’utilisateur[1], comme d’ailleurs celle des cas d’utilisation ou de toute autre technique, se fait en réfléchissant à ce qu’attendent les utilisateurs du logiciel. Il faut donc commencer par identifier ces utilisateurs,au sens large, du logiciel. Les cas d’utilisation utilisent le terme acteur, pour les histoires d’utilisateur on parle de rôle ou de type de rôle ou encore de rôle d’utilisateur.

Il faut être vigilant si on ne veut pas passer à côté de rôles importants, ce qui induira l’oubli d’histoires importantes. Je viens de faire l’expérience avec mes étudiants à qui j’ai demandé d’identifier des histoires d’utilisateur pour une application Web, sans les avoir poussés à réfléchir à cette notion de rôle : certains n’identifient que 2 rôles, l’utilisateur et l’administrateur, d’autres en trouvent un peu plus, probablement en réfléchissant à la solution qu’ils envisagent avec les droits qui seront associés aux rôles d’utilisateur.

Un bon conseil : il ne faut pas avoir un rôle qu’on appelle utilisateur, ce n’est pas assez précis, cela va confiner la réflexion à un seul point de vue. Le risque est d’oublier des histoires d’utilisateur et de faire que celles qu’on propose ne seront pas assez spécifiques du problème.

Les spécialistes des IHM, les ergonomes, les marketeurs du web le savent bien, il faut aller plus loin et penser aux usages.

Pour identifier les rôles, on peut s’inspirer des questions proposées dans OpenUp pour trouver les acteurs des cas d’utilisation :

  • qui fournira, utilisera ou supprimera les informations du système ?
  • qui utilisera le système ?
  • qui est intéressé par une fonction ou un service particulier fourni par le système ?
  • qui assurera le support et la maintenance du système ?
  • quelles sont les ressources externes du système ?
  • quels sont les autres systèmes qui ont besoin d’interagir avec le système en développement ?

Ces questions sont probablement trop axées sur le logiciel en développement, même si c’est système qui est employé dans OpenUp, et pas assez sur son environnement, mais peuvent aider à démarrer la collecte.

Dans un esprit de travail collectif, recommandé par les méthodes agiles, il est souhaitable de faire un brainstorming pour identifier le plus de rôles potentiels, puis de les regrouper. La réflexion en commun sur les caractéristiques de chaque rôle conservé, comme son environnement physique, le nombre d’utilisateurs représentés, leur niveau d’expertise du domaine, leur niveau informatique, les autres applications qu’ils utilisent, et d’autres caractéristiques générales telles que l’age, le sexe, le niveau, aide à consolider l’identification des bons rôles.

La technique des utilisateurs-types ou personas, peut aussi être employée, couplée à des enquêtes sur les comportements, notamment pour les applications Web. Je ne l’ai pas utilisée, je renvoie à ce qu’en dit Quality Street.

Pour compléter la liste, il ne faut pas oublier de penser aux personnes mal intentionnées qui chercheront à profiter abusivement du logiciel, par exemple les trolls et les spammeurs, car il faudra probablement ajouter des histoires d’utilisateur spécialement pour les empêcher. Il peut aussi y avoir des histoires d’utilisateur qui ne sont pas associées à un quelconque utilisateur, ce qui est paradoxal : il faudrait peut-être leur trouver un autre nom ?

Notes

[1] user stories

Voir aussi