Dis-moi copain utilisateur...tu viens jouer avec moi?

Publié le par David Desfougeres

Les applications de mon écosystème obéissent à un système de versionning : c'est à dire qu'à des dates précises elles sont mises en production. Rassurons nous, nous tâchons de respecter le modèle "adaptation au changement plutot que le suivi d'un plan", à ceci près qu'une équipe projet peut être agile, mais que la ou les structures de support en amont ou en aval suivent d'autres règles.

Donc le dernier sprints est une phase de tests de validation. Je cherche à la rendre le plus possible une phase d'exploration par les utilisateurs, un sorte de pêche au feedbacks.

Au travers d'une série de 4 articles, je vais vous raconter leur déroulement ....

Pour cette étape d'UAT (User Acceptance Tests), je réunis un panel d'utilisateurs-testeurs, nos business owners (représentants métiers ou marketing), l'équipe de PO et surtout quelques-uns de nos développeurs dans une salle (ou plusieurs salles selon l'audience) dans une première étape "en présentiel" d'une à deux journées.

J'ai voulu ces journée "Agile", Alex Boutin avait insufflé l'initiative en lancement de notre transformation. C'est devenu une institution sur le projet. Nous la cherchons "Agile" donc et le plus fun possible ...

J'ai donc représenté 3 "jeux", qui sont plutôt une formalisation différente des process qu'un jeu à proprement parler, néanmoins je les présentent ainsi aux testeurs, et .

Ils sont au nombre de 3, voici le premier :

1er jeu : la traversée des tests

Dis-moi copain utilisateur...tu viens jouer avec moi?

L'objectif est de valider que les solutions répondent au besoins (le boulot des Bo) dans des IHM, des process et une ergonomie acceptable pour les utilisateurs (çà c'est ce que nous attendons des utilisateurs).

Les Product Owners préparent des cas de tests de validation globales des projets développés dans une release via une stratégie de tests et des scénarii qui rédigés de façon à ce qu'ils répondent aux 2 impératifs.

Au départ tous les scénarii sont résumés dans un format simplifié qui tient sur une page A4. On les place dans la colonne "A faire" d'un "scrum board" (jusqu'à 70 dans les bons jours), n'importe quel mur peut être squatté ! Chaque Carte test comporte aussi quelques places pour laisser aux utilisateurs le loisirs d'ajouter remarques,

La compléxité des test est laissée de coté pour le moment. L'équipe de testeurs ne s'engage donc pas (...mais c'est la prochaine étape, j'apporte des optimisations et de la nouveauté ... par touches uniquement, surtout quand elles s'attaquent à des fondements, des principes... n'oublions pas que je vais trop vite :) ). La priorisation se fait simplement : les fiches sont numérotées par ordre de priorité et sont affichées dans cet ordre

Donc, pas d'estimation, je connais par expérience le risque à ne pas tout faire durant le (ou les) jour(s) de tests en présentiel : en moyenne 95% des tests sont passés.

Les premières minutes sont consacrées au rappel des règles du premier jeu et au seul aspect logistique important : l'heure du repas, aucune autre contrainte!

Je demande aux testeurs de s'organiser en binômes et de prendre les tests comme bon leur semble (envie spécifiques de découvrir un sujet, impacts directs sur leurs activités, responsabilités projets etc ...).

C'est parti pour un sprint de tests qui dure la demie-journée.

Les tests sont ensuite passés, la "carte scénario" est déplacée en "En Cours" et y reste tant que l'activité n'est pas terminée. Le Dod de cette colonne "tous les tests réalisables sont passés", qu'ils soient KO ou OK. Les cartes KO sont identifiées comme bloquées, le retour (feedback, anomalie) est identifié sur la carte pour re-test après correction.

Lorsque une anomalie ou une question est à poser pour les tests : l'équipe de développement se mobilise pour analyser le problème et aussi (surtout) enregistrer le retour afin de pouvoir le reprendre plus tard. De plus les développeurs sur place font office de business Analysts, ils transfèrent les éléments au reste de l'équipe restée dans les bureaux, sur les environnements de dev (pas d'accès aujourd'hui sur les sites qui peuvent nous recevoir)

Mon rôle est l'animation de ces journées, la mise en place, la préparation. une sorte de G.O. De faire circuler les informations, de relier l'équipe de développements à distance, d'animer des rétros rapides en fin de demie-journée.

Les utlisateurs (qui ne sont pas tous les jours dans nos équipes scrum ou Kanban) peuvent toucher du doigt notre organisation scrum :

  • Tableau de management visuel et de suivi simple (celui du scrum)
  • Auto-organisation : chaque testeur et binome, mais aussi les BO, les PO qui testent ou prennent des informations
  • Les communications directes : les différents acteurs se rencontrent : les PO et BO
  • La notion d'amélioration continue via la prise en compte de Feedback sur l'organisation des journées

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

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

Commenter cet article