Entretien avec C. Aubry – « Agile, Scrum… et ergonomie »

Introduction

Nous nous intéressons depuis quelques temps à la relation entre agile et ergonomie.

Un premier entretien nous avait permis de dresser les bases de cette rencontre avec J.C. Grosjean. Depuis, nous avons approfondi la réflexion en nous focalisant sur Scrum une méthode agile très en vogue à l’heure actuelle.

Après quelques mois de pratique au sein de projets IT concrets, nous avons souhaité partager nos premières convictions avec Claude Aubry, l’un des experts français en matière de Scrum.

Ses réponses nous confortent dans les orientations prises dans nos projets.

La fiche de Claude Aubry

Claude-Aubry_vignette_portraitAuteur du premier livre Scrum rédigé en français : Scrum, le guide pratique de la méthode agile la plus populaire.

Expérience professionnelle : 
Claude est impliqué dans le développement de logiciels depuis 30 ans et a participé à de nombreux projets dans différents domaines (télécom, spatial, aéronautique, édition de logiciels, énergie, transport, secteur public, Web…). Après avoir été développeur en SSII, architecte logiciel et système, chef de projet, chef de produit, il est consultant indépendant depuis 1994, spécialisé dans le génie logiciel. Depuis 2005, il se consacre à Scrum et aux méthodes agiles. Il y a formé plus de 600 personnes et intervient régulièrement comme coach agile dans les entreprises.

Il est également professeur associé, à temps partiel, à l’université de Toulouse et président de l’association SigmaT dédiée à la promotion des méthodes agiles à Toulouse et dans les environs.

Il publie régulièrement sur son blog « Scrum, Agilité et Rock’n roll » qui est devenu une référence sur Scrum en France. Il a récemment participé à la traduction du livre « Kanban et Scrum, tirer le meilleur des deux » et publié l’article « Scrum et les changements pendant un sprint » sur Developpez.com.

Enfin, il est à l’origine d’IceScrum un logiciel Open Source dédié à Scrum et aux méthodes agiles, pour lequel il tient le rôle de Product Owner depuis plusieurs années.

Ergonomie et adaptation aux changements

L’ergonome apporte la connaissance précise de l’environnement et des utilisateurs. Cela facilite l’adaptation aux changements recherchée par Scrum.

Début de l’entretien

Bonjour M. Aubry. Pouvez-vous nous faire part de votre définition de l’agilité en quelques mots ?

L’Agilité est la capacité d’une organisation à créer de la valeur tout en s’adaptant à temps aux changements dans son environnement. Les principes et les valeurs agiles sont toutes recensées dans le manifeste agile. Plusieurs méthodes se réfèrent à ce manifeste considéré comme la référence des valeurs agiles.

(…)

Scrum est une de ces méthodes, la plus populaire d’entre elles. Mais quand je pratique Scrum, j’ajoute des pratiques agiles venant d’autres sources (XP, Kanban). Scrum doit probablement son succès à sa simplicité, elle est facile à partager avec peu de concepts. Elle présente l’illusion que c’est facile.

Entrons dans le vif du sujet : le lien entre Scrum et Ergonomie. 

La démarche ergonomique repose sur une analyse orientée utilisateur solide : identification des profils utilisateurs, des tâches et du contexte d’utilisation. Analyse qui va par la suite conditionner tous les choix de conception. 

Cela nous amène à la question suivante : lorsque le Product Owner définit le Backlog, les besoins des utilisateurs ont probablement été recensés. Nous pensons que l’ergonome doit travailler en amont avec le Product Owner avant la définition du Backlog. Quel est votre point de vue ?  

#1 QuickWin Garga

Ergonomie et définition du Backlog : l’ergonome doit travailler en amont avec le Product Owner avant la définition du Backlog

Oui tout à fait. L’ergonome travaille avec l’équipe avant le premier sprint et pendant les sprints suivants. Au moins les premiers. Le travail de l’ergonome facilite la définition du Backlog initial. Grâce à sa connaissance précise des tâches utilisateurs ainsi que leurs besoins, l’ergonome garantit une certaine concordance entre les User stories et les attentes des utilisateurs.

(…)

Ensuite, le travail plus détaillé doit être fait de façon itérative, à chaque sprint, et en avance de phase par rapport au reste de l’équipe. Ainsi l’équipe de développement disposera des maquettes associées aux cas fonctionnels identifiés.

Ergonomie = Approche holistique

L’approche holistique consiste à considérer une problématique dans sa globalité (environnement, outils, culture…). Les fonctionnalités proposées aux utilisateurs s’inscrivent dans cette approche. Elles répondent aux attentes et sont adaptés aux usages des utilisateurs.

En ergonomie, il est très important de s’assurer que la conception soit holistique. Avec Scrum, une fois l’analyse des besoins utilisateur réalisée on identifie des Features, puis on plonge directement au niveau du Backlog et des User Stories. Etant donné que l’on va très rapidement au niveau de la User Story, on risque d’une part de perdre la vue d’ensemble et d’autre part de faire des choix de conception lors d’un sprint qui auront un impact négatif à d’autres endroits lors d’autres sprints. Comment faire pour éviter ces risques ? 

