L’ergonomie dans les projets Agiles : bases méthodologiques
,Ce billet, librement inspiré de mon intervention sur ce même thème dans le cadre de l’AgileTour 2012 de Sophia Antipolis, vise à mettre en exergue les points de contacts mais également les aspects critiques de l’intégration de la démarche ergonomique au sein d’un projet Agile.
Les principes fondamentaux de l’Agilité : des points communs avec les bases de l’ergonomie
Lorsque l’on s’intéresse à la définition de la méthode Agile en étant ergonome on peut être surpris du nombre de points de contacts que ces deux « philosophies » montrent. Le manifeste officiel de l’Agilité, en effet, cite entre autre les aspects suivants :
- l’importance des échanges fréquents entre la MOA et les Développeurs et au sein de l’équipe des Développeurs
- le fait de tendre vers un produit d’excellence, autrement dit satisfaisant tant sur le plan technique que sur celui esthétique
- la simplicité et la volonté d’éviter « d’en faire trop », ce qui complexifie le produit au lieu de le rendre plus satisfaisant.
Ces principes sont très souvent mis en avant également par les ergonomes, qui tentent :
- d’améliorer la communication entre les personnes qui expriment un besoin (la Maîtrise d’Ouvrage, ou MOA, représentée par le « Product Owner » dans les projets Agiles de type Scrum) et celles qui essayent de le transformer en un logiciel (la Maîtrise d’Oeuvre, ou MOE, dont le leader agile prend le nom de Scrum Master),
- de coordonner le travail des Développeurs afin d’éviter les incohérences et le manque d’homogénéité des IHM et qui prônent la simplicité comme but ultime de tout artefact qui se veut utile, utilisable et satisfaisant.
De plus, la norme ISO 13407 d’abord et la 9241-210 par la suite ont décrit les vertus de la démarche itérative en termes d’ergonomie du produit fini. Les spirales de développement itératif permettent en effet de valider au fur et à mesure les écrans et les fonctionnalités produites, afin d’assurer la meilleure expérience utilisateur possible.
L’ergonomie agile en pratique
L’ergonomie et les méthodes Agiles semblent donc être parfaitement compatibles. Du moins en théorie, car dans la pratique ce n’est pas toujours le cas, car l’approche « centrée utilisateur » est une brique de compétences (et de contraintes) que les experts de l’Agilité n’ont pas l’habitude d’intégrer dans les projets. Cela risque donc de créer de l’entropie dans un système qui se doit d’être un mécanisme bien rodé et huilé, en raison de sa vitesse de production. Dans un « sprint » de 2 semaines, comment intégrer une approche ergonomique dans laquelle il faut plusieurs semaines pour mener un test utilisateurs en bonne et due forme ? Il est donc nécessaire de revoir nos fondamentaux, si l’on veut s’adapter au rythme de ce type de projets.
Mais la vitesse du sprint n’est pas le seul écueil que l’ergonome agile va rencontrer. L’un des principes de base de l’ergonomie d’une interface étant sa cohérence (dans la position des éléments d’un écrans à l’autre, dans les modalités d’interaction, etc), comment peut-on garantir cet aspect des IHM alors que le projet démarre sur un cahier des charges volontairement flou et (pire encore !) évolutif à souhait ?
Il est clair que l’ergonome agile doit être prêt à revoir sa copie (recommencer à zéro par exemple le travail fait sur l’enchaînement de certains écrans, lorsqu’il est bousculé par l’arrivée d’options supplémentaires qui en cassent la logique), ou, encore mieux, se garder quelques cartes à jouer en cas de besoin.
Par exemple, s’il soupçonne que de nouvelles fonctionnalités pourraient venir s’ajouter à celles existantes au cours du projet il a intérêt à maquetter des barres de navigation dans lesquelles il sera possible d’ajouter aisément des éléments sans devoir revoir l’organisation générale.
Product Owner, Scrum Master, Développeurs… et l’ergonome ?
Cette souplesse, ainsi que des temps de réaction dignes du Guinness des Records (lorsqu’on nous demande « peux-tu me maquetter cette fonctionnalité ? » la dead-line courante étant pour avant-hier), ne sont néanmoins pas suffisants pour garantir la prise en compte optimale de l’approche « centrée utilisateur ». Pour que les recommandations de l’ergonome soient prises en compte encore faut-il qu’il se sente à sa place, et que les autres acteurs du projet en reconnaissent la légitimité.
Le rôle de l’ergonome Agile
Généralement, dans mon expérience, les projets Agiles qui se sont bien passés en termes d’ergonomie des IHM sont ceux dans lesquels les ergonomes ont su/pu se positionner en tant que :
- AMOA (assistance à la maîtrise d’ouvrage) : passer d’une User Story (expression d’un besoin) à une liste de tâches utilisateur et par la suite à l’IHM qui va bien pour les représenter visuellement n’est pas chose aisée. Le rôle de l’ergonome est donc d’analyser le besoin de la MOA et de le traduire en solutions IHM viables (qui tiennent compte de la logique métier, mais également des compétences informatiques et des habitudes du public cible). L’ergonome va être ainsi un « facilitateur » dans l’expression du besoin
- AMOE (assistance à la maîtrise d’oeuvre) : les ergonomes produisent des maquettes (lorsqu’ils en ont le temps) et valident les écrans codés (lorsque les Développeurs ont pris des initiatives). Ils sont là pour conseiller, recadrer, proposer des alternatives et garantir non seulement que l’IHM est utilisable mais qu’elle correspond au besoin exprimé en amont. Dans ce sens, l’ergonome est une « interface », au sens premier du terme, autrement dit une « surface de contact entre deux systèmes qui fonctionnent différemment », qui facilite les échanges entre le monde « technique » et celui « fonctionnel », souvent peu à même de se comprendre.
La boîte à outils de l’ergonome agile
A la différence d’un projet « classique » de type waterfall ou cycle en V, l’ergonome agile devra choisir les techniques les plus adaptées aux spécificités de ce type d’organisation. Études en amont sur les usages, Personas ou d’autres approches très pertinentes et utiles mais excessivement « time consuming » ne feront donc pas partie de la boîte à outils de l’ergonome agile. A mon sens, dans un contexte agile, l’ergonome a besoin essentiellement de deux choses : son cerveau et un bon outil de maquettage.
L’ergonome agile doit faire preuve d’une énorme capacité d’observation (il aura peu d’occasions de voir des utilisateurs finaux, il faudra donc faire attention au moindre détail), d’analyse et de synthèse. Il n’aura que peu de temps pour plonger dans un domaine métier spécifique, en saisir l’unicité et les contraintes qui auront un impact en termes d’IHM (fonctions récurrentes, notion de tâches urgentes ou prioritaires, terminologie métier spécifique…).
Maquettage
Une fois la logique utilisateur saisie, il devra très rapidement proposer des IHM dans le cadre des user stories choisies pour chaque sprint. Pour cela, papier et crayon sont toujours de bons alliés, mais lorsque le volume d’écrans à produire est important et le besoin d’illustrer des cinématiques se fait sentir, mieux vaut se doter d’un outil de maquettage professionnel.
Le marché ne manque pas de bons candidats (et plusieurs experts d’ergonomie et UX font régulièrement des articles comparatifs à ce sujet), tous avec avantages et inconvénients. Il conviendra de choisir donc l’outil le plus adapté en fonction des caractéristiques de chaque projet.
Il y a plusieurs bonnes raisons pour se lancer dans du maquettage d’IHM, entre autre :
- car en absence de spécifications détaillées (comme le prévoit la méthode Agile) les maquettes sont un très bon support pour guider le travail des développeurs
- car elles permettent à l’ergonome de valider ses propres idées et hypothèses quant à l’agencement des écrans ou à la cinématique de la navigation
- car dans le cadre des revues de sprint avec la MOA elles permettent de valider l’ergonomie du produit en cours de conception.
Adapter la méthodologie de test utilisateurs
Ce dernier point est particulièrement important, et nous amène à aborder une autre spécificité de l’approche « centrée utilisateurs » agile : pour tout ergonome, l’étape de validation et de tests des IHM est un aspect cruciale du travail. Or, dans des contextes agiles, comment réaliser un « bon » test utilisateurs ? La contrainte de temps a déjà été évoquée, mais elle est doublée par une contrainte en termes d’utilisateurs.
En effet, la MOA est certes notre interlocuteur privilégié dans la compréhension du besoin et de l’univers métier du projet, mais souvent nos interlocuteurs ne sont pas vraiment les utilisateurs finaux. La MOA exprime un besoin fonctionnel, mais ne sera pas confrontée au quotidien au produit dont elle demande la réalisation : la différence en termes d’âge, habitudes, compétences et connaissances entre par exemple un représentant de la Marine Nationale et un opérateur sonar ou entre les commanditaires et les utilisateurs d’un nouveau réseau social sur Mobile sont importantes.
Cette différence entre MOA et utilisateur final est évidente dans beaucoup de projets, cependant dans le cas des projets agiles il est souvent difficile d’organiser des tests utilisateurs avec la « vraie » cible à cause du timing très serré. En revanche, les revues des Sprint sont d’excellentes occasions pour faire valider le travail réalisé en termes d’IHM, et il faut en profiter.
Alternative au test utilisateurs
Au lieu d’organiser un test utilisateurs « classique », il conviendra plutôt d’animer une partie de la réunion, consacrée aux aspects IHM, et y proposer notamment des activités permettant à la MOA de réagir face aux propositions faites.
Dans certaines revues il nous est arrivé par exemple d’imaginer plusieurs tâches (permettant de valider des user stories) et de les faire réaliser une à la fois par les différents représentants MOA, à tour de rôle, en demandant à chaque personne de verbaliser à haute voix ses réflexions et sa façon d’utiliser la maquette (il s’agissait de maquettes Axure, hautement interactives). Contrairement à une démo, ceci a permis d’obtenir certaines données « classiques » d’un test utilisateurs (clics, erreurs, remarques…) mais également de bénéficier des échanges et du débat que chaque tâche réalisée a suscité dans l’audience présente.
Vers une meilleure intégration de l’ergonome agile ?
L’ergonome peut et doit faire partie intégrante des processus Agiles (en utilisant juste une autre couleur de post-it dans les Scrums, peut être !). L’intégrer au mieux dans le processus permet d’optimiser les chances d’arriver à un résultat final satisfaisant en termes d’IHM et d’ergonomie.
Pour ce faire, il me semble nécessaire d’apporter quelques modifications à la méthodologie actuelle : opter pour des sprint de 3 ou 4 semaines lorsque des problématiques d’IHM sont présentes (et nécessitent d’être abordées) ou permettre à l’ergonome de travailler « en avance de phase », autrement dit sur les éléments du backlog qui seront traités par la suite.
En effet, s’il est autonome dans la conception des écrans (car il ne s’agit que de maquettes, sans intervention des développeurs), il peut tout à fait organiser son travail, voire arriver à le faire tester par des « vrais » utilisateurs finaux. Ceci permettra d’apporter à l’équipe technique des éléments IHM déjà validés lorsque le sprint concernant ces fonctionnalités démarrera.
Si vous avez des expériences (positives ou négatives) de projets Agiles avec une composante « ergonomie », n’hésitez pas à réagir et à commenter !
