Copain utilisateur...tu continues le jeu ??

Publié le par David Desfougeres

La vocation de l'UAT est donc, non seulement de trouver ses vilains méchants bugs dissimulés dans les coins noirs de l'application mais aussi (et surtout, car Agile ou pas le taux de bug sur mon application principale est très faible ...merci aux développeurs) de faire émerger des axes d'améliorations, de petites évolutions que nous appelons "Feedbacks".

Notre commando d'experts fonctionnels et techniques se compose des Business Owner, des Product Owners, du Scrum Master et de quelques développeurs : tous sont prêts à venir au secours des utilisateurs en perdition face aux incompréhensions : le cas de tests n'est pas passant, la donnée de tests est erronée ... le comportement attendu n'est pas celui visible à l'IHM.

Selon le niveau du problème, l'éclaireur BO ou PO part au-devant de l'équipe de dev en support et analyse.

Une fois l'analyse effectuée : le développeur rédige conjointement avec l'utilisateur, selon un exemple bien établi, un document papier (si si :) ) qui résume les détails du retour.

Le développeur rédige la fiche pour s'assurer que tous les éléments nécessaires à la reproduction (a postériori) du problème sont présents.

Dès lors, le 2e jeu commence ... la traversée des feedbacks :

Copain utilisateur...tu continues le jeu ??

Puis la feuille est scotchée au mur dans la première colonne d'un tableau qui retrace l'ensemble des étapes que va parcourir cette traversée ..jusqu’à ce que son développement soit mis à disposition dans l'environnement de tests.

Afin de nous rapprocher de nos acteurs clés, nos UAT sont délocalisées. L’équipe de dev et des Po est en Bretagne, nous migrons quelques jours aux abords de la capitale.

Seuls certains développeurs sont donc présents sur site de l’UAT, il faut donc passer les infos recueillies à ceux qui sont restés et qui vont démarrer les corrections. Pour se faire, une copie de la fiche papier est enregistrée dans un outil collaboratif.

Nous en utilisons déjà un pour suivre les développements et gérer notre flux de gestion de suivi opérationnel, les étapes de murissement des besoins etc ...C’est leanKit que j’avais choisi au démarrage de notre activité kanban : Nous rendons un tableau accessible sous l'application (www.leankit.com)

L'UAT sur site dure deux jours maximum, beaucoup de remontées sont faites : seuls les bugs avérés sont prioritaires (et potentiellement certains feedbacks urgents) et donc les corrections prises en charge automatiquement (en kanban : c'est une règle simple de priorisation et d'injection).

Les étapes du processus sont résumées et simplifiées pour le tableau à l’usage des utilisateurs : Saisie, Backlog des anomalies priorisées, Developpements, Tests) mais le kanban « réèl » est beaucoup plus complet. Les cartes sont déplacées sur le mur en fonction de l'avancée des développements jusqu'à la mise à disposition dans l'environnement de tests mis à jour.

Si vous en avez la capacité, faites mettre à jour l'environnement de tests pendant l'heure du repas, puis avertissez négligemment pendant le café que certains bugs sont corrigés ...l'effet est garanti ... nos utilisateurs sont loin de problématique IT ...

Board initialisé
Board initialisé

Ce jeu permet aux utilisateurs d'être en contact avec les enjeux de Kanban :

  • Affichage d'un processus plus élaboré que le précédent
  • Mise en visibilité des goulots d'étranglement.
  • Définition des règles de priorisation claires
  • Partage de notion de "Definition of Done" et de "Definition of ready"
  • Initialisation d'un flux tiré.
  • Autonomie & Auto-organisation des testeurs (pour la validation des corrections dès lors que la fiche est dans la colonne "A tester")

Publié dans scrum, tests, utilisateur, UAT, REX

Pour être informé des derniers articles, inscrivez vous :

Commenter cet article