Afin d’éviter que les choix faits au niveau d’une User story contredisent des choix faits précédemment, nous préconisons, tout comme en ergonomie, d’adopter une approche holistique. Il faut suivre la démarche itérative de Scrum : on ne détaille pas au niveau de la User story dès le début, mais seulement quand cette User story devient prioritaire. L’approche holistique, sur ce plan-là, s’arrête à la vision et aux features.

(…)

Je vous rappelle que dans Scrum il n’y a pas de phase d’analyse, mais une phase avant le premier sprint où il me parait souhaitable de définir les grandes lignes de l’IHM.

#2 QuickWin Garga

La technique du maquettage papier permet de dégrossir les interfaces avant le premier sprint et d’orienter les choix du Product Owner pour alimenter le Backlog initial.


Cela nous amène à une autre question : l’identification des problématiques ergonomiques ne peut se faire qu’en analysant l’ensemble du Backlog. Nous sommes convaincus qu’il faut prévoir un premier travail de maquettage papier pour dégrossir les interfaces (avant le premier sprint) et orienter les choix du Product Owner pour alimenter le Backlog initial. Qu’en pensez-vous ? 

Je suis d’accord avec vous. Sur IceScrum par exemple, dont je suis Product Owner, on fait depuis quelque temps des maquettes avec Balsamiq. C’est bien utile. Notamment lors de la phase de définition du Backlog.

A quel moment savons-nous que nous disposons d’un Backlog permettant d’entamer le premier sprint ? 

Quand le Backlog a suffisamment de User stories prêtes pour au moins le premier sprint. La signification de prêt pour une User story dépend de l’équipe (comme la signification de fini). En général, cela implique que la User story soit estimée, suffisamment petite pour tenir dans le sprint et suffisamment comprise par l’équipe pour être développée.

Afin de réduire les risques ergonomiques, nous pensons qu’il faut faire réaliser des revues de release par un ergonome ?

Cela doit être fait au fur et à mesure, pas uniquement lors des releases, mais également pendant les sprints.

Tests utilisateurs vs Tests de recette

Les tests utilisateurs ne servent pas à identifier les bugs ou à récolter les avis des utilisateurs mais à s’assurer de la qualité ergonomique du système proposé.

A chaque fin de release, il y a une étape User Feedback. Comment est-elle réalisée ? (choix des utilisateurs, représentativité des scénarii proposés aux utilisateurs, méthodologie d’évaluation, technique employée)

C’est à l’équipe de la définir. Le feed-back est sollicité lors de chaque revue de sprint. Je dis sprint, pas release. Puis il est de bon ton de laisser la version obtenue en fin de sprint – elle ne sera mise en production qu’à la fin de la release – à disposition d’utilisateurs privilégiés. Comment cela est mis en place dans le détail sort de mon domaine de compétence.

Si plusieurs User stories sont considérées lors d’un sprint, il semble intéressant de faire intervenir l’ergonome et les utilisateurs plusieurs fois dans une même release. Qu’en pensez-vous ? 

Je pense que c’est une approche tout à fait louable. Mais j’insiste vraiment pour systématiser le recours à l’ergonome et aux utilisateurs dans le même sprint. Pas uniquement au niveau de la release.

Intéressons-nous maintenant plus à Scrum et la gestion de projet. 

Dans Scrum, où sont intégrés les éléments propres à la gestion de projet : gestion des risques, assurance qualité, gestion des ressources… ?

La gestion des risques fait partie de l’approche, qui a pour objectif de réduire les risques dans les premiers sprints. La qualité aussi. Par contre la façon de les gérer (documentation, par exemple) est à l’appréciation de l’équipe, en fonction du contexte du projet et de l’organisation.

(…)

La polyvalence des équipes est un point crucial dans Scrum, cependant généralement on n’a pas vraiment le choix, on prend les personnes qui sont là.

Quelques dernières questions pour conclure : avez-vous des retours d’expérience de structures chez qui Scrum a bien fonctionné ?

#3 QuickWin Garga

La place de l’ergonome dans Scrum : l’ergonome se place en tant qu’expert au sein d’une équipe Scrum. Ainsi les membres de l’équipe peuvent faire appel à sa compétence pour des tâches spécifiques lors de sprints particuliers.

Il y en a énormément. De plus les conférences et séminaires sur Scrum et l’agilité accueillent de nombreux retours d’expérience positifs. Beaucoup d’exemples circulent sur la toile (vos lecteurs peuvent par exemple consulter les retours d’expériences publiés sur SigmaT).

Y a-t-il des types d’organisation dans lesquelles Scrum ne peut pas être implémentée ? 

Non. Il y a simplement des organisations où le changement est plus important.

Y a-t-il des profils de structure qui sont plus propices à l’application d’une démarche Scrum ? 

Tout à fait. Je le décris amplement dans mon récent livre.

M. Aubry, merci pour cet échange !