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

Commentaires

1. Le mercredi 03 octobre 2007, 21:28 par jc-QualityStreet

Je ne peux qu'aller dans votre sens ... c'est un peu notre combat de tous les jours (à nous autres ergonome :)): réfléchir en termes d'utilisateurs (profils), de buts et de tâches, et c'est ce que j'apprecie dans les "users stories".
Un rôle, un but; ça a l'air simple, ça l'est; on va à l'essentiel, c'est vrai mais cela suppose aussi un vrai travail de recueil et d'analyse du besoin.

Selon moi, la combinaison "user stories" / "Personas" est des plus pertinentes: ce sont des axes d'intervention majeurs pour l'Ergonome Agile (et oui, nos techniques d'intervention doivent selon moi évoluer pour répondre aux exigences de ces nouveaux contextes). Attention néanmoins à la façon de créer ces personas pas aussi simple qu'elle n'y parait, et au timing toujours assez serré pour le faire.

Et comme je le disais sur mon blog, la prochaine fois j'attaque les cubes et les posters : vous allez les aimer vos utilisateurs !!! :)

2. Le jeudi 11 octobre 2007, 18:30 par Pascal

Pour ma part, j'utilise la technique des use cases pour cela, et le concept d'acteur UML correspond bien à cette notion de profil ou rôle utilisateur. C'est pour cela qu'il est intéressant par exemple de distinguer Client et Visiteur comme acteurs d'un site marchand : ils n'auront pas les mêmes cas d'utilisation !
Pour plus de détails, regardez le chapitre 3 du livre UML 2 - Modéliser une application web, disponible en téléchargement sur le site d'Eyrolles : www.editions-eyrolles.com...

Pour la prochaine version, ajoute le même exemple fait avec des user stories et de personas. Les personas, ça permettrait probablement de segmenter le client en des rôles plus fins et d'identifier des stories supplémentaires. Claude