12 bonnes pratiques compilées par Jeff Patton (la référence sur la question). 12 bonnes pratiques qui ont prouvées leur efficience avec de multiples équipes, dans de multiples entreprises et qui rejoignent dans les grandes lignes mon Manifeste pour une ergonomie agile, c’est rassurant :))
La traduction que j’en fais est toute personnelle et n’engage que moi; voici pour les puristes la version originale. Pour chaque bonne pratique, je vous livre un rapide commentaire et le niveau de priorité que personnellement je lui donne (Must / Should / Can / Won’t).
1 Faire partie de l’Equipe Métier « Product Owner » (Must)
Notre travail soutient le travail d’analse et de priorisation du Product Owner (projet en SCRUM) ou Client (projet en XP). Cela peut aller jusqu’à rédiger les User Stories et même endosser le rôle. Cela ne nuit pas à notre collaboration avec le Développement puisque dans les contextes agiles, c’est tous ensemble ! Dans l’un de mes derniers projets, nous avions une équipe Product Owner (parlant d’une seule voix) travaillant avec l’ergonome pour faciliter la compréhension, et la mise en contexte des User Stories; c’est pour moi la solution idéale.
2 Faire juste ce qu’il faut de Recherche Utilisateur et de modélisation au début du projet (Must)
Pas mal de chose peuvent être faites en Sprint 0 mais il faut aller à l’essentiel (Personas…), le sprint (= itération) se joue en effet sur queqlues semaines. On attend de nous de l’expertise. C’est aussi un vieux débat …
3 Morceler son travail de conception, ergo & design (Must)
On a pas le choix et ce n’est pas toujours facile. Sur les premières itérations, c’est même une vraie difficulté.
4 Travailler sur plusieurs modes à la fois (Must)
C’est un vrai challenge mais c’est aussi le plus exaltant.
Il nous faut travailler au cours d’une itération:
- en conception sur le contenu des itérations futures (+1, +2),
- en réaction et collaboration sur l’itération en cours avec les développeurs,
- en évaluation / Test du contenu de l’itération précédente (n-1).
C’est ce que j’aime dans l’Agilité.
5 Gagner du temps sur les stories techniquement complexes mais simples d’un point de vue Interface Utilisateur (Can)
C’est très contextuel; si ça peut être le cas, tant mieux.
6 Travailler avec un même panel d’utilisateurs pour une validation continue (Should)
Tout dépend du projet, tout dépend du panel. Si le panel est la cible, c’est l’idéal; sinon cela facilitera les choses. C’est aussi une façon d’amorcer le changement. Mais attention, toujours se garder un regard neuf à un moment ou un autre.
7 Effectuer des recherches Utilisateurs en parallèle sans impact sur le dév (Can)
C’est une question de temps et de moyens mais l’équipe et le projet peuvent réellement en bénéficier. Si ces recherches sont effectuées par des tiers, je dis oui, sinon par l’ergonome travaillant sur le projet, c’est difficile.
8 Profiter à fond du temps passé avec les utilisateurs (Should)
Oui mais dans la limite du raisonnable et ne pas oublier que cela nécessite de la préparation et un minimum d’analyse: tests, entretiens, questionnaires, tri de cartes, conception d’écrans … c’est vrai qu’on a plein de choses à leur faire faire.
9 Utiliser la méthode RITE (Can pour RITE / Must pour le feedback)
RITE (Rapid iterative testing and evaluation), pourquoi pas … mais recueillir le feedback et faire des Tests Utilisateurs est essentiel; des tests le plus souvent informels, avant tout rapides et réactifs quant aux résultats fournis. Feedback et adaptation, c’est le fondement de la démarche: les équipes ne vont pas nous attendre 3 semaines !
10 Faire du prototypage rapide (Must)
On est là pour ça. Papier, PPT, Tableau Blanc tout y passe. Cette activité doit restée source de valeur, toujours au plus juste et définie en fonction de ce qu’attendent les destinataires du travail produit.
11 Considérer le prototype comme une spécification (Can)
Cela nécessite pas mal d’aménagements, des équipes très proches et bien rôdées.
12 Devenir un facilitateur (Must)
C’est pour moi une évidence; c’est le futur de notre métier.
Très bon article qui décrit bien votre démarche, plus clairement finalement que vos articles plus généraux sur l’agilité (à mon sens).
Pour moi qui suis amené à faire du "DIY usability" comme disent les anglos saxons, faute de temps, de budget, et surtout de culture du client, les méthodes agiles telles que vous les présentez sont une bonne source d’inspiration.
Ca m’aide pour estimer un planning et budgétiser. Hélas, les méthodes les plus optimisées ne pourront jamais rien contre la pauvreté de culture ergonomique des dirigeants en France !